Parkeergarage onder gebouw

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.

beste Jan,

Ik heb mijn twijfels. Ik wil werken aan een goede kaart, niet aan een perfecte database die vervolgens gemankeerd op een kaart verschijnt. Het project heet Open Street Map, geen Open Street Database. Puur vullen van een database zou mijn persoonlijke motivatie om aan OSM te werken serieus tot nul terugbrengen; ik wil - letterlijk - het resultaat van mijn werk zien. Serieus trouwens: ik wil van OSM als kaart gebruik kunnen maken. Ik heb geen behoefte aan een kaart met manco’s en een perfecte database.

Wat de zaak in dit geval nog vervelender maakt, is de typisch Nederlandse bijna blinde afhankelijkheid van de BAG. Sorry: er zitten fouten en slordigheden in. Een terugmelding heeft lang niet altijd effect (althans niet in mijn ervaring). In dit specifieke geval is de buitencontour van de ‘verzamelgarage’ niet in de BAG gezet omdat deze (blijkbaar) geen losse referentie heeft. Maar hij bestaat dus wel en is écht een bouwwerk; juist dat soort details zijn funest voor een goed proces van ontwerp naar BAG naar OSM naar kaart.

Ik denk niet dat er in deze situatie één 100% goede oplossing is. Wat je ook kiest, er zal een partij zijn die niet tevreden is. Of de (huidige) BAG wordt perfect gerepliceerd en de kaart is vervuild, of de BAG wordt niet 100% gevolgd en de kaart ziet er correct uit op maaiveld. Er is hier zelfs geen compromis voorhanden. Wat er binnen de Nederlandse OSM-situatie het meest idealer is weet ik op dit moment niet - maar daarvoor voeren we nu deze discussie.

even goede vrienden,

met vriendelijke groet,

Marcel.

Hoewel ik in zijn algemeenheid geen voorstander ben van “mappen voor de renderer”, zeker als daarmee faliekant verkeerde data in OSM komt; gaat het imho inderdaad uiteindelijk om een correcte kaart en geen correcte database.

Het repliceren van een database kan nooit het doel van OSM zijn; OSM is namelijk geen instantie die ten behoeve van andere overheden back-ups van hun databases verzorgt of deze samenvoegt.

Er is m.i. geen enkel argument om storende BAG-panden niet te importeren in OSM, net als er geen argument is om bestaande panden die niet in de BAG staan wel in OSM op te nemen.

Zolang ondergrondse BAG-panden zonder kunstgrepen tot vreemde rendering leiden is er geen enkele reden deze panden te importeren.

Dit heeft niets met mappen voor de renderer te maken.

Uiteraard, indien structureel, zouden idealiter de standaardrenderingalgoritmes aangepast dienen te worden, maar zolang dat nog niet aan de orde is moet we ons een beetje behelpen.

Maar het probleem is dat er maar 1 database is en vele kaarten waarbij je je keuze hoe iets te taggen m.i. dus niet af moet laten hangen van 1 of een beperkt aantal renderers. Als en object volgens OSM conventies juist getagd is en de renderer een in jouw ogen verkeerde keuze maakt in de weergave dan is het advies contact op te nemen met de renderer. Ik kan me dan ook helemaal vinden in de post van Jan Westerhof in post #20.

Ik had het dacht ik ook niet over bewust verkeerd invoeren maar over **weglaten **zolang de standaardrendering niet goed weergeeft. :confused:

Je bedoelt het niet invoeren in OSM van de ondergrondse parkeergarages? tja niemand verplicht je om ze in te voeren maar wat als iemand ze toch invoert bv omdat ie graag wil weten waar de ondergrondse parkeergarages zich bevinden. En hij doet dat met de juiste tags… wat dan? Dan hoop ik niet dat iemand die weer weghaalt omdat CartoDB het niet goed rendert.
Als ik het niet goed begrepen heb verneem ik het graag.

Het uitwissen van andermans werk, zeker in dit geval is vandalisme. Alleen aperte fouten of vandalisme mag men wat mij betreft zonder overleg weglaten.

Maar je kunt een ondergrondse parking ook als node met alle attributen mappen, inclusief de inrit. De ondergrondse contouren zijn voor de gebruiker van de parking niet zo relevant…toch?

Het gaat - in ieder geval mij (en ook Commodoortje, als ik voor hem mag spreken) - beslist niet om wat dan ook uit te wissen. De contouren blijven, absoluut. Ze worden alleen voorzien van andere kenmerken. En in het geval van ‘De Heuvel’ in Velp wil ik zelfs een extra (want als bouwwerk bestaande) contour er bij tekenen. Kan de BAG daarna mooi uit OSM worden ge-updated :wink:

met vriendelijke groet,

Marcel.