European Commission logo
INSPIRE Community Forum

Do we need geometry for the "big" administrative units?

Dominique LAURENT

In the INSPIRE specifications, all administrative units are defined by their geometry. When dealing with large scale data, this may result in very big objects for the level 1 AU (country) or even for the level 2 AU ("region" in France). These objects have a huge number of verices, due to the size of the object and to due its detailed representation, this makes management and transfer of these objects quite difficult.

Proposal: make geometry of these objects voidable if the link to lower level AU is supplied and enables users to recreate this geometry (if they require it).

See slides 8,9, 10 of enclosed document. Transformation_AU_IGNF [Mode de compatibilité].pdf

 

  • Marcus Brühl

    I do see the issue, but I don’t think that is a good solution to refuse to deliver the geometry of upper level units. At the end, you could argue just to deliver the geometry of the lowest level and to provide the upper levels with the association lowerLevelUnit – upperLevelUnit.

    The shortcoming of this solution is that users don’t get the upper level units as such. They have to pre-process the data before getting the geometry of the objects.

    This issue should be answered by a GML expert.

  • Heidi VANPARYS

    By Heidi VANPARYS

    This is not necessarily a GML-only issue.

    In Denmark, the geometry of the whole country (AU level 1), if it would be delivered as 1 instance of a multi-surface, would consist of 1095478 vertices (representing an area of 43052 square kilometer). A 2D-spatial object with this number of vertices cannot be stored in our database used for distribution of data, an Oracle Spatial database, given the restrictions in Oracle Spatial according to the Oracle documentation:

    [...] the maximum number of vertices in an SDO_GEOMETRY object depends on the number of dimensions per vertex: 524,288 for two dimensions, 349,525 for three dimensions, and 262,144 for four dimensions.

    In our production system, the different parts of the geometry of Denmark are stored in separate database rows, with the biggest geometry having 266459 vertices, so in our production system we do not face the same issue.

    The configuration of Oracle Spatial can be changed in order to support very large geometries according to the Oracle documentation:

    If you need to support geometries with more than 1,048,576 ordinates, you must follow the instructions in this section. However, doing so involves significant extra work (running a script, migrating existing spatial data), some database downtime , and some considerations and restrictions. Therefore, you should not perform the actions in this section unless you need to.

    Our database administrators have taken the decision not to support very large geometries, because of possible compatibility issues.

    And what would be the valid business use case behind providing such large geometries? We do not have any users requesting the geometry of the whole of Denmark in this large a scale.

    Since the geometry is not voidable, we do not provide a feature at all representing Denmark in our WFS for AU in large scale, we only provide features of level 2 and 3.

    I agree with Dominique that a solution may be to make the geometry voidable. And maybe a new void reason should be introduced too then, since none of the values in http://inspire.ec.europa.eu/codelist/VoidReasonValue/ really seems to fit here.

    I am wondering if any other data providers are experiencing similar issues? And if not, what may be the reasons? A smaller country would be one valid reason of course, but Denmark is not that big either...