Best practices data importeren in postgresql

Datasets
#1

Hallo, ik ben op zoek naar wat best practices om grote datasets te importeren in een postgresql/postgis database bij Amazon. het gaat voornamelijk om: de kadastrale perceelgrenzen, 3D BAG data en ruimtelijk plannen bestemmingsinformatie

  • welke tools gebruiken jullie hiervoor? importeer je de data eerst in een andere tool om te converteren?
  • ik zie dat op PDOK de kadastralekaart download API aanbevolen wordt. Dit levert een GML bestand op. is het mogelijk dit te importeren in PostGis?
  • 3D bag levert GPKG. moet dit eerst geconverteerd worden?
  • ruimtelijke plannen is een ATOM feed blijkbaar. weer iets anders.

sorry voor de beginnersvragen :slight_smile: tot nu toe gebruiken wij vooral WFS feeds en dat ging prima, maar om alle data te importeren ben ik vooral even op zoek naar wat tips over hoe dit het snelst te doen.

#2

Voor grote datasets gebruik ik het liefst ogr2ogr. Hier 2 voorbeeldjes:

ogr2ogr -f "PostgreSQL" PG:"host=0.0.0.0 port=5432 user=xxx dbname=xxx password=xxx" -nln bag3d.lod13_2d 3dbag_nl.gpkg lod13_2d
ogr2ogr -f "PostgreSQL" PG:"host=0.0.0.0 port=5432 user=xxx dbname=xxx password=xxx" Enkelbestemming.gml -nln enkelbestemming
#3

dank je wel @raymondnijssen ! Dit helpt al een heel eind.
Heb je nog tips om Kdaster data te importeren? ogr2ogr loopt er tegen aan dat de kolom namen ingekort moeten worden, en het resultaat is dat de kolom namen hetzelfde zijn…

deze 2:
kadastraleAanduiding|TypeKadastraleAanduiding|kadastraleGemeente|KadastraleGemeente|code
kadastraleAanduiding|TypeKadastraleAanduiding|kadastraleGemeente|KadastraleGemeente|waarde

worden ingekort tot
kadastraleaanduiding|typekadastraleaanduiding|kadastralegemeent

en dan krijg je dus dubbelen…

#4

Ik begrijp niet precies wat je bedoelt, maar kijk eens in de ogr2ogr opties.

Met name:
-sql
-fieldmap
-relaxedFieldNameMatch

https://gdal.org/programs/ogr2ogr.html

#5

ik snap het inmiddels. -sql was het antwoord, dank je

Ik heb een andere vraag (sorry ik heb niet echt een andere manier om dit uit te vinden…)

De GML dataset van het kadaster (kadastralegrens) is 40GB. ogr2ogr ‘hangt’ bij het importeren hiervan. Ik heb geprobeerd een stukje te gebruiken en dat werkt wel, dus het ligt inderdaad aan de grootte. Importeren van de andere kadaster dataset (perceel) werkt wel. Is dit een probleem wat je herkent?

mijn eigen computer heeft 24gb geheugen en een 1tb harde schijf dus dat lijkt mij toch niet echt het probleem…

#6

Goeiemorgen Erik,

Even als puntje van aandacht: ik weet niet waarom je de volledige datset van de BRK lokaal wil hebben, maar je realiseert je dat die gegevens inmiddels al weer veranderd zijn sinds je download?

Verder: Kadastralegrens zijn de losse lijnen, perceel zijn vlakken. Ik weet niet of dat uitmaakt voor jouw doel, maar daar zit een groot deel van het verschil in grootte van de bestanden in. En het maakt dus ook verschil in wat je er mee wilt gaan doen: voor sommige doelen zijn de afzonderlijke grenzen beter, voor andere doelen is het handiger om de gegevens als vlak te hebben.

Groet,
Stefan

#7

Hallo Stefan,

het doel uiteindelijk is om er queries op te doen gerelateerd aan andere datasets. Simpel voorbeeld: Geef alle percelen in een bepaalde gemeente met een bepaalde bestemming. Ik heb een prototype dat dit kan, mijn belangrijkste uitdaging is het importeren van de data. Ik heb dus uiteindelijk de echte grenzen nodig van de percelen.

Dank je wel. Je noemt iets interessants; in de dataset Perceel zie ik vooral veel Points met alleen een lat/lon punt. Daarom ging ik er van uit dat de Polygon informatie in kadastralegrens zou zitten. Is dit niet correct? Dit zou opzicht fijn zijn, dat scheelt me een dataset.

#8

Als je de GML goed bekijkt, dan zie je dat dat 1 object is dat bestaat uit een polygoon met een punt. Het punt is de plaatsing van het perceelnummer als dat niet binnen het vlak kan. Overigens: waarom lat/lon? Jouw vraag zou ik in RD houden… En kan in principe ook met wfs en api’s, want als je alles lokaal neerzet, moet je alles ook lokaal bijhouden - anders is je data al heel snel verouderd.

#9

het lijkt me niet dat dat met wfs en api’s kan, omdat er veel databases gecombineerd worden. Mijn voorbeelden waren maar voorbeelden, maar ik wil ook ingewikkelde dingen met bijvoorbeeld de 3dbag dataset. ‘alle percelen met gebouwen hoger dan 30 meter’ etc. Ik weet dat ik de data up-to-date zal moeten houden, dit is geen probleem.

Latlon is uiteindelijk wat er in een kaart getoond zal moeten worden.

#10

Ok, ik ben een stapje verder maar ik ben er nog niet

Het blijkt dat de GML van het kadaster 2 geo objecten bevat: plaatscoordinaten en begrenzingPerceel

Bij het importeren van de data met ogr2ogr selecteert ogr2ogr alleen plaatstcoordinaten, en dit zijn punten

Hoe vertel ik Ogr2ogr dat ik beide nodig heb?

Dit werkt niet:

ogr2ogr -f “PostgreSQL” PG:“removed” “kadastralekaart_perceel.gml” -sql “SELECT
gml_id AS gml_id,
plaatscoordinaten AS plaatscoordinaten,
begrenzingPerceel AS begrenzingperceel
FROM perceel” -progress -overwrite

#11

Da’s een bekend probleem zoals dat ook bij BGT speelt. Zie voor een uitgebreide uitleg: De QGIS BGT plugin – Nederlandse QGIS gebruikerscommunity

In de praktijk kun je door het correct manipuleren van het .gfs bestand dat ogr2ogr maakt bij importeren (of gebruik van ogrinfo) ervoor zorgen dat ie de door jou gewenste geometrie pakt.

#12

super dank je! ik heb hem inderdaad. De gfs file had ik even over het hoofd gezien