persistent INSPIRE identifiers for deaggregated multipart geometry objects

[ulbrichtd]

Hi,

we have data describing the forest coverage for the city of Berlin. The source data contains several objects with multipart geometry. We have to transform this data into the LandCover data model of INSPIRE. The LandCover data model does not allow multipart geometries. It enforces points or surface geometry by a constraint in the Implementing Rules (IR 1253/2013): see discussion on this topic here #150.

Currently, the creator of the source dataset is not able to provide data with point or surface geometry. So, deaggregation of object geometries has to be done as part of the tranformation into the INSPIRE LandCover data model. The source dataset consists of 6200 objects and 860 objects have a multipart geometry.

While deaggregation of multipart geometry objects is an easy task with FME, we do not find a sane way to generate unique and persistent INSPIRE-IDs for the generated objects. We think that deaggregated objects share the identity (i.e. the INSPIRE-ID) of the aggregated object. In addition, the deaggregated objects differ in the geometry, so we have to add information to the INSPIRE-ID that can be retrieved from the object geometry:

• We could use the position of the geometry inside the multipart, but multipart geometries do not define an order of the components.
• We could enumerate the deaggregated objects by their area, but area size might be equal or surfaces of a multisurface might be deleted.

Is there a valid programmatic way to generate identifiers for objects that are the result of a deaggregation of the object geometry?

An example to illustrate the problem:
We have an object that uses multisurface geometry and is composed of 13 surfaces. The object with multisurface geometry has INSPIRE-ID "X". Now we deaggregate this object and we get 13 objects with surface geometry. Is there a valid way to enumerate these 13 objects to produce INSPIRE-IDs "X_1", "X_2", ... "X_13" and guarantee their identity for next update?

Best regards and many thanks,
Birgit & Damian

[fabiovinci]

Dear @ulbrichtd,

it seems there is no solution to guarantee the persistence of the identifier for the life cycle of a spatial object for such types of geometries.
Disaggregating the geometries as a post-processing operation will guarantee you the respect of the geometry constraint (automatically checked by the Validator) but will not allow you to guarantee compliance about the persistence of the identifier in case of an update of the dataset (constraint which requires a manual check).

The only definitive solution in these cases is to take into consideration the constraint during the generation of the dataset, creating single-part geometries and assigning them a unique identifier.