Gridded data - cool! Any chance you'd prefer to provide this as a coverage model? There's a deprecated one I've been itching to revive!

:)

For more details on this topic (use of  coverage model for HB gridded data), have a look at this interesting INSPIRE Community Forum post https://inspire.ec.europa.eu/forum/discussion/view/207594/habitatsandbiotopes-in-wcs?

Stefania

More also at: https://workshops.inspire-helsinki-2019.fi/workshop5

:)

Kathi

Dear Miroslav,

generally speaking, a property with multiplicity (1..*) can appear 1 or multiple times in the same spatial object (specific <gml:featureMember> or <wfs:member>).

Let's say, as an example, that one wants to provide two names and two zone type values for the same ManagementRestrictionOrRegulationZone spatial object e.g. "AM_1". The GML would look like the following :

 <gml:featureMember>

<am:ManagementRestrictionOrRegulationZone gml:id="AM_1">
      <am:inspireId> ... </am:inspireId>
      <am:thematicId>.... </am:thematicId>
      <am:name>
        <gn:GeographicalName>
          <gn:language>eng</gn:language>
          <gn:nativeness xsi:nil="true"/>
          <gn:nameStatus xsi:nil="true"/>
          <gn:sourceOfName xsi:nil="true"/>
          <gn:pronunciation xsi:nil="true"/>
          <gn:spelling>
            <gn:SpellingOfName>
              <gn:text>Name1</gn:text>
              <gn:script xsi:nil="true"/>
            </gn:SpellingOfName>
          </gn:spelling>
        </gn:GeographicalName> 
      </am:name>
      <am:name>
        <gn:GeographicalName>
          <gn:language>ger</gn:language>
          <gn:nativeness xsi:nil="true"/>
          <gn:nameStatus xsi:nil="true"/>
          <gn:sourceOfName xsi:nil="true"/>
          <gn:pronunciation xsi:nil="true"/>
          <gn:spelling>
            <gn:SpellingOfName>
              <gn:text>Name2</gn:text>
              <gn:script xsi:nil="true"/>
            </gn:SpellingOfName>
          </gn:spelling>
        </gn:GeographicalName>   
      </am:name>    
      <am:geometry> ...    
      </am:geometry>
      <am:zoneType xlink:href="http://inspire.ec.europa.eu/codelist/ZoneTypeCode/value1"></am:zoneType>
      <am:zoneType xlink:href="http://inspire.ec.europa.eu/codelist/ZoneTypeCode/value2"></am:zoneType>

      ....

  </gml:featureMember>

Hope this helps

Stefania

Dear Stefania,

Thank you for your reply. It means, if using of multiple attributes is intended, then gml data format has to be used only. Unfortunately, I am affraid, such situation is not comfortable for many data providers and data users at all, because in most cases, shapefile or geodatabase are widely used as basic spatial data formats. In both shapefile and geodatabase formats, two or more attributes with identical names are not allowed. If the gml file containing multiple attributes with identical names is converted to shapefile or to geodatabase feature class, these attributes are renamed during the conversion process by adding suffix "_1", "_2", etc.

It is a pity that multiple attributes cannot be solved by relation from attribute table to external table containing multiple values for given multiple attribute. E.g., if spatial data should contain multiple values of zoneType attribute, then the spatial dataset will have one zoneType attribute only and this atribute will contain link (relation) to external table, in which multiple values of zoneType are stored. By that way, multiple attributes could be implemented also for shapefiles and geodatabases. Do you think, this solution could be considered as INSPIRE compatible in the future?

Best wishes

Miroslav

Dear Miroslav,

I understand your point of view, anyway I don't think your implementation proposal could be considered as INSPIRE compliant not even in the future.

Moreover, consider that currently most software tools are not able to resolve the xlinks (both internal and external) in the gml dataset , and this would constitute a 'side effect' of your proposal to be duly taken into account.

Best regards,

Stefania