Airy59
commented
2 months ago My 2 cents:
-
first cent: introducing class NetworkResource evokes the corresponding class in RSM. Purpose of NetworkResource is to describe all resources that are necessary and sufficient to describe a network. These are subsumed under two disjoint classes: NetEntities (broadly equivalent to InfrastructureObject) and NetElements and relations (Topology). A Network refers an aggregate of network resources which completely defines it. An Infra object is definitely managed by an IM, and arguably, a net element (even though abstract) is also managed by an IM that is responsible for its lifecycle, its associated geometry, etc. Recommendation: please consider including topological objects into network resources (as a subclass).
-
second cent: I disagree on Infra objects not having a geometry of their own. Of course, the primary geometry is the one borne by linear elements (at micro level at least). Every infra object can then be located on (mapped to) the topology. On the other hand, you may want to identify a platform by providing the corresponding polygon (bird's eye view). The geo description of the platform might originate from taking BIM info in local coordinates (not part of RINF) and then projecting into some geo coordinate system, sooner or later, if only for a user-driendly presentation: see for instance what OpenStreetMap is doing. Recommendation: keep the former setup; infra object geometry is not topology geometry.
Further comment: topology geometry might be "frozen" (see for instance ETCS configuration data) while observed track geometry may vary, e.g. when replacing a switch. You may then see the topology-linked geometry as a spec and the actual geometry as, well, the actual one. They are expected to match within some tolerances, but they are not the same thing.
gatemezing
marinaaguadocastrillo
I see an issue in having the era:InfrastructureObject as a subclass of era:Feature, while at the same time era:BaseLocation inherits the GeoSPARQL information.
The reasoning is that there should be only one place to describe the geographical information and, in my opinion, the topological layer is this place. The topology layer is the backbone of the railway infrastructure representation, on top of which comes the technical characteristics description.
The proposal would be to keep era:InfrastructureObject as a subclass of era:NetworkResource and add the object property era:validity relation between era:NetworkResource and era:TemporalFeature. Highlighted colors are:
With this approach, we avoid having the provision of geo coordinates as information for both topology and implementation of the same physical railway object.