NWB wegen opgenomen in de Locatieserver (test)

Toepassingen LocatieServer
#1

De afgelopende periode zijn we bij PDOK druk bezig geweest om de NWB wegen op te nemen in de Locatieserver. De NWB en BAG zijn gematched met als gevolg een toename van het aantal wegen die vindbaar zijn in de Locatieserver. We ontvangen graag feedback alvorens we dit in de week van 21 - 25 mei opnemen in de productieversie.

De belangrijkste features:

  1. Het matchen resulteert in een gezamenlijk bron “BAG-NWB” (zonder hectometerpunten)
  2. Wegen die in de NWB zitten bevatten vlakgeometrie en worden (indien aanwezig) teruggeven (ook interessant voor eventuele highlighting)
  3. Wegen die niet in de NWB zitten worden uit de BAG teruggeven (Openbare ruimte gekoppeld aan een adres)
  4. Standaard geeft de Locatieserver de BAG en NWB (zonder hectometerpunten ) terug
  5. Net zoals bij het toevoegen van de percelen (DKK) kun je de hectometerpunten apart toevoegen aan het filter (zie ook eerdere afstemming omtrent filtering: https://forum.pdok.nl/t/feedback-filtering-suggestservice-locatieserver/463/5)

De test URL betreft http://test.geodata.nationaalgeoregister.nl/locatieserver/<versie>/<endpoint>

De documentatie op GitHub zal bij het in productie nemen worden bijgewerkt. Een eerste versie van de nieuwe documentatie is alvast hieronder te vinden (aan optimalisatie van de documentatie wordt gewerkt).

Zoekvoorbeelden-Locatieserver.pdf (77,7 KB)
API-Locatieserver.pdf (98,2 KB)

Op dit moment zijn we ook druk bezig met het toevoegen van overige datasets en functionaliteit aan de Locatieserver (https://forum.pdok.nl/t/nieuwe-databronnen-en-functionaliteit/1252/5). Zodra dit ver genoeg is om te testen zullen wij dit communiceren.

3 likes
#2
#3

Heel mooi dat er nieuwe bronnen beschikbaar komen in de locatieserver en dat er verder aan wordt gewerkt! Het volgende valt mij op:

  • In het nieuwsbericht wordt gesproken over de nieuwe bron “BAG/NWB”. In de (voorlopige) documentatie “API-Locatieserver.pdf” komt die bron echter niet voor, alleen de bron “NWB”. Er staat ook niet vermeld dat de “BAG/NWB” de nieuwe standaard wordt.
  • Bij 3.1 in “API-Locatieserver.pdf” staat vermeld dat de “sortering niet langer gefixeerd is zoals voorheen”. Het lijkt nu net of dit nieuw is bij de locatieserver, maar dit is niet het geval volgens mij.
#4

De volgende feedback na uitvoeren van diverse testen op de test omgeving:

  • Alleen de bron “BAG/NWB” lijkt actief te zijn in de testomgeving: de andere in de documentatie “API-Locatieserver.pdf” genoemde bronnen als CBS en HWH lijken niets op te leveren bij de suggest. Misschien mis ik iets bij het zoeken?
  • De bron “Bestuurlijke grenzen” heeft als enige bron geen afkorting van 3 letters. is dit juist?
#5

@hbaan bedankt voor je waardevolle feedback! Hierbij een reactie:

1e bullet: klopt inderdaad, dat ontbreekt nog in de documentatie. Gaan we aanvullen.
2e bullet: gaan we verduidelijken.
3e bullet: de andere bronnen zijn nog niet beschikbaar om te testen. Enkel de NWB wegen. Eerdaags zullen ook de overige datasets beschikbaar worden gesteld om te testen. Ik meen dat in het bericht te hebben vermeld heb ik over het hoofd gezien.
4e bullet: klopt. We kennen hier geen vergelijking voor (in de volksmond) dus hebben we dit volledig uitgeschreven gehouden.

#6

Jeroen: dank voor je snelle reactie en duidelijke antwoorden!

#7

Klopt het dat de nieuwe functionaliteit in deze testversie weer onbeschikbaar is gemaakt?
http://test.geodata.nationaalgeoregister.nl/locatieserver/v3/lookup?id=weg-562fa6cf1b6d38ffce8c4a2079f6463d&fl=*
Deze URL gaf gister nog ‘multiline geometrie’ en bron ‘NWB/BAG’ terug, maar op dit moment een ‘point’ met de bron ‘BAG’, wat identiek is aan de productieversie.

#8

@JWSjoukema nee de functionaliteit bestaat nog maar we zien dat de nieuwe levering van de NWB wegen voorloopnullen bevat waardoor de matching bij gemeenten met een voorloop nul (bijvoorbeeld Apeldoorn “0200”) niet meer gedaan wordt. We gaan het nu zo aanpassen zodat we de data met voorloopnullen kunnen matchen. Ga er maar vanuit dat dit uiterlijk morgen eind van de dag weer hersteld is. Excuses voor het ongemak!

1 like
#9

Ah duidelijk! Bij een ‘nieuwe’ gemeente zonder voorloopnullen doet ie het wel gewoon inderdaad:
http://geodata.nationaalgeoregister.nl/locatieserver/v3/lookup?id=weg-a5a7b9d5ae0ba7e30619339d5e8dc8c7&fl=*
Succes met de aanpassingen!

Ps. Weten jullie al wanneer jullie deze versie in productie gaan nemen?

#10

We waren bezig met live gang maar er is een storing met de Locatieserver (zie ander topic). Het is nu uitgerold op productie en je vindt de nieuwe data wel maar bij gemeentes met een voorloopnul krijg je nog geen resultaat of de oude BAG geometrie terug (beide conform oude situatie). Zodra de storing voorbij is fixen we dit issue met de voorloopnul en zal ik de aankondiging breder communiceren.

1 like
#11

Mooi dat het uitgerold is in productie! De feedback punten 1 en 2 zijn echter niet aangepast in de documentatie op GitHub: API Locatieserver · PDOK/locatieserver Wiki · GitHub?

#12

Wordt aan gewerkt! :’)

#13

De documentatie is bijgewerkt

1 like
#14

Dank voor de snelle reactie en de update!

1 like
#15

Hierbij een reactie vanuit de BAG als gebruiker van de locatieserver in de BAG-viewer.

De nieuwe versie werkt goed. Het is prettig dat de locatie van openbare ruimten is toegevoegd aan de zoekservice. Openbare ruimten die zijn gekoppeld zijn nu beter te vinden via de BAG-viewer.

Vraag: Zijn alle openbare ruimtetypes uit de BAG gekoppeld, of zijn sommige types uitgezonderd?

Opmerking: We liepen wel tegen het probleem aan dat we nu ook resultaten krijgen van openbare ruimten die niet in de BAG voorkomen.

Het lastige hierbij is dat het veld openbareruimte_id wel gevuld is, maar dat het een NWB-ID is in plaats van een BAG-ID. Het ID is in dat geval namelijk niet te gebruiken om gedetailleerde gegevens uit de BAG op te vragen.

Vanuit de BAG gezien vinden we het wenselijk dat het veld openbareruimte_id alleen een BAG-ID kan bevatten, zodat de inhoud niet afhankelijk is van de bronnen die je bevraagt. Voor het NWB-ID zou dan een apart veld gebruikt kunnen worden. Dat geeft ook meteen ook informatie over de koppeling.

In de BAG-viewer lossen we het probleem overigens op door alleen de BAG als bron te raadplegen. Hierdoor ontvangen we alleen resultaten waarin een BAG-ID is opgenomen in het veld openbareruimte_id.

#16

Hoi, naw het nieuws dat er NWB data was geladen even gezocht op een straat waarvan ik weet dat er volgens mij geen adressen zijn… dus nooit werd gevonden: de Batauweg in Nieuwegein. Ik zie dan:

win10 on QEMU-KVM_506
win10 on QEMU-KVM_5061304×884 397 KB

Mooi!
Opmerkingen:

  • het punt in het record ligt niet OP een punt in de straat? Misschien centroide van de bbox genomen? Zou mooier zijn als het punt wel OP de weg ligt.
  • ‘bron’ meldt (zie screendumpje): BAG/NWB… is dat zo? Ik dacht namelijk dat er geen adressen aan de Batauweg lagen, dus… de bron zou dan alleen NWB moeten vermelden? Dan zou @PieterDijkstraBAG namelijk het bron-veld kunnen gebruiken om te kunnen weten of het een BAG object is niet? Zeker wanneer de id’s later gebruikt moeten/kunnen worden is het wel belangrijk om te weten wat voor een id het is (noem het ‘brontype’ of ‘bron’ of ‘idtype’?)

(Opmerking: ik weet niet 100% zeker of batauweg niet in de bag zit…)

1 like
#17

De Batauweg zat als weg wel al in de BAG, maar omdat er inderdaad geen adressen aan liggen, was deze voorheen niet beschikbaar in de locatieserver. Nu met het NWB is het mogelijk om de NWB geometrie aan de weg te koppelen, waardoor die nu wel vindbaar is.

De centroide gebruikt momenteel inderdaad de boundingbox van de line geometrie, we zullen kijken of we dit kunnen verbeteren.

#18

Wat @Wouter_Remijn zegt!

De Batauweg in Nieuwegein bestaat in de BAG. zie:
https://bagviewer.kadaster.nl/lvbag/bag-viewer/#?searchQuery=batauweg&resultOffset=0&detailsObjectId=0356300000001010&objectId=0356300000001010&geometry.x=133605.789&geometry.y=450254.711&zoomlevel=4

Het veld openbareruimte_ID bevat in dit geval het BAG-ID: 0356300000001010

Voor de koppeling is het niet vereist dat er adressen aan de openbare ruimte gelegen zijn. Voor het raadplegen van de BAG zit hier juist de meerwaarde. In de BAG viewer kunnen nu ook openbare ruimten zonder gerelateerde adressen gevonden worden.

#19

@rduivenvoorde
Op onze test omgeving hebben de centroide nu verplaats naar het dichtstbijzijnde punt op de weg geometrie.
Hierdoor zal de centroide op de weg staan.

@PieterDijkstraBAG
Op onze test omgeving zijn de nwb_ids uit het openbareruimte_id gehaald. Er is nu een apart nwb_id veld voor gemaakt.

Deze aanpassing zijn dus te bekijken op onze test omgeving:
http://test.geodata.nationaalgeoregister.nl/locatieserver/<versie>/<endpoint>

En zullen samen met de andere nieuwe datasets in de week van 21 juni naar productie worden gebracht

1 like