SU - AreaStatisticalUnit geometry type definition is not correct

[ulbrichtd]

Change proposal description

According to Commission Regulation (EU) No 1253/2013 the geometry type of AreaStatisticalUnit must be GM_MultiSurface (constraint on AreaStatisticalUnit in section 1.3.1.2.).

The document Data Specification on Statistical Units - Technical Guidelines is currently missing this information. The UML class diagram for "Vector package" (figure 7 in section 5.3.1.2.3) suggests that GM_Object is allowed to describe the geometry.

Addressed TG

Data Specification on Statistical Units - Technical Guidelines

Location

Data Specification on Statistical Units - Technical Guidelines

• UML class diagram for "Vector package" (figure 7 in section 5.3.1.2.3)
• a constraint on AreaStatisticalUnit is missing

Issue faced

The INSPIRE validator enforces at the moment geometries as GM_MultiSurface and does not allow GM_Surface. According to the Commission Regulation (EU) No 1253/2013 this is correct. According to the Data Specification on Statistical Units - Technical Guidelines GM_Surface should be allowed to describe the geometry.

Proposed solution

Update UML diagram mentioned above and/or add a constraint on AreaStatisticalUnit.

Pull request

Not available as the TG is not yet available in the repository.

Additional information

Impact on INSPIRE validator

Linked issue

INSPIRE-MIF/helpdesk-validator#714

[fabiovinci]

The constraint in the IR says:

The use of "should" is strange in a constraint since, as clearly stated in the MD TG (see screenshot below), this form of the verb shall be used for recommendations.

Let's discuss whether the "Constraints of the spatial object type AreaStatisticalUnit" should be treated as a "constraint" (and in this case, AreaStatisticalUnit must have a GM_MultiSurface reference geometry) or as a "recommendation".

In both cases, the TG must be amended.

[hogredan]

Dear @fabiovinci ,

the use of "should" is indeed strange as for other constraints in the IR usually "shall" or "must" are used.
I didn't check other translations but in the German translation, the constraint of AreaStatisticalUnit was translated as "shall".
Therefore, I assume that this is an error in the IR and suggest to treat the "Constraints of the spatial object type AreaStatisticalUnit" as a "constraint".

[fabiovinci]

Dear @hogredan,

I agree with you, it seems an error in the IR.

Looking at other translations, there are different results, e.g. in Italian, it has been translated as "should" and in Spanish, it seems that it has been translated as "shall".

[MarcoMinghini]

Checking the latest version of the IR, this is indeed the only occurrence of the word "should" in a Constraints section, which suggests that this in an error (unfortunately not spotted and thus not leading to a correction in the upcoming amended version).

[sMorrone]

Subgroup meeting on 24.03.2022:
support by the JRC is requested regarding the interpretation of the IR contraint.

[MarcoMinghini]

The JRC believes that the use of should in the IR constraint is a mistake, since constraints are meant to provide an obligation rather than a suggestion. However, there is no specific definition of 'constraint' in the IR ensuring that all constraints are indeed obligations (in contrast, constraints in the IR make use of several different terms such as have to, must, is required, can only be, applies only, can, have).

Therefore, we should still make it possible to use GM_Surface as a geometry, and relax the corresponding test in the INSPIRE Reference Validator (which at the moment enforces the use of GM_MultiSurface). At the same time, we should keep track of this issue to possibly update the legal text in the next revision.

[fabiovinci]

According to those conclusions, the related ATS has been modified and the test will be relaxed in the Validator.
Updates on the implementation status will be communicated through the related issue in the helpdesk-validator.

[fabiovinci]

The missing constraint was added to the TG and to the UML.
The issue will remain open to keep track of this issue to possibly update the legal text in the next revision of IR.