European Commission logo
INSPIRE Community Forum

Update of the INSPIRE Network model

I have identified some issues with the INSPIRE Generic Network Model that should be taken into discussion in this thematic cluster. I have allready discussed them with Michael Lutz, Lars Wikstrøm and Paul Scarponicini, but I am adding them here to make sure they are taken into discussion. 

The Network Model is a general model for INSPIRE, and is used by at least Transport Networks, Hydrography and Utilities. Since there is no special cluster for the general models, I guess this cluster is the natural place for these issues. 

First - on linear referencing:

Linear Referencing is an important part of INSPIRE Transport Networks, and is based on the Generic Network Model (D.2.10.1). There is also an international standard for linear referencing of geographic information: ISO 19148:2012. On page 5 in the D.2.10.1 document, the relation to ISO19148 is described like this:

ISO/TC 211 has been developing a standard (ISO19148). A mechanism to express linear references is provided in this version of the network model in the sense of a “candidate type” that may require an update once ISO19148 is stable and supported by implementations.

ISO19148 was published in 2012, so one may very well say that it is stable. It is also supported by a number of implementations, including GML 3.3. I have discussed this with Paul Scarponcini, who was the editor for ISO19148, and his conclusion is that there is no discrepancy between the INSPIRE model for linear referencing and ISO19148, INSPIRE is just narrowing ISO19148 by having only one LR Method (absolute – length on geometry). But the model should still be updated, to show the connection to ISO19148. And I also think it should be possible to use interpolative LR methods (0..1 or percentage) as an alternative to geometry length, and maybe also relative methods (length from milepost etc). This would significantly simplify our delivery from the Norwegian Road Database.

My suggestion, that Paul agreed to, is that the INSPIRE model should be presented as a profile of ISO19148. In that way, it will also be easy to extend the model with other LR Methods.

Second - road link positions on road sequences:

Another issue with the INSPIRE Network Model is that we should have from- and to position attributes (and/or length) on the link features, to describe where they are in a link sequence and how long they are in the LR system. This is also supported in ISO19148.

The fact is that each link may have an individual scale in the LR system. In our road database, the features are positioned on the link sequences, while the links have from- and to positions on the link sequences. These positions may differ from the geometry length. The link features also hold the road geometry. To present the features with geometry on a map, we need to go from linear references to road geometry, and the scale for each link is a parameter in this process.

  • Jenny RASSMUS

    From the Swedish Transport Administration's side, we strongly support the suggestion to also allow relative measures as a method for linear referencing.

  • Knut JETLUND

    Attached is a draft model for how ISO19148 could be implemented in the INSPIRE Network Model. This needs to be discussed more with LR experts, but the model can be a start. 

    The model simplifies the ISO1948 model a bit, in particular by using single attributes for distance expressions instead of the data type LR_DistanceExpression, and by using attributes directly on NetworkElement instead of realizing the interface LR_ILinearElement. I believe that the GML implentation of ISO19148 in GML3.3 should be used in the INSPIRE schemas, and the simplifications might be a challenge in that setting. 

    The idea behind the model is that the INSPIRE featureTypes and dataTypes substitutes the ISO19148 featureTypes and dataTypes. The INSPIRE classes are green in the model, ISO19148 classes are white.

    Implenetation of ISO19148

  • Alberto HENCHE

    By Alberto HENCHE

    That draft is a good starting point to update the Inspire GNM but it is only taking into account absolutes LRM (Linear Referencing Methods).

    For relatives LRM, I think that it must go a step forward and include ISO19148 LR_Referent directly linked to Network::NetworkElement similar to the way supported in ISO19148.

    Relative to the last issue, there is something that I don´t understand from the Data Specification on Transport Networks - Technical Guidelines. Why the MarkerPost class is directly related to TransportLinkSet class in "Application Schema Common Transport Elements"?.

    If MarkerPost`s function is to support relative linear referencing, why these elements are not directly related to Network::GeneralisedLink class since "this abstract base type represent a linear network element that may be used as a target in linear referencing"?.

     

  • Knut JETLUND

    This is partly correct - the draft model does not take into account the mechanisms needed for relative LRM, so it must be extended for that purpose. But it supports both absolute and interpolative LRM. 

    I have no knowlegde of why MarkerPost has been modeled as it is in Transport Networks, but I agree that it should be in the General Network Model as suggested. It may be usefull for other purposes than transport networks, and should not be limited just to TransportLinkSet. 

  • Dominique LAURENT

    By Dominique LAURENT

    It may be good idea to authorize relative linear referencing methods if these methods are widely used by the transport stakeholders.

    However, it would be an even better idea to propose (in addition) a logical model for theme TN without any linear referencing but just properties as attributes on the transport links, nodes or link sequences/sets:

    - some data providers (as NMCAs) do not use any linear referencing

    - client applications specific to theme TN may deal with linear referencing but other tools (GIS) can't

    - the objective of INSPIRE Directive is to make data easy to combine not only between countries within a theme but also between themes. Currently, it would be quite difficult to combine INSPIRE TN data with any other theme, even for simple applications, such as mapping. We had this issue in the ELF project when willing to carry out the topographic BaseMap ; use of INSPIRE TN data had been considered as impossible or at least quite too difficult.

  • Knut JETLUND

    Dominique is raising an important issue here. The question behind is whether the INSPIRE models shall be for exchanging data at a detailed level, fit for maintenance, or at a more generalised level, fit for usage. The linear references in the TN models are without doubt complicating the usage of the data in GIS applications. On the other hand, it simplifies the core network data and makes the model more similar to traditional network databases.

    There are two approaches to modelling network data and their properties:

    (1) Core network, with properties connected through linear referencing. Complicates usage, but simplifies the network: Fewer, longer and stable segments, with few attributes.

    (2) Segmented network, with properties attached as attributes. Simplifies usage, but complicates the network: Many, short and unstable segments, with many attributes.

    INSPIRE TN is only allowing (1), while the predecessor EuroRoadS had both possibilities (http://www.euroroads.org/php/Reports/D6.3%20Road%20Network%20Information%20Model.pdf). The model in EuroRoadS made it easier to deliver data from data sources without linear referencing, but at the same time, the data became less harmonized, with some data providers delivering data with linear referencing, and some with attributes. I believe harmonization is important for INSPIRE, so one should keep to one approach. And in my opinion, the pros of using linear referencing is larger than the cons.

    By updating the network model to include interpolative linear references, we will also make it easier to deliver data from a segmented network. Network properties may then be delivered with interpolative linear references, with start 0 and end 1 for all "from-to" properites, and 0 or 1 for all "at"-properties.

    To simplify the use and presentation of TN data, I would suggest that all network properties should have optional geometry attributes. That way, the network properties can be easily used in GIS applications, but at the same time, we keep the advantages of linear referencing. We are using this approach in a presentation database for our road data, the one we are using for creating INSPIRE data. While in our maintenance database, we have pure linear referencing. 

     

  • Dominique LAURENT

    By Dominique LAURENT

    The core network is probably a good solution for some data producers; I remember that in the EuroRoadS project, the balance was around 50 % - 50% between those using or not using  linear referencing.

    However, currently, IGN France is using the segmented network and when transforming our data for INSPIRE, we really have the feeling to make something quite stupid as it is hard work for us to transform our simple attributes into feature types (it implies to provide identifiers and referencing) and as it makes the exploitation of our INSPIRE data quite more complex for data users! The issue is probably the same for the other data producers using the segmented model.

     

    In my understanding, INSPIRE is supposed to simplify the usage of data and not so much, about harmonising the production processes (INSPIRE is not about telling data producers about how they should manage data in their internal database).

    The proposal about each property having optional geometry attributes may be of interest for data under core network but for data under segmented network, the simplest solution is the second option of EuroRoads: one geometry with all properties as direct attributes; this option enables combined queries or analysis on several properties.