| Proposal for semantic constraints for usage of GML elements [message #3811] |
Thu, 04 December 2025 13:03  |
Marharyta Vyskarka
Messages: 21 Registered: April 2025
|
Junior Member |
|
|
Hello everyone,
As I have been working on visualization in railVIVID I noticed an issue with how to interpret functional infrastructure data that is described with multiple GML locations and their elements, and I think some semantic constraints can help with that. In this post I will focus on <lineString> and <point> elements.
As you may know in railML 3.1 and 3.2 it was possible to use multiple <lineString> and <point> elements within the <gmlLocations>. For elements that use <areaLocation> it makes sense, since these coordinates can be aggregated, and by that I mean all the coordinates can be used to determine the outline of the area, etc. However multiple <lineString> would only make sense within a linear element if they are describing the same location in different coordinate systems.
So I propose IS:029:
"<lineString> elements that are defined more than once within the same <gmlLocations> element of a parent functional infrastructure element that used <linearLocation> and belongs to the microscopic level of the infrastructure description must have different EPSG code for each such <lineString>"
For similar reason I also propose IS:030 for spot elements:
"<point> elements that are defined more than once within the same <gmlLocations> element of a parent functional infrastructure element that used <spotLocation> and belongs to the microscopic level of the infrastructure description must have different EPSG code for each such <point>"
Let me know what you think.
Best regards,
Margo Vyskarka
Marharyta Vyskarka – Software Developer
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|