Hier kan een ieder zijn of haar wensen kwijt.
Ha, leuk initiatief dat locatieserver. Op http://www.geonovum.nl/sites/default/files/Quita%20Goede%20en%20Wimfred%20Grashoff%20â%20Geo-informatie%20bij%20Politie%3B%20locatieserver%202.0.pdf zie ik dat de politie geinterresseerd is om deze applicatie te delen, wordt n open source licentie overwogen? indien ja, dan zou ik aanraden om de code via n git platform beschikbaar te maken en een gekoppelde issuetracker te gebruiken om wensen en fouten te registreren, ik vind t zelf vaak t handigste om tussen issues, pull requests en code naar elkaar te verwijzen binnen 1 platform
1 like
Goede vraag! We kunnen hier nog geen concreet antwoord op geven. Dit onderwerp staat nog op de agenda voor een vervolgoverleg (politie en PDOK). Omdat er op dit moment geen sprake van is hebben we gekozen voor deze community vorm zodat we snel en transparant kunnen schakelen. Mocht het in de toekomst een open source licentie krijgen dan zal de door jouw voorgestelde vorm zeker de meest raadzame richting zijn!
De locatieserver bevat nog geen openbare ruimten waaraan geen adres is gekoppeld in de BAG.
Enkele voorbeelden zijn:
Goffert in Nijmegen
Industrieterrein Kromme Gouwe in Gouda
Vanuit de BAG zien we graag dat de locatieserver ook gegevens levert van deze openbare ruimten waaraan in de BAG geen adressen zijn gekoppeld. Van deze openbare ruimten is weliswaar geen geometrie beschikbaar in de LV BAG (die wordt nu eenmaal niet geregistreerd), maar de openbare ruimte bestaat wel.
Het zou daarom fijn zijn dat van deze openbare ruimten wel de naam en het BAGID wordt geleverd (en dus niet de geometrie). Er zou voor gekozen kunnen worden de geometrie van de woonplaats te leveren en voor de toekomst wellicht de geometrie van de openbare ruimte zoals die bekend is in de NWB.
Nog een wens vanuit de BAG:
Het zou fijn zijn als het mogelijk wordt te zoeken op ingetrokken/gesloopte BAG-objecten. Deze BAG-objecten bestaan in de praktijk niet meer maar hebben wel bestaan. Om ervoor te zorgen dat gebruikers die alleen geĂŻnteresseerd zijn in bestaande (huidige) objecten ligt het voor de hand dat gebruikers in hun request kunnen opgeven dat ook gezocht wordt op historische objecten.
In de bijlage hieronder gaat het om het adres Vrijthof 5 (dus zonder toevoeging) in Ommen.
@PieterDijkstraBAG er is voor gekozen om openbare ruimten zonder geometrie niet terug te geven omdat de geometrie van een woonplaats niet echt een terechte teruggeven locatie is. Vanuit het oogpunt van gebruikers (locatieserver = locatie teruggeven) lijkt het ons wat verwarrend voor gebruikers. Slechts een administratieve teruggave zonder geometrie lijkt ook geen handige optie omdat dan ook hierbij verwarring kan ontstaan aangezien er geen geometrie wordt teruggeven (en dus wederom geen locatie). Om die reden is ervoor gekozen om deze objecten niet teruggeven. Zodra de NWB wegen van RWS wordt opgenomen zullen (niet alle maar wel) veel openbare ruimten met geometrie wel worden teruggeven.
Ik heb nog een aanvullende wens vanuit de BAG. In de locatieserver zijn nu BAG-IDâs opgenomen in het zoekresultaat. Het zou mooi zijn als het ook mogelijk wordt een BAG-ID als zoekterm op te geven.
OpenLS interface?
Hoi, de oude geocoder sprak de OpenLS OGC-standaard.
Om de LocatieServer een eenvoudige dropin-replacement te laten zijn voor bestaande applicaties, zou het fijn zijn als er ook een OpenLS output mogelijk zou zijn.
Maar ook in het kader van âverzin ajb geen nieuwe formaten/protocollen/standaardenâ zou het mooi zijn om de OpenLS interface te blijven onderhouden?
Ik zou daar eventueel zelf wel wat tijd in willen investerenâŠ
Vriendelijke Groet,
Richard Duivenvoorde / Zuidt
@PieterDijkstraBAG: met de suggest service kan dit niet, omdat hiervoor een speciaal zoekveld gebruikt wordt. Je kunt wel met de free service (vrije geocodeerservice) zoeken op willekeurige velden. Deze kun je in de query string opgeven d.m.v. {veldnaam}:{waarde}, bijv. openbareruimte_id:0344300000000328
Voorbeeld: Amsterdamsestraatweg, Utrecht
1 like
@rduivenvoorde: De OpenLS interface zat niet in de code en configuratie die van de Politie is overgenomen. In eerste instantie is besloten om de Politie-oplossing zoveel mogelijk gelijk over te nemen bij PDOK. Hierdoor konden we in korte tijd de nieuwe Locatieserver up and running krijgen en in beheer nemen. Tijdens dit proces is overleg gevoerd met een klankbordgroep. Vanuit hier was er nog geen behoefte aan de OpenLS interface. Dit zou ook vertraging van de doorlooptijd hebben betekend. Wanneer er duidelijk behoefte is aan de OpenLS interface, zullen we dit natuurlijk in overweging nemen.
Bedankt voor de info!
Hallo, net gekeken naar de mogelijke functionaliteit van de Locatieserver van PDOK. Mijn conclusie is dat op de volgende BAG gegevens geocoderen mogelijk is: adres, postcode, woonplaats, gemeente, weg.
De geocodeerservice (bb0x) die wij intern gebruiken, kan ook geocoderen op kadastraal perceel en wijkindeling (wijk, buurt, subbuurt, subbuurtdeel en blok). Is er gesproken om de locatieserver ook te laten serveren op deze themaâs en wat is daar uitgekomen. Of is dit echt nieuw. Ik ben benieuwd naar je reactie. Groet, Theo
@tdsmidt op dit moment zijn wij bezig het opnemen van de kadastrale kaart gegevens in Locatieserver. Ik verwacht (onder voorbehoud van rariteiten) nog voor de zomer beschikbaar te kunnen stellen. Het toevoegen van de CBS wijk-en buurtgegevens staat nog niet concreet op de planning dus die verwachten we op de hele kort termijn niet te kunnen bieden. @CBS ter info.
dank je wel, ben benieuwd naar de volgende versie.
Wij zoeken naar een makkelijke implementatie om een buurt/wijknaam te zoeken op basis van een adres. Het zou dus geweldig zijn als de buurt/wijknaam bij de response van de Lookup-service kan verschijnen! Je schrijft nog geen concrete planning te hebben om de CBS wijk- en buurtgegevens, wat zou dit eventueel kunnen versnellen/hogere prioriteit geven? Hoor het graag. Groet, Joey.
Hoi, mag ik nog eens vragen om ajb ook wegen toe te voegen waar geen adres aanwezig is, bijvoorbeeld door de straatnamen uit het NWB te halen die nog niet in de BAG voorkomen?
Hier bij de gemeente Nieuwegein bijvoorbeeld, loopt de (grote) Batauweg dwars door Nieuwegein. Maar zoeken daarop geeft geen resultaat:
http://geodata.nationaalgeoregister.nl/locatieserver/v3/suggest?q=batauweg,nieuwegein
vs
Google Maps, nieuwegein
Ik weet dat het een dataset âprobleemâ is, maar âgewoneâ gebruikers willen nu eenmaal alle staatnamen kunnen zoeken, en mopperen dat niet âalle straten erin staanââŠ
Dus wens: meer data⊠
Hoi, nog een wensâŠ
Als ik de locatieserver gebruik voor een hele eenvoudige geocoder interface (zoals bijvoorbeeld in PDOKKaart of in de QGIS PDOKservices-plugin, zou ik eigenlijk voldoende hebben aan ALLEEN de suggest MITS die ook direct de XY mee zou geven.
Bijkomend voordeel zou zijn dat ik in de kaart ook direkt de posities van de suggests zou kunnen laten zien (en bijvoorbeeld aanklikbaar maken).
Dus concreet de wens om het veldje centroide_rd, bv:
centroide_rd âPOINT(133230.698 448750.088)â
toe te voegen aan de output van suggest
Voorbeeld: http://geodata.nationaalgeoregister.nl/locatieserver/v3/suggest?q=koolmees,nieuwegein
Zou mooi zijn als ik (zonder nog weer een request te moeten uitvoeren) direct alle x,y-tjes zou kunnen laten zien van het resultaat.
Ik begrijp dat hierdoor de suggest-resultaat-json wat groter zou worden, maar dat ânadeelâ neem ik op de koop toe.
Ik kan me ook voorstellen dat in het datamodel de x,y (nog) niet aanwezig is in de data die voor de suggest wordt gebruikt, en er een extra join nodig zou zijn om die toe te voegen. Als dat zo zou zijn, en de query/suggest trager zou worden zou dat wel een argument tegen zijn⊠Maar ik hoop dat deze stap bijvoorbeeld al in de data-preparatiestap genomen kan wordenâŠ
Hoi Richard, het toevoegen van het NWB staat op de planning, maar dat heeft helaas vertraging opgelopen.
Het toevoegen van centroide_rd of centroide_ll kunnen we overwegen. Technisch gezien is het heel makkelijk, omdat het suggest endpoint gebruik maakt van dezelfde index, dus hoeft er geen join plaats te vinden. De uitdaging zit meer in het openstellen zonder alle informatie open te stellen.
Je zou eventueel het free endpoint kunnen gebruiken: http://geodata.nationaalgeoregister.nl/locatieserver/v3/free?q=koolmees%20and%20nieuwegein
Let op het gebruik van âandâ. Bij de suggest is dit impliciet opgenomen in de configuratie. Het nadeel is dat de scoreberekening anders kan zijn. Die van de suggest-service is beter âgetunedâ dan de free, omdat we daar veel meer de focus op gelegd hebben. Dat is bijv. te zien aan het adres âKoolmees 7001â, dat als 4e resultaat opduikt bij het free endpoint en bij het suggest als laatste.
In PDOK Locatieserver versie 3 kun je filteren op 2 vaste bronnen BAG en DKK. In de toekomst worden dat er meer. De wens is om een API functie toe te voegen die kan opvragen welke bronnen er zijn om zo de eindgebruiker een dynamische lijst te kunnen bieden om te filteren.