Duplicated entries in Production KLICs

[adam-ludera-intive]

In production KLIC we face issues with duplicated entries, i.e. the same data is provided twice. There are numerous samples, most recent with KLIC Number 19G468931 where the EigenTopo PNG layer for Utility Company (Netbeheerder) KL1040 is given twice - the same type and the same file is provided in the XML (ln. 73-78 and ln. 85-90). This is of course in regards to Manifest file (LI_19G468931.xml)

<bijlagePerNetbeheerder> <soortBijlage>eigenTopo</soortBijlage> <bestandLocatie>bronnen/KL1040/ET_Liander+N.V.+Pac+2Ai68G2_0000574962_19G468931.png</bestandLocatie> <bestandMediaType xlink:href="http://definities.geostandaarden.nl/imkl2015/id/waarde/BestandMediaTypeValue/PNG"/> <bestandIdentificator>ET_Liander+N.V.+Pac+2Ai68G2_0000574962_19G468931.png</bestandIdentificator> </bijlagePerNetbeheerder>

Those in our opinion should be filtered out (or validated) on Kadaster side and we shall only expect just a single instance of each type of layer per Utility Company and Discipline (thema). This relates to all layers: eigenTopo, planTopo, maatvoering, ligging, annotatie.

[FuatAkdeniz]

Naar aanleiding van bovenstaand issue zullen we een analyse uitvoeren.

[herman-vandenberg]

This problem still has our attention.
From our registration we were able to deduce that this occurred in the period from 17 September to now with 8 KLIC-requests. See the list below.

19G508063
19G543257
19G543262
19C033025
19G554736
19G560262
19G563752
19O090176

If you find that this happens more often, we would like to be informed.

[herman-vandenberg]

Incidentally it could happen that double attachments were delivered to a network operator (mainly caused by network problems). We have made the software more robust.
(internal reference: https://dev.kadaster.nl/jira/browse/KLCW-5065)