sMorrone
commented
2 years ago Dear @bfrichet3 ,
with reference to the third table column “Spatial object type(s)”, the obligation to provide layer Name according to AU.<CodelistValue> encoding, is referred to spatial object type MaritimeZone and specifically to the MaritimeZoneTypeValue codelist. This becomes clearer when reading the table at the end of the page listing “the layers for all code list values” and /or querying the INSPIRE layer register for Administrative Units layers.
In case one wants to provide more layers for the AdministrativeUnit and the AdminstrativeBoundary spatial objects following classification in the AdministrativeHierarchyLevel code list, the AU.<CodelistValue> nomenclature is not mandatory. One could e.g., use AU.AdministrativeUnit.<CodelistValue> and AU.AdministrativeBoundary.<CodelistValue>.
Warm regards,
Stefania
bfrichet3
Dear Sir or Madame
I hope you are all right. I am working with the conformity of our WMS with the INSPIRE TG.
I noticed in the TG concerning AU two points of interest concerning the conformity of our WMS.
1) The [regulation 1089/2010] article 14 3. states that "for spatial object types whose objects can be further classified using a code list-valued attribute, several layers may be defined". As I read it, we can deliver one separated layer for each administrative level for both AdminstrativeUnit and AdministrativeBoundary types (both feature types include AdministrativeHierarchyLevel as a code-list);
2) The names of these multiple layers are speciefied by annex II of the same [regulation 1089/2010]. If we publish one layer for each administrative level, layer names should be like that AU. where is equal to the concerned code from AdministrativeHierarchyLevel codelist (e.g. 1stOrder) for both AdministrativeUnit and AdminstrativeBoundary.
So this is my question: following these requirements, how could we create layers for each administrative level and be compliant with OGC WMS regulation (each name should be unique).
Regards,
Benoît