de locatie van de node (je kunt de ingang een eindje naar het noorden zien zitten op bing). is het beter een nieuwe node te maken en de oude te verwijderen, of de oude node te verplaatsen?
de operator (inmiddels Interparking in plaats van Q-park)
adres en postcode (al vraag ik me af of die hier relevant zijn, volgens mij heeft een parkeergarage helemaal geen adres, maar wordt gewoon een adres in de buurt opgegeven om het te kunnen vinden)
Het lijkt me ook hier voornamelijk handig te weten waar de ingang zit. Als ik alleen een node maak met amenity=parking_entrance, wordt ie dan gerenderd? De opmerkingen over layers snap ik niet helemaal, zijn er layers om ondergronds te mappen?
Voordat je de ingang plaatst, moet je eigenlijk eerst weten waar de parkeerplaats zich bevindt. In mijn tekening heb ik hem blauw gemaakt. Ik weet niet hoe die parkeerplaats daar precies ligt, klopt mijn blauw gearceerde gebied met de plek waar die parkeerplaats ongeveer ligt? Als je de parkeergarage hebt getekend moet je de ingang (rode rondje?), hoe dit moet, staat ook weer op de wiki:
Oftewel, je moet het zou het volgende moeten doen:
De weg naar de ingang (het rode streepje denk ik) van de parkeerplaats kan je taggen met highway=service.
De blauwe stip taggen met amenity=parking_entrance.
Als je de parkeergarage hebt getekend moet het nog tags hebben. Even naar beneden zie je ‘tags’ staan, bij ‘parking’ zie je ‘underground’ staan, volgens mij is dit wat je zoekt.
Dan zou je je parkeerplaats deze tags moeten geven: amenity=parking
parking=underground
Dan heb je in principe de parkeergarage, maar de naam en alle andere info die je toe wilt voegen staan er dan nog niet op.
Het adres mist nog bijvoorbeeld. Nu komen we bij de node waar je het over had.
Zoals je ziet is dit de adresnode (addr:city=Amsterdam, addr:country=NL, etc), deze moet je niet weg halen of verwijderen! Meestal wordt een de naam van iets gewoon aan de adresnode toegevoegd, zodat je niet te veel nodes op één gebouw of vlak hebt staan.
Volgens de Interparkingwebsite zit de hoofdingang op Carnapstraat 200, 1062 KZ Amsterdam (rare plek als je het mij vraagt trouwens). Adresnodes moet je absoluut niet gaan verplaatsen, hij hoort op die plek, bij dat specifieke gebouw. (Ik kan niet verhuizen naar Amsterdam en dan nog steeds zeggen dat ik op hetzelfde adres in Groningen woon, ik kan mij adres niet meenemen ;)).
Om het kloppend te maken, kan je de amenity=parking, name=Q-Park Oranjekwartier en operator=Q-Park van de adresnode weghalen, dat kan je gerust doen omdat die niks met het adres te maken hebben en dat Q-Park niet meer bestaat.
Aan het vlak waar je de parkeergarage van wilt maken kan je dan de volgende tags toevoegen:
Voor opening_houres moet je iemand anders vragen, want je zit met het feit dat je er op bepaalde tijden wel uit, maar er niet in kan, ik weet niet hoe dat moet ;).
Volgens mij doet het adres van de parkeerplaats er nu niet zo veel meer toe, je kan niet twee keer exact hetzelfde adres op een kaart hebben staan, en de ingang zit volgens mij op een andere plek dan op de website van Interparking staat.
Layers werden in de begintijd van OSM gebruikt om aan te geven dat een bepaald object bovenop (of onder) een ander object lag.
Huizen verdwenen dan niet onder het gras…
Tegenwoordig zijn de renderers slim genoeg om dat te begrijpen, maar de layer wordt nog wel altijd gebruikt bij bv. een brug over een rivier, want je kunt dan de rivier met layer=-1 taggen. Ook fly-overs en op- afritten bij snelwegen kunnen op die manier juist worden getagd en weergegeven.
Lees ook nog maar dit topic.
En inderdaad, ook parkeergarages (of ander ondergrondse bouwwerken, zoals de metrolijn) kunnen daar baat bij hebben. Soms is het ook nogal dubbel, want een tunnel gaat volgens mij altijd ergens onderdoor, dus layer=-1 heeft daar niet zoveel zin.
Sommige ondergrondse parkeergarages komen voor in de BAG als ‘gebouw’, andere weer niet. Sommige hebben een eigen adres met huisnummer, andere niet.
De garages die als gebouw in de BAG staan (building=yes), worden na import net als andere gebouwen standaard boven elke landuse afgebeeld, ongeacht of ze nu voorzien zijn van level=-1, layer=-1, location=underground.
De tag ‘building=yes’ weghalen helpt bij het niet afbeelden, maar zorgt er helaas voor dat bij BAG import/controle lijkt alsof het gebouw nog niet bestaat, dus alsnog een tweede keer kan worden toegevoegd.
De tag amenity=parking_entrance wordt standaard niet afgebeeld. Leuk dat een proposal over parking=site met amenity=parking_entrance is aangenomen, maar zonder ondersteuning in afbeeldingen kopen we er weinig voor.
Wat ik in de praktijk doe:
a. maak een weg met highway=service vanaf een andere weg naar een plek een stukje binnenin de parkeergarage
b. als in- en uitgangsweg gescheiden zijn, herhaal stap a en voorzie beide van oneway=yes; eindpunt in de garage is wel gemeenschappelijk
c. splits de ingaande/uitgaande weg(en) net buiten de garage en voorzie het binnenste deel van de tags ‘layer=-1’ en ‘tunnel=yes’
d. voorzie het (gemeenschappelijke) eindpunt in de garage van ‘amenity=parking’, ‘parking=underground’ en naar wens tags als name, operator, fee, opening_hours, capacity etc.
De ‘approved’ tags voor site=parking en amenity=parking_entrance worden hierbij dus niet gebruikt! Nogmaals en helaas, approval betekent nog niet dat het praktisch bruikbaar is.
Hmm, ik proef hier toch “taggen voor de renderer”.
“building=yes” weglaten omdat het lelijk wordt gerendered, afwijken van approved tagging omdat renderers ze nog niet weergeven…
Beter is het om bij de issue-trackers van een renderer aan te geven dat je wat gewijzigd wilt zien. Bijvoorbeeld een voorstel om ingangen te renderen en ondergrondse buildings niet/anders.
Heel eerlijk gezegd: dan ben ik ook voor ‘taggen voor de renderer(*)’.
Ondergrondse parkeergarages die als gebouw worden afgebeeld geven een kaartbeeld dat totaal niet overeenkomt met wat op maaiveld te zien is; en dát is wat ik van een kaart in eerste instantie verwacht. Hier als voorbeeld de Markt-garage in Delft: http://www.openstreetmap.org/#map=19/52.01420/4.36608
Er is totaal niet meer te zien dat er op maaiveld gewoon een open ruimte van zo’n 20 meter tussen de gevels zit omdat de contouren van de parkeergarage die helemaal opvullen. De meerwaarde van de contouren van de parkeergarage zijn mij niet bekend in dezen.
mijn 2 centen,
Marcel.
(*) totdat de renderer aangepast is om dit netter te verwerken, dan tenminste. Een afwijkende en lichtere kleur zou een eerste oplossing zijn. Overigens volg ik zelf als ik map ‘gewoon’ de BAG: als de garage als ‘gebouw’ is vermeld laat ik het tandenknarsend staan.
Ik vind de parkeergarage onder het Malieveld ook wel een aardig voorbeeld van een pand dat iets te prominent op de kaart verschijnt.
Maar hoe vervelend het soms ook is dat iets niet ‘naar wens’ gerendered wordt, dat mag nooit een reden zijn om de data te ‘verminken’.
Hoe vaker het juist getagd wordt, maar verkeerd gerendered, hoe groter wellicht de kans dat renderers er iets aan doen. Maar het moet dan wel bekend zijn bij de renderers dat deze situatie verbetering behoeft, maar deze staat al een paar jaar in de queue: https://github.com/gravitystorm/openstreetmap-carto/issues/552
Mijn absolute #1 ergernis in deze: ‘Den Heuvel’ in Velp (Gld). Hier is - onder een ‘normaal’ plein met parkeerplaatsen - een ondergrondse parkeergelegenheid met individuele, losse (nou ja, wel geschakelde), garageboxen die ook als zodanig in de BAG staan. De outline (eh, buitenmuur) van de ondergrondse garage staat merkwaardigerwijze dan weer niet in de BAG, wat mij een weinig inconsistent lijkt met andere parkeergarages. http://www.openstreetmap.org/#map=19/51.99465/5.97536
Het gerenderde resultaat lijkt op een plein met marktkraampjes. Poëtisch, maar onzinnig. Map what’s on the surface? Vergeet het maar.
Dat we BAG gebruiken mag naar mijn mening niet voorgaan op het standpunt dat de kaart moet weergeven wat zichtbaar is. Het is veel belangrijker dat iemand de kaart begrijpt, dan dat alles erop staat dat in de BAG zit. De BAG is niet ontwikkeld om OSM up to date te houden, dan moet je dat ook niet leidend maken voor wat er op OSM zit, en de BAG enkel als hulpmiddel gebruiken om van wijzigingen op de hoogte gehouden te worden.
Als de BAG niet leidt tot een feilloos resultaat, dan kun je niet zomaar de BAG overnemen is een menselijke controle dus altijd nodig. Misschien is het noodzakelijk dat juist daar wijzigingen in aangebracht worden.
Ik heb mij bij de BAG import ook eens bezig gehouden met dit ding in Drachten dat level=-1 heeft en als ik het mij goed herinner ook een parkeergarage moest voorstellen. Er lijkt van alles bovenop gebouwd te staan maar daarvan staat veel niet ingetekend.
Verder heb ik deze ooit in vier gebouwen gesplitst (4 torens, de smalle stukken ertussen zijn parkeergarage) maar een collega van de BAG import heeft daar onbewust het origineel weer overheen geïmporteerd.
Dit zijn maar een paar voorbeelden van iets wat bij de BAG gauw fout gaat, je hebt bij het importeren vaak niet door dat je een parkeergarage in je data hebt zitten. De oplossing zie ik zo snel ook niet, behalve dat iemand die ter plaatse bekend is met de hand de vorm van de bovengrondse gebouwen moet gaan intekenen. In het voorbeeld in Ede nog vrij simpel, maar in Drachten zonder goede kennis of een goede recente luchtfoto niet te doen.
Hoewel door velen “taggen voor de renderer” als een geslachtsziekte wordt beschouwd vind ik dat we hier vooral pragmatisch mee om moeten gaan.
OSM is ten eerste niet de (officiële) database / kaart van de overheden; die hebben hun eigen middelen. OSM is voor ons en de gemeenchap!
[off topic] het mappen van alle brandkranen inclusief diameter van de aansluiting heeft de brandweer echt niet nodig om nog maar eens zo’n voorbeeld te noemen
[/off topic]
Als ondergrondse gebouwen in het veld niet zichtbaar zijn en erger nog op de kaart de zichtbare informatie boven de grond (what’s on te ground) onzichtbaar maken of ernstig verminken (bijvoorbeeld promenades in een winkelecentrum, dan moeten we de ondergrondse parking gewoon niet als BAG-pand mappen. Dit is immers niet te vergelijken met een (weg)tunnel onder land of water door.
De precieze outline van het ondergrondse gebouw is niet zichtbaar of verifieerbaar en interesseert ons niet.
Dat die via import beschikbaar is, is geen reden om het dan ook maar te (moeten) tekenen
Dan maar een node maken met de amenity eraan en de nodige tags (undergound, capacity, etc.) en de toegangswegen
Zo heb ik het nieuwe winkelcentrum en ondergrondse parkeergarage in Valkenburg a/d geul inderdaad moeten mappen.
De BAG import van de parking overschadude alles inclusief de wandelpassages etc.
(ik weet niet of het plaatje doorkomt, maar het is in Valkenburg aan de Geul, Daalhemerweg (ten zuiden) aan de oostzijde)
Dit is een plaatje hoe de gemeente Valkenburg aan de Geul twee ondergrondse mergelgroeven tekent.
Mijn vraag en constatering dat die verre van de werkelijkheid was werd beantwoord: we moeten toch iets tekenen en willen niet publiek maken dat daar een uitgebreid grottenstelsel loopt."
Dus: ook de (ondergrondse) BAG info is niet altijd juist.
Nogmaals: OSM is voor de users en in mijn ogen geen replica/back-up van alles wat we in externe databases kunnen vinden.
Bij een BAG import mag je imho best de beslissing nemen bepaalde panden niet te importeren. Dit kunnen panden zijn nog wel in de BAG, maar verifieerbaar gesloopt of ondergrondse parkeergarages.
Wat mij betreft zetten we een dergelijk notitie in de BAG wiki. Desnoods importeren en building tag eraf halen (for the renderer) en een note erbij “Niet herimporteren aub”?
Dat snap ik toch niet helemaal.
Ik heb in Hengelo parkeergarage “de Brink” geïmporteerd, met daarbij de tags “layer=-1” en “location=underground”.
Daar worden de andere gebouwen, het plein en de passage gewoon netjes overheen gerenderd op de standaard mapnik.
Maar je ziet inderdaad op de standaard rendering niet dat het gebouw op maaiveldniveau niet zichtbaar is. Het zou wel handig zijn om (een gebouw met) “location=underground” iets minder prominent te renderen denk ik.
Maar Kars, jij hebt een truc toegepast: een deel van de parkeergarage wordt bedekt door een multipolygoon zonder enig kenmerk (voor zover ik kan zien): het plein van de Brink / Markt. En die multipolygoon heeft (ik vraag me af hoe, eigenlijk) de kenmerken van een straat - en straten worden nu eenmaal standaard boven gebouwen gerendert.
Ik moet zeggen: dan ziet het er meteen op het oog een stuk beter uit. Maar die multipolygoon staat ook over de stukken voetgangers-straat die iemand daar had aangelegd en wist die totaal uit. Sporen zijn nog zichtbaar, want de labels ‘Markt’ en ‘Brink’ zijn daarvan, vermoed ik. En helemaal perfekt werkt het ook niet, want voor de gevel waar ‘Bever’ zit, zie je een dunne rij bebouwing. Ik neem aan dat zoiets niet op maaiveld bestaat.
Best een creatieve oplossing, die ik in een aantal gevallen graag zou gebruiken. Het stationsplein in Arnhem (met name de ‘kuil’ van het stadsbusstation) zou daar één van zijn. De straat boven parkeergarage Markt in Delft een andere. Maar vóór ik zelfs maar denk daaraan te beginnen: we hebben een community hier: wat denken anderen daarvan ?
Die multi heeft wel kenmerken hoor. Dat is het voetgangersgebied (vroeger alleen op de Markt, ik heb hem vergroot inclusief de Brink). Die multi heb ik juist gemaakt omdat de kiosk en de Brinktoren op het plein niet gerenderd werden… Die heb ik met de multi “uitgeknipt”.
Die labels zijn van de straten, die liggen er nog onder voor de routering (op basis van het NWB). Standaard wordt er niet goed over een plein gerouteerd. Ik heb het plein alleen niet doorgetrokken over de Brinkstraat en een stuk Brink heen, mede omdat die (weliswaar lage) stoeprandjes heeft. Die bebouwing voor ‘Bever’ is inderdaad een stuk van de parkeergarage, onder de grond.
