| 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: 235
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
|
|
|
|
Search
Help
Members
Login
Home
