Ziet er goed uit Otto !
Gebruik key building:part=
Ik heb juist een 13 uit een dozijn gebouw gekozen voor een meedenk sessie omdat dit in de bouw wereld zo’n beetje de standaard gebouw vorm geworden is in stedelijk gebied, met de logische naam: ‘woon- & werk-bouw’-gebouw. Kenmerkend aan dit soort gebouwen is: winkelfunctie, gecombineerd met wonen en een gezamenlijke maatschappelijke functie in dit geval een parkeergarage.
Omdat de parkeergarage onderdeel is van het hele gebouw en een hele ander functie & attributen heeft dan de andere 2 delen te weten: supermarket & het andere deel: apartments zou dit het gebruik building:part= rechtvaardigen.
Toch zie ik dat deze key, in dit soort steeds meer mainstream wordende gebouwen, vrijwel nooit gebruikt wordt.
De key owner (bij dit specifieke gebouw zou dat zijn: owner= Hoorne Vastgoed) kan heel handig zijn m.b.t. het snel op kunnen diepen van opstapelzijnde verbouwings- en/of grotere herstructureringsplannen van de gebouw eigenaar omdat dit vaak resulteert in publieke ruimte wijzigingen rondom het bewuste gebouw.
Bovendien hoor ik van ondernemersverenigingen dat deze key welkome nuttige data voor hun is ook wegens bovenstaand genoemde reden.
Tevens wilde ik praktisch, middels een future note, laten zien dat het gebruik van een note op een heel project heel nuttig kan zijn ook voor gebouw-bouwprojecten omdat je op deze manier:
- Vele kleine note opmerkingen na de oplevering van een gebouw door goed bedoelde surveys aanzienlijk terug kan dringen, immers door in 1 gebied zowel gebouwplannen als ook gemeentelijke herstructurerings-infrastructuur plannen op te nemen in 1 future note volstaat 1 goed geplande gebiedssurvey.
Immers door de future note weet je exact welke plekken survey-waardig zijn zodat je kan controleren dat de definitieve ontwerpen ook daadwerkelijk de praktijk situatie geworden is…
- Door het verzamelen van infobronnen in 1 future-note kom je ook data tegen die je in een normale survey nooit ontdekt zou hebben.
Mijn inziens zou samenvattend: dit standaard type gebouw alsvolgt gemapped moeten worden:
Contour van het totale gebouw:
key building= parking; supermarket; apartments (building relation wordt door deze notatie overbodig en kan dan ingezet worden voor complexere gebouw relatie’s (bijv: afzonderlijke gebouwen die bij elkaar een gebouwcomplex vormen bijv: gevangenis-complex.)
key owner=
BAG info keys
key building:architect=
key building:levels= [totaal aantal verdiepingen]
Optional keys: name, all monument info
Vlak-Contour ‘basement/underground’
key building:part= parking
key building:levels= [totaal aantal parkeerverdiepingen] waar mee parking multi-storey key overbodig wordt.
key level= (om aan te geven op welke verdieping(en) deze faciliteit zich bevindt)
key layer=-1
Vlak-Contour begane grond:
building:part=supermarket
building:levels= [totaal aantal supermarket verdiepingen gerekend vanaf de verdieping met deze faciliteit tot het aantal aangegeven verdiepingen]
key level=
key brand=Vomar
key level= om aan te geven op welke verdieping(en) deze faciliteit zich bevindt.
key layer=0
Op de adresnode: de adres keys, key brand=, key operator=, key website=, optioneel aangevuld met wiki keys
Vlak-contour top-verdiepingen:
key building:part=apartments
key building:levels=
key level=
key layer=1
Zou dit alles zo gestructureerd zijn dan voorkom je dubbele data opslag en kun je een gebouw in detail mappen…
Edit: typo correctie: Voorne —-> Hoorne
