De project plattegrond laat gebouw gedeelten zien waarbij in de project tekst vertelt wordt dat de gebouwdelen E & F als eerste (=bouwfase 1&2) gebouwd gaan worden…
Als je echter project plattegrond hierboven vergelijkt met te importeren BAG-pand van bewuste projectgebouw kom je er achter dat BLOK E & F (fase1 & 2) niet afzonderlijk te importeren valt…
Fase 1 & 2 zullen ongeveer 2,5 jaar in beslag nemen door o.a. ook de bouw van groot ondergrondse parkeergarage.
Hoe dit goed weer laten geven in OSM ?
Meedenkend: de import doen met alleen import van de adresnodes behorend bij blok E (36 appartementen) & F (23 Parkwoningen) ?
Dit zouden dan in totaal 59 adresnodes zijn van de in totaal 136 adresnodes.
Mijn mening: we zien wel als het in BAG verschijnt. Plannen kunnen worden veranderd en zelfs afgeblazen. Als de BAG niet klopt met werkelijkheid dan BAG-terugmeldingen doen. Uiteindelijk, ook door terugmeldingen, BAG leidend maken en op grond daarvan in OSM mappen wanneer moment daar is. We zien wel tegen die tijd. Laat dan evt. weten via de BAG Update Topic.
Er is momenteel nog zoveel te doen om met huidige BAG-stand OSM te actualiseren…Ga bijv. eens in JOSM met BAG Updater plugin “Nederland rond”, en zie hoeveel er nu nog te doen valt en actualiseer evt. ter plekke.
Zeker mee eens en een goede tip voor alle JOSM gebruikers om dat oppakken.
Zelf gebruik ik de ‘tactiek’ om alle import aanvragen die ik tot 2 jaar terug gedaan heb op dit forum na te lopen op, op dit moment onjuiste actuele in gebruikname status en deze dan te actualiseren, daarbij in de ruime omgeving scannend op andere op onjuiste status staande gebouwen (Immers je bent dan toch al op een bepaalde lokatie , kleine moeite zonder oogkleppen op goed de omgeving te verkennen).
Dit project staat al in BAG. In het specifieke door mij aangegeven geval zal (als alles in 1 keer met alle adresnodes geïmporteerd gaat worden) er 2,5 jaar (namelijk de tijdsduur van bouwfase 1 & 2 van dit bouwproject) adressen in OSM bestaan die in de echte werkelijkheid niet bestaan
Dat lijkt me ook geen wenselijke situatie volgens mij.
De import bij dit project is nog niet gebeurt en daarom dit overleg om vooraf een passende oplossing te vinden voor het zeer binnenkort naderende OSM-import moment voor dit project.
Ik denk dat je dat te simpel ziet want de adressen staan in BAG verspreid over het hele projectvlak en ja zelfs op plekken waar straks een wijk park gaat komen…
Dus ja welke adresnode hoort dan waar ?
Ter verduidelijking:
Verdieping situatie tekeningen Blok F
Het simpelste blok (Blok F) is zelfs al verwarrend: in BAG tel ik voor de lokatie waar Blok F zou moeten staan: 20 adresnodes.
Op de verdieping situatie tekening Blok F: 23 adresnodes
En dus kun je nooit exact de juiste adresnodes die niet nog zichtbaar moeten zijn weghalen…
Consequentie daarvan is dan dat alle adresnodes geïmporteerd worden waardoor alleen al in dit specifieke geval 2,5 jaar lang: 136 - 59 = 77 adresnodes in OSM staan als toekomstige nog niet bestaande ‘spookadressen’.
Oplossing blijkt zeer eenvoudig: Op het moment dat de bouw start, BAG pand id importeren zonder adresnodes en de adresnodes pas importeren als deze in het veld (in dit geval pas na 2,5jaar) zichtbaar zijn.
Voor een woning in aanbouw wordt de adres node altijd toegevoegd. Voor een flat ook. Er wordt niet gekeken hoelang de bouw duurt. Bij andere grote bouw projecten worden ook adres nodes toegevoegd. Het lijkt me logisch om dat hier ook te doen. En daarbij heeft het gebouw in OSM status in aanbouw. Ik zou het hier dus ook toevoegen
Is ook de meest logische stap als de bouw van object en de adressering 1 op 1 loopt.
In dit geval wordt maar een deel van de appartementen die staat in BAG met Pand ID 0392100000092883 gebouwd door bouwfasering toe te passen.
Ter vergelijk:
Als op een vakantiepark initieel 9 vakantiehuisjes in BAG staan en daarom in OSM ge-import worden maar in een bepaald tijdsbestek daadwerkelijk er uiteindelijk maar 4 neergezet worden, worden de omtrekken en adresnodes die niet in het veld staan terecht weggehaald uit OSM.
Ook dit kan je zien als projectfasering die groundtruth weergeeft.
Het enige wat lastig is met dit Bloom-bouwproject is: dat je de appartementen die nog niet gebouwd worden niet uit de BAG-import weg kan halen zoals je dat met individuele vakantiehuisjes wél kan doen.
Om dan enigszins de adresnode-‘schade’ te beperken (die recht doet aan ground-truth) is deze adres-node weglatingsmethode toe te passen..
Als er een elegantere manier om geschetste problematiek op te lossen bestaat lees ik dat graag hier !
Want dat is precies waarom ik dit draadje gestart heb.
Tenzij je een prefab woning neerzet duurt de bouw van een gewone woning ook al gauw een jaar en zetten we direct de adresnodes er alvast bij. Handig, want dan kunnen de bouwers en leveranciers al snel navigeren naar het adres.
Dat een flat wat langer duurt is niet heel veel anders, parkeerkelder, meerdere woonlagen, wellicht meerdere woontorens die niet tegelijk gebouwd worden… daarvoor lijkt 2,5 jaar niet heel gek.
Navigatie naar zo’n grote projectsite gaat vast anders dan naar specifiek 1 van de adressen die opgeleverd gaan worden, maar heeft iemand er last van als de adressen er alvast staan? In mijn ogen hoeft het adres niet perse te wachten totdat de geraniums in de vensterbank staan.
Je mist een belangrijk punt: de adressen in Blok E & F (het enige deel wat na 2,5 jaar gereed is) om die te voorzien van adresnodes: prima.
Echter blok E & F is slechts een deel van de import van wat onder geïmporteerde BAG pand ID valt. Daardoor worden als je alle adresnodes die vallen onder het pand ID meteen toekent (dus ook die niet eens over 2,5 jaar ground truth zijn) ruim 40% spook adressen.
Nu de moeilijkheid van de adresnodes toekenning van Blok E & F: je weet niet welke adressen vallen onder respectievelijk: Blok E & F… en het valt ook niet af te lezen van de kadasterdata…
Volgens mij is het pand dat je aangaf het hele blok E+F van 136 huisnummers.
De andere blokken zijn de losse panden daaromheen als ik het bouwplan goed interpreteer:
Adressen, geheten Nummeraanduidingen NUM, in BAG vallen niet rechhtstreeks ‘onder een Pand’ PND, maar zijn gerelateerd aan een Verblijfsobject VBO. De VBOs, bijv een appartement, zijn weer gerelateerd aan één, heel soms meerdere, PND. Ieder van deze drie objecttypen heeft een status attribuut. Bijv. de PNDen hier ‘bouwvergunning verleend’. Dacht dat we dezen dan niet zouden importeren. De VBOen hier hebben status ‘verblijfsobject gevormd’, een soortgelijke ‘gepland’ status. Pas bij status ‘verblijfsobject in gebruik’ kun je geraniums verwachten…Daarmee zijn m.i. de NUMen Adressen, ook impliciet, vooral qua locatie, in planning status. Alleen het VBO heeft namelijk locatie, NUM niet.
Dus m.i. deze Adressen niet invoeren, net als de Panden. Afwachten, evt terugmelden als BAG achterloopt.
