Een milieuhygiënisch bodemonderzoek onderzoekt de aanwezigheid van verontreinigende stoffen in de bodem op een specifieke locatie. In deze BRO-dataset vind je gegevens over onderzoeken naar landbodems, drogere oevergebieden en grondwater. De resultaten omvatten informatie over meetpunten, monstername, veldwaarnemingen, laboratoriumanalyses van veldmonsters en kerngegevens uit bodemonderzoeksrapporten.
In eerste instantie bevat de dataset alleen zogenoemde ‘historische’ data; gegevens van onderzoeken die vóór 1 juli 2025 zijn uitgevoerd. Daarnaast zijn in de beginfase alleen data beschikbaar van een beperkte groep bronhouders. In de loop van 2025 zullen steeds meer bronhouders hun onderzoeksgegevens aanleveren aan de BRO, waarna deze via deze dataset beschikbaar komen.
URL’s
Dit zijn de URL’s waarmee de services van BRO Milieuhygiënisch bodemonderzoek (SAD) te benaderen zijn:
Na atom download was ook de (enige) geometrie tabel (soil_research) niet te zien, omdat het geometry_collection als geometrie type heeft, wat niet wordt ondersteund in QGis. Na wat uitzoekwerk bleken de geometrieën in werkelijkheid allemaal multipolygon’en te zijn, zodat een eenvoudige view of update query mbv st_collectionextract() voldoet om in QGis zichtbare resultaten te krijgen. Kan dit wellicht inspireren meer gebruiksvriendelijkheid in QGis?
Ik hoop dat de dekking snel toeneemt, nu nog sporadisch.
Excuses, ik was te vlug met st_collectionextract(), ik gebruikte alleen de default zonder nadere type aanduiding, die dan alleen geometrieën van de hoogste dimensie geeft.
De geometry_collections bevatten ook punten.
Hieronder mijn view query ter referentie:
(de dataset is met ogr2ogr naar postgresql omgezet waarbij de geo naar EPSG:7415 getransformeerd is).
create view bro.soil_research_geom_vw AS
WITH a AS (
select *,
st_collectionextract(geom, 1)::geometry(multipoint,7415) multipoint,
st_collectionextract(geom,2)::geometry(multilinestring,7415) multilinestring,
st_collectionextract(geom)::geometry(multipolygon,7415) multigon
from bro.soil_research
)
select soil_research_pk,
bro_id,
quality_regime,
delivery_accountable_party,
delivery_context,
report_date,
identification,
name,
project_type,
investigation_reason,
asbestos,
investigation_conclusion,
applied_transformation,
case when st_isempty(multipoint) then null else multipoint end,
case when st_isempty(multilinestring) then null else multilinestring end,
case when st_isempty(a.multigon) then null else a.multigon end multipolygon
from a;
Mooi dat de data als Geopackage wordt aangeleverd, maar zoals Jan ook concludeert is de data als ‘geometry collection’ opgeslagen. Open data in Geopackage zou als OGC Simple Features geometry type moeten worden opgeslagen. Anders is het nog geen open data… @PDOK kan dit aangepast worden?
Hallo @Marco_v_Antwerpen en @janhec,
Ik ben het met jullie eens dat data opgeslagen als geometry collection minder bruikbaar is. Wij hebben de data op deze manier aangeleverd gekregen van de BRO. Ik zal vragen of zij de geometrie kunnen uitsplitsen naar point en multipolygon.
Groeten,
Derek van Bochove (PDOK)
De link die je doorstuurt verwijst naar ‘Annex G: Geometry Types (Normative)’ van de ‘OGC® GeoPackage Encoding Standard’. In ‘Table 27. Geometry Type Codes (Core)’, van die bijlage zie ik GEOMETRYCOLLECTION gewoon staan
Verder ter informatie. In de abstract van de entry van de SAD ATOM Data Feed (de toelichting op de GPKG), is het volgende aangegeven;
Deze dataset bevat de volledige objectinformatie van alle milieuhygiënische bodemonderzoeken die zijn geregistreerd in de BRO. De dataset wordt aangeboden als geopackage. De SAD gegevenscatalogus (Milieuhygiënisch Bodemonderzoek (SAD)) is opgenomen op de BRO Productomgeving. Hier vindt men ook de gegevensdefinitie, met daarin onder andere een omschrijving van alle entiteiten en attributen.
De gestandaardiseerde locatie van het Bodemonderzoek is een multi-geometrie die bestaat uit de contour van de onderzoekslocatie en de locaties van alle meetpunten (contour onderzoekslocatie van de entiteit Bodemonderzoek en aangeleverde locatie van de entiteit Meetpunt).
Het maakt het mogelijk alle gegevens in de registratie ondergrond in één en hetzelfde referentiestelsel te ontsluiten.
Het is dus nu eenmaal op deze manier gestandaardiseerd…
Om alleen de contour onderzoekslocatie (van Bodemonderzoek; GM_MultiSurface) of alleen de aangeleverde locatie (van Meetpunt; GM_Point) als gestandaardiseerde (ETRS89 - EPSG:4258) geometrie te extraheren, zou je een methodiek zoals voorgesteld door janhec kunnen volgen. Het lijkt me dat je dit ook in een programma als DBeaver kunt uitvoeren zonder eerst ogr2ogr te gebruiken.
Verder zijn de aangeleverde locaties van deze entiteiten ook opgenomen in de dataset. Dit zijn dus de geometrieën in het referentiestelsel waarin ze zijn aangeleverd (waarvoor verschillende opties zijn).
Helaas is dit wel op een m.i. onhandige manier opgenomen. Zie ook de bro_location tabel, en de verwante subtabellen.
In geval van de aangeleverde locatie van het Meetpunt gaat het dan verder om de tabel bro_point.
In geval van de contour onderzoekslocatie van het Bodemonderzoek gaat het dan verder om de tabellen bro_multi_polygon, bro_polygon, bro_interior, bro_linear_ring & bro_point…
Ik heb reeds een wijzigingsverzoek ingediend of aangeleverde geometrieën in een meer reguliere encoding zoals GML of GeoJSON opgenomen zou kunnen worden. Hier is reeds naar gekeken, maar ik begreep dat dit nog niet is gereleased ivm behoud backwards compatability van bestaande ATOM services/datasets.
