Invalid Geometries delivered in KLIC

[szmucha]

In Klic 20G141489 we have received invalid geometry:

`

233529.702 581688.180 233536.497 581683.947 233527.233 581685.496 233529.702 581688.180 233527.967 581696.121 ` based on http://www.datypic.com/sc/niem21/e-gml32_Curve.html there is an assumption: "The curve segments are connected to one another, with the end point of each segment except the last being the start point of the next segment in the segment list." also I've found the same case asked by someone on osgeo: https://lists.osgeo.org/pipermail/gdal-dev/2016-July/044775.html Looks like https://www.klicviewer.nl/ skips this particular geometry (I can't find it based on vertices coordinates.

[herman-vandenberg]

@szmucha We have analyzed the delivery and we can confirm that invalid geometry is delivered by this network operator. We have just checked whether the error was possibly caused by our KLIC system. It appears that this geometry was "as-is" supplied by the network operator. We informed the network operator (GM0014) about this invalid data.

For your information: We intend to add an additional validation in one of our next sprints to check whether the line segment geometries match.

[JanGroenestein]

Gentlemen, I would like to know why Herman found this geometry invalid. It is found valid using Altova XMLSpy. Furthermore, the geometry contains a with two . If these two linestrings would have identical end- and startpoints this would make the possibility of having multiple useless, a single poslist would suffice then. If this method of building a geometry containing 2 or more separate linestrings is not allowed, can you advise me on how I can build the geometry without problems ?

[szmucha]

@JanGroenestein, please refer to my first comment. The problem I've pop up is not related to xml format (I'm not experienced with Altova XMLSpy software but as far as I know it may valid the XML schema only) but this issue is directly related to GML specyfic spatial data content. I've figured out this issue based on GDAL which is directly geo spatial tool.

[JanGroenestein]

@szmucha, XmlSpy validates an XML using the GML definition (or any other standard mentioned) so I conclude that the geometry is a valid GML. Nevertheless, I would like to know how you would like to see the geometry of an object that consists of two or more separate linestrings in GML. Can you show an example ?

[herman-vandenberg]

@JanGroenestein The geometry of many IMKL-objects is captured with the UtilityLink-object. It only allows a centrelineGeometry of type GM_Curve (not GM_MultiCurve). If the geometry consists of several separate segments, multiple UtilityLink-objects must be created. The IMKL-object must then refer to multiple UtilityLink's.

Example: netinformatie_20G141489_1 (GM0014).zip results in:

[JanGroenestein]

@herman-vandenberg Ok thank you, I can work with this.

[JanGroenestein]

The software is changed as required. The results should become visible after the weekend.

[herman-vandenberg]

@JanGroenestein Our servicedesk did a test-request with the same polygon, but the data were not changed already...

[JanGroenestein]

@herman-vandenberg Refresh of netinformatie is weekly, the update of the service was just after the refresh was done, I suspect. I made sure a refresh is done, can you test again ? Thanks in advance.

[herman-vandenberg]

@szmucha @JanGroenestein The network operator delivered correct geometry-segments now. Now only a small mistake about duplicated IDs remains. Our answer to the network operator / serviceprovider: "De nieuwe aanlevering hebben we gecontroleerd en ziet er – qua geometrie – correct uit! Dubbele links naar UtilityLink zijn correct doorgevoerd. Nog een klein verbeterpunt (en validatiefout): het ID van het geometrie-deel van de UtilityLink wordt dubbel gebruikt."

[JanGroenestein]

@szmucha @herman-vandenberg The problem should be fixed now, results will be visible early next week.

[adam-ludera-intive]

@herman-vandenberg same issue we spot in KLIC 20O028925 for GM0437 (Gem. Ouder-Amstel afdeling Bor)

For example GML Id: nl.imkl-GM0437.11030000000058EG (Utility Link)

1. The second segment ends with 124237.574 479090.613 and the next begins with 124147.709 478880.655;
2. The third ends with 123784.404 479212.960 and fourth begins with 123725.129 479357.414

Looking at the GML ID format those objects could be caused by the same software (@JanGroenestein)?

`

124687.478 477940.782 124688.521 477941.315 124687.811 477942.704 124675.135 477935.447 124626.121 478023.284 124573.142 478118.379 124528.287 478199.526 124479.498 478285.574 124430.860 478373.159 124381.541 478461.603 124310.306 478589.045 124275.224 478651.897 124235.824 478722.554 124212.087 478765.122 124183.676 478815.859 124147.709 478880.655 124147.709 478880.655 124148.209 478880.677 124148.154 478881.913 124147.288 478883.449 124155.668 478888.936 124161.622 478893.188 124168.314 478898.353 124173.664 478902.885 124176.764 478905.896 124183.010 478913.145 124182.670 478919.724 124182.033 478932.065 124181.680 478946.583 124182.264 478961.172 124183.955 478973.143 124187.150 478986.978 124191.393 478999.843 124192.005 479001.701 124198.310 479017.441 124205.494 479032.938 124213.817 479048.497 124224.172 479066.214 124233.748 479080.439 124236.730 479085.976 124237.574 479090.613 124147.709 478880.655 124147.660 478881.772 124145.500 478885.600 124143.363 478889.388 124142.482 478889.921 124100.981 478965.085 124092.733 478980.054 124084.527 478993.462 124082.663 478994.450 124080.156 478996.917 124070.710 479002.469 124038.019 478983.734 123973.307 478945.543 123950.470 478934.193 123946.673 478934.782 123937.501 478945.545 123932.425 478947.360 123918.292 478973.484 123913.967 478981.478 123893.760 479017.396 123831.327 479130.649 123784.404 479212.960 123725.129 479357.414 123726.260 479355.273 123730.931 479346.430 123730.283 479346.020 123723.580 479341.468 123722.598 479340.786 123721.743 479339.952 123721.037 479338.988 123720.501 479337.920 123720.148 479336.779 123719.989 479335.595 123720.028 479334.400 123720.264 479333.229 123720.690 479332.113 123721.294 479331.082 123722.586 479327.917 123723.800 479324.941 123726.632 479326.555 123728.543 479323.270 123738.784 479305.668 123738.817 479305.612 123741.846 479296.846 123741.970 479296.488 123742.332 479293.183 123751.958 479274.764 123771.836 479238.020 123784.694 479213.119 `

[herman-vandenberg]

@JanGroenestein Zijn jullie ook provider voor GM0437? Zo nee, dan moeten we KLIC-OIM weer inschakelen.

[JanGroenestein]

@herman-vandenberg Ja, dat is Ouder-Amstel, wij zijn provider voor deze gemeente. Ik heb het even nagekeken, de verbeterde netinformatie was inderdaad niet verzonden. Dat is nu verholpen.

[herman-vandenberg]

@JanGroenestein Thanks, we can see that the geometry for gml:id="nl.imkl-GM0437.11030000000058EA" is delivered now in 4 UtilityLink's!