Update / opschonen Arnhem Centraal.

Ik hengel bij deze even naar de ‘wisdom of the crowd’.

Station Arnhem Centraal is, met vele grotere stations in Nederland, een samenraapsel van gebouwen geworden met daarbij loopwegen en voetgangersgebieden op verschillende niveaus. De standaard renderer (ik neem gemakshalve hier even aan dat de meesten ‘Mapnik’ als standaard gebruiken) maakt er niet bepaald een fraai gezicht van. ‘Boosdoener’ is met name de contour van de (ondergrondse) parkeergarage, die het oostelijk (stads / trolley) busstation overlapt. Ook blijken een aantal in de BAG aanwezige gebouwen (nog) niet geïmporteerd.

Kijkt u even mee: http://www.openstreetmap.org/#map=18/51.98419/5.90205

Voor hiermee aan de gang te gaan had ik toch graag wat ruggespraak over de volgende onderwerpen:

  1. Import van de missende gebouwen uit de BAG:
    Wat er nu met name mist, zijn gebouwen op level -1 (denk ik ?), zijnde winkels in de stationstunnel. Het is (natuurlijk) niet de bedoeling dat deze de perrons en sporen (immers op een hoger niveau) gaan overwoekeren. Voorzover ik weet, gaan sporen en perrons in Mapnik rücksichtslos over gebouwen heen, dus zou dat goed moeten gaan, maar is dit werkelijk zo ?
    Daarnaast zou ik dan een bredere voetgangerstunnel willen voorstellen (nu een simpel voetpad). Zou dat met een voetgangersgebied mogen en kunnen ? Grappig: ook dat lijkt standaard onder de sporen te worden gerenderd, maar wel bovenop gebouwen… Wat is daar de meest elegante oplossing voor ?
    En er moet wat met POI’s gesleept worden (winkels, liften), maar dat lijkt me de minste zorg.

  2. Overlay van het oostelijk (stads / trolley) busstation:
    Ik zou willen voorstellen om over het oostelijke busstation een voetgangersgebied te leggen. Daardoor wordt de parkeergarage die nu het kaartbeeld verziekt netjes overdekt. IMHO klopt het ook beter met de werkelijkheid: het westelijke (streek) busstation ligt dan écht binnen in een gebouw (zoals het is) en het oostelijk busstation in de open lucht in een voetgangerszone.

Mis ik verder nog iets ?

Gezien de impact sla ik niet meteen aan het mappen en wacht even op jullie reactie(s), waarvoor bij voorbaat vriendelijk dank,

Marcel.

Altijd lastig dit soort drukke gebieden.

Import vanuit BAG kunnen we zo doen. Zolang een mapper met lokale kennis de gebouwen op het juiste niveau zet zodat ze niet onderling conflicteren.
Voor het renderen blijft het behelpen. Heb voor een parkeergarage al ergens gezien dat men de building tag eraf gesloopt had waardoor het geel ipv grijs renderde, maar zou sowieso wel zorgen voor nette layer en location tags.

Doorgaans geen probleem om wandelgebied als pedestrian area in te tekenen (met F in JOSM volg je heel gemakkelijk een andere (pand)contour om niet raar te overlappen.
Zorg er, ivm routering, wel voor dat er wel een lijntje blijft lopen binnen het voetgangersgebied.
Eerder van de week was in een van de draadjes op het forum ook al een opmerking dat ondanks layer tags wegen altijd prominent overal bovenop gerenderd worden. Maar dat is logisch gezien het ontstaan van openSTREETmap, de rest is 'slechts` opsmuk :smiley:

Anderen zullen ook nog wel noodzakelijke danwel handige tips en aanwijzingen hebben.

Het is wel heel erg een verzoek om te mappen voor de renderer :slight_smile:

Ab
so
luut

niet. (en ja, ik zag je smiley)

Het zou ‘mappen voor de renderer’ zijn als ik elementen zou introduceren die er niet zijn of bestaande elementen zou veranderen of vervormen- en dan ten doel voor een beter kaartbeeld. Maar als er bovenop een ondergrondse garage een voetgangersgebied ligt kan dat er toch gewoon neergezet worden ? Ik ben alleen niet 100% gerust op complicaties wegens het feit dat het hier meerdere niveaus betreft en met name in de nieuwe stationstunnel.

Marcel.

Ik denk dat we een ondergrondse parkeergarage, ook al staat die in de BAG, niet dogmatisch behoeven te importeren. We kunnen ook een node met amenity=parking, location=underground mappen.

Niet alles wat kan moet.

Dit is m.i. niet mappen voor de renderer. De precieze omvang van een ondergronds gebouw doet in het kader van OSM niet ter zake.

…maar ik kan het mis hebben…

+1!

Overigens, amenity=parking heeft zijn eigen sub-key:
amenity=parking
+
parking=underground/multi-storey/rooftop zijn de meest gebruikte sub-tags

In dit specifieke geval kun je dus beter parking=underground kiezen i.p.v. location=underground

Ik heb laatst de ondergrondse parkeergarage onder het nieuwe Venlose gemeentekantoor aangepast. Building=yes heb ik gewist en
note=Not visible above ground. Probably parking underground
toegevoegd.
Ik was me eigenlijk van geen kwaad bewust maar het was inderdaad een gevalletje taggen voor de renderaar.

Heren, heren, pas op met dat soort acties!

In het Arnhemse geval, bijvoorbeeld, is er één grote BAG contour die zowel de ondergrondse parkeergarage als het gedeeltelijk daarop gelegen kantoorgebouw omvat. Dat is in OSM dan ook als één polygoon verwerkt - terecht, want zo werkt de standaard BAG import. Van zoiets de ‘building=yes’ verwijderen leidt er toe dat ook het zichtbare bovengrondse deel verdwijnt…

Een oplossing zou zijn de contour te splitsen in een gedeelte dat écht alleen maar ondergronds is, en een gedeelte dat zowel ondergronds als bovengronds is, maar dan treed je dus buiten de BAG. Ik zou er in dit geval geen bezwaar tegen hebben, maar hoe wordt er hier over zo’n oplossing gedacht ?

Er blijken trouwens in Arnhem een aantal ‘spookpolygonen’ aanwezig met ‘building=yes’ welke in het gebied van het (overdekte) westelijke streekbusstation liggen. Ze liggen verdacht gelijk aan de trappenhuizen van de parkeergarage en - een deel van - de buitenmuren. En ze staan (terecht) niet afzonderlijk in de BAG. Die mogen mijns bescheidens insziens dus sowiso weg.

Marcel.

@openMvD:

Precies!

Los van het feit dat de BAG zelf ook fouten bevat en dus niet als onfeilbare bron beschouwd kan worden: OSM is door en voor ons. Het laatste wat OSM moet beogen is een 100% kopie (back-up?) van officiële (overheids)kaarten gebaseerd op overheidsdatabases te zijn. De overheid maakt (hopelijk) haar eigen back-ups.

Dus als een BAG gebouw in het echt niet zichtbaar is: niet tekenen; en splitsen in een bovengronds deel (zichtbaar) en een ondergronds deel (onzichtbaar) op basis van waarneming of luchtfoto is niets mee.

Als voorbeeld de door de gemeente ingetekende ‘panden’ in Valkenburg aan de Geul: https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?geometry.x=185923.02125853&geometry.y=318565.47494049&zoomlevel=6

Omdat de ondergrondse ruimte (voormalige mergelgroeven - let op: geen grotten) als toeristisch ding geëxploiteerd wordt moest er een BAG-pand komen. De fantasievorm (want zo heeft de gemeente mij verteld) is gekozen om niet ingewijden geen idee te geven dat daar een ondergronds gangenstelsel loopt.

Dit soort dingen dus niet rücksichtlos importeren “omdat het kan”.

Een soortgelijke situatie zag ik in Geleen, daar stond de hele ondergrondse parkeerplaats als pand. Daar heb ik de panden los ingetekend en de parkeerplaats op layer -1 gezet.
Ik neem aan dat dit een redelijke oplossing hiervoor is?

:stuck_out_tongue:

edit: typo

Ik neem aan dat je deze way bedoelt.
Hoe kom je dan aan de huizen?Heb je die van de luchtfoto overgetekend?

Die bedoel ik, de huizen (appartementen) komen idd gewoon vanaf de luchtfoto. De situatie op kaart komt nu tenminste overeen met de werkelijke situatie, maar daarvoor moet je dus wel ter plaatse gaan kijken (of Mapillary gebruiken).