| 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
|
|
|
|
| Re: Proposal for semantic constraints for usage of GML elements [message #3812 is a reply to message #3811] |
Fri, 05 December 2025 00:00  |
Mathias Vanden Auweele
Messages: 86
Registered: February 2025
Location: Brussels
|
Member |
|
|
Hi Margo,
Thank you for sharing your thoughts and proposals--they raise an important discussion point. I see the intention behind IS:029 and IS:030, but I have a slightly different perspective.
From my understanding, the current railML specification and XSD schema do not strictly associate GML locations with topology. For example, the geometry of a Signal in GML doesn't necessarily have to represent its exact position on the track (or whatever lateral offset was given to it's linear coordinate) , nor does it have to be a single point. It could just as well be a lineString extending from the signal's center toward its application direction, or even other representations depending on the use case.
Similarly, an operational point might include both spotLocations (reference points) and areaLocations (application areas). Its GML could describe parcel contours, a center point, building outlines, or even multiple lineStrings for platform edges.
Before introducing semantic constraints, I think it would help to clarify the intended role of GML locations. For example: that it needs to be topology related. But if that is the case, then I would propose to consider making the GMLLocation a subelement of the Location element. At present, railML only requires that GML locations relate to the element in some way and support geographic visualization, without imposing strict topological constraints. Furthermore, what about situations where elements both have spot/linear/area locations? As my example for the OP.
In general, this is higly conceptual question as I've already discussed with ERA. You can consider the GMLLocation synonymous with geosparql "Feature".
In the ERA vocabulary there is this image:
As you can see, there are 3 subclass relationships to 'Feature' and each of them represents a different view for a railway asset related element.
1) The NetElement as a Feature would be the GIS location of NetElements as you know them in railML. So this would be equivalent to having a GMLLocation element inside a <netelement>. Since ERA only works on the micro topology, this would be the track center axis for linear netelements.
2) InfrastructureElement as a Feature would be the GIS location of the asset independent on the topology. A signal would be placed with its centerpoint where it is effectively installed. For an OP, this would be a polygon of the area or a centerpoint.
3) The NetBasicReference as a Feature would be the GIS location of the topological effect of the InfrastructureElement. So when you put this on the map, you will have an overlay on top of the NetElement Feature.
So railML should first decide which approach is meant with the current GML location before you can set these rules. And if it's more meant like ERA's point 3, then I would propose to move the GML as a subelement of the Location. Then the semantic rules will also make more sense and will be easier to verify.
Best regards,
Mathias
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
| Re: Proposal for semantic constraints for usage of GML elements [message #3814 is a reply to message #3812] |
Fri, 05 December 2025 15:20 |
Thomas Nygreen
Messages: 110
Registered: March 2008
|
Senior Member |
|
|
Dear Margo,
I agree with Mathias that GML locations are not connected to the topology or to the other *Locations provided.
If we need such a semantic constraint, we would also need it for the other *Locations. It is also currently valid to provide multiple *Locations with different geometric coordinates in the same CRS.
Another detail is that the srsName is not necessarily an EPSG code, although EPSG is the most commonly used database of CRSs, so unless we also introduce a requirement that the srsName must provide an EPSG code, we should use srsName in the wording of any constraint.
I am sceptical towards moving GML locations as they are into the other *Locations, because the other *Locations already provide geometric coordinates. The GML location currently offer two things that the other *Locations do not: (1) a geometric coordinate independent of the topology and (2) the lineString. If we decide that we do not want (1), we can maybe remove GML locations and offer a lineString as an alternative to geometricCoordinateBegin/geometricCoordinateEnd.
Best regards,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
[Updated on: Tue, 09 December 2025 14:12] Report message to a moderator |
|
|
|
| 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: 213
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
|
|
|
|
| Re: Proposal for semantic constraints for usage of GML elements [message #3827 is a reply to message #3825] |
Tue, 09 December 2025 14:40 |
Marharyta Vyskarka
Messages: 21
Registered: April 2025
|
Junior Member |
|
|
Hello everyone,
Thank you for your input. I also agree that we need to find a way to define how we should interpret GML locations. Part of the goal of defining these constraints is to bring more clarity to our interpretation and to make the usage of GML elements also make sense with other *locations, so I agree with Milan regarding the usage of multiple <gmlLocations> elements for different representations.
Also thank you, Mathias, for pointing out the usage of multiple different RTM locations within an element, which was not properly considered in initial wording of the proposed constraints. Based on your feedback the definition of such constraints definitely would need improvement, on which we will work on once we can reach the conclusion regarding the intent of GML locations.
As for the topic of srsName and EPSG code, Thomas, this is actually a topic we were already planning to discuss. We would need to have a separate conversation about it, so we could also define it's usage.
Best regards,
Margo
Marharyta Vyskarka – Software Developer
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
