European Commission logo
INSPIRE Community Forum

TransportProperty issue

DESCRIPTION:

•FormOfWay is a featureType.
•FormOfWay is a subclass of TransportProperty and then is a subclass of NetworkProperty
•On the other hand, RoadLink is a featureType as well.
•RoadLink is a subclass of TransportLink and then is a subclass of Link and then is a subclass of GeneralisedLink and NetworkElement.
 
•NetworkProperty has an attribute networkRef:

+networkRef: NetworkReference[1..*]

•NetworkReference has a relation  with NetworkElement.

•So this is the way to establish a relation between FormOfWay and RoadLink.
 
THE PROBLEM
•In Spain we have more than 9M of RoadLinks so we have two options:
–To define 1 FormOfWay feature for each RoadLink (9M of FormOfWay features)
–To define 15 FormOfWay features (1 bicycleRoad, 1 freeway, 1 walkway,…) with thousands of references to RoadLinks  
 
THE QUESTIONS
•What should we have to implement? Millions of FormOfWay features or 15 FormOfWay features with thousands of references?
•What happened with other TransportProperty (RoadWidth, SpeedLimit, RoadName,…)?
  • Dominique LAURENT

    By Dominique LAURENT

    In IGN France, we have chosen first option: millions of FormOfWay features (or other properties) with single reference to the related RoadLink.

    As unique identifier, we use:

    - namespace: the same as for RoadLink or other features in sub-theme TN road ("FR.IGN. BDUNIGE. RoadTransportNetwork....")

    - localId : property title  (e.g. "FormOfway") + local identifier of the  related RoadLink.

    To be honnest, it was  a "natural" choice; we haven't considered the second option and assessed the benefits/drawbacks of each alternative.

    My guess is that our solution is nevertheless the best one: when querying a TN property, users would probably be more interested to get the properties related with the RoadLinks within the geographic extend  (e.g. Bounding box) of interest rather than getting all the RoadLinks related to the property FormOfway  (or to a specific value of it).

    However, of course, we are not very happy with this solution that makes the INSPIRE TN data quite complex : in source data, we model properties as attributes directly attached to the Tra 

    but there is no way to escape from the INSPIRE data models  complexity, due to linear referencing principles.

     In my  point of view, at least, the "core" properties should be defined as attributes of RoadLinks (or of RoadNode or of Road) and not as separate feature types.

     

     

     

     

     

     

  • Michael LUTZ

    I think, the general idea for the linear referncing approach used in INSPIRE lies somewhere in the middle, i.e. a Transport property can be linked to more than one transport link. This is more obvious for properties like road name, where you could link one property feature (e.g. the "E 40") to all the links that make up the E40. Also speed limits could apply to more than one road link (or parts of them). For the form of way, this is probably a bit less obvious.

    In terms of use, the linear referencing approach is probably indeed complicated. Maybe the TN model could be a candidate for a simplified (GML) encoding, where the transport properties are mapped as attributes to the corresponding transport links.