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.
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 ?
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.
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.
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.
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
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).
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.
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.
