Ik denk er ook zo over. Zulke paden zijn volgens mij overigens een path en geen footway.
Het geeft een goede indruk van de omgeving en het maakt de buurt herkenbaar. Wel vind ik het jammer dat er voor een natural werd gekozen maar die discussie was al geweest.
Wat de blauwe P’s betreft, een mogelijke oplossing daarvoor is om dit soort parkeervakken met de juiste sub-tag te taggen zodat renderaars juist daar op in kunnen spelen. Ik heb tot nu toe parking=street aangehouden, maar dit wordt waarschijnlijk parking=street_side. Daar ligt nu een voorstel voor:
https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side
Een stoep is toch juist per definitie een footway? Of bedoel je een ander pad?
Even over de P’s… We hebben toch
parking:lane:left /right/both = parallel / perpendicular
Je kan ze op twee manieren mappen, impliciet (parking:lane) en expliciet (amenity=parking). Supaplex030 en ik hebben dat in het voorstel voor street_side parking ook meegenomen. Daar staan een aantal voorbeelden bij van beide manieren.
De expliciete manier is soms logischer wanneer het parkeervlakken betreft die qua vorm afwijken, of zo groot zijn dat ze ook ter oriëntatie nuttig zijn op de kaart. De impliciete manier is met name heel geschikt voor een straat met parkeervlakken in de lengterichting, en natuurlijk op plaatsen waar geen hogeresolutiesatellietbeelden of BGT-achtige data beschikbaar is.
Gelezen, goed werk! Voorgestemd. Ga het toepassen in mijn omgeving (als ik de tijd vind).
Dank je!
Waaruit blijkt dat het een stoep is?
Welke way op OSM specifiek?
Persoonlijk voeg ik stoepen wel toe, mits er een groenstrook of parkeerhaven tussen ligt. Stoepen die aan de weg liggen teken ik alleen in als ik een achterpad aan de straat wil verbinden maar er een boom of parkeerplaats in de weg ligt.
Overigens vind ik de toevoeging parking=street_side ook een hele goede! Ik ben het eens met het gegeven dat een kaart erg druk wordt. Maar het dan niet in kaart brengen omdat het anders te druk wordt, wordt dan weer intekenen voor de renderaar.
Ik ben zelf parkeerplaatsen gaan intekenen omdat ik bij het verbeteren van de kaart andermans werk tegenkwam (en dat betrof vaak parkeervakken). Uiteindelijk geeft het een goede indruk van het straatbeeld. Parkeervakken slurpen inderdaad veel publieke ruimte!
Alles voor auto’s slurpt ruimte!
Ik heb recent in Houten wat gemapt voor Knooppuntnet, ook daar zijn veel stoepen “los” van het naastliggende fietspad of erftoegangsweg getekend. Het leverde nogal wat problemen op omdat ik “doorsteekjes” moest tekenen, zoals hier. Als ik dit al een aantal keer moest doen dan levert het op andere punten ook nogal wat problemen op, zoals hier waar de router een enorme omweg voorstelt omdat het fietspad net ten oosten van het bruggetje niet overgestoken kan worden.
Precies mijn gedachte. En door de tagging goed te regelen geven we de renderaars handvatten om de rendering aan te passen. Supaplex030 had in ons voorstel al een paar voorzetjes gedaan; de kleinere blauwe P lijkt mij wel kansrijk bijvoorbeeld.
In het kader van stoepen en trottoirs. Bij het zoeken van een geschikte locatie om als praktijkvoorbeeld te dienen in een filmpje over bedrijfsinformatie stuitte ik op Almere-Haven, waar iemand een rondgang had gemaakt langs de diverse winkels in dit gebied.
Bij het bewerken viel me op dat er veel trottoirs zijn ingetekend (zonder groenstrook ertussen). Sommige trottoirs eindigen ook ‘zomaar’, zonder aan te sluiten op een andere weg.
Dit is duidelijk de keuze van de kaartmaker, en daar kan ik tot op zekere hoogte in meegaan. Want dit is persoonlijk, en er bestaat geen consensus over ‘hoe het hoort’.
Nu liggen veel van die trottoirs schots en scheef; de cartograaf had geen beschikking over de BGT en was bezig via de webbewerker iD.
Een aantal verschoven polygonen van gebouwen heb ik zo goed en kwaad als het ging recht gelegd, parkeervakken beter ingetekend, alsmede wegen en groen.
Maar die trottoirs. Wat daarmee gedaan? Nu vraag ik mij af: handhaaf ik de noeste arbeid van de kaartenmaker die daar duidelijk een bepaald doel mee voor ogen had? Dus: trek ik ze recht adhv bgt? Koppel ik ze aan de andere wegen zodat ze in ieder geval routeerbaar zijn?
Of is er toch een soort van standaard waaraan we conformeren?
Hier is het gebied waar ik het nu over heb, ik heb een stuk gemarkeerd waar ik nog niet ben ‘geweest’.
https://www.openstreetmap.org/?mlat=52.33502&mlon=5.21947#map=19/52.33502/5.21947&layers=N
Als het niet teveel werk is handhaaf ik ze wel, maar ik denk dat het niet verkeerd is om ze gewoon weg te doen als ze niet aan een paar minimale eisen voldoen:
Routering werkt, geen eilanden en doodlopende punten als je daar als voetganger wel verder kan
Redelijk uitgelijnd en netjes parallel met fietspad of straat waar van toepassing
Tagging voegt waarde toe (footway=sidewalk, rolstoeltoegankelijkheid meegenomen, etc.)
Vooropgesteld: als een voetpad gewoon goed ingetekend is, dan is weggooien niet de bedoeling. De betreffende tags zijn gewoon ondersteund, goedgekeurd, en gedocumenteerd, en ook als je als mapper zelf niet tot dat niveau mapt, dan betekent dat niet dat anderen dat niet mogen.
Goede routering met ingetekende stoepen is moeilijk. Zo’n voetpad als deze zou ik zelf ook als los pad intekenen als ik ook gelijk de bomen, de fietsenstallingen, en de parkeerhavens had ingetekend (die scheiden hem van de straat), maar dan moeten er ook oversteekplaatsen bij tussen de kade en die restaurantboulevard.
Eigenlijk zou ik er in dit geval vanaf blijven tenzij ik toch al grondig bezig ging daar. Dus ook de landuse op retail en zo, en meer details die bij zo’n verblijfsgebied horen.
Zo’n pad als deze die op meerdere punten niet verbonden is met de rest van het netwerk… Ja wat moet je er mee? Goed intekenen is een optie, maar weghalen en de sidewalk=* op het fietspad lijken me ook niet verkeerd. Het zit er een beetje tussenin. Als iemand die wel los wil intekenen, dan moet dat wel goed gedaan worden. Er is dus denk ik wel een minimale set eisen die je er aan kan stellen, maar wat nou de juiste ondergrens is? Goede vraag.
Het is een aanliggen troittoir denk ik, misschien zelfs een gedeeld fiets-/voetpad.
Apart intekenen behoeft dus zeker niet. Ook is de tagging footway=sidewalk én highway=footway onjuist.
Sidewalk op het fietspad is het beste.
Je kunt het onder vermelding van de reden in de changeset aanpassen vind ik.
Maar dat is ook maar een mening…
Bij het intekenen van de Sluiskade kan ik bij een volledige weergave van de indeling wel voorstellen. Nu ziet het er een beetje verloren uit. Ik kan dat nu wel even invoeren. Ik heb hem immers gisteren ook een beetje rechtgetrokken.
Zo ver als de Oosterdreef ben ik niet gekomen. Ik kijk net op de obliquebeelden (van een week terug) en het is een fiets-/voetpad uitgevoerd in twee kleuren klinkers. Mij lijkt highway=cycleway met foot=yes en segregated=yes een prima vervanging. Het is ook geen pad met apart voetgangersoversteken, en dan nog.
Mijn gevoel zegt ook: indien niet goed uitgelijnd of niet aansluitend: verbeteren of verwijderen. Ik ben nog even in dubio of ik me de komende tijd ga richten op Almere Haven, maar daar is dat werk dan wel aan gerelateerd. Of ik het ga doen of niet. Beetje in lijn met wat Jeroen zegt. (Wat ik wel ga doen, is aan landgebruik vastgeplakte gebouwen losweken en dan beschouwen over een aantal polygonen opnieuw geǐmporteerd moeten worden.)
Trouwens: footway=sidewalk, zet je die op een autoweg? Is dat beschouwd als de correcte toepassing?
Nee, footway=sidewalk is als sub-key een verdere duiding van highway=footway. Daarmee geef je aan dat een voetpad als stoep fungeert.
Ik zie nu (opnieuw) de consensus waar Martin over sprak.
Ik bedoel: sidewalk=no|left|right|both op de doorgaande weg.
Ja, dat routeeert meestal ook voor voetgangers.
Nou ja, sidewalk=* an sich doet niets met de routering in de zin van ‘mag je er langs’ (het is geen access-tag), maar kan eventueel als extra waarde meegewogen worden. Bijvoorbeeld door straten mét stoepen voor te trekken in de routing, of om gebruikers van een navigatie-app de mogelijkheid te geven een voorkeur voor straten met stoepen (of anders losliggende wandelpaden) uit te laten spreken.
Qua rendering zou er ook iets mee gedaan kunnen worden. Geen idee eigenlijk of er al kaarten zijn die dat doen los van de kaarten die specifiek op die key gericht zijn.