@Rogehm
Eigentlich sollte alle tags an ways bleiben und beim möglichen rendern von diesen an Flächen sozusagen transferiert. Aber wird das ein bisschen kompliziert erstens braucht mehr ressourcen, zweitens wenn jmd. schon erwähnt hat, surface beginnt ab Fläche, nicht ab beginn der way, wenn wir jetzt taggen (so wie hier http://www.openstreetmap.org/way/171430521 ab Fläche ist diese surface, nicht früher). Das macht Probleme, wie ich das verstehe, beim SQL-Anfragen (bin ich nicht Experte!)…So macht wie du willst 
Ich würde beim way-tagging bleiben.
@Javnik Vielen Dank für deine Antwort. Tendenziell (gefühlsmäßig) würde ich es ja gerne so machen wollen:
Der footway bekommt natürlich das tag surface=paving_stones. Eben auch wegen der Oberfläche. Wie bisher. Mehr braucht es hier eigentlich nicht.
Das Proposal zeigt natürlich eindeutige Tendenz, das ganze in 3D darstellen zu wollen. Hierzu muss aber unbedingt auch die Fläche herhalten. Es gibt natürlich Ränder, Übergänge usw.
Diese kann man nicht so einfach in den herkömmlichen way packen. Es muss gezeichnet werden. Das war meine Idee.
Zur Info. Neu: die Darstellung der Abbiegepfeile in der Karte
http://osmapa.pl/w/area/?lat=53.43169&lon=14.55518&zoom=19&ol=BPE
Halb transparente Darstellung der Tunnel:
http://osmapa.pl/w/area/?lat=50.30534&lon=18.78997&zoom=19&ol=BP
Der Wunsch aus in anderen Bundesländer zu rendern wurde angesprochen. Mal sehen was sich machen lässt.
Hallo!
Wow, das sieht toll aus!
Und was über andere Länder (konkret - Ukraine)? 
Ich habe vor kurzem viele turn:lanes=* in meinem Gebiet gemappt: http://overpass-turbo.eu/s/aYm
Es wäre schön, sie sehen zu können. Nicht alle, aber nur den kleinen Teil ist genug.
Ich frage, ob das möglich ist. Ich denke, die Technik soll auf den OSM Server laufen, zumindest nach der Verabschiedung des Proposals.
Uii, da wirst du aber noch mächtig Lobbyarbeit betreiben müssen bis das auf den offiziellen OSM-Servern landet, das kann dauern.
Gruss
walter
Das weiß ich. Wie war das aber nochmal?
Steter Tropfen höhlt den Stein.
Ich finde schade das Informationen, wie Straßenbahngleise und teilweise Namen, verloren gehen.
Das soll geändert werden. Es ist die Arbeit von einem einzelnen Mapper, da ist noch viel zu berücksichtigen.
Neu in der a:h Karte - Visualisierung von man_made=bridge
http://osmapa.pl/w/area/?lat=52.30881&lon=20.95606&zoom=18&ol=POBR ,
sowie railway=rail und railway=tram:
http://osmapa.pl/w/area/?lat=51.10348&lon=17.03081&zoom=18&ol=POBR
Ganz BRD schluckt der polnische Server nicht. Wir müssen nach einer anderen Lösung suchen.
Das sieht doch ganz niedlich aus. Auch wenn die Spielerei eher an 3D erinnert als an die Darstellung von Brücken auf Karten.
Hier sieht es ganz gut aus. Ein Zommlevel weiter mischt sich aber schwarz mit schwarz.
Stimmt.
Sonst: Ich fügte dem Proposal a:h=emergency_lane hinzu. Das trifft man auf den Autobahnen ziemlich oft.
Frage: kann man generell der Streifen rechts auf der Autobahn als emergency_lane bezeichnen oder gibt es hier Differenzierung die in dem Proposal berücksichtigt werden muß?
Darüber hinaus:
area:highway=crossing with crossing= , if neccessary junction=yes for roundabout*
Für den Punkt K:
Possible combination:
highway=traffic_signals with traffic_signals=stop_line
Grüße,
Marek
Ich kenne das allgemein als “shoulder” [1], wenn man die genaue Funktion abstrahiert, die ja auch situationsabhängig sein kann.
Super, es gibt sogar ein Proposal dafür wobei a:h erweitert dies auf die Fläche…
Grüße,
Marek
Ich könnte mich vielleicht für das Proposal erwärmen, habe aber zwei Bedingungen:
-
Es sollte aufgezeigt werden, wie eine schrittweise Anwendung/Einführung aussehen könnte. Am besten mit optionalen Detailstufen (z.B. ganze Fläche ohne Detailunterscheidungen wie Fahrbahn oder Seitenstreifen als a:h, Kreuzungen nicht separat als a:h.)
-
Abgrenzung: Klärung wie sich das Proposal zu anderen Vorschlägen und Mappingarten verhält (z.B. landuse=highway u.ä.).
Ich denke, einige würden ohne diese Informationen mit vielleicht unpassenden Argumenten gegen dieses Proposal sein.
EDIT: Typos
Verstehe.
-
Macht durchaus Sinn, wobei ich ab a:h=tertiary nach oben von Anfang an mit einer Kreuzungsfläche arbeiten würde.
Natürlich kann zu Anfang mit nur a:h=yes arbeiten. Das würde aufzeigen, dass die Daten generalisiert sind.
Ich baue es ein in einem Abschnitt “Umsetzung”, oder so ähnlich. -
Landuse=highway ist im Idealfall die Summe von a:h=Straßenfläche + a:h=Gehweg bzw. Radweg, steht also nicht in Konkurrenz sondern stellt eine weitere Detaillierungsstufe dar.
Ansonsten verwendet man soweit es geht Inhalte von dem etablierten Tagging. Z.B. Kerb, was oft erfasst ist ist auch z.T. eine Grenze für a:h
Grüße,
Marek
In dem Proposal steckt noch viel Arbeit.
Marek, du solltest auch die Kritikpunkte der Diskussionsseite beantworten und ggf. berücksichtigen. Die Kritik an a:h=bridge teile ich.
Wie kann man das “plumbers principle” auf Rad- und Fusswege anwenden? Gibt es eine Kreuzung, bei der auch Rad- und Fusswege als a:h erfasst sind?
Das Hauptbeispiel in Paris ist unseriös. Es vergleicht schlecht erfasste Kreuzung, an der viele Wege fehlen und Geometrien ungenau erfasst sind, mit einer idealisierten Darstellung. Ein Beispiel sollte dieselben Daten mit und ohne Darstellung von a:h vergleichen.
Der Hinweis “Advanced tagging is complicated for beginners” als Nachteil der üblichen Erfassung der Straßen ist irreführend, das das Proposal nur die zusätzliche Erfassung der Fläche vorschlägt und keine anderen Informationen einspart oder vereinfacht.
Die Vorteile gegenüber dem area:highway Vorschlag sind mir nicht klar.
Ein Datenmodell, das eine Kreuzung definiert, könnte insbesondere die Routinganweisungen vereinfachen. Aber dieses Modell müsste dann auch die Rad- und Fusswege einbeziehen.
Stimmt, da ist noch viel Arbeit drin.
a:h=bridge ist überflüssig da man_made=bridge vorhanden und in der Visualisierung bereits verwendet wird. Geändert.
Ein Beispiel zu generieren kostet Zeit. Ich nahm ein Beispiel aus Paris weil in Frankreich (leider) sehr oft schlecht digitalisiert wird. Ein Realistisches Beispiel aus Hamburg / Burgstraße ist bereits vorhanden, ich habe den Screenshot von dem Ist-Zustand eingebaut. Gebäude und sonstige Details füge ich morgen hinzu.
Ich glaube schon, mache edit dazu, please wait a while.
Moin!
Auch dieses Beispiel ist nicht ideal. Es gibt dort viele Elemente, die nichts mit a:h zu tun haben, aber die Situation unübersichtlich machen (U-Bahn Station). Die Bing-Luftbilder passen von der Lage nicht zu den OSM-Daten. Viele Rad- und Fusswege sind auf den Luftbildern durch Bäume oder Gebäude verdeckt. Das bisherige Tagging ist recht kreativ oder schglicht falsch (Verkehrsinseln als highway=pedestrian, area=yes, access=yes).
Im Vergleich sollte nur um die Verbesserungen durch a:h gehen, nicht um zeitgleich erfolgte Änderungen an Gebäuden und sonstigen Details.
Nimm besser eine Kreuzung, die gut auf den Bing-Luftbildern erkennbar ist, mit viel Verkehrsfläche und wenig sonstigen Elementen, etwa wie hier (groß, aber eingfach) oder hier (komplex mit Brücke).
Nimm kein Beispiel mit schlechten Daten, sondern eines, was bislang schon sehr gut erfasst ist, und zeige, dass es durch a:h noch besser wird.
Marek, du hast das Proposal seit dem Start der RFC-Phase 37(!) mal geändert und einige neue Inhalte hinzugefügt. Das ist nicht der Sinn der RFC-Phase.
M.E. solltest du dich auf den Kern, die a:h-Flächen beschränken.
Ergänzungen, wie das Tagging von Haltelinien, die noch gar nicht diskutiert sind, wären in einem zweiten Proposal besser aufgehoben.
Also was nun?
Seit der Einführung von dem Renderer aus Polen ist plötzlich viel Bewegung in dem Thema. Ich bekomme von vielen Seiten völlig unterschiedliche Vorschläge, da das Thema so viele Fragen wie auch Potential mit sich bringt.
Wenn Dich das beruhigen sollte, kann ich die RFC zurücknehmen, dann wird aber weiterhin nach diesem Schema gearbeitet. Wenn ich mich nicht irre sid es täglich um 1200 Flächen, Tendenz steigend.
Ich weiß nicht ob Beispiele noch überhaupt Sinn machen seitdem man sich in Polen an vielen Stellen selbst ein Bild davon machen kann was man selbst aus dem unvollständigen Mapping rausholen kann.
Grüße,
Marek