Hoe zijn adressen aan gebouwen gerelateerd?

Hoi,

Wij krijgen door onze klanten lijsten met adressen aangeleverd, en vervolgens moeten we voor al die adressen de gerelateerde gebouwen vinden. Tot dusver hebben we dat op een beetje onbetrouwbare manier gedaan, namelijk als volgt:

  1. We geocoden het adres naar een coordinaat
  2. We zoeken het perceel dat dit coordinaat bevat
  3. We zoeken alle gebouwen die in het perceel liggen, of daar mee snijden

Vooral die laatste stap is onzeker. We krijgen veel false positives wanneer een gebouw over het perceel van de buren rijkt.

Is er een directere verbinding tussen adressen en gebouwen, of percelen en gebouwen?

1 like

Dat je deze vraag in deze Categorie>BAG (basisregistratie adressen en gebouwen) weet te plaatsten betekent dat je al een heel eind bent :smiley:

Als jullie een lijst van adressen hebben is de eerste (?) stap deze te relateren aan verblijfsobjecten (een object binnen de BAG). Verblijfobjecten bevatten naast ā€˜adres gegevensā€™ (waarmee je het juiste object mee kan zoeken/vinden) ook een pandidentificatie attribuut! Deze identificatie kan je gebruiken om het bijbehorende pand er bij te zoeken.


voorbeeld OGC WFS request
https://geodata.nationaalgeoregister.nl/bag/wfs/v1_2-preprod?request=getfeature&service=wfs&version=2.0.0&count=10&typename=bag:verblijfsobject&outputformat=application/json

Nu is de ā€˜vervolgā€™ vraag welke technieken willen jullie inzetten/gebruiken. Je kan dit met OGC webservices doen, de BAG API of de locatieserverā€¦ zie hier voor overzicht
Misschien kunnen jullie aangegeven welke tooling jullie nu gebruiken? Dan kan er mogelijk een gerichter antwoord (qua techniek) gevonden worden.

1 like

Thanks @wouter.visscher! We gebruiken nu voornamelijk de BAG REST API en de locatieserver. Hoe komen we aan het verblijfsobject? Ik zie niets daar over in de resultaten van de locatieserver.

Zijn dit soort dingen makkelijker met de WFS? ik dacht dat dat vooral voor geoqueries bedoeld was.

Oh ik zie net dat die adresseerbaar_object code een verblijfsobject is, dus op die manier?

edit:

Ok ik heb hem, we hebben voor elk adres een BAG id gekregen, dat id is voor een nummeraanduiding, dus dan vullen we die in op de nummeraanduiding API dan krijgen we een object waarin een link staat naar een adresseerbaar object wat een verblijfsobject is, en dan queryen we die, dan krijgen we het verblijfsobject waar de pandrelatering in zit, en dan belanden we uiteindelijk bij het pand.

Zou je dat in 1x kunnen doen met een fancy sparql query?

Jazeker, de basis query ziet er ongeveer zo uit:

PREFIX bag: <http://bag.basisregistraties.overheid.nl/def/bag#>
SELECT * WHERE {
  ?nummeraanduiding a bag:Nummeraanduiding ;
    bag:identificatiecode "0313200000219038" .
  OPTIONAL {
    ?adresseerbaarObject bag:hoofdadres | bag:nevenadres ?nummeraanduiding .
    OPTIONAL {
      ?adresseerbaarObject bag:pandrelatering ?pand .
    }
  }
} LIMIT 10

Kan je ook hier zelf proberen in YASGUI.

Moet er wel een paar kanttekeningen bij maken:

  • Een adresseerbaar object is een verblifjsobject, of een standplaats, of een ligplaats. Er zijn niet heel veel stand- en ligplaatsen in vergelijking met verblijfsobjecten, maar je zult er wel rekening mee moeten houden (in de REST API trouwens ook).
  • Op de BAG REST API mag je altijd een redelijke performance verwachten. Op het SPARQL endpoint ligt de performance heel sterk aan de query die je doet, en kan je bij een ā€œverkeerdeā€ query al snel tegen een timeout aan lopen.
1 like