Question

What is/are the default (X,Y) coordinate order conventions in FME (particularly in relation to the 'Lat/Long vs Long/Lat discussion')?


Badge +3

Like described in the header, In short I'm wondering what the default (X,Y) coordinate order conventions are in FME (particularly in relation to the 'Lat/Long vs Long/Lat discussion')?

 

Reason/motivation of the question

The reason I'm asking is that in quite some workspaces I prompt users to enter an extent for a particular area (mainly to filter out data for the user defined area). Recently a user asked me if it was possible to incorporate an option to also allow the input extent to be entered by means of explicit Bounding Box (BBOX) coordinates in the form of a specific envelope, i.e. to enter both the (Xmin, Ymin) AND the (Xmax, Ymax) coordinates.

Of course these explicit coordinates are meaningless without knowing how to interpret them (i.e. without knowing the underlying coordinate system). In the Netherlands it turns out that the vast majority of spatial files make use of the 'RDNew coordinate system' (EPSG:28992). However, I also wanted to give users the option to enter coordinates that they find in google maps, which makes use of the 'LL-WGS84 coordinate system' (EPSG:4326).

 

Lat/Long vs Long/Lat discussion

It is at this point in time that I stumbled upon the 'Lat/Long vs Long/Lat discussion'. For more info on this I found a suggested link in the Documentation of CoordinateSwapper transformer. Unfortunately, this underlying page was no longer online, but using the Internet Archive: Wayback Machine, I managed to open a http://gisconsultancy.com/blog/microsoft/what%E2%80%99s-your-lat-long" target="_blank">stored version of this particular link. Some particular information here I found that:

"The problem seems to stem from the widely held assumption that ‘What is your Lat Long?’ is the same question as ‘What is your XY?’

However, Latitude is a measure of distance from the equator, so it’s really more analogous to the distance Y in a planar model; likewise, Longitude is a measure of distance from the Prime Meridian and is therefore analogous to the distance X in a planar model. So ‘What is your XY?’ in a flat earth model, is really more comparable to the question ‘What is your Long Lat?’ in a round earth model. "

Lastly, while I was dealing with this issue/discrepancy I also read the following page of gisgeography that seems te explain that this is the 'most natural coordinate order':

"lines of longitude have X-coordinates between -180 and +180 degrees" and "lines of latitudes have Y-values that are between -90 and +90 degrees"

So in short, it seems that the most natural coordinate order convention would be (X,Y):= (Longitude, Latitude). Fortunately this is also the order that seems to be used by FME. Unfortunately it seems that different applications make use of different coordinate order conventions, and e.g. google (at least in google maps) seems to make use of the unnatural coordinate order convention (X,Y):= (Latitude, Longitude) (see also example in comments to this item to the reply of redgeographics).

 

'Discrepancy' in the definitions of the coordinate order between different applications; (X,Y):= (Longitude, Latitude) (in the above claimed as the 'natural definition') OR (Y,X):= (Latitude, Longitude)

When I was working on my particular workspace I seemed to have found that there is a discrepancy in the coordinate order definition of FME and Google Maps. In short FME seems to use the 'natural coordinate order definition' (X,Y):= (Longitude, Latitude), whereas Google Maps uses the 'unnatural coordinate order definition' (X,Y):= (Latitude, Longitude). See also the example I specified at one of the comments below this item (from redgeographics).

 

Main question and subquestion

This all led me to the main question; What is/are the default (X,Y) coordinate order conventions in FME?

One particular subquestion I'm having is whether all of the predefined coordinate systems in FME that make use of the 'LL projection' are making use of the 'natural coordinate order definition' of (X,Y):= (Longitude, Latitude).

 

More confusion; my own search for an answer to the subquestion

On a first try to answer the above subquestion myself, I found the 'coordsys.db' file in the FME installation folder (as described in the FME Coordinate Systems documentation, n.b. the file actually turns out to be a CSV file that makes use of '|' as its delimiter (and without a header). What I found is that quite many of the coordinate systems that make use of the LL Projection, have some tag of 'Latitude/Longitude' in its description. See also below;

 

However, to add to the confusion, as described above (and below in a comment to redgeographics), it seems that mentioning 'Latitude/Longitude' is just common practice in how to speak about LL coordinates, whereas FME actually handles the first (i.e. X) coordinate as the Longtitude, and the second (i.e. Y) coordinate as the Latitude.

What I don't know however is whether this is true for all of the predefined coordinate systems in FME that make use of the LL projection, or just for my testcase where I made use of the 'LL-WGS84 coordinate system' (EPSG:4326). It would be nice if this can be verified/confirmed.

 

My current idea for a workaround

If it is true that the FME engine has a fixed build in structure for the coordinate order convention (as I strongly expect), it will be easier for me to know for which of the specified coordinate systems it is neccessary to apply the CoordinateSwapper transformer before using the 2DBoxReplacer transformer, and for which of the transformers this isn't neccessary.

Right now I request users to enter the BBOX coordinate envelope in the coordinate order convention (X,Y):= (Longitude, Latitude) (in case of a LL projected coordinate system). If in short the answer to my subquestion is 'Yes', I may for instance assume to always the swap coordinates when the specified coordinate system is of the 'LL projection' kind, and to keep the original coordinate order in any other case. N.b. based on the units of the predefined coordinate systems in FME, it seems a valid assumption that (nearly) all non LL projected coordinate systems will be of the 'Orthogonal (X,Y)' kind:

 


14 replies

Badge +10
FME's 'discrepancy' on the seemingly commonly used natural order (X,Y):= (Longitude, Latitude) When I was working on my particular workspace I seemed to have found that FME doesn't comply to this seemingly commonly used natural order, and instead makes use of the coordinate order convention (X,Y):= (Latitude,Longitude) (at least it seems to do so in e.g. the 2DBoxReplacer and the BoundsExtractor). Also upon investigating a bit further (see items below) this seems to be the case.

Are you sure? I've never seen that behaviour

Userlevel 4
Badge +25

I agree with @ebygomm, I've never seen the behaviour you're describing. Can you provide a test workspace that shows this?

Userlevel 4

I agree with @ebygomm, I've never seen the behaviour you're describing. Can you provide a test workspace that shows this?

+1 for me as well

Userlevel 4

Could it be that your users have different notions of whether X means northing or easting?

For more details: https://gis.stackexchange.com/a/99862

Perhaps consider not only asking for "X", but asking for "X (easting)" to make it clear what you expect.

Badge +3

I agree with @ebygomm, I've never seen the behaviour you're describing. Can you provide a test workspace that shows this?

Thanks for the quick feedback. Happy to admit that I seem to have been wrong in the sense that FME seems to use the (by the sources claimed) 'Natural coordinate order' (X,Y):=(Longitude, Latitude), whereas Google maps uses the 'nonnatural coordinate order' (X,Y):=(Latitude, Longitude). I'll change this in the tekst above, and will add an example shortly

Badge +3

Could it be that your users have different notions of whether X means northing or easting?

For more details: https://gis.stackexchange.com/a/99862

Perhaps consider not only asking for "X", but asking for "X (easting)" to make it clear what you expect.

Hi @david_r,

This exactly dives into the root of the question. It seems that different platforms seem to use different notations of whether X means Latitude or Longitude (and conversely whether Y means Longitude or Latitude) (and on a bit more eleborate note whether it e.g. means northing or easting, which implicitly also concerns the 'positive number direction', i.e. the left-handed or right-handed systems). For me as a mathematician this is quite confusing... :O

By means of an errata things seems to be the other way around than I originally described; FME seems to use the naturally (claimed) definition of X:= Longitude, Y:= Latitude, and Google Maps seems to use the nonnatural definition of X:= Latitude and Y:= Longitude.

N.b. what adds to the confusion for me is that the description of the LL coordinate systems in FME often contain a tag like 'Lat/Long' or 'Latitude-Longitude', whereas internally (again by means of errata of my earlier post), the first coordinate (i.e. X) seems to be handled in FME as Longitude, and the second coordinate (i.e. Y) seems to be handled in FME as Latitude. It would make more sense to me when the order in the description and the order in which they are handled would match.

 

In regards to how to ask coordinates from users;

It would be natural for users to copy paste coordinates from google maps into FME, but as the coordinate order definitions are the other way around, either the user has to manually swap the latitude and longitude order, or this has to be done in FME. I would like to take this stress away from users, but then at least I need to know whether the definition of X:= Longitude and Y:= Latitude is the same for ALL of the predefined coordinate systems in FME. Can this be confirmed?

Userlevel 4
Badge +25

Hi @david_r,

This exactly dives into the root of the question. It seems that different platforms seem to use different notations of whether X means Latitude or Longitude (and conversely whether Y means Longitude or Latitude) (and on a bit more eleborate note whether it e.g. means northing or easting, which implicitly also concerns the 'positive number direction', i.e. the left-handed or right-handed systems). For me as a mathematician this is quite confusing... :O

By means of an errata things seems to be the other way around than I originally described; FME seems to use the naturally (claimed) definition of X:= Longitude, Y:= Latitude, and Google Maps seems to use the nonnatural definition of X:= Latitude and Y:= Longitude.

N.b. what adds to the confusion for me is that the description of the LL coordinate systems in FME often contain a tag like 'Lat/Long' or 'Latitude-Longitude', whereas internally (again by means of errata of my earlier post), the first coordinate (i.e. X) seems to be handled in FME as Longitude, and the second coordinate (i.e. Y) seems to be handled in FME as Latitude. It would make more sense to me when the order in the description and the order in which they are handled would match.

 

In regards to how to ask coordinates from users;

It would be natural for users to copy paste coordinates from google maps into FME, but as the coordinate order definitions are the other way around, either the user has to manually swap the latitude and longitude order, or this has to be done in FME. I would like to take this stress away from users, but then at least I need to know whether the definition of X:= Longitude and Y:= Latitude is the same for ALL of the predefined coordinate systems in FME. Can this be confirmed?

Wouldn't it be better to simply not rely on the user typing or pasting anything but letting them draw a shape on a map? I understand that may be tricky on FME Desktop, but depending on what you want to do FME Server or Cloud may be better suited.

You could add some logic to this as well, assuming you only need to support Netherlands RD and WGS84 lat/lon coordinates (yes, I know, we say lat/lon but it really should be lon/lat), you know that within The Netherlands the X coordinate in RD is always smaller than the Y. Same goes for the WGS84 coordinates.

As far as I know FME always assumes the first coordinate to be X and the second to be Y (and a potential third to be Z). But that is coming from personal experience and I have not had to work with each and every supported coordinate system.

Out of curiousity, what are you planning to do that requires you to have to know this for all predefined coordinate systems?

Badge +3

I agree with @ebygomm, I've never seen the behaviour you're describing. Can you provide a test workspace that shows this?

Hereby the promised example. I hope the location is familiar ;)

See the following example of google maps with (X,Y):= (51.6466836, 4.6099576):

One can verify (see e.g. north and east identifiers to the left of the second picture), that this actually matches the nonnatural coordinate order definition (X,Y):= (Latitude, Longitude).

When using a VertexCreator transformer in FME (while using the LL-WGS84 coordinate system), while setting (X,Y):= (51.6466836, 4.6099576), I obtain;

However, when I swap the coordinates, (e.g. by using a CoordinateSwapper transformer), I do obtain the desired result;

 

So in this case FME seems to use the natural coordinate order definition (X,Y):= (Longitude, Latitude), whereas google maps sees to use the nonnatural coordinate order definition (X,Y):= (Latitude, Longitude).

 

See also the following workspace;

Example_coordinate_order_(X,Y)-(Longtitude,Latitude)_Google_Maps_vs_FME.fmw

Userlevel 4
Badge +25

Hereby the promised example. I hope the location is familiar ;)

See the following example of google maps with (X,Y):= (51.6466836, 4.6099576):

One can verify (see e.g. north and east identifiers to the left of the second picture), that this actually matches the nonnatural coordinate order definition (X,Y):= (Latitude, Longitude).

When using a VertexCreator transformer in FME (while using the LL-WGS84 coordinate system), while setting (X,Y):= (51.6466836, 4.6099576), I obtain;

However, when I swap the coordinates, (e.g. by using a CoordinateSwapper transformer), I do obtain the desired result;

 

So in this case FME seems to use the natural coordinate order definition (X,Y):= (Longitude, Latitude), whereas google maps sees to use the nonnatural coordinate order definition (X,Y):= (Latitude, Longitude).

 

See also the following workspace;

Example_coordinate_order_(X,Y)-(Longtitude,Latitude)_Google_Maps_vs_FME.fmw

I may have been at that location, yes :)

Google does have a bit of a history of doing their own thing in this regard (back when I was still doing coding on top of the Google Maps API they actually swapped the coordinate order between two API versions...)

Even more reason to try to rely as little as possible on users manually typing in coordinates. Take a look at this example, which lets users draw a polygon on a web map and then sends that as a WKT string to FME. Even if you don't go all-in with FME Server you could set up a simple webpage for your users that outputs that WKT string and then have them paste that into FME Desktop.

Badge +10

Hereby the promised example. I hope the location is familiar ;)

See the following example of google maps with (X,Y):= (51.6466836, 4.6099576):

One can verify (see e.g. north and east identifiers to the left of the second picture), that this actually matches the nonnatural coordinate order definition (X,Y):= (Latitude, Longitude).

When using a VertexCreator transformer in FME (while using the LL-WGS84 coordinate system), while setting (X,Y):= (51.6466836, 4.6099576), I obtain;

However, when I swap the coordinates, (e.g. by using a CoordinateSwapper transformer), I do obtain the desired result;

 

So in this case FME seems to use the natural coordinate order definition (X,Y):= (Longitude, Latitude), whereas google maps sees to use the nonnatural coordinate order definition (X,Y):= (Latitude, Longitude).

 

See also the following workspace;

Example_coordinate_order_(X,Y)-(Longtitude,Latitude)_Google_Maps_vs_FME.fmw

Whilst ESPG 4326 requires that input coordinates are specified in order as lat/lon it doesn't follow that lat = X and lon = Y

Userlevel 4

Hereby the promised example. I hope the location is familiar ;)

See the following example of google maps with (X,Y):= (51.6466836, 4.6099576):

One can verify (see e.g. north and east identifiers to the left of the second picture), that this actually matches the nonnatural coordinate order definition (X,Y):= (Latitude, Longitude).

When using a VertexCreator transformer in FME (while using the LL-WGS84 coordinate system), while setting (X,Y):= (51.6466836, 4.6099576), I obtain;

However, when I swap the coordinates, (e.g. by using a CoordinateSwapper transformer), I do obtain the desired result;

 

So in this case FME seems to use the natural coordinate order definition (X,Y):= (Longitude, Latitude), whereas google maps sees to use the nonnatural coordinate order definition (X,Y):= (Latitude, Longitude).

 

See also the following workspace;

Example_coordinate_order_(X,Y)-(Longtitude,Latitude)_Google_Maps_vs_FME.fmw

The VertexCreator (as far as I know) does not take any coordinate system into account, it will simply create a geometric point at a give position, where "X" is assumed to be the easting and "Y" is assumed to be the northing, in whatever coordinate system you are. In my world, that is also the expectation in 99% of the datasets I work with (ESRI, Oracle, SQLServer, PostGIS, you name it).

As a workspace developer, the consequence is that somewhere, somehow, you will have to assume something about the input given by the users. If you have a fairly limited range of valid coordinates, it might be possible to detect this automatically simply by checking if the result is within range or not. Of course, if this is not feasible you need to look into other solutions, e.g. as suggested by @redgeographics.

Badge +3

Wouldn't it be better to simply not rely on the user typing or pasting anything but letting them draw a shape on a map? I understand that may be tricky on FME Desktop, but depending on what you want to do FME Server or Cloud may be better suited.

You could add some logic to this as well, assuming you only need to support Netherlands RD and WGS84 lat/lon coordinates (yes, I know, we say lat/lon but it really should be lon/lat), you know that within The Netherlands the X coordinate in RD is always smaller than the Y. Same goes for the WGS84 coordinates.

As far as I know FME always assumes the first coordinate to be X and the second to be Y (and a potential third to be Z). But that is coming from personal experience and I have not had to work with each and every supported coordinate system.

Out of curiousity, what are you planning to do that requires you to have to know this for all predefined coordinate systems?

Thanks for the reply. Of course it would be nice if users could draw a shape on a map (live). However, I don't know how to build/make the neccessary 'web plugin' for this. Of course I started from the easy way of allowing users to enter a file with their shape (e.g. shapefile, dwg, gml, etc.). After that a user asked whether it would be possible to also enter this through min/max BBOX coordinates, because the application he was using already shows these coordinates by means of 'grid tags', and otherwise he would have to open a GIS/CAD application to draw the shape there and create an export.

 

I get your ideas for the built in logic, and I already build in some tests to see whether manually entered coordinates to comply to these kind of checks, and whether the resulting BBOX is actually within range of the 'allowed extent' for the translation.

 

For me I like to make the workspace as generic as it can be, so therefore initially I wanted to allow users to be allowed to enter files/coordinates in any of the predifined FME coordinate systems. However, in that case I need to know whether the same rules/conditions on coordinate order apply in FME for all of the LL projected coordinate systems. Besides that I'm also always interested to find out the inner workings/meanings of things (including FME) :)

Badge +3
FME's 'discrepancy' on the seemingly commonly used natural order (X,Y):= (Longitude, Latitude) When I was working on my particular workspace I seemed to have found that FME doesn't comply to this seemingly commonly used natural order, and instead makes use of the coordinate order convention (X,Y):= (Latitude,Longitude) (at least it seems to do so in e.g. the 2DBoxReplacer and the BoundsExtractor). Also upon investigating a bit further (see items below) this seems to be the case.

Are you sure? I've never seen that behaviour

Thanks for the reply. As mentioned in the other comments I'm happy to admit that I seem to have been wrong in this initial claim. Sorry for the confusion. Actually things seem to be the other way around, in the sense that FME seems to use the (by the sources claimed) 'Natural coordinate order' (X,Y):=(Longitude, Latitude), whereas Google maps uses the 'nonnatural coordinate order' (X,Y):=(Latitude, Longitude).

Badge +3

A few weeks back I again came across situation, what in the end seems to be linked to the Lat/Long vs Long/Lat conventions. I remembered I already opened a community question about it before, so I would like to add an addendum to this.

 

I was converting some data on boreholes to INSPIRE datasets. My Borehole had a point geometry, and its coordinates made use of the coordinate system EPSG:4258. Looking at the data in FME's data inspector, all was well, and the Feature Information window depicted the coordinates as: 6.81131977, 53.16301199 (Longitude, Latitude). Also on the background map it showed up where I would expect it (in the province of Groningen of the Netherlands):

imageThen I used a GeometryExtractor to extract the Geometry as a GML Encoding, and that resulted into (I manually set the URL for the srsName in the GeometryExtractor):

<gml:Point srsName="http://www.opengis.net/def/crs/EPSG/0/4258" srsDimension="2">
<gml:pos>6.81131977 53.16301199</gml:pos>
</gml:Point>

I used this GML geometry encoding for my INSPIRE GML dataset. Then, when I opened my INSPIRE GML in FME's data inspector, the feature information window showed me the coordinates:

53.16301199, 6.81131977 (Longitude, Latitude), and it showed up in the sea to the east of Africa:

imageIt turns out that upon reading FME uses '2,1' (swapped coordinates) by default for the GML SRS Axis Order, when using this coordinate system.

Furthermore I noticed that for other GML datasets that use EPSG:28992 for the coordinate system, FME uses '1,2' by default for the GML SRS Axis order. 

 

Upon checking I found that there is actually some documentation for the default GML SRS Axis Order in the GML Reader. See the following:

"For WFS 1.0, the value is assumed to be 1,2. For WFS 1.1.0 and 2.0.0, the SRS order is determined by the SRS specified. For example, the default axis order for EPSG:4326 is 2,1.

If the srsName in the GML document is set to urn:ogc:def:crs:EPSG:6.6.4326, and you know that the coordinate order in the GML document is lon-lat and not lat-lon order, set this parameter to 1,2 so that the reader reads the data in lon-lat order."

 

Looking a bit further, I found the following interesting question on Stack Overflow: gps - Lat Long or Long Lat - Stack Overflow. See below on the most quoted anwer there:

You are correct, there is no universal standard on the order:

In mathematical functions which do an universal conversion, between x,y or lon,lat or inverse, the lon,lat order should be used, because the x-axis relates to longitude and y to latitude and the x,y order is usually preferred.

Further, if you program a piece of code which is related to draw a lon,lat coordinate on x,y coordinates (screen), I also would use the lon,lat order because of the direct relation to x,y.

 

It seems FME uses this convention/advise, i.e. depicting geodetic coordinates in the order Longitude, Latitude. However, it turns out that there is also an ISO 6709 document about this, which uses a different convention (first Latitude, then Longitude). For ISO 6709 it is indicated that:

It describes that a geographical point is specified by the following four items:

  • a first horizontal coordinate (y), such as latitude
  • a second horizontal coordinate (x), such as longitude
  • optionally, a vertical coordinate, i.e. height or depth
  • optionally, an identification of the coordinate reference system (CRS)

 

 

Also, if I look at Table 1 of the INSPIRE Data Specification on Coordinate Reference Systems – Technical Guidelines

Coordinate reference system = 2D geodetic in ETRS89 on GRS80 (Latitude, Longitude)

Short name = ETRS89-GRS80

http URI identifier = http://www.opengis.net/def/crs/EPSG/0/4258

 

So in conclusion;

Although to me the most natural definition seems to be to use Longitude, Latitude for the default SRS Axis order (like also adopted by FME), because on 2D screens the 'x-axis relates to longitude and y to latitude', the SRS Axis order of Latitude, Longitude seems to have a more formal status and seems to be more widespread used (Like in Google maps, INSPIRE guidelines, ISO 6709. Furthermore, the EPSG:4258 page of EPSG.io also lists 'Latitude, Longitude' for the axis.

 

That is probably also the reason why FME uses '2,1' as the default GML SRS Axis Order when reading a GML dataset with a long/lat coordinate system such as EPSG:4258.

So maybe something to be aware of when creating or reading GML datasets that make use of a long/lat coordinate system. Especially since in a GML geometry encoding such as

<gml:Point srsName="http://www.opengis.net/def/crs/EPSG/0/4258" srsDimension="2">
<gml:pos>6.81131977 53.16301199</gml:pos>
</gml:Point>

there is no definition/reference to how the coordinates should be interpreted (i.e. if the coordinates are listed as Long/Lat or Lat/Long). Note that you could use the optional 'axisLabels' attribute in your GML encoding to provide some clarity on the mattter. However, these are just optional labels, and provide no formal definition for applications to pick up. So I guess you will always need to check how your application expects/handles long/lat coordinates...

 

Reply