| [railML3.3] xs:choice between linearCoordinate and geometricCoordinate [message #3596] |
Mon, 28 April 2025 11:14  |
Mathias Vanden Auweele
Messages: 85
Registered: February 2025
Location: Brussels
|
Member |
|
|
Hello all,
Since v3.3, a SpotLocation or LinearLocation can only contain LinearCoordinates or GeometricCoordinates.
This means that if we want to supply both LinearCoordinates and GeometricCoordinates for a NetEntity, we'll need to create 2 SpotLocations with the same IntrinsicCoordinate and other attributes. This effectively changes the conceptual meaning of SpotLocation to one that is specifically tied to a PositioningSystem.
What was the reason for this chance?
This seems wasteful and a possible source for mistakes. Can we roll this back in the next version (or preferably, even doing a bugfix on the 3.3 version)?
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
[Updated on: Mon, 28 April 2025 11:16] Report message to a moderator |
|
|
|
| Re: [railML3.3] xs:choice between linearCoordinate and geometricCoordinate [message #3597 is a reply to message #3596] |
Mon, 28 April 2025 13:41  |
Morten Torstensen
Messages: 4
Registered: October 2023
Location: Oslo, Norway
|
Junior Member |
|
|
A spotLocation is a single spot that can be referred to using many different coordinate systems. As you can have many geometric positioning systems and many linear positioning systems, you should be able to model it in the same spotLocation.
I am not sure what the reasoning was to only allow a single positioning element for a spotLocation? Happy to be enlightened.
Morten Torstensen
Bane NOR - Norwegian Infrastructure Manager
Digital Information Model for railway infrastructure
Ontology, modeling, mapping
|
|
|
|
| Re: [railML3.3] xs:choice between linearCoordinate and geometricCoordinate [message #3699 is a reply to message #3597] |
Fri, 22 August 2025 14:41 |
christian.rahmig
Messages: 529
Registered: January 2016
|
Senior Member |
|
|
Dear Mathias and Morten,
thank you for bringing up this topic and sorry for my late reply. I finally looked at the situation in schemas railML 3.2 and railML 3.3:
In 3.2 you can define both, a linearCoordinate and a geometricCoordinate for one spotLocation. In 3.3 you have to choose between them.
Well, both implementations are far away from being perfect. For example, you cannot model two linear coordinates (with different linear coordinate systems) for one spotLocation...
From my perspective, we have two possible solutions:
a) Allow for only one coordinate instance within one spotLocation element (which actually is the solution with railML 3.3)
b) Allow for multiple linear or geometric coordinate instances within one spotLocation
Of course, each solution need to be adapted to linearLocation and areaLocation accordingly to provide a consistent schema.
Dear beloved railML infrastructure community: which solution do you prefer?
As usual, any kind of feedback is highly appreciated...
Best regards
Christian
PS: Until this issue is solved, the way to model one infrastructure element location with several different coordinates, is to model several spotLocation child elements for this infrastructure element...
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3.3] xs:choice between linearCoordinate and geometricCoordinate [message #3701 is a reply to message #3699] |
Mon, 25 August 2025 11:28 |
Rémi Collet
Messages: 12
Registered: November 2024
|
Junior Member |
|
|
What we all agree upon is that a given LocatedNetEntity is truly unique, and has one physical manifestation. We also agree that this physical manifestation can be located on multiple coordinate systems.
Digressing a little bit now. A given LocatedNetEntity could have a spotLocation as well as an areaLocation (e.g.). For example a signal post is, for all intents and purposes, a dot on any 2D map. But zooming in, we could argue that it would make sense to make it an areaLocation. If we are zooming to that level of detail, then it makes sense that the spotLocation and areaLocation perhaps do not share the same coordinate system, since the latter has to be much more precise than the former.
To me, then, it makes more sense to attach the Location and the coordinate system together (be it linear or geometric). So option (a).
This is also the view that is currently standard @ OGC with the geo:Feature ( https://opengeospatial.github.io/ogc-geosparql/geosparql11/d ocument.html#_a42db74e-d071-2ecd-6de6-3919edd15d40) and geo:Geometry ( https://opengeospatial.github.io/ogc-geosparql/geosparql11/d ocument.html#_159f457b-0368-4953-5bd2-82f574779d5b) pair, linked together with the geo:hasGeometry property ( https://opengeospatial.github.io/ogc-geosparql/geosparql11/d ocument.html#_c086d794-1dde-e889-393c-325f441a3963). This pair greatly resembles the LocatedNetEntity & EntityLocation pair.
With (b), we posit that a LocatedNetEntity has only one spotLocation, but that location can be represented in different coordinate systems. In a way, we move the concept of the "truly unique, one physical manifestation" to the EntityLocation, which I am less in favour of.
All that being said, perhaps I am wrong, and perhaps I misunderstood the OGC standard. I would be happy to be corrected if that was the case !
Ontologist @Infrabel (Belgian Railway Infrastructure Manager)
remicollet(at)infrabelbe
|
|
|
|
| Re: [railML3.3] xs:choice between linearCoordinate and geometricCoordinate [message #3705 is a reply to message #3701] |
Thu, 28 August 2025 15:00 |
Mathias Vanden Auweele
Messages: 85
Registered: February 2025
Location: Brussels
|
Member |
|
|
@Christian: I would prefer option b.
A '(spot)Location' is unique in terms of the topology and can be linked to multiple different coordinates systems. So one '(spot)Location' and multiple 'coordinate instances'. This is much more in line with how RTM was conceived.
@Remi: I think the comparison "geo:Feature" <=> "rtm:BaseLocation" is more appropriate then "geo:Feature" <=> "rtm:NetEntity". Because a physical object is a rtm:NetEntity and can have multiple 'rtm:BaseLocations'. A physical object, can also have multiple "geo:Feature".
A geo:Feature is a mapping feature and can depend on context, so it doesn't necessary align 1 to 1 with a physical object in the same way as the rtm:BaseLocation. But I have always been somewhat troubled with comparing RTM with OGC. RTM also covers aggregation which is not a need for OGC.
Besides, geosparql perfectly allows you to have one Geometry with multiple coordinate systems. There is no limit to the number of geo:asWKT properties. So in that sense, even when you are correct to assume "geo:Feature" is like "rtm:NetEntity", then a "rtm:BaseLocation" is like "geo:Geometry" and should allow multiple coordinates (which would only make sense...) with different coordinate systems :)
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
|
|
|
|
Members
Search
Help
Login
Home
