PS: Suppressing Geometry Information
During the work on extending the INSPIRE PS Theme for CDDA Reporting to the EEA we've come upon the problem of how to deal with suppressed geometry information. While formally all protected sites should provide geometry, there are cases where the MS refuse due to the sensitive nature of the information. Within CDDA we've come to the agreement that if this is the case:
However, as this problem could come up in different contexts, it could make sense to foresee a mechanism for this at the PS level. Options we discussed within the CDDA project:
In addition, it would make sense to find a consensus on what type of dummy geometry to use. Options we discussed within the CDDA project:
Does anybody have further ideas on this, or additions to these requirements?
:?
Kathi
This discussion is closed and is not accepting new comments.
Hi Kathi,
It's not possible to leave the geometry property element empty and provide a nilReason attribute "withheld"? If possible I would strongly prefer this over dummy coordinates.
Hi all,
It's not possible to leave the geometry property element empty and provide a nilReason attribute "withheld" because the geometry attribute is mandatory and not voidable.
Cleanest solution is asking a change to the PS TG so to make geometry element voidable (and in this case a nilReason attribute "withheld" could be specified).
In the meanwhile, the workaround " dummy value (0,0) + optional attribute to show that the geometry provided is a dummy" could be considered.
In this case it should be kept in mind that, of course, if someone displays the dataset using GIS tools, the site with (0,0) geometry would be displayed "on the equator somewhere south of the UK" (and eventually a validator for the dataset - e.g. the OGC validator - could say that the point (0.0) does not belong to the CRS addressed by the dataset so that dataset validation would fail .... )
Stefania
Hi all,
I perfectly agree with what Stefania said.
cheers, Dirk
One final note on the reasoning behind providing the (0,0) coordinates instead of the bounding box:
While the bounding box initially made more sense, many MS are worried that this will then actually be used. With 0,0 most folks should understand that these are not serious coordinates.
Still would prefer it if ps:geometry could be made voidable for such cases, with nilReason=Withheld just as Stefania proposed
:)
Kathi
Even if the geometry attribute will be optional, still it will be interesting to provide view and download services for features without geometry.
Its possible to provide a WMS with features without geometry? For sure they will not be seen on the map. Its possible to provide a WFS based on features without geometry? Its possible to make a GetFeatureById request if the feature does not have geometry?
The geometry tag from the GML3.2 file can be easily deleted, but it is possible to create WMS and WFS view and download services?
Will try next week!
Iurie
Not sure what a view service would deliver without a view (i.e. a geometry), not my strong point
However, download services without geometry are no problem. Within the European Air Quality Reporting we've done exactly that in order to provide all required data via one service; in addition to the classical spatial features (stations, zones) we also provide non-spatial features:
http://luft.umweltbundesamt.at/inspire/wfs?service=WFS&version=2.0.0&request=GetFeature&typeName=aqd:AQD_ReportingHeader
http://luft.umweltbundesamt.at/inspire/wfs?service=WFS&version=2.0.0&request=GetFeature&typeName=aqd:AQD_AssessmentRegime
http://luft.umweltbundesamt.at/inspire/wfs?service=WFS&version=2.0.0&request=GetFeature&typeName=aqd:CompetentAuthorities
I haven't tried getFeatureById, but it is possible to filter based on gml:id:
http://luft.umweltbundesamt.at/inspire/wfs?service=WFS&version=2.0.0&request=GetFeature&typeName=aqd:AQD_AssessmentRegime&featureID=ARE.3
:)
Kathi
I was rather questioning if it is possible to have WFS and WMS for some features having geometries and some others that do not have geometry. GIS software is using tables to store only attribute data with no geometry and feature classes / shapefiles to store geometry and attributes. So I assumed that a WFS with some features with geometry and some others without geometry must be tested.
Therefore, my colleague Daniel Cocanu created a GML 3.2 for PS:ProtectedSites and a WFS 2.0 view service, by filling the polygon geometry of one protected sites with NULL value in a PostGIS Database. He made this for the only one protected area in Romania for which nobody know exactly where it is located.
QGIS loads the GML and the WFS with no problems, showing only one layer.
But ArcGIS loads two layers (interoperability feature classes):
- one called "ProtectedSite NoGeometry" - point type, showing the attributes of the protected sites with NULL geometry as boundary
- one called "ProtectedSite Polygon" - polygon type, showing all sites that have geometry, but not those ones for which the geometry was replaced with NULL.
The protected site with no geometry can be retrieved in browser trough the following request:
http://inspire.biodiversity.ro/WFS/RO_ENV_PS/wfs?service=wfs&version=2.0.0&request=GetFeature&TYPENAME=ps:ProtectedSite&featureid=RONPA0968
Any other protected site with geometry can be retreived in browser trough the following request:
http://inspire.biodiversity.ro/WFS/RO_ENV_PS/wfs?service=wfs&version=2.0.0&request=GetFeature&TYPENAME=ps:ProtectedSite&featureid=ROSCI0231
by replacing "ROSCI0231" with any sitecode of format ROSCIxxxx and ROSPAyyyy
Yesterday Romania reported to the EC the Natura 2000 sites boundaries according to INSPIRE Technical Specifications for Protected Sites, when it was delivered the new 2016 N2K Database. The report is loaded in Reportnet at http://cdr.eionet.europa.eu/ro/eu/n2000/envvouqdw/
The dataset, the view and download services can be discovered in the INSPIRE Geoportal http://inspire-geoportal.ec.europa.eu/discovery by searching after any sitecode.
The WFS download service is available at http://inspire.biodiversity.ro/WFS/RO_ENV_PS/wfs
Iurie
Hi Iurie,
thank you for sharing.
I downloaded the RO.ENV.PS.N2k.gml file following your link.
It may be of interest for you (and for those who will use your example) to know that validating the file (e.g. by means of eENVplus Validation Service or Oxygen XML editor ...) an error arises due to the use of the http://www.w3.org/2009/XMLSchema/XMLSchema.xsd which is not a valid schema.
Error message is
" 2 schema error(s) detected. - Severity: ERROR Message: rcase-Recurse.2: There is not a complete functional mapping between the particles.
Severity: ERROR Message: derivation-ok-restriction.5.4.2: Error for type 'all'. The particle of the type is not a valid restriction of the particle of the base".
The issue is very simple to solve:
you can
or (more conveniently)
I modified the downloaded RO.ENV.PS.N2k.gml file changing the schema location element as follows "xsi:schemaLocation=http://www.opengis.net/wfs/2.0 http://schemas.opengis.net/wfs/2.0/wfs.xsd urn:x-inspire:specification:gmlas:ProtectedSites:3.0 http://inspire.ec.europa.eu/schemas/ps/3.0/ProtectedSites.xsd" and now it validates successfully.
Hope this helps …
Coming back to the original question, I think this case is covered by Art. 13(1) of the INSPIRE Directive, which states:
Thus, the solution could also be to restrict access to the sensitive information to those people with appropriate permissions. However, this would require object- (or even attribute-) level access control.
So I am not sure this is a viable solution, but I thought I'd mention it for the sake of completeness (and since it seems that this is the solution the authors of the Directive had in mind...).
Hi Michael,
while that was one of the various Options we considered, the Problem Comes up due to the combination of INSPIRE and EEA Reporting. Here I see two problematic aspects:
While Workarounds are possible in both cases, it may be adventageous to provide a solution (or at least recommendation) to MS that allow them to fullfill their INSPIRE and EEA Reporting requirements without adding additional technical burdens
:)
Kathi