Onlangs een aantal nieuwe straatnamen opgevoerd in de bag en bgt.
Aan deze straatnamen zijn nog geen adressen gelinkt. Hierdoor zijn ze op dit moment niet te vinden binnen mijn applicatie, bag of pdok viewer. Middels het bag Id zijn ze weer wel te vinden. Klopt dit?
Ja, dat klopt. Het is in elk geval wat de huidige zoekmogelijkheden zijn. De BAGviewer maakt gebruik van de locatieserver van PDOK. Om te kunnen achterhalen waar een straat ligt, is er geometrie nodig. Van een straat zonder adressen is geen geometrie bekend. De locatie kan daarom niet gevonden worden. Zodra een adres wordt toegekend, is er via het verblijfsobject geometrie bekend en is de straatnaam te vinden via de naam.
Omdat in de locatieserver van PDOK ook een koppeling is gemaakt van wegen in het nationaal wegenbestand (NWB) en straatnamen in de BAG zijn straten zonder adressen in de BAG die zijn gekoppeld ook te vinden via de locatieserver. Een voorbeeld hiervan is de anacondabrug in Lelystad. Deze koppeling wordt periodiek geactualiseerd. Als de straatnaambesluiten zijn doorgestuurd richting het NWB is het goed denkbaar dat deze straten na een tijdje wel zijn te vinden.
Als je via de BAG viewer zoekt op het ID van een object, dan bevraag je onder water de LVBAG. Daar is de straatnaam wel gewoon te vinden. Wat je merkt bij het zoeken op het ID is dat je niet te zien krijgt waar deze straat zich bevindt. Dat komt dan weer door het ontbreken van de geometrie.
Pieter , bedankt voor je heldere antwoord!
Maar het zou toch mogelijk moeten zijn om de geometrie (puntgeometrie) uit de BGT te trekken…
maar dat is een andere discussie die in dit forum al eens eerder is gevoerd.
Ga hier voor de zekerheid intern ook maar eens navragen of de raadsbesluiten daadwerkelijk richting NWB gaan.
Het heeft mij vanaf het begin van de BAG (2005 of zo) enorm verbaasd dat OpenbareRuimte geen geometrie kreeg. Toen al vragen over gesteld, tijdens de consultatie voor BAG 2.0 weer aangegeven, maar nog steeds niet. Enorme gemiste kans als je 't mij vraagt…
En wat me dan nog het meest bevreemd, is dat voor het brondocument wel een kaartje vereist word (werd? weet niet zeker of dat nog steeds zo is, was toentertijd wel zo), dus de geometrie moet voor het proces wel inzichtelijk gemaakt worden en bekend zijn. Waarom dan niet direct meenemen in het datamodel?
Ik heb tot op heden nog geen goede reden gehoord waarom dat zo is…
Helemaal correct, is voor mij nu ook een raadsel. Vanuit de BGT kan de puntgeometrie gehaald worden en die weer koppelen aan BAG (maar eigenlijk is de naam al gekoppeld en heeft een uniek ID)?
En ja, bij het brondocument/raadsbesluit moet nog steeds een tekening zitten waaruit de ligging duidelijk wordt.
1 like
Ja, dat kan, maar heeft wel lastige kanten. Vooral bij langere straten/wegen zie je dat er nogal veel punten worden opgenomen (het is de locatie van de tekst), dus dan krijg je een langwerpige puntenwolk.
Bovendien is dat modeltechnisch niet echt correct, omdat je dan een kartografisch presentatie element gebruikt om de oorspronkelijke lokatioe van een object terug te vinden…
Hoewel je die punten wel weer tot een lijn zou kunnen samenvoegen - maar bij sommige straten moet je je dan weer afvragen of daar een beetje een juist beeld bij ontstaat.
Ja, het was heel handig geweest als deze geometrie onderdeel van de BAG zou zijn. In zekere zin is het zeker een gemiste kans.
Bij deze toch even wat context van mijn kant over BAG 2.0.
Bij de overgang van BAG 1.0 naar BAG 2.0 is ervoor gekozen de impact zo klein mogelijk te houden. Op zich kon en kan ik me daar wel in vinden. Het was nu al best ingewikkeld om de transformatie van BAG 1.0 naar BAG 2.0 uit te voeren.
Daarnaast zijn er natuurlijk meerdere registraties waarin gegevens van Openbare Ruimtes/straten worden bijgehouden. Het was/is nog steeds niet zeker dat de BAG de beste registratie is om deze geometrie vast te leggen. Als object in de BAG is de Openbare Ruimte in de registratie niet meer dan een registratief object.
Duidelijk verhaal Stefan. Wel leuk, op deze manier krijg ik een steeds beter zicht op het geheel dankzij jullie input/antwoorden.
1 like
Daar kan ik me iets bij voorstellen. Het zou een behoorlijk grote impact gehad hebben, dat is zonder meer waar.
Ik weet niet zeker of ik het hier mee eens ben. De BAG is verantwoordelijk voor adressen, en Openbare Ruimte is een enorm belangrijk, zo niet essentieel, onderdeel van een adres. Daarmee is, van mijn standpunt uit althans, de BAG DE aangewezen basisregistratie om (alle) informatie over een openbare ruimte of straat/weg vast te leggen.
Je zou kunnen beargumenteren dat de BGT, met als 1 van de voornaamste doelen het beheer van die openbare ruimte, ook een goede kandidaat zou zijn, maar gezien het verband met adressen vind ik dat modeltechnisch niet voor de hand liggen.
Klopt, maar dat geld ook voor een verblijfsobject en een woonplaats… beiden hebben een toch enigszins arbitraire geometrie.
De vindbaarheid van een “straat” vind ik toch van cruciaal belang. Alleen al daarom zou ik geneigd zijn er geometrie aan te knopen. Nu is het enerzijds een registratie in de BAG maar niet op naam terug te vinden en anderzijds een aparte registratie in het NWB die ervoor moet zorgen dat de vindbaarheid gewaarborgd is.
Exact! Dat was ook 1 van de oorspronkelijke redenen voor de BAG! 1 landelijke regsitratie van alle adressen om daarmee de vindbaarheid te waarborgen…
Stuk voor stuk goede argumenten waarin ik me persoonlijk erg goed kan vinden. Het was mijn bedoeling aan te geven wat de redenen zijn geweest het niet in BAG 2.0.
Laat ik voor de duidelijkheid nog even opmerken dat als het aan mij zou liggen de geometrie van openbare ruimten zeker een onderdeel van de BAG zou zijn. Maar ja, dit soort beslissingen worden altijd vanuit een bredere context genomen.
Inderdaad Pieter, maar zoals eerder gezegd : ik ben blij met deze korte maar verhelderende discussie!
2 likes