Parkeergarage onder gebouw

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.

Ik weet (voordat de initiële BAG import heeft plaatsgevonden) dat er veel is gecommuniceerd over hoe de BAG geïmporteerd zou moeten gaan worden. Ook is hierbij de ondergrondse parkeergarage aan bod gekomen. Aangezien ik destijds een newbie was begreep ik nog niet alle ins en outs, toch heb ik veel waardering waarop de afspraken tot stand zijn gekomen.
Nu zijn veel van deze afspraken geheel volgens verwachting tot een goede import gekomen.
De volgende fase is het onderhouden van BAG ook dit geschiedt op een voortreffelijke manier/samenwerking.

Het punt van de ondergrondse parkeergarages, zoals al eerder aangegeven, stoort me inderdaad al een tijdje.
Allroads heeft hier een Github melding (vermoedelijk is inloggen noodzakelijk) van gemaakt, met nogmaals het verzoek hier iets in te betekenen.

Deze request is gestart door Math1985 op 21-05-2014

Ook ik ben geen voorstander van building:part=yes maar als openstreetmap carto dit niet wil aanpassen in de rendering, wil ik overwegen om deze tag toch door te zetten,
denoods een betere oplossing zoals de building tag weg te laten en de amenity=parking tag toe te voegen.
Maar dit zal vermoedelijk ook een verstoort kaartbeeld opleveren.

Misschien dat Math1985 nogmaals zijn best wil doen om het bespreekbaar te maken in het team van openstreetmap carto.

Ik wacht even af voordat ik begin met omtaggen, tot openstreetmap carto een betere oplossing biedt.

Voor de duidelijkheid: de osm-carto ontwikkelaars hebben hier nog geen beslissing over genomen. Het issue staat nog open (tezamen met 300 andere issues). Bovendien kon dit issue niet worden opgelost zonder https://github.com/gravitystorm/openstreetmap-carto/issues/1504 , die pas recentelijk is opgelost.

Ik ben zelf wel iets van gedachten veranderd ondertussen. Dit probleem speelt in onze stylesheet, maar ook in alle andere stylesheets. Een stylesheet maken is best veel werk, en ik zou niet elke ontwikkelaar van een stylesheet willen opzadelen met het incoderen van alle uitzonderingen. Wij zouden het aan onze kant kunnen fixen, maar dan staat het nog steeds op alle andere renderers (zoals Mapbox Streets, die veel door externe websites wordt ingeladen) fout.

De grote vraag voor mij is: is een ondergrondse parkeergarage een gebouw in cartografisch opzicht? Nog afgezien van bergbezinkstations en dergelijke (hoe staan die in BAG?). Iets kan natuurlijk wel een gebouw zijn in bouwkundig opzicht, maar niet in cartografisch opzicht. Een nieuwe tag als underground_structure=yes of iets in die richting zou misschien een uitkomst zijn. Building:part zonder building lijkt me in elk geval onjuist (maar ik begrijp de hack).

Zelf ben ik er nog niet helemaal over uit.

Op zich is er al de tag “location=underground”. Dat kan op volgens mij al voldoende zijn tot het gebruik van stippellijntjes / no fill o.i.d. in de renderer zonder het specifiek alleen te betrekken op buildings. Dan is het geen uitzondering meer.

https://wiki.openstreetmap.org/wiki/Key:building:levels

building:levels:underground=1

Als er alleen deze key/value op staat?

Cartografie
De Bosatlas van Ondergronds Nederland

Heb dit in Hengelo geprobeerd en het wordt gerenderd als een normale parkeerplaats. Blijkbaar is er iets veranderd, zie Weert https://www.openstreetmap.org/#map=19/51.25107/5.70342 Dus wat nu?

Een tag om niet te renderen zie ik wel zitten, uiteraard met bijbehorende regels wanneer wel/niet toe te passen. Misschien ook voor de overtollige namen van fietspaden ?

Moeten er voor het deel dat volledig ondergronds is, niet zowel building:levels:underground=1 en building:levels=0 worden gebruikt? Het lijkt me dat als default kan worden gezien dat een gebouw minimaal 1 niveau heeft.

Een tag om niet te renderen? Dat lijkt me vreemd in OSM, eerlijk gezegd.
Wij mappers verzamelen gegevens die eventueel gerenderd kunnen worden - het al of niet in een kaart opnemen is naar keuze van de renderer, niet van de mapper.

Dat geldt ook voor ondergrondse bouwsels. Als het lelijk staat op een kaart, of het renderingsresultaat is anderszins niet gewenst, dan is het aan de renderer om dit aan te passen. Die kan bijvoorbeeld beslissen ondergrondse parkeergarages niet weer te geven.

Ik wil nog even wijzen op de punttag amenity=parking_entrance in combinatie met service road om alle in- en uitgangen van een parkeergarage te markeren. Ook handig in combinatie met de slagboomtag.

http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_entrance

Zie als voorbeeld
https://www.openstreetmap.org/node/5243271308

@Hans: als je daar (bij je voorbeeld) bekend bent moet je eens naar de adresnodes kijken van het gebouw aan Corneliusplein/Groeët Genhei . Daar ligt veel over elkaar heen. Bij de nummers 44 en 28 (zichtbaar op kaart) zitten er wel 50 adressen onder. Zelfde bij de nummers 6. Wellicht ook BAG terugmelding.

Het is een appartementencomplex, hoe wordt dat normaliter in openstreetmap behandeld, bijvoorbeeld ook een flatgebouw met tientallen huisnummers bij dezelfde ingang?

Het is een compromis die gemaakt dient te worden.
Als je weet waar de huisnummers zitten kun je ze verslepen naar de positie waar ze horen. Aan de andere kant is er inderdaad een afspraak om de adresnodes zo dicht mogelijk bij de ingang te plaatsen.

Op zich is dit laatste het meest logisch, alle adresnodes bevinden zich namelijk binnen het gebouw, en een routeplanner kan hier gebruik van maken om zo dicht mogelijk bij de ingang te routeren.

Het zichtbaar krijgen van alle nummers in een appartementencomplex met veel adresnodes, is een utopie en zou als taggen voor de renderer opgevat kunnen worden. Alhoewel ik dit niet vind.
Taggen voor de renderer is dat ik een hotel maak van een B&B omdat hotel meer opvalt, dit vind ik meer een geval van tagging voor de renderer.

Hier eenzelfde probleem, helft van het gebouw is ondergrondse parkeergarage, maar het gebouw staats als een unit in de BAG. Wat is handig?

  • Splitsen in twee gebouwen, maar dan raak je de koppeling met een unieke BAG code kwijt

  • Splitsen in woontoren en amenity=parking

  • Zo houden en latere bovengrondse objecten er gewoon overheen tekenen met layer=1

https://www.openstreetmap.org/#map=19/52.30153/4.87593&layers=N

Ik stel voor: het pand zoals deze er nu staat behouden en er de tags van parkeergarage, layer en location op zetten. Binnen het bovenste deel van de controur dan een extra way met building:part en de tags van het bovengrondse deel. Eventueel dan nog een 2e building:part als je ook nog de hoogbouw wilt onderscheiden van de laagbouw.

Een building:part heeft uitsluitend betekenis voor 3D rendering. Hierbij moeten alle delen van het gebouw van een building:part worden voorzien.

De BAG code kan blijven bestaan maar dan op een van de twee gebouwen. (Tenzij dit andere problemen geeft, ik voer geen BAG-imports uit.)

Ik denk dat het afhangt van de situatie, bijvoorbeeld als de gebouwomtrek samenvalt met de parkeergarage maar niet met het woongedeelte. In dat geval zou de parkeergarage layer=-1 + parking=underground kunnen krijgen en het gebouw zou eroverheen kunnen worden getekend. Het is hierbij ook mogelijk om de building tag van de parkeergarage te verwijderen. Dat laatste maakt de omtrek van het bovenste gebouw zichtbaar op de kaart maar is misschien ook een vorm van taggen voor de renderer.

Als de gebouwen samenvallen dan zou ik eventueel van het gebouw zowel een parkeergarage als een appartement maken maar de bovenstaande oplossing is ook mogelijk. Ik ben dit nog niet tegengekomen.

Het zou natuurlijk erg fijn zijn als gebouwen met parking/location=underground of level<0 gestippeld zouden worden weergegeven maar de renderer houdt zich daar nu eenmaal niet mee bezig. Dat wil overigens niet zeggen dat het niet zo getagd mag worden.