| [railML3] Proposing new @epsgCode for <geometricPositioningSystem> [message #3898] |
Tue, 17 February 2026 11:38  |
Marharyta Vyskarka
Messages: 23
Registered: April 2025
|
Junior Member |
|
|
Hello everyone,
We have been taking an extensive look at the attributes related to the reference systems. It was noticed that there are multiple such attributes between railML 2 and 3. For example, railML 2 has <geoCoord>/@epsgCode [1], railML 3 has @srsName (in such elements: <lineString> [2], <posList> [3],<point> [4], <pos> [5]) and <geometricPositioningSystem>/@crsDefinition [6].
It is also worth to note that the mentioned attributes have different types of data (xs:anyURI and xs:string), which doesn't put many restrictions on the expected data. Both of these options allow such values as "4326", "EPSG:4326", "urn:ogc:def:crs:EPSG::4326", "urn:ogc:def:crs:EPSG:9.8.7:4326", "https://www.opengis.net/def/crs/EPSG/0/4326".
To bring more clarity and to be consistent we wanted to propose replacing @crsDefinition [6] by a new attribute @epsgCode (xs:int) in railML 3.4. This proposal is based on the idea that the EPSG code was intended by the previous crsDefinition, and that making it just a code instead of a relative URI would make it more uniform, removing ambiguity. I also want to note that @srsName would stay the same, as it is part of GML, and we cannot change it.
Therefore I want to ask, does anyone use anything else other than EPSG for @crsDefinition? Are there any other concerns regarding such change?
[1] https://wiki2.railml.org/wiki/IS:geoCoord
[2] https://wiki3.railml.org/wiki/IS:lineString
[3] https://wiki3.railml.org/wiki/GML4RAILML:posList
[4] https://wiki3.railml.org/wiki/IS:point
[5] https://wiki3.railml.org/wiki/GML4RAILML:pos
[6] https://wiki3.railml.org/wiki/RTM:geometricPositioningSystem
Best regards,
Margo Vyskarka
Marharyta Vyskarka – Software Developer
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
[Updated on: Thu, 26 February 2026 17:33] Report message to a moderator |
|
|
|
| Re: [railml3] Proposing new @epsgCode for <geometricPositioningSystem> [message #3903 is a reply to message #3898] |
Sun, 22 February 2026 11:52  |
Mathias Vanden Auweele
Messages: 97
Registered: February 2025
Location: Brussels
|
Member |
|
|
Hello Marharyta,
I'm not sure I think it's a good idea to go from @crsDefinition to @epsgCode because of the loss of functionality:
- no possibility to reference non-epsg CRS (probably not a very big problem but I was planning on using this in the future for a more schematic representation of the network)
- no longer dereferenceable, I really like the use of URI's instead of ints and strings... Makes it much easier to really understand what you are reading
- axis order... just the EPSG will need the data consumer to assume axis ordering.. OGC:CRS84 (lon/lat) vs EPSG:4326 (lat/lon). Although there is a lot of confusion about this and some implementations are not doing it correctly
- from memory, there is also something about the vertical axis
I did some research about this a while ago and my conclusion is to prefer URI's. It also seems strange to have GML on the one side that uses srsName and then a simple epsgcode on the other side.
I don't think I would agree with this statement: "This proposal is based on the idea that the EPSG code was intended by the previous crsDefinition". I know several people that have developed RTM and I don't think that they would have chosen crsDefinition if they meant to use EPSG code. So for me, that's really intentional.
Although I would very much agree on a more strick set of possible values for the crsDefinition. I would force the use of URI's and disallow the use of strings such as EPSG:4326
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
| Re: [railml3] Proposing new @epsgCode for <geometricPositioningSystem> [message #3913 is a reply to message #3903] |
Wed, 25 February 2026 18:15 |
Milan Wölke
Messages: 217
Registered: April 2007
|
Senior Member |
|
|
Hi Mathias,
The problem is, that URI is not a URL. So your example of EPSG:4326 is an URI but it doesn't help you understanding the way the coordinates are formed. The idea of using a simple int is to work around this, so that an importer can decide if he can work with the coordinates or not. After all the vast majority of systems will only support a limited set of coordinate systems that is specifically implemented. Converting CH1903 or DB_REF to WGS84 is not always straight-forward.
The problem with the string or URI approach is that not even the format of the URI is standardized. You can indicate usage of WGS84 with an URI like this: EPSG:4326 or like this: urn:ogc:def:crs:EPSG::4326. I have also seen sth like this: https://spatialreference.org/ref/epsg/4326/projjson.json
When implementing an importer I think the only thing you can do is to use a regular expression, and that is probably not exactly safe.
Does this make sense to you, or am I overlooking something here?
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
| Re: [railml3] Proposing new @epsgCode for <geometricPositioningSystem> [message #3915 is a reply to message #3914] |
Thu, 26 February 2026 12:13 |
Milan Wölke
Messages: 217
Registered: April 2007
|
Senior Member |
|
|
Hi Mathias,
so what you are trying to say is, that you would only allow URIs that point to valid OGC WTK definitions? Because otherwise the software supplier would not just need to be specific about what CRS is used in the software but also about the way it is indicated.
BTW, I wouldn't use trivial when the actual reprojection that is necessary for the conversion is not part of the project you are referencing (at least as far as I could see at a first glance).
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
[Updated on: Thu, 26 February 2026 12:15] Report message to a moderator |
|
|
|
| Re: [railml3] Proposing new @epsgCode for <geometricPositioningSystem> [message #3916 is a reply to message #3915] |
Sat, 28 February 2026 00:51 |
Mathias Vanden Auweele
Messages: 97
Registered: February 2025
Location: Brussels
|
Member |
|
|
Hi Milan,
No, I would allow all URI's for CRS in railML. And then it's up to the software vendor to specify which URI CRS's he supports. And he could say that he supports all http://www.opengis.net/def/crs/ URI's for example. Or only WGS84 or UTM32.
I would definitely also allow custom URI's so that railML providers can use their own coordinate system URI and request software vendors to support them by providing them with the required information to do so.
I haven't had any issues with conversions between coordinate systems (for OGC defined ones), but I might not understand what coordinate systems that you are referring to. For my yasgui fork, it happens on the fly from any coordinate system: https://shorter.matdata.eu/w
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
Members
Search
Help
Login
Home
