Hi Kathi,

I was not as clear as I would have liked .. I was somehow triggered by the reference to the soil code lists and I took the opportunity to recommend an encoding for “the code list cases” , that is for the cases when we have an attribute whose value type is a code list (gml: ReferenceType) and code list registry entry provides only a reference to an external document (PDF, excel … )

e.g.  

https://inspire.ec.europa.eu/codelist/MarineStrategyFrameworkDirectiveCodeValue

https://inspire.ec.europa.eu/codelist/MarineStrategyFrameworkDirectiveClassificationValue https://inspire.ec.europa.eu/codelist/NaturalVegetationClassificationValue 

and that’s why I ended with

"Forcing the code list values to be provided as http identifiers is great if these latter exist".

That said, in any case I would avoid using non-working links, unless commonly/ clearly agreed as a way forward.

I was thinking about something like <gml:identifier codeSpace=" https://inspire.ec.europa.eu/document/WasteHaz">200301</gml:identifier&gt;

Would this work?

:) Stefania

Hmm... theoretically that would work, but in reality we'd have to modify the UML, or at least the XSD. Probably the same amount of work as putting up the codelist (none of the three are technically difficult, but the administrative aspects will take a few years off your life ;) )

To my view one of the underlying issues here is the misuse of the xlink standard, originally designed for a totally different purpose (providing an external linking mechanism for resources available via a URI). 19115 handles codelists differently, codelist references become gco:CodeListValue_Type in the XSD, providing the two attributes codeList and codeListValue (in this version, you get to guess how to concatenate the two to get to a resolvable URL).

I believe that GML encoding then shifted this to xlink, but am not really sure where this really came from. Result in INSPIRE is that we have to deal with both versions, as some codelists are referenced by types adopted from 19115 (so the 2 attribute version), others defined within the model use xlink - perfect confusion all round!

Conclusion - as there's currently no correct solution, the incorrect ones are valid by default (very curious how the validator will try and solve this!)

Hi Kathi, hi Stefania,

Thank you for your input. I will now go ahead with https://inspire.ec.europa.eu/document/WasteHaz#value in the href attribute.

If you get any official feedback on what is supposed to be used, I would be happy to learn about it :)

All the best

Johanna

Dear Stefania,

Many thanks for this information!

Best regards,

Panu

Dear Panu,

a short note on the extendability of INSPIRE Schemas. Formally, you only need provide what's foreseen in the INSPIRE Schemas. However, if you have the data in your national DB, and there is a valid use case for providing such information (would make a lot of sense to me!), it would be fairly simple to create a featureType to represent these signs

The signs do seem related to the objects derived from TransportPoint (Buoy and Beacon), that are both associated with the TrafficSeparationScheme

:)

Kathi

Dear Kathi,

Many thanks for pointing out the extendability aspect. You are right that instead of implementing a strictly minimum level INSPIRE data product from legal requirements perspective, extensions provide an alternative way of doing the job. Of course there has to be a clear user-driven case as a starting point for implementing extensions.

Buoy and Beacon feature types are certainly related to traffic signs but they do not quite match. Extensions and a more generically specified spatial object type for fixed or floating signs related to vessel navigation could be a valid choice in this case too.

Best regards,

Panu

Hi Fabio,

Thank you for the update and the clarification.

All the best

Johanna

Hi Fabio,

nice to see progress on this! Quick question (just to be sure ;) ) - by "the legalBasis association is void" - I'm assuming you mean the legalBasis entry has been provided with xsi:nil="true" and nilReason,

"void" is a bit like "null" vs. "nil", lots of subtly different ways of saying nothing

:?

Kathi

Hi Kathi,

yes, that's what I meant.
And, due to the fact that the nilReason is "only" recommended by TG, the following encoding:

<am:legalBasis xsi:nil="true"/>

passes the test.

Fabio