Darüber sprechen wir hier nicht zum ersten Mal, aber ich schreibs nochmal, unter “Wohngebiet” kann man sich m.E. vor allem 2 Dinge vorstellen (insbesondere unter dem englischen term “residential area”):
ein Teil einer Siedlung (Stadt, Dorf, …), der unter einem Namen bekannt ist, und in dem vorwiegend bzw. zu einem nennenswerten Anteil gewohnt wird.
M.E. ist dafür am besten place=neighbourhood, quarter oder suburb geeignet. Welcher landuse dort zu welchem Anteil vorkommt, sollte eigentlich schon aus den beinhalteten landuse Flächen hervorgehen, man könnte aber auch zusätzlich ein manuell kuratiertes Attribut setzen, z.B. neighbourhood=residential oder place:use=residential (es gibt “residential” bereits als Attribut mit abutters=residential und use=Residential (import?), neighborhood=residential gibt es auch bereits 1379 mal).
eine vorwiegend fürs Wohnen genutzte Fläche (landuse=residential)
Hier ist die Verwendung des Ausdrucks Wohngebiet für Siedlungen oder Teile davon nicht üblich, vielleicht ist das in Deutschland anders. Ich versteh das deutsche Wort und auch das englische Wortpaar so gut wie nur im Sinn von Punkt 2 oben. Für die Sachen in Punkt 1 hat man hier eigene Wörter: Block, Grätzel, Stadtteil; nicht unähnlich wie die Werte für “place” übrigens.
In kleinen Gemeinden ohne nennenswerten Fremdenverkehr, Landwirtschaft oder Industrie ist das kein Fehler, wenn das gesamte Siedlungsgebiet als Wohngebiet erfasst ist. Die reine Lehre würde gebieten, den Supermarkt und das Dorfpub auf “retail” zu legen und den Gasthof mit Übernachtung auf “commercial”. Auch wenn das beim Pub nur fürs Parterre (den Boden) gilt?
Wie man sieht wird von Detailmappern die Grenze gern mit den Bordsteinkanten der Straßenfahrbahn zusammengelegt. Das hat mehr mit Malunterricht zu tun als damit, eine Datenbank mit Dingen zu füttern, an denen einem etwas liegt.
Das lässt sich übrigens ganz leicht korrekt abbilden: Die Verkehrsfläche (building_passage) nicht aus dem Wohngebiet ausstanzen (als Loch in einem Multipolygon), sondern einfach so drüberlegen. Dann ist die darunterliegende Fläche doppelt kodiert.
[Update, das Skript für quick-quote hat mich zum Autor des Zitats gemacht.]
Hier ein besonders schönes Exemplar, warum das Getrennt-Mappen baulich nicht getrennter Bürgersteige ein zwar zulässiges Mapping ist, aber meistens schlecht schlecht gemacht: “kurzer” Besuch in der Nachbarschaft
Das Beispiel aus Bern ist nicht uninteressant, da kommt etwas vor, das Tordanik weit oben im Thread angesprochen hat: eine Straßenrelation, https://www.openstreetmap.org/relation/3092754 - ob Graphhopper das auswertet kann nicht mit Gewissheit gesagt werden, weil der Gehweg eigens benannt ist, aber eher nicht.
Wenn nur Gehwege benutzt werden dürften, für das Profil “Fuß” nicht abwegig, dann wäre eine ostseitige Verbindung schon möglich, man müsste zwar die Kirche umrunden und es wäre fast noch einmal so weit, aber es ginge. Vielleicht mehr Strafpunkte für Straßen mit “separatem” Gehweg? https://github.com/graphhopper/graphhopper/issues/1470 zielt haarscharf daran vorbei. Wenn dann herauskommt, was OSRM in dem Fall vorschlägt, dann kann man sich auch die Runde um die Kirche sparen.
Es kommt trotzdem aufs Selbe heraus: Niemand ortskundiger würde die vorgeschlagenen Wege nehmen. Fußverkehr reagiert sehr sensibel auf Distanz. Die Idee, dass man bei getrennt erfassten straßenbegleitenden Gehwegen einfach den Router fürs Auto verwenden kann und keinen eigenen Fußrouter bauen muss, die steht und fällt mit den fehlenden Übergängen. Aber das war gerade erst Thema in einem andren Thread.
Wenn die Gehwege dann erst einmal getrennt in den Daten stehen kann selbst der beste Fußrouter nicht mehr umhin, denen auch zu folgen. Weil ein auch ein “footway=sidewalk” eben nicht so verstanden werden darf, dass vom Gehweg aus die Straße zu Fuß überquert werden kann. Das stimmt in der Praxis zu oft nicht.
Relationen sind ohne Zweifel eine elegante Methode, um die Zusammengehörigkeit von Fahrbahn und Gehweg in den Daten abzubilden. Aber KISS ist das nicht mehr, wenn ein Anfänger eine Relation bauen muss, um einen Gehweg zu erfassen. Solche Konzepte sind für Profis genial, aber interessierte Neumapper bekommen wir damit nicht viele ins Boot.
diese ganzen Fußgängerroutinganwendungen unterschlagen, dass Fußgänger auf der Straße gehen müssen, sofern sie sperrige Gegenstände mit sich führen und damit andere Fußgänger behindern würden. Zumindest in Deutschland.
Trotzdem der Einwurf für den Thread hier eh null von Belang ist, mein Senf dazu Wenn es Bedarf gäbe, würde es Schalter bei den Routern dafür geben. Vielleicht aber auch nicht. Denn die Pflicht ist ans Verkehrsaufkommen gebunden, also von Tageszeit und Wetter abhängig. Das zum Kriterium für die Qualität von Routern zu machen zeugt von den allerhöchsten Ansprüchen!
ich kenne die österreichischen Gesetze nicht, in Deutschland steht das Verkehrsaufkommen nicht drin:
(2) Wer zu Fuß geht und Fahrzeuge oder sperrige Gegenstände mitführt, muss die Fahrbahn benutzen, wenn auf dem Gehweg oder auf dem Seitenstreifen andere zu Fuß Gehende erheblich behindert würden. Benutzen zu Fuß Gehende, die Fahrzeuge mitführen, die Fahrbahn, müssen sie am rechten Fahrbahnrand gehen; vor dem Abbiegen nach links dürfen sie sich nicht links einordnen.
Ich würde gerne die Eingangs gestellte Frage erweitern und fragen, wie man denn Fuß- und Radweg gemeinsam korrekt (attributiv) mappt/taggt? Ich tu’ mich noch schwer damit mein aus der Wiki gesammeltes Wissen anzuwenden und bereits gemappte Fuß- und Fahrradwege zu entfernen, die direkt an der Straße anliegen. Irgendjemand hat sich ja die Mühe gemacht und als Neuling kann ich ja auch nicht einfach machen, was mir passt .
Aber da scheint es auch keine endgültigen Konsens zu geben?
Ich versuche es mal zu konkretisieren:
Soweit ich das verfolgen konnte, auf die Gefahr hin, zu wiederholen was ihr bereits diskutiert hattet, und gemischt mit dem, was ich aus der Wiki und anderen Foren(-beiträgen) entnommen habe:
Alles getrennt, doof fürs routing, unübersichtlich, aber geometrisch am “korrektesten”
Attributiv, Super fürs routing, doof fürs exakte Rendern, wobei bei 1. auch naheliegende Wege von der Straße geschluckt werden können beim rendern.
2.5 Attrbutiv, und einzelnd gemappt zusammen, und dann attributiv kennzeichnen mit z.B. sidewalk=separate; cycleway=separate
Als Fläche, dann per attribut oder relation verbinden. Super aufwendig.
Was wäre denn euer aktueller Konsens diesbezüglich, mit besonderem Blick auf Fahrradstreifen auf dem Gehweg?
Ich hatte es jetzt an zwei Beispielen z.B. so versucht:
Den sidewalk (also jetzt mal randomisierte Beispielmerkmale):
sidewalk=right
sidewalk:right:surface=paving_stones
sidewalk:right:foot=designated
sidewalk:right:bicycle=designated
sidewalk:right:segregated=yes
Was, soweit ich weiß nicht gerendert wird?
Und noch zusätzlich:
cycleway:right=track
cycleway:right:surface=paving_stones
Was sogar gerendert werden kann?
An stellen, an denen der Weg baulich getrennt bzw. signifikant distanziert vom Straßenverlauf abweicht, habe ich versucht es mit
sidewalk=separate
cycleway=separate
zu Kennzeichnen, und die entsprechenden Merkmale auf den seperaten Weg gesetzt.
Wobei man an Kreuzungen oder Querungsmöglichkeiten cycleway=crossing setzen sollte? Nützte man dabei überhaupt noch das footway crossing (https://wiki.openstreetmap.org/wiki/Key:crossing)?
Wäre das ein gültiges und produktives Vorgehen nach den Statuten der OSM-Community?
Ist gleichzeitiges sidewalk und cycleway vielleicht ein schlechtes Vorgehen wegen Redundanz/verschiedenen Werten?
Gibt es vielleicht bereits einen Forenbeitrag, den ich nicht gefunden habe und meine Frage bereits beantwortet?
Das kannst Du machen wie Du möchtest. Beide Varianten sind immer möglich, auch wenn gerne etwas anderes behauptet wird und die “bauliche Trennung” als Weichensteller genannt wird. Beide Varianten haben Vor- und Nachteile. Aus meiner Sicht überwiegen die Vorteile des separaten Geh-/Radweg-Mappings. Anfangs habe ich soweit möglich das Tagging-Schema verwendet und musste dann immer wieder feststellen, dass es unheimlich kompliziert und unübersichtlich wird, wenn Radwege mit ins Spiel kommen oder manche Situationen ließen sich gar nicht darstellen. Daher nutze ich das Tagging-Schema nur noch bei reinen Gehwegen, die direkt an die Fahrbahn grenzen.
Das separate Mapping hat vor allem daher einen schlechten Ruf, weil nicht selten die wichtigen Verbindungen zur Straße und anderen Wegen/Zufahrten weggelassen werden. Dann macht es das Routing kaputt. Ansonsten ist das Routing wesentlich genauer mit separat gemappten Wegen.
Leider bei der Tagging-Methode nicht anders möglich. Ein deutlicher Nachteil, der mich auch schon früh gestört hat. Hatten wir hier im Forum bereits an anderer Stelle diskutiert. Dieser Punkt fehlt noch in der Tabelle von JochenB, wenn ich den nicht übersehen habe.
Wenn der Radweg separat und benutzungspflichtig ist, dann kann auch noch ein ‘bicycle=use_sidepath’ an die Straße.
Wenn der Radweg nur einseitig und seperat ist mache ich auch gerne ‘cycleway:right=separate’ und ‘cycleway:left=no’
Ich selber markiere die Kreuzungen zwischen Straßen und Geh- bzw. Radwegen nur dann, wenn durch Fahrbahnmarkierungen, Ampeln, Schilder, Inseln o. ä. besonders hervorgehoben sind, und dass nur auf dem Kreuzungspunkt. Dass ein Geh- oder Radweg kreuzt, ist mit dem gemeinsamen Kreuzungspunkt bereits abgebildet. Aber auch hier sind die Geschmäcker verschieden. Am Besten auch schauen, wie es drumherum von anderen gemacht wird.
Ich hab das nur insofern in der Tabelle, als dass die Eigenschaftenliste durch die vielen Einträge unübersichtlich wird, wenn alles an eine Linie getaggt wird. Dafür wird es im grafischen Editor übersichtlicher. Alles Geschmackssache.
Redundant ist es nur beim “Gemeinsamen Geh- und Radweg”, also wenn der Strich zwischen Fahrrad und Fußgänger auf dem blauen Schild horizontal ist. Das habe ich noch nicht, Danke für den Hinweis!
Theorethisch wäre es mit folgendem Tagging auch alles gesagt:
Allerdings würde ich dem immer ein ‘sidewalk=both’ spendieren und damit wäre es redundant zum ‘cycleway:foot=designated’.
Am Saubersten wäre das Verwenden des übergeordneten Begriffs ‘path’ bzw. ‘side_path’ statt ‘cycleway’ oder ‘sidewalk’. Bei getrennt gemappten Rafd- & Gehwegen ist das Standard. Bei an der Straßenlinie gemappten Wegen macht das aber keiner.
Diese doppelte Angaben entfallen bei einem separaten hw=path.
Jetzt noch das ganze für den linken Geh/Radweg…
Vorteil: Man kann surface, smoothness, width eindeutig getrennt für den Gehweg und den Radweg erfassen. Das wird bei einem separaten hw=path schon wieder schwierig. Geht das überhaupt?
Redundant sind sie nicht, den das eine bezieht sich auf den Teil links des Strichs, das andere auf den Teil rechts davon. Da sind Eigenschaften häufig unterschiedlich.
Im Endeffekt sind das aber sehr viele Tags und es fehlt das Übergreifende für cycleway & sidewalk.
Das könnte man auf zwei Arten lösen:
Grundannahme dokumentieren, dass Werte für das Eine immer auch für das andere Gelten, solange nicht nur eines getaggt ist
Idee ‘sidepath=right/left/both/no/seperate’ analog zu ‘hw=path’ einführen
Aber ich muss erstmal mein aktuelles Proposal anstoßen, das reicht mir erstmal.
Ins Wiki könnte noch, dass mit einem ‘cycleway:segregated=no’ klar ist, dass die Eigenschaften für den Radweg auch für den Gehweg gelten und umgekehrt, oder?
Aufgrund miserablen separaten Trottoirtagging habe ich mich auch mal damit beschäftigt und stimme zu, dass bei richtiger Umsetzung die Vorteile überwiegen. Zusätzlich zu bicycle=use_sidepath ist natürlich auch foot=use_sidepath sinnvoll. Ich persönlich habe dann noch is_sidepath (Proposal) verwendet, um den Zusammenhang zwischen Straße und Trottoir/Fahrradweg in Tags abzubilden.
Damit es aber das Routing wirklich gut funktioniert braucht es eigentlich aber alle Barrieren, inklusive Bordsteine und natürlich eine genaue Erfassung von Grünstreifen und Böschungen. Dies zu Erfassen ist aber eine Menge Arbeit und geht doch weit ins Mikromapping.
Hmm, ja, jetzt ist ja doch noch einiges dazugekommen:)
Das mit den doppelten Einträgen stört mich z.B. auch ungemein; da wird mir mit Sicherheit irgendwann, und nicht nur ein mal, ein Fehler passieren. Oder der nächste mapper ändert etwas an einem der Wege und vergisst z.B. den Eintrag für beide anzupassen, oder umgekehrt.
Die Tabelle ist ja super anschaulich, kommt man da über die normale Wiki so einfach rauf? Die ist mir so bisher noch nicht begegnet. Wenn nicht, würde es Sinn ergeben, sie in der Wiki für sidewalk o.ä. in einem Satz zu erwähnen? Dafür gäbe es von mir zumindest ein +1
Aaaalso, sind beide vorgehen legitim, sofern sich ans Tagging-Schemata gehalten wird / bzw. Querungen gemappt werden. Und noch lässt sich beim attributiven Redundanz nicht vermeiden, da hierzu noch nichts implementiert oder proposed wurde.
Und eigentlich wäre getrennt mappen sogar zu bevorzugen, wenn richtig gemappt, soweit ich das verstanden habe.
Dann ergäbe sich mir da noch die Frage: wie mäppte man denn die Querungen korrekt?
Querungen ergeben sich zumindest automatisch an Kreuzungen und Zebrastreifen; oder, wenn einzusehen, herabgesetzte Bordsteine.
An städtischen Häuserblocks ist das Problem vermutlich auch überschaubar, da genügend Kreuzungen vorhanden sind.
Was ist denn mit längeren Wegabschnitten, bei denen sich keine kreuzungen auffinden lassen und keine “natürlichen” Querungen vorhanden bzw. ersichtlich sind, um z.B. auf die andere Straßenseite zu kommen? Gäbe es denn eine Möglichkeit, die Wege in eine Relation zu setzen? (Wenn ja, wozu gehört der Weg bei Kreuzungen?)
Konkretes Beispiel: Angenommen, ich habe einen km-langen Weg ohne ersichtliche Querungen, und auf beiden Seiten gibt es erreichbare Ziele. Was wäre da ein gutes vorgehen? Oder gibt es sowas praktisch nicht / ist das Beispiel zu konstruiert?
Und noch eine Verständnisfrage zur Tagging-Redundanz bei gemeinsamen Fuß-Radwegen:
Ihr erwähntet, dass z.B. mit
cycleway=track
cycleway:foot=designated
cycleway:segregated=no
das taggen des sidewalks überflüssig wäre.
Aber wäre es dann auch nicht überflüssig, wenn man für getrennte Wege:
cycleway=track
cycleway:foot=designated
cycleway:segregated=yes
täggte? Sofern man zumindest nicht vor hat, weitere Eigenschaften dem sidewalk zuweisen zu wollen, aber nicht selten sind beide doch gleich ausgebaut?
Da kam ich leider nicht mit.
Wenn ich einen cycleway=track habe, warum sollte ich ein sidewalk=both spendieren?
Oh warte, du meinst dem dezugehörigen path. Der hätte dann cycleway=seperat, sidewalk=both, richtig? Okay, Frage hat sich von selbstgeklärt.
Aber was meinstest du mit ‘path’ bzw. ‘side_path’ statt ‘cycleway’ oder ‘sidewalk’ bei getrennt gemappten Fuß-Rad-Wegen? Wie mappt man das nun korrekt?
Aaach, du meinstest, dass beim path *=seperate getaggt gehört und auf dem seperaten Rad-Fuß-Weg ein cycleway/footway=side_path, richig?
Wobei, du meintest statt.
Könntest du das doch nochmal kurz ausführen? Gibt es dazu eine Wiki-Seite? Das kann ja ganz schön verwirrend werden
Wenn es Bedarf gäbe, würde es Schalter bei den Routern dafür geben. Vielleicht aber auch nicht. Denn die Pflicht ist ans Verkehrsaufkommen gebunden, also von Tageszeit und Wetter abhängig. Das zum Kriterium für die Qualität von Routern zu machen zeugt von den allerhöchsten Ansprüchen!
.
