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

Thanks Stefania you have been very helpfull!!!

I have an other problem with the  transformation on hale, I finished the mapping setting up all the relation between source schema and target schema but when i try to exporting as gml it doesn´t allow me and also on the workbench 'transformation' it doesn´t appear anything, I mean this:

I´ve checked out an example training and I could see this:

I don´t what I am doing wrong.

Thank you in advance!

Hi Beatriz,
I can see that you have loaded your source and target schemas. Have you loaded your source data?

You should see the number of loaded features beside the feature type. Please see the following screenshot:

The feature type HydroNode has data loaded. The feature type WatercourseLink does not.
Once you have loaded your source data and enabled live transformation, you should be able to export your gml file.

Kind regards,
Kate Lyndegaard

wetransform Gmbh
www.wetransform.to

Hi Kate!  no I didn´t do it !! yes that was the problem...thank so much indeed!

have a nice day

Hi Miroslaw,

the water supply zones are "areas managed" under the Drinking Water Directive and well fit the scope of the Area Management / restriction / regulation zones & reporting units INSPIRE data theme.

Regarding the geometry representation, the AM Data Specification state that "Typically the representation of the geometry of a ManagementRestrictionOrRegulationZone shall be either a GM_Surface or GM_MultiSurface. However, it has been recognised that at some levels of detail the geometry may be represented as either a GM_Point or GM_Curve.Consequently, any constraints on the geometry representation have been removed".

This means that point geometry can be used because in this case it corresponds to the level of detail of the source data set .

Regarding the Zone Type code, the http://inspire.ec.europa.eu/codelist/ZoneTypeCode/drinkingWaterProtectionArea is the value to use.

To further specify that the source data set contains water supply zones under the Drinking Water Directive, the specialisedZoneType attribute (optional attribute) could be used. In fact, this attribute is meant to provide an additional value to further specialise the type of zone specified in the zoneType element. 

The specialisedZoneType can contain any value defined by data provider (as long as it is made available in a public register – ref. Article 6(3) of the Implementing Rules).

More specifically, the http://inspire.ec.europa.eu/codelist/SpecialisedZoneTypeCode does not contain any value (empty code list). The AM Data Specification state that the values for the specialisedZoneType “should be derived from relevant domain-specific controlled vocabulary, where available". An extension of the INSPIRE code list SpecialisedZoneTypeCode is provided in the Eionet Data Dictionary, but currently it does not contain any value for water supply zones under DWD (read more on the specialisedZoneTypeCode in this Thematic Cluster post.).

Regarding the WMS layer,  follow what specified in Sec 11.1 of the Data Specification for the layer AM.DrinkingWaterProtectionArea and in Sec 11.2.7 for the style relevant to abovementioned layer (for points, the geometry is rendered  as a square with a size of 6 pixels, with a light blue(#BED2FF) fill and a black outline).

Hope this helps

Stefania
 

Dear Stefania,

thank you very much for your prompt reply.

Concerning Zone Type Code attribute, using of suggested "drinkingWaterProtectionArea" codelist item could be considered as problematic from the first point of view, because meaning of the drinking water protection area (= area from which the drinking water is taken) is different from the water supply zone (= area supplied by drinking water). On the other hand, if appropriate clarification is provided in the specialisedZoneType attribute (for example: "water supply zone (DWD)") and if we consider, that no more suitable value is available in the ZoneType codelist, then suggested solution is OK.

I have just one additional question (which could be relevant also for other Area management topics) - if polygon dataset is provided by country within this theme, is it allowed to use overlapping polygons?

Example: agglomerations A, B and C are served by drinking water sources 1 and 2. Out of this, agglomeration A is served by source 1 only, agglomeration C is served by source 2 only and agglomeration B is served by water mixed from both sources 1 + 2. In such case, water supply zone relevant for drinking water source 1 includes agglomerations A + B and water supply zone relevant for drinking water source 2 includes agglomerations B + C. If the water supply zones are represented by polygons, these polygons will overlapp in the area of agglomeration B. Is such solution acceptable?

Miroslav

Dear Miroslav,

the solution is acceptable.

Stefania

Hi Beatriz,

you can connect hale studio directly to PostGis Database ... no need to use csv or any other format.

You might find it useful to follow the tutorials on the INSPIRE Knowledge Base (https://inspire.ec.europa.eu/portfolio/training-library). More specifically you can reference the module on Examples of data transformation (though it is for AU data theme, it gives an overview on how to use hale studio - aka HALE)

Hope this helps

Stefania