European Commission logo
INSPIRE Community Forum

View service, Common Transport Elements?

By Lars Erik STORGAARD Replies (7)

Dear all,

I hope someone can help me clarifying this:

It seems to me that there is a requirement in the interoperability IR and/or in TG TN specifying that a view service has to establish for the Common Transport Elements application schema? There is of course no doubt about that data set under TN road, railway, air, water has to be provide according to each dedicated schemas but what about this “Common Transport Elements application schema”?

The TG TN says on page 23: “The Common Transport Elements application schema covers elements that are shared by subthemes Road, Rail, Cable, Water and Air. These subthemes have been modelled as separate application schemas within the Transport Networks theme.”

The interoperability IR and the TG TN specifies the layers that has to be provide in the TN view service. And the first three layers regard the common transport elements:

Why this requirement?

Thanks in advanced. 

  • Alexander RAMAGE

    By Alexander RAMAGE


    Is it even possible to build the schema without using the common Network Elements?

    Alex Ramage

  • Heidi VANPARYS

    By Heidi VANPARYS

    The Common Transport Elements application schema is indeed a dependency for the other Transports application schemas (or an import, in XML terms).

    But TransportNode, TransportLink and TransportArea are all three defined as abstract classes in the UML model and this is also reflected in the Technical Guidelines.

    E.g. TransportArea:

    So that means that the only TransportArea features present in a data set will be instances of subclasses of TransportArea, such as AerodromeArea, RailwayStationArea or RoadServiceArea.

    The same goes for TransportNode and TransportLink: only features that are instances of their subclasses can be available in data sets.

    So why is it required that the layers TN.CommonTransportElements.TransportNode, TN.CommonTransportElements.TransportLink and TN.CommonTransportElements.TransportArea are provided in a view service?

  • Michael LUTZ

    I agree that it does not seem to make too much sense, since as far as I can tell all non-abstract Link and Area spatial object types are covered by other layers. Note, however, that the layers do not include any Node spatial object types, so the TN.CommonTransportElements.TransportNode may have some sense.

    The only reason for including these layers in the IR that I can see would be to have layers devided by "network element type" including all the TN spatial objects (i.e. all the link objects, all the node objects and all the area objects). But I'm not sure this was the intention.

    What might have made more sense are layers of all the objects of a given transport type (e.g. the complete road network, or the complete rail network).

  • Heidi VANPARYS

    By Heidi VANPARYS

    Note, however, that the layers do not include any Node spatial object types, so the TN.CommonTransportElements.TransportNode may have some sense.

    The question whether it was intentional that no layers were defined for AirNode, CablewayNode, RailwayNode, RoadNode and WaterNode. It appears a bit strange to me that a different approach was chosen for nodes than for links and areas. There may be a reason behind all this though, but then I would like to see that reason documented in the TG somewhere.

    How do we proceed from here? Can someone from the Thematic Working Group shed light on this, or should it be taken up one way or another in this cluster, and e.g. a change proposal be created if we agree that the specification should be clarified/changed on this point?

  • Jordi ESCRIU

    Dear All,

    For me it does not make any sense to have layers corresponding to abstract objects, as Heidi already said. So the inclusion of such layers in the IR might be probably an error.

    The fact of not including layers for node non-abstract spatial objects types may be related to the fact that they were proposed as optional in the TG (i.e. provision of nodes should not be mandatory) - See section of TG TN v3.2. - Surprisingly this spatial object type went into the IR.

    I was almost focused in the data models with my collegue Ward Verlinden, and hardly had opportunity to check the portrayal section. It was proposed by Mark Lepage (Ordnance Survey) quite near the deadline, and he did what it was in his hand. Surely, we lack time for checking. 

    Tomorrow I will try to trace emails and old documents that could be related to the development of the portrayal chapter.



  • Jordi ESCRIU

    Dear All,

    I has been recently involved in the implementation of several INSPIRE view services for my organization and also for other stakeholders in my region.

    Before implementing the service I was studying the Technical Guidance for the Implementation of INSPIRE View Service v3.11, where I discovered some content that may bring light to the present discussion topic. Concretely, section explain the concept and use of "category layers".

    Category (or classification) layers are those layers defined for an INSPIRE View Service that contains one or more nested layers. As explained and recommended (Implementation Recommendation 16) in the previous section, Category layers should be used to describe a layer including more than one featuretype (e.g. Hydrography Layers in INSPIRE Regulation as regards interoperability of spatial data sets and services [INS DS]) or a layer consisting of regional separated spatial datasets.

    Additionally, implementation Requirement 49 adds that A containing Category Layer itself includes a Name by which a map portraying all of the nested layers can be requested at once.

    In other words, category layers may be used in a view service to group several content layers (nested layers) and portray them together with a common representation style / symbology - With the following options:

    A) Each nested layer corresponds to a different non-abstract INSPIRE spatial object type - The category layer may correspond to an abstract class that group them together - e.g. see example 23 from the TG:

    For instance, the Category Layer Hydrography Physical Waters Waterbodies (HY.PHYSICALWATERS.WATERBODIES) could contain HY.PhysicalWaters.Waterbodies.Watercourse and HY.PhysicalWaters.Waterbodies.StandingWater nested layers.

    B) Nested layers contains information for the same non-abstract INSPIRE spatial object type, but provides the data from different regions or data providers - e.g. to be used in a descentralized implementation scenario.

    Case A was probably used when drafting the TG on Transport Networks, and the style defined for an abstract class may be used for portraying together all the non-abstract spatials objects included as content of nested layers.






  • Marie LAMBOIS

    I have tried to publish MarkerPost objects (which inherits from TransportPoint) but I realized that there is no layer containing this kind of objects (and no style of course). Have you ever noticed this issue ?

    Right now I have published the objects under a layer called TN.CommonTransportElements.MarkerPosts