European Commission logo
INSPIRE Community Forum

Use of reference to standard grid for distribution maps in the context of Nature Directives reporting

Does anybody know an example where a service for HB or SD (or other theme) is implemented using a reference to a standard grid (e.g. EEA standard GRID 10x10 qkm)?

I assume that geometry for distribution maps could be a link to a GRID cell identifier of a standard grid (e.g. such as "10kmE582N260"). Is that correct? How would the gml look like? I would be grateful to see an example and get to know advantages/disadvantages.

 

 

  • Dirk HINTERLANG

    By Dirk HINTERLANG

    Hi Sabine,
    your suggestion is correct. Sorry I cannot present  GML for this purpose yet, even in NRW it's still due until end of this year for the theme HB-distribution.
    Best wishes to all!  Dirk

  • Iurie MAXIM

    Hi Sabine,

    No, the "geometry for distribution maps" cant be "a link to a GRID cell identifier", but it need to be a GM_Object as it is defined in the UML Schema from the Technical Guideline for Species Distribution as you can see bellow:

    So it must have geometry (coordinates for vertices):

    I would use GM_Multisurface to represent the 10x10 km grids.

    So even if the data looks like a GRID, it must be provided simmilar to the way it is stored now in ESRI Geodatabase or in a shapefile, like a polygon. Only polygons where the species occurs must be provided.

    But good news are that you can specify in the GML the Identifier (gml:id) of the GRID cell such as <gml:Polygon gml:id="10kmE531N258">.

    Below an example of encoding:

    <sd:geometry>
        <gml:MultiSurface gml:id="Geom_CanisLupus" srsName="urn:ogc:def:crs:EPSG::3035">
            <gml:surfaceMember>
                <gml:Polygon gml:id="10kmE531N258_1">
                    <gml:exterior>
                        <gml:LinearRing>
                            <gml:posList srsDimension="2" count="4">2580000 5310000 2570000 5310000 2570000 5300000 2580000 5300000 2580000 5310000</gml:posList>
                        </gml:LinearRing>
                    </gml:exterior>
                </gml:Polygon>
            </gml:surfaceMember>
            <gml:surfaceMember>
                <gml:Polygon gml:id="10kmE531N259_2">
                    <gml:exterior>
                        <gml:LinearRing>
                            <gml:posList srsDimension="2" count="4">2590000 5310000 2580000 5310000 2580000 5300000 2590000 5300000 2590000 5310000</gml:posList>
                        </gml:LinearRing>
                    </gml:exterior>
                </gml:Polygon>
            </gml:surfaceMember>
            ......
        </gml:MultiSurface>
    </sd:geometry>

    However it must be ensured that the gml:id is unique in one GML. So you cant use the same gml:id="10kmE531N258" in the same GML. Therefore gml:id="10kmE531N258_1" ... can be used instead.

    Best regards,

    Iurie Maxim

  • Michael LUTZ

    Dear Sabine,

    what Iurie wrote is not entirely correct. There are indeed two options to provide the geometry for a SpeciesDistributionUnit: (1) directly using the GM_Object as described by Iurie (note the multiplicity 0..1), or (2) through a reference to another spatial object (e.g. an administrative unit or a grid cell) in another data set through the spatialObject association.

    This is expressed through the constraint: "If geometry has no value, a reference to a spatial object needs to be provided." 

    The reference to the spatial object would be expressed as any other association in the INSPIRE models. I am not, however, aware of a real example for this option being used for an SD data set.

    Hope this helps,
    Michael

     

  • Iurie MAXIM

    Hi Sabine and Michael,

    First of all thanks Michael for the comment. I didn't even noticed this. But you are right.

    In any case, if the reference is provided, it need point to a spatial object (with geometry). Therefore it is not enough just to indicate the CODE of the GRID, like for example "10kmE531N258", but it need to be provided a http:// link to a WFS service that returns the geometry.

    Such a link can be for example:

    http://inspire.biodiversity.ro/WFS/RO_ENV_PADS/wfs?service=WFS&version=2.0.0&request=GetFeature&typeNames=ps:ProtectedSite&featureId=RO_ENV_PADS_psPSRef_RONPA0022&propertyName=//geometry

    The link returns the geometry of the RONPA0022 protected site.

    So this link can be used in order to indicate that a certain species is present in this protected area for example.

    Simiilar if the EEA or another institution would provide the 10x10 km grid for entire Europe trough a WFS 2.0 service, the data providers will be able to make such simmilar requests to that service in order to retrieve the geometry of each grid cell by filtering based on the grid cell id.

    A better solution is to create a stored querry to retrieve the geometry of that protected site and even better would be to use redirect to shorten the URLs, but this seems not to be to simple.

    Therefore theoreticaly a http://geom.gmlid.eu/RO/ENV/PADS/psPS/RONPA0022 request would redirect to http://inspire.biodiversity.ro/WFS/RO_ENV_PADS/wfs?service=WFS&version=2.0.0&request=GetFeature&typeNames=ps:ProtectedSite&featureId=RO_ENV_PADS_psPSRef_RONPA0022&propertyName=//geometry

    and simmilarly a http://geom.gmlid.eu/EEA/GRID/10kmE531N258 would return the geometry of the "10kmE531N258" grid cell to be used by data providers in their datasets.

    Therefore, indded EEA would need to think at this and to provide such services to be used for data harmonisation.

    In any case we did some testings and we were not able to find any existing solution that is able to resolve these external links in order to retrieve the geometry, Therefore curently if such a service will be done and data providers will use these external geometries, nobody will be able to display such data. Users will be able to retrieve the GML 3.2, but they will not be able to show the data in a viewer, so the data will be of no use.

    This solution will work only with data served trough WFS 2.0 and not trough ATOM and only if the WFS 2.0 service is able to resolve remote links. Currently we do not now any such WFS solution. Currently only local resolve is supported in the WFS solutions. Remote resolve is not supported nor by Geoserver (see link), Snowflake Go Publisher WFS (see link) and for Deegree it is mentioned "Remote xlinks should probably not be resolved automatically" (see link).

    In conclusion it would be good to have in place such WFS services from the EEA that are providing GRID cells geometries, but the WFS technology must be able to resolve remote xlinks, including the geometry. Have no ideea in how many years this will happen, but of course it would be good if we will know at least an approximate time when the solutions will be available to implement INSPIRE as required by TGs in order to have the network functional and data interoperable and usable.

    Probably another solution would be to use local resolve, namely to serve in the same GML, both the distribution of the species and all the GRID cells with the geometry(only once).

    We need to look in the XSD and try to implement with local resolve.

    But in any case, even with local resolve the geometry of each cell need to be provided within the GML. 

    I remember that last year we tried to use local resolve for the lower level and upper level administrative units for au:AdministrativeUnits feature types, but we found that qGIS is not able to display the geometry. Maybe we will repeat that exercise and ask the community if there is a solution to retrieve the geometry in order to be displayed ina desktop or server solution.

    If someone has more practice or knowledge about local and/or remote resolve it would be really usefull to share the information.

    Best regards,

    Iurie Maxim

  • Michael LUTZ

    Dear Iurie, all,

    I think you are asking valid questions about how to deal with references to objects in other data sets in INSPIRE. I just wanted to point out that, in this specific case, but also in all other object references in INSPIRE, the link should actually be to the (whole) spatial object, not just its geometry.

    How this information is processed and presented to the user by client software is of course another question, as you rightly point out.

    Best regards,
    Michael

  • Stefania MORRONE

    By Stefania MORRONE

    Dear all,

    same topic is addressed by https://themes.jrc.ec.europa.eu/discussion/view/159705/hb-and-sd-geospatial-reference-units TC discussion.

    Therefore I am closing this discussion. Please use abovementioned link to post possible replies.

    Thank you.

    Stefania

This discussion is closed.

This discussion is closed and is not accepting new comments.

Biodiversity & Area Management

Biodiversity & Area Management

If themes like Protected Sites, Area Management/Restriction/Regulation Zones and Reporting Units, Habitats and Biotopes, Species Distribution, Bio-geographical Regions matters to you, join these groups!