Strassenbreite, sidewalks,..

Meiner Meinung nach wäre es logisch, die Breite der sidewalks in width mit einzurechnen, wenn sie via Tag als Bestandteil des highway modelliert werden.

Linker Sidewalks hat 50cm, rechter 1m?

Es gibt bei cycleways die einigermaßen verbreitete Lösung cycleway:right:width=*. Diese könnte man analog auch für sidewalks nutzen - obwohl sie dort bislang nicht so häufig vorkommt.

Tordanik wrote:

Meiner Meinung nach wäre es logisch, die Breite der sidewalks in width mit einzurechnen, wenn sie via Tag als Bestandteil des highway modelliert werden.

Tja, das ist die Frage. Je nach Wichtigkeit für einen selbst wird man das sehr unterschiedlich beurteilen. Für den Autofahrer z.B. zählt nur die Fahrbahnbreite. Halt, gehören Parkstreifen dann noch dazu? Die sind für einen Autofahrer ja auch wichtig.
Für das Kataster zählt nur die gesamte Breite, die als öffentlicher Raum für Straße, Parkstreifen, Gehweg, Radweg, umgebende Grünstreifen und sonstige Ausstattung (Gräben, Leitplanken, ...) reserviert sind.

Da ich davon ausgehen, dass für viele die Antwort auf die Frage nach der Breite einer in OSM eingetragenen Straße genauso unklar ist wie mir, trage ich grundsätzlich keine Breite bei Straßen ein. Die abstrakte Zahl der Fahrspuren muss für mich reichen.

Auswerter haben das gleiche Problem. Sie können keine sinnvolle Annahme darüber stellen, was der jeweilige Eintragende denn nun gemeint haben könnte oder welche Interpretation als 'normal' gelten könnte. Die regelmäßigen Anfragen hier und in der Mailingliste zeigen das Dilemma recht deutlich.

Wenn man klar stellen will, was man wirklich meint, sollte man also bei Straßen die Breitenangaben nach width:carriageway, width:left/right/both:parking_lane, width:left/right/both:cycleway, width:left/right/both:sidewalk und nicht zu vergessen width:left/right/both:road_green verwenden.
Dabei kann man über die Reihenfolge von Breite:Seite:Bestandteil oder die Namen für die einzelnen Bestandteile natürlich diskutieren.

Und irgendwie müssten wir auch noch über die Reihenfolge der einzelnen Bestandteile reden, die ist nämlich alles andere als eindeutig. Vielleicht sollte man das schlicht wie bei den Fahrspuren als Liste machen.

Eine einfache Frage, die eine Menge von Folgefragen aufwirft und für die es daher keine einfache Antwort gibt.

Edbert (EvanE)

EvanE wrote:

Tordanik wrote:

Meiner Meinung nach wäre es logisch, die Breite der sidewalks in width mit einzurechnen, wenn sie via Tag als Bestandteil des highway modelliert werden.

Tja, das ist die Frage. Je nach Wichtigkeit für einen selbst wird man das sehr unterschiedlich beurteilen.

Ich habe ja nicht mit Wichtigkeit argumentiert, sondern mit "Logik". 😉 Wenn width die Breite des Objekts ist und die Sidewalks keine eigenen Objekte sondern Teil des Objekts highway sind, dann - so die Überlegung - würde ich sie mit einrechnen.

Aber klar, da kann man sich nicht drauf verlassen und letztlich wären nur explizite Tags richtig eindeutig. Was aber auch wieder nicht die Frage löst, was wir mit den 675.145 width-Tags an highways machen.

EvanE wrote:

Und irgendwie müssten wir auch noch über die Reihenfolge der einzelnen Bestandteile reden, die ist nämlich alles andere als eindeutig. Vielleicht sollte man das schlicht wie bei den Fahrspuren als Liste machen.

Ich hatte ja ursprünglich gehofft, dass man auch die Gehsteige einfach als Spur betrachten und auf diese Weise mit in die Spurwertliste aufnehmen könnte. Aber das hat der Autor des Lane-Proposals wohl anders gesehen. 🤔

Das macht die Sache nicht einfacher. Zumal uns dadurch jetzt auch eine Lösung fehlt, die Ordnung der Nicht-Autospuren anzugeben. Also doch die Gehsteige, Parkstreifen, Radspuren mit in die Spurliste? Oder zwei Listen?

Du siehst, mir fehlen hier ebenfalls die befriedigenden Antworten.

Hey

tordanik, wie wertet das denn osm2world aus?

Amiga4000

Amiga4000 wrote:

tordanik, wie wertet das denn osm2world aus?

Mangels einheitlicher Regelung eben so, wie es dem Chefentwickler logisch erschien: width als Gesamtbreite inklusive Gehsteige.

Die sidewalk:right:width (o.ä.) werden noch gar nicht ausgewertet, ebensowenig die Lane-Wertlisten. Das liegt daran, dass ich aus Zeitgründen noch nicht zum Einbau gekommen bin. Die technischen Voraussetzungen wären gegeben.

Tordanik wrote:

...
Aber klar, da kann man sich nicht drauf verlassen und letztlich wären nur explizite Tags richtig eindeutig. Was aber auch wieder nicht die Frage löst, was wir mit den 675.145 width-Tags an highways machen.

Nun ja einige Highway-Typen sind eher unkritisch, da man dort erst mal keinen zusätzlichen Gehweg vermutet:
- highway=footway/cycleway und highway=path + *=designated
- highway=path (ohne *=designated)
- highway=bridleway
- highway=track
In diesen Fällen tagge ich auch manchmal eine Breite.

Andere Straßen sind eher unklar:
- highway=road (ohne Klassifizierung keine Aussage möglich)
- highway=service (Gehweg nicht sehr häufig, aber kommt vor)
- highway=residential (in der Regel mit Gehweg, direkt daneben oder abgesetzt)
- highway=unclassified/tertiary/secondary/primary (unterschiedlich je nach Stadt/Land)
- highway=trunk/motorway (Gehweg selten, wenn dann abgesetzt (Grünstreifen/Leitplanke/...))
Gilt entsprechend auch für highway=*_link.

Die gleichen Überlegungen gelten natürlich auch für Radwege und kombinierte Rad-/Fußwege.

Als Auswerter würde ich entweder alle width-Tagg an highway=* ignorieren oder nur beim ersten Block berücksichtigen. Beim zweiten Block höchstens als Fahrbahnbreite betrachten, was natürlich falsch sein kann und würde es daher unterlassen.

Tordanik wrote:

EvanE wrote:

Und irgendwie müssten wir auch noch über die Reihenfolge der einzelnen Bestandteile reden, die ist nämlich alles andere als eindeutig. Vielleicht sollte man das schlicht wie bei den Fahrspuren als Liste machen.

Ich hatte ja ursprünglich gehofft, dass man auch die Gehsteige einfach als Spur betrachten und auf diese Weise mit in die Spurwertliste aufnehmen könnte. Aber das hat der Autor des Lane-Proposals wohl anders gesehen. 🤔

Das macht die Sache nicht einfacher. Zumal uns dadurch jetzt auch eine Lösung fehlt, die Ordnung der Nicht-Autospuren anzugeben. Also doch die Gehsteige, Parkstreifen, Radspuren mit in die Spurliste? Oder zwei Listen?

Du siehst, mir fehlen hier ebenfalls die befriedigenden Antworten.

Da weiß ich auch keine Antwort.
Ich möchte jedoch sagen, dass die Einigung auf eine Tagging-Variante für Fahrspuren schon ein großer Fortschritt ist.

Das Lane-Proposal bezieht sich nur auf Fahrbahnen und den Fahrspuren darauf. Selbst die Stand- und Parkstreifen sind nicht enthalten. Das mag man bedauern, ist im Sinne der Einfachheit/Übersichtlichkeit aber nachvollziehbar.

Um den gesamten Straßenraum einschließlich der Stand-/Parkstreifen, Fuß-/Radwege und entsprechender Trennungen (soweit vorhanden) bräuchte es ein neues Schema. Dass kann dann die Fahrbahn mit ihren Fahrspuren als eine Einheit behandeln, da Verfeinerungen bereits durch *:lanes=* abgedeckt sind.

Edbert (EvanE)

Gibt es schon Neuigkeiten bei diesem Thema? Würde ganz gerne mal die Straßenbreiten erfassen, bin mir aber wegen Parkplätzen am Straßenrand nicht sicher was gemessen werden soll. Gehsteige finde ich mit sidewalk:width*=* sinnvoll und width=* für die Straße selbst.

Und um das Thema noch zusätzlich zu verkomplizieren: Spurbreite zusätzlich abmessen? Abbiegespuren zu Einfahrten sind oft kleiner als solche vor Kreuzungen.
Noch etwas: Was wäre eine sinnvolle Angabe für eine Wendeplatz? Durchmesser oder Radius?

chatter wrote:

Gibt es schon Neuigkeiten bei diesem Thema? Würde ganz gerne mal die Straßenbreiten erfassen, bin mir aber wegen Parkplätzen am Straßenrand nicht sicher was gemessen werden soll. Gehsteige finde ich mit sidewalk:width*=* sinnvoll und width=* für die Straße selbst.

Und um das Thema noch zusätzlich zu verkomplizieren: Spurbreite zusätzlich abmessen? Abbiegespuren zu Einfahrten sind oft kleiner als solche vor Kreuzungen.
Noch etwas: Was wäre eine sinnvolle Angabe für eine Wendeplatz? Durchmesser oder Radius?

Die spinnen, die Römer.

Nach allem, was ich getestet habe, ist die Erfassung der Straße als Fläche ein Mittel der Wahl.
Sonst gibt es zu viele Ausnahmen und Diskussionspunkte über die wir eine Ewigkeit weiter reden werden ohne sinnvolle Ergebnisse zu bekommen.
Wieso sollen wir auf den alten Ansatz pochen, der aus der Zeit ohne Luftbilder stammt, wenn wir mittlerweile sehr gut die Straßengeometrie abbilden können?

marek kleciak wrote:

Nach allem, was ich getestet habe, ist die Erfassung der Straße als Fläche ein Mittel der Wahl.
Sonst gibt es zu viele Ausnahmen und Diskussionspunkte über die wir eine Ewigkeit weiter reden werden ohne sinnvolle Ergebnisse zu bekommen.
Wieso sollen wir auf den alten Ansatz pochen, der aus der Zeit ohne Luftbilder stammt, wenn wir mittlerweile sehr gut die Straßengeometrie abbilden können?

Weil die Daten aus OSM nicht nur zur Erstellung schön aussehender Karten verwendet, sondern auch für Navigationsanwendungen benötigt werden? Stand der Technik ist bei allen Anbietern/Geräten "Routing auf Linien". Für bleibendes/wachsendes Interesse an OSM als Datenlieferant sollte sich das Projekt an die technischen Konventionen halten.

Grüße
Mario

Garmin-User wrote:

Für bleibendes/wachsendes Interesse an OSM als Datenlieferant sollte sich das Projekt an die technischen Konventionen halten.

Routing ist nicht gerade mein Spezialgebiet, aber könnte man nicht beides machen? Die Straßen nach und nach als Flächen erfassen und dennoch eine generalisierte Linie im Zentrum? Die "alten" Router können weiterhin arbeiten und moderne schaffen das auch mit den Flächen?

Nur so eine Idee.

Gruss
walter

Ach ja: bei den breiten Flüssen gibt es auch sowas: Waterway und Riverbank - zumindest an vielen Stellen (Rhein)

Garmin-User wrote:

Weil die Daten aus OSM nicht nur zur Erstellung schön aussehender Karten verwendet, sondern auch für Navigationsanwendungen benötigt werden? Stand der Technik ist bei allen Anbietern/Geräten "Routing auf Linien". Für bleibendes/wachsendes Interesse an OSM als Datenlieferant sollte sich das Projekt an die technischen Konventionen halten.

Lieber Mario,
hat damit nichts zu tun.
OSM bildet die Realität ab. Routing soll natürlich so bleiben wie es ist und die Polylinie mit highway=* und lanes=* ist die Grundlage dafür. Die Flächen sind ja ählich zu vertehen, wie bei dem breiten Fluß: Wir zeichnen ja die Mittelachse und an der die Flußrichtung.
Ohne dass wir die tatsächliche Ausprägung der Wasserfläche wäre die Karte natürlich für einige Zwecke weiterhin gut verwendbar.
Trotzdem ist es mittlerweile Standard weil die Karte besser aussieht und auch mehr bietet.
Wie könnte eine solche Karte mit Straßen aussehen?
Hier ein Beispiel:
http://www.openstreetmap.org/#map=18/50.03065/22.03795

Ich sitze im übrigen gerade an dem Proposal:
http://wiki.openstreetmap.org/wiki/Prop … treet_area
Am Wochenende sollte ich damit fertig sein. Momentan ist es a little bit cryptic 😉

Wambacher wrote:

Routing ist nicht gerade mein Spezialgebiet, aber könnte man nicht beides machen? Die Straßen nach und nach als Flächen erfassen und dennoch eine generalisierte Linie im Zentrum? Die "alten" Router können weiterhin arbeiten und moderne schaffen das auch mit den Flächen?

Nur so eine Idee.

Gruss
walter

Lieber Walter,
das geht durchaus! mittlerweile ist es Standard und in vielen Situationen würde dies für uns die Arbeit vereinfachen;
Etwa bei unregelmässigen Flächen wo man eigentlich überall rumfahren darf.

wambacher wrote:

Routing ist nicht gerade mein Spezialgebiet, aber könnte man nicht beides machen? Die Straßen nach und nach als Flächen erfassen und dennoch eine generalisierte Linie im Zentrum? Die "alten" Router können weiterhin arbeiten und moderne schaffen das auch mit den Flächen?

Dem stimme ich zu. Das läuft auf ein landuse/landcover=street/highway hinaus, was ja hier auch schon angesprochen wurde.
Mit den Straßenlinen beißt sich das ja nicht zwingend. Nachteil ist allerdings, dass dadurch Redundanzen entstehen (Name an Fläche und Linie).

wambacher wrote:

Ach ja: bei den breiten Flüssen gibt es auch sowas: Waterway und Riverbank - zumindest an vielen Stellen (Rhein)

Auch da geht die Entwicklung weiter: Durch die genaueren Vorlagen werden vielfach auch schon bei kleineren Flüssen die Flächen gemappt (riverbank ist dafür ein etwas irreführender Begriff).

Etwas inkonsequent ist es schon, wenn zum einen zig Meter breite Plätze nur durch einen Strich erfasst werden, woanders aber zwei Meter Gestrüpp eine Fläche (natural=scrub) ergeben.

Nachteil ist allerdings, dass dadurch Redundanzen entstehen (Name an Fläche und Linie).

Für die Straßen als Flächen bräuchten wir halt keine Namen.
Die Visualisierung dieser Idee fand ich schon recht beeindruckend:
http://www.openstreetmap.org/#map=18/50.03029/22.03670

seichter wrote:

Dem stimme ich zu. Das läuft auf ein landuse/landcover=street/highway hinaus, was ja hier auch schon angesprochen wurde.

Ich bin mehr für highway=killefitt - aber als geschlossenes Polygon. Keine neuen Keys/Tags sondern einfach nur die Geometrie. Geht in Richtung Area.

Dafür landuse und Co zu verwenden, behagt mir garnicht.

Gruss
walter

Ich bin ebefalls gegen landuse.
Was bedeutet killefitt?

marek kleciak wrote:

Was bedeutet killefitt?

Ich nehme an, dass er meint, dass die Fläche zu einem highway=secondary auch ein highway=secondary ist

marek kleciak wrote:

Ich bin ebefalls gegen landuse.
Was bedeutet killefitt?

Sorry, ist so ein deutscher Begriff für "alles mögliche". oder auch Schnickschnack.

Gruss
walter

Ich glaube, wir sind uns in der Sache einig, wir suchen nur nach einem Taggingschema?
Oder?

marek kleciak wrote:

Ich glaube, wir sind uns in der Sache einig, wir suchen nur nach einem Taggingschema?
Oder?

nö, nur "anders zeichnen" - ist zumindest meine Meinung. Das müsste wirklich ohne andere oder gar neue Tags gehen.

highway=service mit area=yes haben wir ja schon öfters. MMn könnte area auch weg und das war es dann.

In der Datenbank, die in der Regel mit osm2pgsql gepflegt wird, sind die Straßen und die Flächen schön sauber getrennt, da diese automatisch in unterschiedlichen Tabellen landen. Einfach nur aufgrund ihrer Geometrie (Linestring und geschlossener Linestring) . Was will man mehr?

Gruss
walter

marek kleciak wrote:

Ich bin ebefalls gegen landuse.
Was bedeutet killefitt?

http://de.wiktionary.org/wiki/Killefit

highway=service mit area=yes haben wir ja schon öfters. MMn könnte area auch weg und das war es dann.

In der Datenbank, die in der Regel mit osm2pgsql gepflegt wird, sind die Straßen und die Flächen schön sauber getrennt, da diese automatisch in unterschiedlichen Tabellen landen. Einfach nur aufgrund ihrer Geometrie (Linestring und geschlossener Linestring) . Was will man mehr?

Lieber Walter,
nun, mal wollen wir eine Donut Topologie, Mal nicht. Also Linestring bzw.geschlossener Linestring. Vielleicht verstehe ich hier aber Was nicht.
Es wäre schön, wenn Du anhand eine Skizze zeigen könntes wie Du es meinst.
Grüße,
Marek

Ich glaube auch, dass er vergessen hat, dass ein highway eine geschlossene Linie nicht als Area interpretieren darf, da sonst seeeeehr viel kaputt geht.

marek kleciak wrote:

highway=service mit area=yes haben wir ja schon öfters. MMn könnte area auch weg und das war es dann.

In der Datenbank, die in der Regel mit osm2pgsql gepflegt wird, sind die Straßen und die Flächen schön sauber getrennt, da diese automatisch in unterschiedlichen Tabellen landen. Einfach nur aufgrund ihrer Geometrie (Linestring und geschlossener Linestring) . Was will man mehr?

Lieber Walter,
nun, mal wollen wir eine Donut Topologie, Mal nicht. Also Linestring bzw.geschlossener Linestring. Vielleicht verstehe ich hier aber Was nicht.
Es wäre schön, wenn Du anhand eine Skizze zeigen könntes wie Du es meinst.

Ganz einfach:

Ein Way im OSM-Sinn ist eine einfache Linie aus mehrere Punkten. Das nennt man in GIS: Linestring. --- Eine Fläche ist ein geschlossener Way und das nennt man "Closed Linestring".

Straßen bestehe bei uns aus mehreren Ways - die landen automatisch in planet_osm_roads. Aber auch Mauern oder Hecken oder Richtfunkstrecken: alles sind Linestrings. Der Tabellenname ...roads ist nur historisch.

Sobald der Way geschlossen ist (erster und letzter Node sind identisch) wird das ein "closed linestring" und landet in planet_osm_polygon. Das ist zum Beispiel bei allen Landuse (residential, commercial, ...) oder highway=service der Fall - völlig unabhängig vom Tagging.

Danach hat man als Auswerter die freie Auswahl: nehme ich die Straßen aus der Roads-Tabelle oder aus der Polygon-Tabelle oder gar aus beiden. Mapnik nimmt auf jeden Fall beide.

Multipolygone/Boundaries werden ähnlich behandelt: Routen landen bei den Roads und Flächen bei den Polygonen. Ebenfalls vollautomatisch.

Was ich eigentlich klarstellen möchte: Ein spezielles Tagging um Wege von Flächen zu unterscheiden, ist mMn nicht nötig. Das macht die Software mit links - und zwar seit 2007 (?)

Gruss
walter

EDIT: Nun, ich hab das ein wenig generalisiert, aber das Prinzip sollte schon zu erkennen sein.

Lieber walter, danke für die Erklärung.
Beginnt eine Straße und endet also in dem gleichen Punkt, ist die automatisch eine Fläche.

Das kann in einigen Fällen problematisch sein. Etwa dann wenn eine geschlossene Service road eine Donut Topologie hat.
Oder ein Feldweg um eine Wasserfläche herum.
Ich glaube, wir müssen differenzieren.

Grüße,
Marek

wambacher wrote:

marek kleciak wrote:

Ich glaube, wir sind uns in der Sache einig, wir suchen nur nach einem Taggingschema?
Oder?

nö, nur "anders zeichnen" - ist zumindest meine Meinung. Das müsste wirklich ohne andere oder gar neue Tags gehen.

highway=service mit area=yes haben wir ja schon öfters. MMn könnte area auch weg und das war es dann.

In der Datenbank, die in der Regel mit osm2pgsql gepflegt wird, sind die Straßen und die Flächen schön sauber getrennt, da diese automatisch in unterschiedlichen Tabellen landen. Einfach nur aufgrund ihrer Geometrie (Linestring und geschlossener Linestring) . Was will man mehr?

Gruss
walter

Hallo Walter,

so einfach geht es nicht. Ein Unterscheidungsmerkmal (sei es durch zusätzliche Angabe von area=yes oder spezielle Tags für die Flächen) muss vorhanden sein. Es gibt etliche "geschlossene Linien", welche keine Fläche darstellen, z.B. alle Kreisverkehre oder etliche Biegungen von Straßen/Wegen, die noch eine "diagonale Abkürzung" haben usw.). Auch Fußgängerzonen als Plätze können nur aufgrund "area=yes" von Straßen nur für Fußgänger (meist Einkaufspassagen) unterschieden werden, welche durchaus um ein Einkaufszentrum herumführen können. Gleiches Problem bei highway=service - handelt es sich bei der geschlossenen Linie um einen frei überfahrbaren Platz oder verläuft "highway=service / service=parking_isle" kreisförmig?

Wenn Straßen als Fläche gezeichnet werden, dann zusätzlich(!) zu herkömmlichen Linien (Routing mit aktuellen technischen Möglichkeiten) und mit abweichendem Tagging (sonst hat man drei parallele Straßen - die herkömmliche Linie und die beiden nächsten Ränder der Fläche). Das Proposal von Marek geht schon in die richtige Richtung.

Grüße
Mario

Edit: Aber ist, glaube ich, geklärt.

marek kleciak wrote:

Das kann in einigen Fällen problematisch sein. Etwa dann wenn eine geschlossene Service road eine Donut Topologie hat.
Oder ein Feldweg um eine Wasserfläche herum.
Ich glaube, wir müssen differenzieren.

Ja, da hast du wirklich Recht. Manche closed linestrings sind Flächen und andere nicht. Muß mal nachsehen wie das osm2pgsql feststellt.
Der area-tag ist da mein Verdacht. Aber mit dem könnte ich "leben" 😉

Nun denn, da war ich wohl ein wenig zu konsequent.

Irgendwo hatten wir doch schon mal so eine Straßenflächen-Diskussion 🤔
Von mir eine erste Idee:
Warum nehmen wir für die Flächen denn nicht z.B. area=highway oder area=sidwalk usw. Dadurch, dass der way "highway=* über diese Flächen führt, ließe sich doch die geometrische Zuordnung auswerten und für Darstellungen verwenden 🤔 Je nach Bedarf holt sich der highway-linestring zusätzlich Informationen aus der area welche er kreuzt oder umgekehrt.
Schlagt bitte nicht zu fest, wenn ich falsch liege.

area=highway oder area=sidwalk

Finde ich klasse, baue dies in den Proposal ein.
Sonst erbitte andere Vorschläge.

Wir könnten vielleich dies auch ausbauen z.B.: area=highway:residential?

Viele Grüße,
Marek

Nun,
ich habe es eingetragen.
Bitte sieht Euch den Vorschlag an.
http://wiki.openstreetmap.org/wiki/Prop … treet_area
soll ich den Part "Advanced concept for rendering optimization" vielleicht besser woanders einbauen, damit es die Leute nicht verwirrt?
Dann könnten wir mit der Abstimmung für den kleinsten gemeinsamen Nennen starten, oder?

Grüße,
Marek

Ich halte es für ungünstig, das etablierte area=yes/no um Attribute wie area=highway zu erweitern. Warum? Dadurch würde die Information verlorengehen, dass es sich um einen highway handelt. Entweder nutzt man (wie bisher) 2 Attribute (highway=* area=yes) oder man führt highway:area=*/area:highway=* ein. Letzteres allerdings zum Nachteil, dass alle Auswertungsprogramme und Editoren erst nachgerüstet werden müssten. Die Variante mit 2 Attributen hat sich für highway=pedestrian bereits durchgesetzt und hat nur den Nachteil, dass es 2 Attribute sind. Aber sogar die Editoren könnten damit auf Anhieb umgehen und es gibt sicherlich weniger Widerstand in der Community. Glaube ich zumindest mal…

Lieber Nadijta,
das hat auch Sinn.

Sollte man das vielleicht als Vorschlag 2 einbauen damit wir mit der Abstimmung über beide Alternativen beginnen können?

Grüße,
Marek

Hey. Ich habe da gleich mal eine Frage und einen Änderungsvorschlag
1. Worin besteht der Unterschied zum area:highway Proposal ?
2. Statt "area=sidewalk" sollte besser "area=sidepath" verwendet werden, so das eine Verbindung zu "bicycle=use_sidepath" bzw. "cycleway:left/right=sidepath" geknüpft werden kann. (Bei Alternativen Lösungen analog.)

Junctions ist anders. An jeder Kreuzung wo 3 oder mehr Straßen antreffen, gibt es einen connector.
Dadurch kann in zukunft die Kreuzungsfläche besser gerendert werden, was ich ansatzweise in dem "Advanced Part2 beschreibe.
2. Ist ok.

Also ich hab mir beide Proposals noch mal durchgelesen und ein wenig sinniert und ich kam zum Schluss, dass das derzeit benutzte highway=* area=yes Tagging auch ein paar Nachteile hat, vor allem die Notwendigkeit, der area auch den Namen zu geben, was ja auch nicht das gelbe vom Ei sein kann. Also frage ich mich: warum möchten wir eigentlich Straßen als area darstellen? Da fällt mir ein:

- Weil es einfach besser aussieht
- Weil man Kreuzungen viel detaillierter mappen kann mit all den Inseln, etc.
- Weil man theoretisch die Breite einer Straße ermitteln kann
- Weil man die surface so automatisch bekäme (in Deutschland wohl als default „paved“)

Das derzeitige Benutzen von highway=* heißt auch, dass Attribute, die ein highway=* implizit hat, auf einmal auch für die area gelten, was z.B. im Falle von oneway=no doch eher erheiternd ist. Wenn wir highways als Flächen erfassen sind einige Attributem die ein highway=* haben kann/muss überdies ziemlich unsinnig (z.B. name, maxspeed oder oneway), andere hingegen besser (z.B. access, surface). Ich halte es deshalb für geboten, sich vom alten highway=* area=yes zu verabschieden, da highway=* Dinge impliziert welche auf einer area keinerlei Bedeutung haben und eher zu Problemen führen könnten. Nach einiger Überlegung finde ich das Tagging des area:highway=*-Proposals für sinnvoller als weiterhin area=yes zu nehmen oder auf area=highway:* zu wechseln. Der Trend geht nicht umsonst in letzter Zeit zu Key:Subkey=* 🙂
Abgesehen davon gat mir die gute Ausarbeitung Deines Propoals schon immer gut gefallen, befürchte aber, dass es wieder Stimmen geben wird, die „zu komplex!“ rufen werden. Ob man z.B. die Kreuzungen separat erfassen sollte oder nicht halte ich für diskussionswürdig. Ich sehe momentan noch den Informationsgewinn im Verhältnis zum Aufwand als nicht so toll an. Gerne lasse ich mich eines Anderen belehren.

Nadjita wrote:

Also ich hab mir beide Proposals noch mal durchgelesen und ein wenig sinniert und ich kam zum Schluss, dass das derzeit benutzte highway=* area=yes Tagging auch ein paar Nachteile hat, vor allem die Notwendigkeit, der area auch den Namen zu geben, was ja auch nicht das gelbe vom Ei sein kann. Also frage ich mich: warum möchten wir eigentlich Straßen als area darstellen? Da fällt mir ein:

- Weil es einfach besser aussieht
- Weil man Kreuzungen viel detaillierter mappen kann mit all den Inseln, etc.
- Weil man theoretisch die Breite einer Straße ermitteln kann
- Weil man die surface so automatisch bekäme (in Deutschland wohl als default „paved“)

Das derzeitige Benutzen von highway=* heißt auch, dass Attribute, die ein highway=* implizit hat, auf einmal auch für die area gelten, was z.B. im Falle von oneway=no doch eher erheiternd ist. Wenn wir highways als Flächen erfassen sind einige Attributem die ein highway=* haben kann/muss überdies ziemlich unsinnig (z.B. name, maxspeed oder oneway), andere hingegen besser (z.B. access, surface). Ich halte es deshalb für geboten, sich vom alten highway=* area=yes zu verabschieden, da highway=* Dinge impliziert welche auf einer area keinerlei Bedeutung haben und eher zu Problemen führen könnten. Nach einiger Überlegung finde ich das Tagging des area:highway=*-Proposals für sinnvoller als weiterhin area=yes zu nehmen oder auf area=highway:* zu wechseln. Der Trend geht nicht umsonst in letzter Zeit zu Key:Subkey=* 🙂
Abgesehen davon gat mir die gute Ausarbeitung Deines Propoals schon immer gut gefallen, befürchte aber, dass es wieder Stimmen geben wird, die „zu komplex!“ rufen werden. Ob man z.B. die Kreuzungen separat erfassen sollte oder nicht halte ich für diskussionswürdig. Ich sehe momentan noch den Informationsgewinn im Verhältnis zum Aufwand als nicht so toll an. Gerne lasse ich mich eines Anderen belehren.

Nur zur Erinnerung:
Ich hatte als Flächen-tag für Straßenflächen lediglich area=highway vorgeschlagen und angeregt, dass alle anderen highway-Attribute auf dem way (highway=*) gelegt werden. Durch die Geometrie des innerhalb der Fläche liegenden highway-linestring können Auswertungen die linestring-Informationen den highway-Flächen zuordnen.
Dadurch erübrigt es sich auch m.E., values wie area=highway:residential einzuführen. Redundanzen könnten so verhindert werden.
Ich denke jetzt bewusst nicht daran, highway=* und das entsprechende area=* in eine Relation zusammenzufassen.

Warum bin ich der Meinung, dass man Kreuzungen Getrennt erfassen sollte:

Es geht um dies Möglichkeit, die Straßenflächen generisch so zu rendern wie uf diesem Bild zu sehen ist:
http://wiki.openstreetmap.org/wiki/File … tlines.jpg

Wenn wir immer dort, wo tatsächlich eine Haltelinie direkt vor der Kreuzung ist, mit dem Zeichnen der Kreuzungsfläche beginnen, kann aus den Straßenflächen und dem Tagging für sie Straßenpolygone (proposal Lanes) das Bild wie oben gerendert werden.
Die weiteren Beispiele die das detailliert erläutern sowie die mapping guidelines für dieses Thema bin ich Euch natürlich noch schuldig, daher verstehe ich die Fragen.
Der Proposal dafür wird mich einige Tage Arbeit kosten, aber ich möchte es in den nächsten Tagen definitiv machen, damit man dies auch besser versteht.
Eines im Vorab: Ich bin mir ziemlich sicher, das wir damit Google und alle anderen ganz schön abhängen können. 😉

Viele Grüße,
Marek

Ich wollte doch nur wissen, wie der aktuelle Stand zur Straßenbreite ist. 🙂

Grundsätzlich finde ich Flächen zur Linie auch gut. Aber wirklich alles einzeln als Fläche? Wären für eine normale Straße mindestens 5 Flächen: Fußweg,Parkreihe,Straße,Parkreihe,Fußweg.

Hi Chatter, ups 😛
Natürlich, Du hast Recht. Das Thema passte aber.
In Zukunft werden wir sicherlich auch den Detaliierungsgrad mit 5 Flächen erreichen, wenn man bedenkt wie das Projekt noch vor 5 Jahren aussah und wie viele neue User dem Projekt beitreten.
Vor 5 Jahren habe ich es kaum für möglich gehalten, dass wir Gebäudegrundrisse einzeln erfassen.
Der Ansatz kann uns einfach einen neuen Entwicklungsschub geben. Mich irritiert an einigen Stellen mittlerweile, dass die Karte die in den Titel "Street" hat, ausgerechnet die Straßen am wenigsten detailliert rendert. Insbesonder bei großen Kreuzungen stört dies und führt in einigen Fällen zu einem Übermaß an Verbindungselementen weil die Leute die Realität abbilden wollen.

Beste Grüße,
Marek

Ich habe eine Skizze hinzugefügt:
http://wiki.openstreetmap.org/wiki/File … ample1.jpg
an den Punkten die schwarz sind kann man taggen dem Sinn nach: rechts von dem Punkt durchgezogene Linie.
Der Punkt entspricht etwa der stopp position direkt vor der Kreuzung.

Ach so, wie gebe ich ein Proposal zum abstimmen frei?

Grüße,
Marek

marek kleciak wrote:

Ich habe eine Skizze hinzugefügt:
http://wiki.openstreetmap.org/wiki/File … ample1.jpg

Leicht verständlich. "Way edge" (dunkelblaue Linie) sollte besser "Way center line" lauten.

marek kleciak wrote:

Mich irritiert an einigen Stellen mittlerweile, dass die Karte die in den Titel "Street" hat, ausgerechnet die Straßen am wenigsten detailliert rendert.

Das ist mir auch schon aufgefallen. Muss man aber in einem extra Thread besprechen.

Edit: Dazu gehts hier weiter:
http://forum.openstreetmap.org/viewtopic.php?id=26134

Garmin User,
Du hast Recht.
Ich baue es am Freitag ein. Es war ein Fehler von mir die temporäre Beschriftung in ein Bild einzubauen. Unnötige Arbeit...

Und noch eine herzliche Bitte an Euch:
Die Skizze machte ich auf die Schnelle.
Es gibt sicherlich schwierige Fälle die geklärt werden müssen.
Bitte um Hinweise

marek kleciak wrote:

Insbesonder bei großen Kreuzungen stört dies und führt in einigen Fällen zu einem Übermaß an Verbindungselementen weil die Leute die Realität abbilden wollen.

Wie sollen in deinem Beispiel Fuß- und Radwegen einfließen?

Ich persönlich finde es einfacher nach dem area:highway zu verfahren. Ähnlich dem waterway oder landuse=railway. In deinem Beispiel ist es zwar ähnlich, betrachtet aber nur die Kreuzung. Beides zu verbinden macht durchaus Sinn.

Was auf alle Fälle passieren sollte, das die lanes gerendert werden. Es gibt immer noch Probleme mit Routing und lanes - und in der bildlichen Darstellung (Karte) sind sie gar nicht ersichtlich. Deshalb war mein Bestreben einmal, detaillierter Kreuzungen und Straßenverläufe zu mappen (Doppellinie wurde leider wieder abgeschafft). Auch das Routing funktionierte damals richtig (nicht das NAVI) und auch der Mensch erkennt, was er machen kann und soll.

Die Fuß- und Radwege gehen genauso. Der Unterschied liegt eben darin, dass für Zwecke die ich hier aufzeige:
https://wiki.openstreetmap.org/wiki/Pro … inciple.22
der Rendering der Karte deutlich besser gemacht werden kann.
Als Nächstes baue ich Beispiele die die Unterschiede im Rendering zwischen den beiden Ansätzen besser aufzeigen.

Hab noch an dem Proposal gearbeitet
Ist https://wiki.openstreetmap.org/wiki/Pro … of_point_K
und weiter.

Ist es verständlich so wie ich es momentan beschreibe?