# Esri x and y coordinate confusión

I am trying to figure out which coordinate system x and y are in and trying to understand the data from the Esri site.

datasource: DATA

In the data each FID represents a Polyline, the coordinate is in the geometry attribute. Sometimes the first given value (0 -> 0,1) represents the stating point of the line, and some times x0 and x1 gets inverter, the dame happend to y0 and y1.

For example:

FID: 124

``````0:{0:142239, 1:104776}
1:{0:-1345, 1:2253}
``````

The 1 represents the difference between origin and next point.

When you represent the data, it should be displayed as:

``````0:{0:142239, 1:109282}
1:{0:-1345, 1:-2253}
``````

FID: 127

``````0:{0:142239, 1:104776}
1:{0:-13221, 1:3123}
``````

The 1 represents the difference between origin and next point.

When you represent the data, it should be displayed as:

``````0:{0:140894, 1:107029}
1:{0:-13221, 1:-3123}
``````

Another thing, which coordinate system x and y are this data in? FID: 124 origin is supposed to be nearby: 18.929 -70.358 FID: 127 origin is supposed to be nearby: 18.909,-70.370

• Look at the layer metadata, at the level above, which reports "Spatial Reference: 102100 (3857)". The units in Web Mercator are nominally "meters" but actually of no particular meaning. Tiny values near the origin keep you on Null Island. Feb 25 at 3:32
• And if you request geojson (`f=pgeojson`) instead of Esri json (`f=json`), you'll get lon, lat in EPSG:4326 i.stack.imgur.com/zahOk.png Feb 25 at 7:06
• @user2856 Thanks for your help. How did you manage to organize the data? I noticed that the dataset got from the 'f=pgeojson' refered to EPSG:3857 and the data seems to be lat and lot inverter, and the decimal point misplaced. Feb 26 at 19:44
• No, the data returned from that query is in EPSG:4326 not EPSG:3857. i.e. latitude and longitude (Y, X) in decimal degrees. The coordinates are reversed as that is the correct axis order for EPSG:4326 and there is no misplacement of decimal point, the coordinates are decimal degrees not metres. If you read it as GeoJSON, i.e use a library that understands GeoJSON you don't need to worry about that. Feb 26 at 20:12