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