Hiya,

just did a quick search in the model for ThoroughfareNameValue, I can confirm that it is used nowhere within the model.

Also, it may be an oddity of Annex I, but usually the dataTypes ending in Value are codelists

On the pragmatic implementation level, I'd say you can only encode what's there and formalized. Thus I'd recommend just providing whatever GeographicalName information you have available in ThoroughfareName and just ignore ThoroughfareNameValue

:)

Kathi

Initially I wondered if it had been left over in the model from an earlier draft of the spec - but the diagrams in v2 (2009!) are the same.

It does seem over engineered to me. In practice, we collapse this schema.

Oddly, the "version 4" XSDs do implement ThoroughfareName.name with type ThoroughfareNameValue

http://inspire.ec.europa.eu/schemas/ad/4.0/Addresses.xsd (and the older http://inspire.ec.europa.eu/schemas/ad/3.0/Addresses.xsd)

This is odd, because I believe that the XSDs were generated automatically from the UML.

So then I looked at the Address specification, and the diagrams there match the XSD.

Snapshot from v3.1 of the spec, dated 2014-04-17 (downloaded 2015M11 & again just now).

So now the question is "why is the UML at https://inspire.ec.europa.eu/data-model/approved/r4618/html/ different?" (& https://inspire.ec.europa.eu/data-model/approved/r4618-ir/html/)

We confirm, that we have the same issue. Until now we are denying the result from the validator until a solution will be issued.

Furthermore it is important to know, that the same problem will arise with designated points used in Free Route Airspace as to the fact there are no more routes used and published and the aircraft is directed from point to point at the availability of airspace and is a decision of the air traffic controller.

Some more information on three different FeatureTypes inheriting from TransportNode that cannot be connected to links for the data of the Deutsche Flugsicherung.

1. I can confirm the issue concerning DesignatedPoints that Klaus reported. It will also occur for the data of Deutsche Flugsicherung where the implementation of Free Route Airspace has already started and will increase gradually within the next years. This means AirRouteLink objects will not exist anymore between all of them and DesignatedPoints can therefore exist at the end/start of AirRouteLink objects as well as without connection to AirRouteLink objects as freeNodes.
2. Concerning AerodromeNode objects, I think all information is available in my original post. As Figure 40 of the Data Specification is showing, there is no TransportLink objecs connected to them (as NetworkConnections are directly inheriting from NetworkElemenets and therefore are no TransportLinks).
3. RunwayCentrelinePoint objects are supposed to be located at the end/beginning of InstrumentApproachProcedure/StandardInstrumentDeparture objects. Both of these (as well as StandardInstrumentArrival objects) don't exist in the database of Deutsche Flugsicherung. Therefore, RunwayCentrelinePoint objects will also occur as freeNodes in the German data.

As suggested by Fabio Vinci in the linked GitHub issue, we would support to change the model in a way, these three FeatureTypes are inheriting from TransportPoint and not TransportNode in order to be able to deliver conformant data.

Please, if there is anybody out there who can help here, do not hesitate and reply.

The question is: Do we miss those requirements while reading the document mentioned above or do they exist somewhere else?

And what do you recommend, if not?

Dear Dominique,

We have implemented the first version at BKG (single geometry and multiple values of the attribute). We don’t think that it would be wise to provide the geometry up to 6 times. The data is already big enough. Furthermore, we would have to find a procedure to create new (additional) inspireId, because our national data source is single geometry. So, our INSPIRE data wouldn’t have an easy link to the original data.

Concerning user-friendliness, after all it’s INSPIRE – and INSPIRE is always complex (also the second option).

Best regards,

Marcus Brühl (BKG)

Dear Dominique and all,

I was a member of the expert group for the theme administrative units. And I can only confirm what Marcus said.

In the first version of the data specification there was only option one. Option two came in because there were countries that had multiple geometries in their existing national data and did not feel able to provide the data according to option one. But in this case it is a lot more difficult to keep the geometries of the different layers consistent - you must make shure that you have identical geometries up to 6 times!  I would have liked to have only option one.

Best regards

Ulrich