Invalid Geometries delivered in KLIC

[adam-ludera-intive]

In KLIC 20G135476 we have found numerous invalid geometries that are delivered by GM0080 (Gemeente Leeuwarden Sector Wijkzaken). The geometries are declared to be 3D (srsDimension="3") but are given as 2D, eg.:

`

  <net:centrelineGeometry>
    <gml:Curve gml:id="nl.imkl-GM0080.108811_0_geo" srsDimension="3" srsName="EPSG:28992">
      <gml:segments><gml:LineStringSegment><gml:posList>185639.29 578663.82 185637.902338141 578668.568604343</gml:posList></gml:LineStringSegment></gml:segments>
    </gml:Curve>
  </net:centrelineGeometry>
  <!-- Removed for clarity -->

</us-net-common:UtilityLink>`

Moreover, it seems that Kadaster's Viewer displays those invalid geometries, which would imply that such issues were anticipated and an explicit workaround has been implemented. In such case, it would be expected that the Service Providers are informed prior to the situation happening in the production environment.

[herman-vandenberg]

The IMKL-data specification states that the geometry profile is mandatory in 2D. See IMKL2015_dataspecificatie 1.2.1: "Het verplichte geometrieprofiel van IMKL2015 is 2D. Primair bestaat de geometrie uit punten en lijnen die het netwerk representeren. 2D vlakken zijn additioneel." Note that with the objecttype "ExtraGeometrie" it is in principle possible to supply also 2.5D and 3D geometries, but that this option - in consultation with the sector - has not been implemented (yet).

Given the above, the relevant network operator has supplied incorrect network information. As can be concluded, KLIC is not currently validating this. We will point out to the network operator that this information is incorrect.

[adam-ludera-intive]

@herman-vandenberg to add to this, we have found another Beheerder with the same error in the supplied data: Gemeente Boxmeer (GM0756) in KLIC 20O021519.

The fact that the suppliers attempt to deliver 3D data, as per your analysis, is one thing, but please also make sure that the supplier is aware that they declare the data to be 3D (srsDimension="3") and yet the data itself comes with only 2 coordinates per vertice (185639.29 578663.82 185637.902338141 578668.568604343</gml:posList>). So the declaration does not match the data, which cannot be parsed by any geospatial engine as long as it is running complete validation.

[herman-vandenberg]

@adam-ludera-intive Thanks for you attention. It seems that GM0080 sometimes is using X-Y-coordinates, and sometimes X-Y-Z-coordinates (with Z-coordinate being "0"). We will also check GM0756 and notify this network-operator.

We will make an internal issue to add another validation to check on using the correct geometry profile.

[mwjhartogs]

Just read this post....

Seems our IMKL generator does something wrong with some geometries. GM0756 on 080 are our customers.

I've fixed our application and will do a new data delivery shortly.

[mwjhartogs]

updated the data

[herman-vandenberg]

Bedankt / Thanks!