Problemen met ruimtelijke plannen ATOM feeds

Datasets
#1

Hallo,
wij ervaren sinds deze maand meerdere problemen met de ruimtelijke plannen ATOM download beschikbaar via PDOK. Het gaat in elk geval om enkelbestemming, bouwvlak en maatvoering.

  • velden zijn hernoemd (geometrie <-> geom)
  • veel geometrien zijn niet valid (in postgis te valideren met de query ‘SELECT * FROM enkelbestemming WHERE NOT ST_IsValid(enkelbestemming.geom)’. Dit was voorheen niet het geval
  • geometrieen hebben andere hoeveelheden coordinaten

Het lijkt wel of de geometrieen op een andere manier geëxporteerd zijn of iets dergelijks

Weet iemand of er iets veranderd is of wat er aan de hand kan zijn?

Hier een van een problematische geometrie (Bouwvlak NL.IMRO.e6c1747e11fb42938f7a6c77850809a4):

En een uitsnede van het problematische gedeelte:

2 likes
#2

Dank voor je bericht, we hebben je melding meegenomen voor verder onderzoek.

#3

Dank je Anouk. Heb je inmiddels al meer informatie?

Van je collega heb ik het volgende antwoord gekregen:

‘Wij hebben de dataset ruimtelijke plannen gepubliceerd onder creative commons. In dit geval houdt dat in dat er geen auteursrechten zijn, tevens is er geen garantie en geen aansprakelijkheid.’

Niet erg behulpzaam dus.

#4

In ieder geval is bovenstaand antwoord correct, maar ik begrijp dat dit jou niet verder helpt. Met input van de dienst Ruimtelijke plannen wil ik je graag het onderstaande delen:

Destijds is de update van de Ruimtelijke Plannen INSPIRE as-is dataset voor de download uitgevoerd met een verkeerd datamodel. Inmiddels is dit hersteld door een nieuwe aanlevering en de update is verwerkt.
Om alles uit te sluiten is mijn eerste vraag, maak je gebruik van de meest recente data?

#5

Hallo Anouk,

Dank voor je antwoord. Weet je nog waneer dat ongeveer was? Klinkt namelijk wel alsof dat het probleem zou kunnen zijn, echter voor zover ik kan zien is het probleem nog wel aanwezig in de downloads die wij gebruiken. Misschien zit er nog iets vast in een cache ergens… ?

Ik gebruik inderdaad in onze scripts een directe download, die 1-1 geïmporteerd wordt in onze database, waarna de bewerkingen worden gedaan die wij nodig hebben. De laatste keer dat ik het geprobeerd heb is eind vorige week geweest. Hierbij zie ik de verschillen nog steeds.

De link die wij gebruiken:
https://service.pdok.nl/kadaster/plu/atom/v1_0/downloads/Bouwvlak.gml.gz
(En dan voor enkelbestemming, maatvoering etc dezelfde links maar dan Enkelbestemming.gml.gz etc)

de pdok pagina:
https://www.pdok.nl/atom-downloadservices/-/article/ruimtelijke-plannen#51158a77a67fb84de3d97edcca28eabc

1 like
#6

Hoi Erik,
De vernieuwde set is omstreeks 12 juli geplaatst. Ik verwacht dat jij omstreeks 3 juli de download hebt uitgevoerd. De set van 12 juli hebben wij gecontroleerd en deze is geheel conform de leveringen zoals deze voor 1 juli ook al plaats vonden, dus zelfde datamodel en opbouw geometrie.
Ik verwacht dat je hiermee dus geholpen zult zijn.
Groeten, Merijn

1 like
#7

Hallo @MerijnKerlen en @Anouk

Ik heb het zojuist nogmaals geprobeerd met de Bouwvlak dataset, en ik zie nog steeds problemen en verschillen met voorheen.

Hier een stap-voor-stap overzicht van wat ik doe, in de vorm van een log van onze scripts. Deze doet deze stappen:

  • Downloaden dataset
  • Unzippen dataset
  • Importeren van de gml file in een PostGIS database met behulp van ogr2ogr, een standaard tool waar wij dit mee doen.

2024-09-01 21:20:56: Starting download https://service.pdok.nl/kadaster/plu/atom/v1_0/downloads/Bouwvlak.gml.gz

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 378M 100 378M 0 0 8186k 0 0:00:47 0:00:47 --:–:-- 8362k

2024-09-01 21:21:44: Starting unzip Bouwvlak.gml.gz

2024-09-01 21:22:37: Starting ogr Bouwvlak.gml on database geodata-playground

2024-09-01 21:23:19: ogr2ogr -f PostgreSQL PG:***** /Volumes/Passport/tmp/Bouwvlak.gml -progress -overwrite

0…10…20…30…40…50…60…70…80…90…100 - done.

Hierna voer ik op de tabel ‘bouwvlak’ deze query uit:
“SELECT COUNT(*) FROM bouwvlak WHERE NOT ST_IsValid(geometrie)”

Hierbij krijg ik 14 hits. Dit wil zeggen dat er nog steeds invalide geometrie zijn.

Daarnaast heet de geometry column ‘geometrie’, dit was voorheen ook niet zo. Bovendien is de geometrie zelf ook echt anders, zie vergelijking zoals ik hierboven gemaakt heb.

Zoals ik het kan zien zijn er echt verschillen met de situatie van vóór juli. Onze python scripts van voor die tijd doen het in elk geval niet meer op deze dataset.

Graag advies

1 like
#8

Hallo Erik,
Je hebt van mij een aparte mail ontvangen waarin ik dieper ben ingegaan op jouw bevindingen. Wij hebben in ieder geval een vergelijk uitgevoerd tussen de leveringen van 1 januari 2024 en 1 juli 2024. Deze gebruiken beide hetzelfde datamodel en de data van overeenkomende objecten is ook identiek, inclusief de geometrie.Dit hebben we ondermeer vergeleken voor NL.IMRO.e6c1747e11fb42938f7a6c77850809a4. De naamgeving van de geometrie is dus ook niet gewijzigd, ook 1 januari (en daarvoor) heette deze al geometrie.
Wat betreft de geometrische fouten zoals jouw uitsnede in blauw/rood; dit betreft een self intersect die vermoedelijk bij de tekenaar van het ruimtelijk plan is ontstaan, mogelijk door omzetting van CAD naar GIS. Dit soort kleine tekenfouten komen soms voor en vallen normaliter binnen de toleranties. In situatie NL.IMRO.e6c1747e11fb42938f7a6c77850809a4 is deze afmeting ruimschoots kleiner dan 0,1 mm.

1 like
#9

Ik heb inmiddels begrepen dat de levering door PDOK en de inhoud van Ruimtelijke plannen correct zijn en er een aanpassing in het gebruik heeft plaatsgevonden.

Voor een gebruiker die met dezelfde situatie stoeit is het zinvol om het juiste gebruik in deze post op te nemen. @erik1 mocht je nog in de gelegenheid zijn?

#10

Hallo Anouk dank voor je reactie, en ik ben er inmiddels inderdaad uit met hulp van Merijn! Het bleek een combinatie te zijn van een foutieve dataset in juli, en een library aan onze kant die gelijktijdig ge-update was, faalde, en daar geen feedback over gaf wat mij op het verkeerde spoor zette. Alles werkt nu naar behoren

Dank voor het meedenken!

1 like