BAG API /Panden POST "Geografisch zoeken ..." werkt niet

Datasets BAG
#1

Een “https://bag.basisregistraties.overheid.nl/api/v1/panden?page=1” POST request van …

“{“geometrie”:{“within”:{“coordinates”:[[[4.884561314,52.356523535],[4.884448538,52.356528404],[4.884432207,52.356529117],[4.884134986,52.356541974],[4.884127511,52.356474992],[4.884595297,52.356454761],[4.884605982,52.356511933],[4.884607767,52.356521521],[4.884561314,52.356523535]]],“type”:“Polygon”}}}”

met headers (API Key ge-edit) …
[
{“Accept”, “application/hal+json”},
{“X-API-Key”, “…”}
]

resulteert in een response body met een lege lijst …
“_embedded” => %{“results” => []}

Dit is onjuist en treedt op sinds de BAG datamigratie van 26 juni 2020. Is reeds gemeld onder ticketnummer 10046953.

Heeft iemand een workaround als ik vanuit een individueel BRK perceel gerelateerde panden uit de BAG wil ophalen?

#2

Je zoekvraag geeft wel een antwoord als je de ‘within’ vervangt door de ‘intersects’ operatie. Je krijgt dan mogelijk wel meer panden terug als je 1 perceel opvraagt omdat je met deze operatie alle panden krijgt waarvan de geometrie door de zoekgeometrie loopt.

De reden dat de query met within niet meer werkt is omdat de nauwkeurigheid van onze nieuwe database een heel stuk hoger is dan de oude database. Waar we voorheen een nauwkeurigheid hadden van 10 meter met geoqueries, hebben we nu een nauwkeurigheid van milimeters. Omdat je met een within query alleen zoekt naar panden die binnen je zoekgeometrie liggen kreeg je voorheen wel resultaat (de geometrie waarmee gezocht werd was 10 meter meter ruimer), nu we op een nauwkeurigheid van millimeters zitten kwa zoeken valt het pand dat je eerder vond niet meer binnen de zoekgeometrie en krijg je dus met de within operatie een lege array. Het huidige antwoord is dus in principe correcter, het is alleen wel vervelend dat je nu ineens geen resultaten meer krijgt. Mijn advies is dus om de within te vervangen door een intersects.

Verder nog wel belangrijk om te beseffen dat de Digitale Kadastrale kaart waar je de BRK percelen hoogtwaarschijnlijk uit ophaalt geen 1-op-1 weergave is van de werkelijke ligging van percelen. Als je dus zoekt op basis van een perceel uit de Digitale Kadastrale kaart en een pand lijkt buiten het perceel te liggen dan wil dat niet zeggen dat dit in de werkelijkheid ook zo is.

#3

Het liefst zou ik in dit geval via percelen naar panden niet geometrisch willen zoeken maar bijvoorbeeld via een “perceelrelatering” analoog aan zoals pandrelatering dat in de BAG doet voor panden en verblijfsobjecten.

#4

De koppeling tussen een perceel en een pand zit nog niet in de DKK API en ik verwacht hem ook niet op de hele korte termijn. Je zou hiervoor wel de PDOK locatieserver kunnen gebruiken zoals Wouter ook al suggereert omtrent de vragen voor het ophalen van percelen.

#5

Dat vraagt per perceel een extra query naar de locatie server.

Zou ik de geometrie die ik vanuit BRK Percelen krijg vanuit het geometrisch zwaartepunt naar buiten met 1-2 meter kunnen oprekken en dan toch de BAG Panden geometrische {“geometrie”: {“within”: “opgerekte perceel geometrie”}} zoekopdracht kunnen gebruiken?

Moet uitzoeken hoe ik dat algoritmisch veilig doe en of dat kan. Moet natuurlijk wel werken voor elke willekeurige polygoon. Ben bang dat ik met intersect veel naastgelegen panden krijg die ik er dan weer uit moet filteren.

#6

De optie die je schetst kun je eens proberen, in de praktijk was dat ook wat er met onze vorige database gebeurde, daar kreeg je ook van een veel groter gebied de panden terug door de minder nauwkeurige zoekacties op geometrie.

Met een intersect zul je in veel gevallen zeker ook naastgelegen panden krijg, dat zie je zelfs al met de geometrie in Amsterdam die je bij je vraag meegaf.

#7

Dat geografisch matchen is mij toch wat te fuzzy … more art than science :slight_smile:

Na een kennismaking met de locatieserver vind ik die API best wel complex.

Kan iemand mij helpen met een locatieserver query om met bijvoorbeeld params {“kadastraleGemeentecode”:“ASD16”,“sectie”:“R”,perceelnummer:5050} de bijbehorende BAG /Panden te vinden met hun BAG “identificatiecode”?

#8

Ik heb sinds kort ook problemen met het geografisch zoeken via de BAG API. Ik heb bijvoorbeeld de volgende payload voor de call:
{“geometrie”:{“intersects”:{“type”:“Point”,“coordinates”:[51.91316,4.46057]}}}
Dit coördinaat is van een pand in Amsterdam, maar ik krijg panden terug vanuit de BAG API. Waar kan dit aan liggen en hoe zou ik dit kunnen oplossen?

#9

Je bent nu op zoek naar een punt in de Indische Oceaan ten oosten van Somalië. Coördinaten moet je als [lon, lat] opgeven.

#10

Ga toch het liefst vanuit de BRK Percelen direct naar BAG Panden met de geografische zoek mogelijkheid.

Gebruik nu geometrische zoekopdracht middels BAG Panden POST {“geometrie”: {“intersects”: “opgerekte perceel geometrie”}}. Dat geeft resultaten buiten het perceel. Mijn eigen pand in Amsterdam geeft 4 hits. Een ander pand in Amsterdam 2 hits.

Om deze panden verder te filteren bereken ik van elk (sub) pand het geometrisch centrum. Voor alle berekende geometrische centra moet gelden dat er een geometrie in het perceel is waarin dat centrum binnen valt.

Dat reduceert mijn beide testgevallen tot een enkel pand en het juiste pand. Voor mijn eigen pand geldt dat dit in één van de dichtstbevolkte gebieden van Nederland ligt. De Pijp heeft kleinere huizen dichter op elkaar. Zal daar ook een testcase prikken.

Vooralsnog tevreden met dit resultaat. Als geografische centrum niet voldoende onderscheidt kan ik de individuele punten van het (sub) pand polygoon aflopen en turven hoveel punten buiten de perceel geometrie vallen.

#11

Werkt een within met de opgerekte geometrie niet beter? Dat zou eigenlijk meteen het juiste resultaat moeten geven als je de geometrie de juiste hoeveelheid weet op te rekken.

#12

Was een typefoutje. De optie van de opgerekte geometrie was mij eerste idee. Maar dat is erg ingewikkeld als je complexe polygonen hebt. Gebruik dus nu de normale BRK Perceel geografie. Voorheen kon ik nooit mijn eigen pand terug vinden. Ook pre BAG migratie. Nu lukt dat wel.

Mocht ik toch nog panden tegen komen die niet bij een perceel horen dan kan ik dat geometrisch oplossen door het algoritme te verfijnen. Vergeleken met de netwerk latencies van twee extra queries heb ik voldoende tijd voor wat extra rekenwerk.

#13

Met geometrisch centrum: is dat dan een ‘echt punt’ binnen de geometry of het middelpunt/zwaartepunt van de bbox van het object? Gezien niet ieder pand een ‘nette’ rechthoek is is het ‘belangrijk’, omdat je mogelijk hier door ‘misses’ hebt op je zoekresultaat. (hangt denk ik ook af van de tooling die je hiervoor gebruikt…)

image

1 like
#14

geographic_center(points)

Compute the geographic center (aka geographic midpoint, center of gravity) for an array of geocoded objects and/or [lat,lon] arrays (can be mixed). Any objects missing coordinates are ignored. Follows the procedure documented at Geographic Midpoint Calculation Methods.

#15

Heb even een test uitgevoerd op een klein perceel ASD14-R-2150 in de Pijp met goed resultaat.

Daarna rond geshopt in Amsterdam naar wat vreemdsoortige pand/perceel vormen: ASD17-U-9249, ASD22-Z-698 en ASD23-AB-1707 … allemaal OK.

Het geometrich centrum schijnt als onderscheidend heel behoorlijk te werken. Natuurlijk werkt het niet voor bijvoorbeeld concentrische cirkels … de bekende dougnut. Moet er eerst een tijdje mee werken om een definitief oordeel te vormen.

Als wij een false negative introduceren door een pand te missen is dat geen ramp. Wat wel belangrijk is dat de positives goede betrouwbare attributen hebben. Die attributen worden aangeleverd door een lange pipeline van gestapelde filters.