| Re: Proposal for semantic constraints for usage of GML elements [message #3825 is a reply to message #3814] |
Tue, 09 December 2025 13:49   |
Milan Wölke
Messages: 217
Registered: April 2007
|
Senior Member |
|
|
Hi all,
I agree that we need to define what the gml data is supposed to encode in railML. My current understanding would probably mostly align with option 2 of Mathias. I would still think that the proposed semcons would help to structure the multitude of options when describing where a functional infrastructure element is located.
Just to add this to the discussion as I got the feeling this is not considered yet, it is possible to repeat the gmlLocations element. That means that it is still possible to have multiple lineString with the same srsName for the same functional infrastructure element with these semcons active. From my point of view this would bring the usage of of gmlLocations closer to the usage of area-, linear-, and spotLocations. If you have a parallel description of a location you can provide that in another element. Same applies for example for areaLocation. If you have an operational point that is defined on micro and meso level (with the op spanning over multiple meso netElements) then you would need two areaLocations to encode this. One for the micro representation and one for the meso. Both representations would exist side by side describing the same object. The same would apply for gmlLocations. Each gmlLocations element would contain one semantic aspect, possible in multiply coordinate systems (srsNames).
My 3 cents.
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
