The axis order of coordinates is part of the definition of a coordinate reference system (CRS). Some are defined as (longitude, latitude), others as (latitude, longitude). GML respects this order. In [geometricCoordinate](https://wiki3.railml.org/wiki/RTM:spotLocation:geometricCoordinate), the order of the x, y and z attributes were not documented in railML 3.1. In 3.2 since SR2 and in 3.3 since its first release, they are documented as x = longitude, y = latitude and z = altitude. There are some issues with this documentation: 1. The examples on our wiki page [Geographic positioning of functional infrastructure](https://wiki3.railml.org/wiki/Geographic_positioning_of_functional_infrastructure) and railVIVID follow the order of coordinates defined by the CRS, not the attribute documentation. This was also one of the two natural interpretations before the attribute documentation was added. 1. Longitude and latitude are angular measurements and only apply to ellipsoidal CRSs. Cartesian CRSs, such as UTM don't have longitude and latitude. Given that the most common cartesian CRSs (in Europe) use easting and northing, we could change the documentation to x = easting / longitude and y = northing / latitude. 1. But not all cartesian CRSs use easting and northing. For instance, some use southing and westing. We could add these as well. There are also polar and geocentrical coordinate systems, mostly using axes X and Y or E and N without further naming. These are probably very rare in a railML context and would naturally map to the already provided options. 1. EPSG has coordinate systems where axes are explicitly named x and y but where x means northing/southing and y means easting/westing. This could cause some ambiguity whether you should follow the name or the abbreviation. I do not know how commonly used these are. I see two possible approaches: - A: we adapt the documentation to - x: longitude / easting / westing - y: latitude / northing / southing - Pros: similar to current documentation, same component (e.g. north) always found in the same place, easy mapping from/to datasets also using fixed order - B: we follow the CRS order - x: first coordinate of the CRS - y: second coordinate of the CRS - Pros: same as GML, same as railVIVID, same as CRS definition, easy mapping from/to datasets also using CRS order **Additional consideration: required/optional coordinates** As pointed out by @coordination.IS in the forum: What do we do with CRS that define a height information only? With approach A it is coordinate z (and x and y are empty). With approach B it is coordinate x (and y and z are empty). x and y are currently required, while z is optional. Since geometricCoordinate currently require x and y (while z is optional), such coordinates are currently excluded. (They are supported by gmlLocation, and a use case was demonstrated at the Madrid conference.) With approach A all attributes must be optional, but with approach B we can require at least one coordinate (x) to avoid an empty element. ## Links * Forum discussion: * Thomas Nygreen, 04.09.2026: https://www.railml.org/forum/index.php?t=msg&th=1181&goto=4157&#msg_4157 * Gitlab workitems: * #788 * Wiki documentation: * RTM:spotLocation:geometricCoordinate: https://wiki3.railml.org/wiki/RTM:spotLocation:geometricCoordinate