Herimport BAG voor nieuwbouwwoningen Kanaleneiland

Gebouw http://www.openstreetmap.org/way/268730384 is in 2014 uit de BAG geïmporteerd als “construction” als een simpel rechthoekig gebouw. Inmiddels wordt het bewoond: het deel tegen de Churchilllaan aan is een flat van 7 hoog met de naam “de Handelaar”, en daarvoor staan rijtjeshuizen.
Mijn vraag is nu of iemand de adressen uit BAG kan importeren zodat de adressen zichtbaar worden en te vinden zijn. Of denken jullie dat het beter is om te wachten tot ook de flat ernaast, “de Verkenner” nu nog in aanbouw en nog niet ingetekend, bewoond is?

1: kun / wil je dat zelf niet doen? Zo moeilijk is dat nu ook weer niet…:wink:
2: we wachten als community al tijden op een ‘Delta-BAG-importtool’ die alleen wijzigingen ten opzichte van de nieuwe BAG en de reeds gemapte BAG-date beschouwt. Ik denk dat dat, gezien de herhaalde vragen steeds nijpender wordt.

Ik zelf heb geen programmeerervaring, maar ik denk dat velen dankbaar zullen zijn!

Staat nog op status in BAG:
Bouw gestart

dan zijn via de import tool, de adressen nog niet te importeren

https://bagviewer.kadaster.nl/lvbag/bag-viewer/#?searchQuery=Marco%20Pololaan&objectId=0344100000139543&geometry.x=135042.51041999&geometry.y=453789.46888923&zoomlevel=13&detailsObjectId=0344010000168460

Business & Administration College, ICT College, heeft ook een andere vorm gekregen.

En wat is er mis met een “goede ouderwetse” manuele edit na survey ? :slight_smile: De adressen hoeven toch niet geïmporteerd te worden ? Je kan die er toch gewoon opzetten ook en terzelfdertijd building=construction vervangen door building=apartment of iets dergelijks.

In mijn eigen omgeving merk ik dat de BAG status van gebouwen (ingemeten en bewoond bv) behoorlijk achterloopt op de werkelijkheid. Periodes van 2 jaar zijn niet zeldzaam.
In zo’n geval teken ik de gebouwen zelf in met de BAG-laag als ondergrond en wacht voor de definitieve import gewoon af tot de BAG ook definitief is geworden. Eventueel ontbrekende adresgegevens zet ik er dan ook bij, maar niet als het om een heel flatgebouw gaat met 256 verschillende huisnummers.

Bedankt voor de informatie. Spijtig dat de adressen niet te importeren zijn.
Als het om een paar adressen ging, had ik ook graag de informatie er bij gezet maar hier zijn het 62 bewoonde adressen en een paar met een andere functie die ook in BAG ook zijn opgenomen. De appartementen (59 t/m 129) zijn wel te plaatsen namelijk zes naast elkaar per verdieping, maar van de huizen met een eigen ingang op de begane grond (131 t/m 181) kan ik bij gebrek aan een goed GPS apparaat, slechts schatten waar de ingangen geplaatst moeten worden op het gebouw. BAG viewer laat deze adressen in ieder geval goed zien.

building=construction naar building=apartments heb ik al gedaan.

De veranderde vorm van het college in BAG, kan ik niet verklaren. Voor zover ik weet staat dat gebouw goed op de kaart nu, maar ik zal eens wat nauwkeuriger kijken als ik daar donderdag weer langskom.

Je kan ook altijd een addr:interpolation gebruiken. Dan kunnen de mensen nu al naar het juiste gebouw navigeren en moeten ze geen x maand meer wachten tot er ooit nog eens een import komt.

Ik ben gisteren weer aan de Amerikalaan geweest en zal in ieder geval de geschatte positie van een aantal nummers op de kaart zetten. Misschien nog wel nauwkeuriger dan BAG, want de precisie daarvan blijkt - in ieder geval nu nog - tegen te vallen. Afstanden tussen de huizen kloppen niet altijd, en nr. 153 is verdwaald.

AlbertP, een blik op de galerijen of portieken en de geplaatste huisnummers, maakt zoals je opmerkt een juiste plaatsing van de huisnummers in het pand goed mogelijk. Kost wat tijd maar dan heb je ook wat en de nummers staan dan ook nog aan de juiste kant van het pand.:wink:

We hebben volgens mij nog steeds niet de goede methode voorhanden hoe we omgaan met adresnodes in appartementen. Ik heb er bij de BAG import (de thread met bijna 200.000 views) eens het volgende over geschreven:

‘…de veelvoud aan nodes (‘wolkjes’) zijn niet de perfecte oplossing. Alleen bestaat die perfecte oplossing nog niet. Een probleem is dat we in 2D werken, terwijl flats/appartementen in werkelijkheid 3D zijn. Ook is het nog niet duidelijk of de adresnodes op de ingang moeten, op de deur van het appartement of op de omtrek van het appartement (van de xe verdieping) met een entrance=main node op de ingang. Bovendien, een eis van de Data Working Group: de adresnodes moeten eenvoudig te bewerken zijn voor beginners. Het kan immers zo zijn dat een deel van de nodes een POI betreft (denk aan winkels met daarboven appartementen). Het werken met ranges is te moeilijk voor beginners. Ik heb in Delft ervaren dat het werken met interpolation lastig is voor beginners: nieuwe POI’s werden namelijk niet op de interpolated lijn gezet zoals het hoort, maar ergens daarnaast. De losse nodes maken het ook in Potlatch en iD mogelijk om een losse node op te pakken, die te voorzien van POI data en op de rand van een gebouw bij de ingang te plaatsen. Als de perfecte oplossing nog eens gaat ontstaan over een paar jaar, met voldoende consensus daarover, dan pas is het de moeite waard om over te gaan tot hertaggen. Anders bestaat het risico dat er nu al gehertagd zou worden, en dat dit over een jaar of twee, drie weer compleet anders gedaan zou moeten worden.’

Misschien is een redelijke oplossing om de losse nodes zoveel als mogelijk op plaats van de ingang (de deuren naar de betreffende appartementen) te zetten en daarbij te voorkomen dat nodes op elkaar gaan vallen. En voorts de straatingang te taggen met entrance=main om te zorgen dat je navi de ingang weet te vinden.

Hier mijn wijzigingen: http://www.openstreetmap.org/changeset/34415044
Ik had je bericht nog niet gelezen toen ik dit maakte, dus ik heb er niet alles aan aangepast.
Ik heb bij interpolatie de adressen in losse nodes laten omzetten, de addrInterpolation plugin heeft daarvoor een optie. Hiermee vermijdt je waarschijnlijk wel wat van de genoemde interpolation problemen.
Verder heb ik nu een associatedStreet relatie gemaakt om de appartementen (59 t/m 129) aan het pad langs de ingang te koppelen, begrijpen routers dat ook?
De huizen 131 t/m 181 hebben wel een eigen voordeur, deze gaan in navi wel goed op deze manier.

Er wordt op dit moment nog veel gebouwd op deze plek, dus er komen waarschijnlijk nog wel wat edits van mij in de komende maanden.

volgens mij is er geen enkele router die naar associatedStreet kijkt. En buiten misschien een QA-tool van de Franse community is er AFAIK geen enkele tool die die relatie ondersteunt. Er is nog niet zo heel lang geleden een behoorlijke discussie geweest over het nut van die relatie. In Duitsland zijn ze er vanaf gestapt, in Frankrijk nog niet.

Volgens mij dient een associatedStreet-relatie ook niet om de routers te helpen, die zoeken wel naar iets dat zo dicht mogelijk bij de knoop komt. Voor die tools is de nummer op de ingang en een weg naar de ingang het beste. De bedoeling van die relatie was/is om losse adresknopen en gebouwen aan een straat te koppelen om zo aan een volledig adres te komen. Nu ja, de mening over het doel van die relatie verschilt ook nogal van persoon tot persoon.

Bij het bepalen van de wijze hoe de BAG import moest verlopen is besloten om in Nederland geen associatedStreet-relaties toe te passen. Routers kunnen prima werken met adresnodes waar alle info in staat en hebben deze relatie dus niet nodig. Bovendien is deze relatie erg onhandig in het open model van OSM (iedereen die wil mag mutaties aanbrengen wat op termijn tot enorm veel inconsistenties zou gaan leiden, dus keep it simple)

edit: dit is de changeset http://www.openstreetmap.org/changeset/34432457

Ik heb de relation weer verwijderd en een entrance node toegevoegd aan het gebouw. Is er een manier om te taggen dat de huizen 59 t/m 129 door deze entrance bereikt worden en 131 t/m 181 door de eigen voordeur, of kan ik beter het gebouw in tweeën splitsen zoals in de BAG ook met het gebouw ernaast (dat er vrij veel op lijkt maar nog niet klaar is) is gebeurd?

Goeie vraag. Ik vind jouw suggestie om het gebouw te splitsen een mooie oplossing.

Gr., Johan

Voor ik het splits wil ik eerst nog even de situatie ter plekke bekijken. Komende week kom ik er waarschijnlijk niet maar de week daarna moet ik weer aan de Amerikalaan zijn, dan zal ik eens bekijken waar de splitsing moet komen.

Hi AlbertP, dit is een voorbeeld met een centrale ingangs partij op de begane grond en op de eerste verdieping langs een voetgangerszone gegroepeerde huizen rond een lift met trappen aan de zuidzijde en een vrij toegankelijke openbare parkeerplaats, met op dezelfde manier gegroepeerde huizen aan de noordzijde. http://www.openstreetmap.org/#map=17/52.35508/6.66866
Je moet dan dus echt naar binnen om de juiste nummers op de juiste plaats ± te zetten, interpoleren of groeperen maakt IMHO geen juist beeld. Het geheel heeft een plint met winkels of horeca.

Ik weet niet helemaal wat je hier mee wilt zeggen, dit gebouw zit veel eenvoudiger in elkaar dan jouw voorbeeld. Ik ben zelf binnen geweest, in het noordelijke deel zijn de rijtjes huizen die ik getekend heb de verdiepingen van het gebouw. Bijvoorbeeld de 5e verdieping waar ik iedere 2 weken kom, loopt van 95 (rechts) tot 105 (links). Die huizen zijn allemaal even groot dus tussen 95 aan de rechterkant en 105 aan de linkerkant is interpolatie een prima hulpmiddel.

Albert, slechts dat je bijna altijd de voorkeur moet geven aan waarnemingen boven interpolatie. Zo te horen komt dat helemaal op zn pootjes terecht. ;-)) En bij de BAG import zijn de rijtjes of volgorde van de huisnummers onbedoeld weleens omgedraaid, van links naar rechts vice versa.

Of ze liggen in een stapel op elkaar, van meerdere straten tegelijk en dan kun je het fijn gaan uitzoeken.