European Commission logo
INSPIRE Community Forum

Bug in the Spikes and Punctures Test within OGC and eENVplus validators

Hello everybody,

If someone will test all poligon geometries in a large dataset, will find that there are chances that few poligons are not valid.

According to the rule 4 from  2.1.10 Polygon section of the OGC Simple Features Specification ”A Polygon may not have cut lines, spikes or punctures”

If testing the GML or the WFS with the OGC Validator http://cite.opengeospatial.org/teamengine/about/wfs/1.0.0/site/ there are chances that some poligons to fail the Spikes and Punctures Polygon Test even if they look fine, have no topology errors and can be opened and edited with all common GIS software.

Here is an example of a spike that is not passing the test (the thinest part have several meters).

 Interesting is that the adiacent poligon (green) with the coresponding puncture is passing the test.

And here is an example of a puncture that is not passing the test.

Similarly, it is interesting is that the adiacent poligon with the coresponding spike is passing the test.

This is doue to a bug in the algorithm that is testing the poligons for spikes and punctures, because none of these poligons have neither spikes or punctures.

The code of the validator is found on github here and we noticed that the same code is used by the eENVplus Validation Service that is providing the same errors.

We made more investigations and found this usefull document where can be found conclusions of testing several types of poligons tested against several database types (i.e: Oracle, PostGIS) and against OGC-SFS and ISO 19107.

However the poligons shown above need to be valid, so the OGC validator has a bug described here.

When the EC Geportal Validatior will check the data (curently it does not checking the data), if it will do an exhaustive validation, there will be polygons that will not pass the spikes and puncture test.

Therefore this bug https://github.com/opengeospatial/ets-gml32/issues/20 must be solved.

Luckily a workaround exist! We tried several tricks and we found a solution.

If adding few more vertices in the area where the spike or puncture exist (even withouth changing the shape of the geometry) the polygons will pass. The difficulty to apply this workaround is that the spikes and punctures need to be identified within that poligon that is faining the test and this takes a significant time as polygons must be splitted in several polygons untill the area that fails the test is isolated and identified.

Same polygons with few more vertices added are passing the test.

And here is a geometry that is not passing the tests http://inspire.biodiversity.ro/geoserver/ows?service=wfs&version=2.0.0&request=getfeature&typename=ps:ProtectedSite&featureid=ROSPA0076

(The error will not exist after we will find the spike/puncture and fix it)

It can be tested with

The eENVplus Validation Service http://cloud.epsilon-italia.it/eenvplus_new/PS_E1.html

Or with OCG Validator http://cite.opengeospatial.org/teamengine/viewSessions.jsp

The error message looks like:

Test method validSurfaceBoundary:

              Exterior boundary of surface with @gml:id='GEOM.RO.ENVPS.ROSPA0076.2016-02-29.2' is not simple. expected [true] but found [false]

Any comments are welcomed,

Iurie Maxim

  • Stefania MORRONE

    By Stefania MORRONE

    Hi Iurie,
    just to point out that the eENVplus Validator is based on the use of OGC GML 3.2 -ISO 19136:2007- Conformance Test Suite (currently on rel 1.22): the same OGC code is used implying of course that the same bugs are present. As you already mentioned, the bug has been reported on github but it's still unsolved. Unfortunately I guess your workaround is the only one - at least it's the one I use.
    I'm sending an email to the OGC CITE developers and include a link to this TC discussion, hoping this will speed up bug-fixing times ...

    Stefania

  • Iurie MAXIM

    Hi Stephania,

    I saw your comments on this bug, so hope it will be solved. Unfortunately there are quite many bugs and issues that make the INSPIRE Directive so difficult to implement.

    I am not so sure if this bug is database dependent or not. So most probably we will test on SQL and Oracle as well.

    We found another critical issue for PostGIS databases, related to clockwise and counter clockwise poligon orientation that makes this database unsuitable for serving datasets via WFS from data production environments if a bug will not be solved. I saw you raised this subject and a work around was developed in HALE but only for exporting GMLs, not for mapping attributes. I will open a separate topic on this as well.

    Therefore, as it seems that you encounter a lot of problems as well, maybe it would be a good ideea to raise all these issues in the INSPIRE Thematic Clusters by openening separate discutions and then to collect all the bugs that need to be solved in order to allow INSPIRE Directive to be implemented.

    Iurie

  • Giacomo MARTIRANO

    By Giacomo MARTIRANO

    Hi Iurie,

    I agree wth you when you say "... maybe it would be a good ideea to raise all these issues in the INSPIRE Thematic Clusters by openening separate discutions and then to collect all the bugs that need to be solved in order to allow INSPIRE Directive to be implemented."

    Just recommending the spirit to see the glass half full (and not half empty), in order to do not discourage the "willing implementers" and  to do not encourage those using the implementation complexities as an excuse to reduce their efforts in solving issues.smiley

    Giacomo

  • Iurie MAXIM

    Hi Giacomo,

    For sure the glass is almost full, not just half full or half empty. Few issues still exist and first of all they need to be identified, then known by all interested parties and of course solved.

    I rather do not think that there are "willing implementers" that can be discouraged, but there are Member States that have obligations according to the INSPIRE Directive, Implementing Rules and Technical Guidelines.

    On the other hand I do not think that MS need to be focused on solving issues or in identifying the tools that can be used for implementing INSPIRE.

    I rather consider that Member States need to use the necessary tools according to clear guidelines, As well MS need to clearly understand which are their obligations and what to do in order to meet these obligations at the imposed deadlines.

    Iurie

  • Johanna OTT

    Hi Iurie, hi Stefania,

    are there any news how to solve the "Exterior boundary of surface with @gml:id='[...]' is not simple. expected [true] but found [false]"-error without searching for all the geometries that cause the error and changing the number of vertices?

    In my dataset it is not only one geometry that is failing the test (I don't know how many as the validator only mentions one for every time I try to validate).

    Johanna

  • Stefania MORRONE

    By Stefania MORRONE

    Hi Johanna,

    unfortunately, I have no good news. The relevant bug reported on the OGC github has been closed (the tolerance for detecting consecutive duplicate positions has been decreased) but the problem is still present in some cases. To be more precise, the OGC CITE team released new version of the GML test suite (v1.25), claiming the resolution of the issue, but, when I test some of the files failing with the older release, I still get the same errors.

    Stefania

  • Johanna OTT

    Hi Stefania,

    thank you for your fast reactions! Did you or anyone else here ever use FME trying to repair/change the geometry in order to make it pass the validation?

    Johanna

     

  • Iurie MAXIM

    Hi Johanna,

    We made a lot of investigations on this bug and till now we did not found any software able to "repair" the geometries that are not falling this test simply because all the GIS software that we tested are able to display and edit those geometries that are not passing the OGC test, because actually the geometries are correct.

    So there is nothing to be repaired. The OGC must implement another algorithm similar to those implemented by PostGIS as this is providing the least number of fake fails, as it can be seen in the table 1 of this document that was mentioned before in the first post http://www.gdmc.nl/publications/2004/Invalid_Valid_Clean_Polygons.pdf

    If you want to automatically modify the geometry to pass the test, you can densify vertices, but this will increase the the size of the geometry to so large sizes that the geometry will be almost not usable.

    With FME you can use the densifier transformer https://www.safe.com/transformers/densifier/

    You should try to denisfy till the geometry will pass the test. If you are lucky the geometries will be still not unmanageable, but expect at least to have size tripled.

    Best regards,

    Iurie Maxim

    Teamnet

    ROMANIA

     

     

  • Johanna OTT

    Hi Iurie,

    Thank you very much for your hint! I tried the Densifier and it worked :) (at least for the part of the data I tested – I’m going to check with the rest today). As you predicted the size is 4-5 times bigger than it used to be, so definitely not a solution to aim for in the next months and years.

    Best regards,

    Johanna

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!