Parkeergarage onder gebouw

Ik had in Valkenburg het nieuwe winkelcentrum vanuit de BAG geïmporteerd. Een groot gebouw.
Verificatie ter plekke toonden twee gebouwen. Er is dus een ondergrondse parkeergarage en die wordt door BAG getoond.

Heb uiteindelijk zo goed en zo kwaad als dat kan de bovengrondse gebouwen gemapt, inclusief de winkels erin (dat de BAG ‘construction’ aangeeft is dus achterhaald). Hoe dien ik nu de ondergrondse garage te mappen?

Uitgaande van “map what is ON the ground” zou ik alles wat ONDER de grond is niet mappen.
Een soortgelijk probleem doet zich voor bij de Markthal in Rotterdam
Maar ook deze discussie kan helpen.

Volgens mij moet de uitdrukking ‘on the ground’ niet letterlijk als ‘op de grond’ (en dus niet eronder) worden opgevat. De betekenis is meer ‘ter plaatse’, en in OSM-verband: we mappen wat we ter plaatse aantreffen, met eigen waarneming, en dat heeft in principe voorrang op andere bronnen.

Als je ‘on the ground’ alleen letterlijk met ‘op de grond’ zou vertalen, zouden tunnels en metro’s ook niet meer gemapt kunnen worden. Bovendien zouden objecten op hogere verdiepingen dan begane grond ook niet gemapt moeten worden, want die staan immers op een gebouw op de begane grond, en dus niet op de grond zelf.

Het zou ook de ontwikkeling naar drie-dimensionaal mappen verhinderen.

Al met al een onwenselijke uitkomst, lijkt me.

In dit geval, een parkeergarage die ondergronds is kun je toch gewoon taggen met layer=-1?

Ik zou zeggen: gewoon toevoegen, met extra tags:
layer=-1
location=underground

Ik zal eens kijken; probleem is denk ik dat de outline van de parkeergarage grotendeels samenvalt met de buitenste outlines van de op de grond staande gebouwen, hoewel dat natuurlijk niet te verifiëren valt bij gebrek aan röntgenogen.

In de initiële BAG handleiding staat hetvolgende:

https://wiki.openstreetmap.org/wiki/NL:BAGimport_via_ODS_plugin#STAP_2._BAG_panden_en_adressen_voorzien_van_relevante_bestaande_data

Kijk ook nog eens hier als het gaat over complexe vormen.

Bij tunnels is het belangrijk dat ze op de kaart staan omdat anders routering volkomen in het honderd loopt.
Metrolijnen op de kaart laten complete routesystemen zien, maar bij een parkeergarage onder de grond is het vooral voor de kaartgebruiker belangrijk dat hij de ingang van die garage kan vinden! Misschien moet je die duidelijk op de kaart zetten?
Nogmaals, in de eerder door mij genoemde forumdiscussies is voldoende voor/tegen het mappen van ondergrondse objecten te vinden.

En 3D mapping? Misschien kan OSM eerst aandacht besteden aan 2D? En daarna eens goed nadenken over de manier waarop we 3D gaan doen? Anders krijgen we een nog grotere chaos op de kaart dan bij de huidige 2D al het geval is.

Persoonlijk vind ik het ook al een tijd hinderlijk, dat een ondergrondse parkeergarage als gebouw wordt gemapt terwijl het latent aanwezig is.

Maar buiten dit draadje waren er meer.
https://forum.openstreetmap.org/viewtopic.php?id=57591
https://forum.openstreetmap.org/viewtopic.php?id=57146
https://forum.openstreetmap.org/viewtopic.php?id=32350
https://forum.openstreetmap.org/viewtopic.php?id=52726
https://forum.openstreetmap.org/viewtopic.php?id=25483
https://forum.openstreetmap.org/viewtopic.php?id=58424

Tijdens de initiële BAG import is afgesproken om deze (ondergrondse) parkeergarages die in de BAG staan, als gebouwen op te nemen met de extra tag layer=-1 en later bij survey of local knowledge om te zetten naar parkeergarage met alle aanverwante tags en ingang(en)

Bovenstaande problemen zijn allemaal te voorkomen om van building=yes ► building:part=yes te maken.
Op deze manier blijven de contouren van het gebouw in OSM, de “P” met zijn naam wordt gerenderd, en het gebouw (dat onder de grond ligt) niet meer. Uiteindelijk is de parkeergarage een “building part”

Als voorbeeld heb ik het gebouw (de parkeergarage) onder het stadhuis in Weert voorzien van de volgende tags.
amenity=parking
building:part=yes
layer=-1
name=Parkeergarage Centrum
parking=underground
ref:bag=988100000295701
source:date=2017-03-09
source=BAG
start_date=2014

Graag zou ik hierover willen discusiëren om (ondergrondse) parkeergarages op een dergelijke manier te gaan taggen. Zodat de wiki die parkeergarages uitlegd maar ook de BAG handleiding verbeterd kan worden.

Oude situatie:

Nieuwe situatie:

Sateliet beeld:

Een passage in een draadje dat me aansspreekt.
https://forum.openstreetmap.org/viewtopic.php?pid=635420#p635420

building:part lijkt me dan een afdoende oplossing.

Over de mogelijkheid amenity=parking_entrance
Volgens mij maakt navigatie software gebruik van deze tag om de ingang te vinden bij navigeren?

Maar de oplossing die HenkL aangeeft vind ik ook een goede gedachte, en geen tagging voor de renderer zoals misschien gesuggereerd werd.

Ik ben persoonlijk blij dat dit soort discussies herhaald worden, omdat er af en toe nieuwe inzichten / oplossingen opduiken, zoals deze keer met ‘building:part’. Ik vind het een prima oplossing, die ik inderdaad voor de parkeergarage van Arnhem Centraal zal gebruiken (zodra ik een écht goede contour getekend heb van het gebouw daarboven).

De ‘amenity+parking_entrance’ als hulpje voor navigatie-software kende ik nog niet.
Maar werkt dat ook als een parkeergarage meerdere ingangen heeft ?

Marcel.

Voor mij is het duidelijk:
Er moet eerst sprake zijn van een building=* voordat je een building:part=* kan taggen.

Zolang hier geen keuze wordt gemaakt, blijft het probleem bestaan.

https://github.com/gravitystorm/openstreetmap-carto/issues/552

Een attentie aangemaakt.

Ik vind het building:part een elegante oplossing. Heb het inmiddels bij diverse ondergrondse garages in de stad Groningen toegepast.
Heb alleen bij een ervan (Rademarkt) zelf apart bovengronds deel als ‘gewone’ building getekend, waar kantoren zitten boven ingang P-garage.

Een kleine complicatie:

In Velp (Gld.) staan op het plein ‘Den Heuvel’ ondergrondse parkeerboxen. Ze hebben elk een eigen BAG-vermelding en zijn nu dan ook nog consequent ingetekend als gebouw, waardoor ze op maaiveld zichtbaar zijn - op OSM dan. Ik heb van één rijtje de kenmerken veranderd in ‘building:part=yes’ en ‘amenity=parking’ , maar zie nu dat de nummers nog zichtbaar zijn (de contouren zijn mooi weg). Wat zou daar nog aan kunnen gebeuren ?

Ter controle:
https://www.openstreetmap.org/#map=19/51.99477/5.97519

met vriendelijke groet,

Marcel.

Als het aan mij zou liggen, zou ik deze adresnodes verwijderen, en misschien ook de ondergrondse gebouwen.
Maar het is een leuke discussie.
Op deze manier worden er wel erg veel parkeerplaatsen gecreëerd, terwijl on top (boven de grond) een openbare parkeerplaats is.
Zijn de ondergrondse garageboxen particulier bezit? Of kan hier openbaar onder de grond geparkeerd worden?

Het lijkt mij niet juist om gebouwen, ook al zitten ze onder de grond, weg te laten van OSM omdat het rendering-resultaat niet bevalt. Lijkt me een zuiver geval van taggen voor de renderer.
Die gebouwen zijn er gewoon, en horen als alle gebouwen te worden ingetekend.

Ook lijkt me gebruik van building:part dubieus, als het niet onderdeel van een (groter) gebouw is, wat hier idd niet het geval lijkt.

Volgens mij moet je ze gewoon in OSM opnemen, evt. met layer=-1 om aan te geven dat ze ondergronds zitten. En bij de renderer melden dat je het graag anders, of helemaal niet, gerenderd wil zien.

Je kan alle nodes op 1 plek heel dicht bij elkaar zetten zodat er minder ruimte is om ze allemaal te renderen (en dus eigenlijk taggen voor de renderer). Adresnodes weghalen lijkt onttaggen voor de renderer en net zo erg.
De adresnodes kunnen eventueel samengevoegd worden met de building om, als tegen de tijd dat het pand minder prominent gerenderd wordt, te hopen dat dan het huisnummer ook minder prominent weergegeven wordt. Of in plaats daarvan op de adresnodes ook location=underground erbij zetten zodat de adresnodes in dat geval zelfstandig minder prominent gerenderd worden.

Indien een parkeergarage onder een gebouw ligt vindt ik building:part zeker gerechtvaardigd omdat het toch hoogstwaarschijnlijk 1 en dezelfde constructie is en geen 2 gebouwen.
Is het een zelfstandige parkeergarage zonder bovenliggend gebouw, maar bijvoorbeeld een grasveld (zoals het Malieveld) vindt ik de building:part al wel heel erg gaan lijken op taggen voor de renderer.

In het rijtje tags hierboven mis ik eigenlijk nog location=underground (ondanks dat er al parking_underground staat).

@ Jan:
Het zijn individuele boxen, die in een ondergrondse parkeergarage-achtige constructie liggen, dus wel degelijk deel van een gebouw (hoe wou je anders losse ondergrondse garageboxen ueberhaupt bereiken ?). Alleen is de garage sec nou net niet in de BAG opgenomen. Omdat dat dus wél degelijk een constructie is, vindt ik dat voor de losse garageboxen ‘building:part=yes’ wel degelijk juist is en geen ‘taggen voor de renderer’. Dat de garageconstructie zelf niet in de BAG zit is mijns insziens een foute keuze, maar dat mag jij de Gemeente Rheden gaan vertellen (ik heb ooit een BAG-terugmelding gedaan, overigens, en nooit wat gehoord).

@ Commodoortje:
De boxen zijn particulier, en van/voor bewoners van de flat er naast / boven. Het parkeerterrein op maaiveld erboven is openbaar. Adresnodes verwijderen vind ik nèt een stap te ver, maar zo kwam ik wel aan dit dilemma.

Marcel (die het ook niet meer weet)

building:part mag je feitelijk alleen gebruiken als het het gebied dat als part gemapped wordt omsloten wordt door een gebied waarop building staat. alle andere gebruik is foutief volgens mij.

Ik sluit me dus aan bij Sander H en Jan Westerhof. Slechte keuze voor op zich zelf staande ondergrondse gebouwen

@Escada:
Het zijn geen op zich zelf staande gebouwen in die zin. Je kunt je toch moeilijk voorstellen dat elke keer dat daar een auto in of uit wil, die als een mol door de grond gaat graven ? Er zit een ‘envelop’ omheen, een grotere (verzamel)contour met de toegang tot alle boxen - maar die staat niet in de BAG.

En de gebouwen an sich staan (dus) ‘los’ in de BAG, maar dat komt omdat de omliggende contour nou eenmaal geen kadastrale aanduiding heeft gekregen. Dit is precies waar 't gruwelijk misgaat als we hier in OSM blind de BAG gaan volgen. We zouden beter, intelligenter, moeten zijn. We doen toch geen dubbele boekhouding voor 't Kadaster ?

Lees even Commodoortje’s verhaal hierboven over de parkeergarage in Weert. Wél in de BAG, maar nu niet (meer) zichtbaar binnen de standaard renderer. Dit vind ik dus een écht intelligente oplossing. Dit is géén ‘mappen voor de renderer’ maar je hersens gebruiken om een net en consequent kaartbeeld te genereren - de gebreken van de renderer in acht nemende.

@allen:
Zou het een oplossing zijn als ik om die %&##^& ondergrondse garageboxen de ‘verzamelcontour’ teken ?

met vriendelijke groet,

Marcel.

Het id volkomen invoelbaar dat het jammer is om je werk als mapper op een onjuiste manier weergegeven te zien worden op een kaart, nog wel de standaardkaart op osm.org.
Maar toch kun je uiteindelijk maar op een punt uitkomen: de mapper is verantwoordelijk voor het juist invullen van de OSM-database, en de renderer is verantwoordelijk voor het maken van een kaart op basis van die database.
Ik snap heel goed dat je als mapper de neiging krijgt om zaken anders dan correct in de database in te vullen als je ziet dat het een ongewenst kaarbeeld veroorzaakt, maar daarmee ga je op de stoel van de renderer zitten.

Het is de renderer die kan besluiten om op basis van een tag als bijvoorbeeld location=underground een gebouw anders (of niet) weer te geven op zjn kaart. En het is de mapper die de renderer in staat stelt onderscheid te maken tussen bovengrondse en ondergrondse bouwsels door zijn veldwerk, en het al of niet toevoegen van de tag location=underground.

Het is belangrijk je te realiseren dat je als mapper werkt aan één database, waarmee niet alleen die ene kaart op osm.org wordt gemaakt, maar nog vele andere kaarten. Al die renderers zijn afhankelijk van de correcte en zo volledig mogelijke informatie die mappers in de database invullen.

Dingen weglaten of oneigenlijke zaken invullen als een ‘verzamelcountour’ om een bepaald effect op een kaart te bereiken lost dus geen problemen op, maar creëert ze juist.

Het enige wat je verder kunt doen is contact zoeken met de renderer, in de hoop dat die zijn rendering aanpast. Daar hoort bij dat je moet accepteren dat renderers niet aan alle verzoeken kunnen voldoen.