Strassen als Fläche

Wenn´s in der Tat ein Platz ist, dann kann manmehr als die Straßenfläche erfassen. Sonst ist das eben "nur" eineStraßenfläche die wir für Rendering benutzen.
Lass uns reden über den konkreten Fall.
Btw.: Ich habe die http://wiki.openstreetmap.org/wiki/Prop … treet_area weiter vereinfacht.

Das ist dann eine der Sachen (neben 3D und indoor-mapping) denen ich mich verweigern werde weil ich der Meinung bin, dass diese Entwicklung bei OSM in die falsche Richtung geht.
Ich halte auch die wiki-Formulierung "Eine Straße soll ... doppelt repräsentiert werden" für falsch, ein "kann" wäre IMHO ein geeignetere Formulierung. "Soll" bedeutet "muss" oder ich muss begründen, warum ich vom "soll" abweiche.
Warum bin ich dieser Meinung?
Für mich ist bei OSM eine einheitliche, vergleichbare Datenbasis und die Chance, das zu pflegen, wichtiger als einzelne Vorzeigeprojekte

Wir haben auch kein Muß für die Erfassung von einem Fluß als Fläche. Wenn das Projekt weiter organisch wächst, wird dies von allein passieren. Die Begründung ist eben stets die Verbesserung der Kartenqualität.

Mich nervt es, dass die Karte die "Street" in dem Namen trägt, ausgerechet die Straßen eher bescheiden darstellt:

https://wiki.openstreetmap.org/w/images … cesNow.jpg

Ich will es lieber so haben:

https://wiki.openstreetmap.org/w/images … faces3.jpg

Ich sehe darin kein "Vorzeigeprojekt" sondern die Zukunft. Wie kommt man überhaupt auf die Idee eines "Vorzeigeprojektes"? Wir brauchen in der Tat eine vergleichbare Datenbasis, genau so wie Du schreibst. Die einzige Frage die sich aus meiner Sicht stellt ist: sind wir schon soweit, oder noch nicht.

Grüße,
Marek

Ich finde "highway=*; area=yes" passt gut, wenn man ausdrücken möchte, dass diese Fläche eine Straße ist und man dort überall ohne Fahrbahnen rumfahrten oder -laufen kann. Eben bei Fussgängerzonen, unorganisierten Parkplätzen...

Die längliche Fläche zu erfassen finde ich auch gut, aber genau dafür ist "area:highway" gedacht. Das kann gerendert werden und ausgewertet und gezählt. Für Router ist es aber klar, dass sie das nichts angeht.

Für die meisten Router sind Flächen generell unpraktisch. Die freuen sich über die erste gefundene "Straße" am Zielpunkt und folgen dieser dann. Das gibt dann Umwege, bis sie wieder auf den Straßenvektor treffen. Hier z.B.: http://graphhopper.com/maps/?point=47.6 … ation=true

Ein weiteres Problem bei den Flächen ist, dass sowas schlecht wartbar ist. Auch bei wirklich gut gepflegten doppelt gemappten Gegenden wird immer irgendwo ein Anschluss vergessen...

Grüße, Max

marek kleciak wrote:

Wir haben auch kein Muß für die Erfassung von einem Fluß als Fläche.

Deshalb ist das im wiki beim Fluss auch nicht als muss oder soll sondern als eine Möglichkeit beschrieben
http://wiki.openstreetmap.org/wiki/DE:Key:waterway

marek kleciak wrote:

Die einzige Frage die sich aus meiner Sicht stellt ist: sind wir schon soweit, oder noch nicht.

sind wir eben IMHO nicht
im Gegenteil
wir entfernen uns
Ich stelle in meiner Gegend z.B fest, dass da vor Jahren mal Micromapper unterwegs waren: jeder Busch mit seinen Umrissen, jeder Grünstreifen zwischen den Parkbuchten auf dem Parkplatz ist dargestellt. Das sollte die Zukunft sein so wie jetzt 3D und Straßenflächen. Unterdessen ist das alles falsch, aber keiner ändert es. Ich mache es auch nicht weil ich mich auch Mikromapping verweigere und es aber aus Achtung vor der Arbeit anderer mapper nicht löschen will.
Damit meine ich hauptsächlich: eine solche uneinheitliche Datenbank ist letzlich z.B. für irgendwelche Auswertungen unbrauchbar.

Dir scheint es mehr um eine "schöne" Karte zu gehen, das verstehe ich wiederum.
Ich glaube nicht dran.
Muss ich auch nicht.
Wie immer trägt jeder das bei, was er kann und will

Richtig, es is ale eine Möglichkeit beschrieben. So werde ich es auch ändern. Letzt endlich haben wir nirgendwo ein Zwang. Ist das OK für Dich?

Deine Vorbehalte verstehe ich auch. Eine Situation wie Du sie beschreibst ist ohne Micromapping besser als ohne.
Mir geht es nicht um eine schöne Karte, sonder um eine bessere. Bessere entsteht durch Aktualität und Content.
Zu viel Content und zu wenig Aktualität ist Mist. Genau wie Du´s schilderst!
Ich würde solch falsche Daten selbst entfernen wenn sich die Situation geändert hat.

Wie auch immer: Wir haben bereits Gebiete mit einer Mapperdichte wo Micromapping durchaus Sinn macht.
Mal sehen.

Viele Grüße,
Marek

Wir haben bereits Gebiete mit einer Mapperdichte wo Micromapping durchaus Sinn macht.

Noch was von mir:
Alles, was über der "Grundkarte", wie auch immer die definiert ist, hinausgeht, alles was wir im Content zusätzlich machen, verstehe ich als eine Art Luxus, den wir uns eigentlich noch nicht gönnen dürften. Dafür gibt es noch zu viele schlecht gemappte Gegenden auch bei uns in Germany.
Um den Ausdruck Luxus etwas zu verdeutlichen, ein paar Zitate:

Ideen sind der Anfang aller Vermögen ( Napoleon Hill )

Zuviel von einer guten Sache kann wundervoll sein ( Mae West )

Das Überflüssige ist das zutiefst Notwendige, weil es der Wunsch der Freiheit ist. ( E.W. Eschmann )

Man umgebe mich mit Luxus. Auf das notwendige kann ich verzichten. ( Oscar Wilde )

In diesem Sinne ( Oscar Wilde's Spruch ist wohl eher nicht so gut )

Viele Grüße,
Rolf

maxbe wrote:

Für die meisten Router sind Flächen generell unpraktisch. Die freuen sich über die erste gefundene "Straße" am Zielpunkt und folgen dieser dann. Das gibt dann Umwege, bis sie wieder auf den Straßenvektor treffen. Hier z.B.: http://graphhopper.com/maps/?point=47.6 … ation=true

Hier ist aber auch ein Fehler, das die service als Fläche aber nicht als Weg da sind. Solche Zufahrten sind viele Verbindungsstellen fürs Routing. Wenn aus dem Flächen-highway ein area:highway richtigerweise wird, klappts auch m.E. mit dem Routing ...

marek kleciak wrote:

Ich sehe darin kein "Vorzeigeprojekt" sondern die Zukunft. Wie kommt man überhaupt auf die Idee eines "Vorzeigeprojektes"? Wir brauchen in der Tat eine vergleichbare Datenbasis, genau so wie Du schreibst. Die einzige Frage die sich aus meiner Sicht stellt ist: sind wir schon soweit, oder noch nicht.

Wir sollten einmal die Entwicklung von OSM beachten:
Vor einigen Jahren gab es nur eine paar Mapper, die die Straßen und größere Flächen erfassten.
Danach wurde die Mapperzahl mehr und Örtlichkeiten wurden mit Straßen und Gebäuden ergänzt.
Mapper trugen dann immer speziellere Daten zusammen: Fußwege, Bäume, und dann POI's mit mehr Angaben.
Heute sind Bereiche gemappt, die sehr detailliert sind und weiter detailliert werden möchten - was auch durch die immer größer werdende Anzahl der Mapper einfacht ist, da Veränderungen vor Ort - Betonung liegt auf vor Ort - schnell ergänzt/geändert werden.

Wären diese "Detailierungen" nicht möglich gewesen, indem man nur Ortschaften als Flächen und Straße zugelassen hätte, wäre OSM schon lange gestorben. Es ist nicht alles richtig, was in den Daten ist - aber jeder hat die Möglichkeit dies zu ändern (Notes oder eigene Mitarbeit). Und nicht jeder soll sich mit den Details beschäftigen müssen - er kann es. Aber wir sollten diesen "Detailmappern" nicht die Mitarbeit bei OSM "verqraulen".

Je mehr Mapper sich beteiligen, desto aktueller sind die Daten - wenn jeder auf sein "Umgebung zu Hause" achtet und mit Hilfe der Qualitätstools in Ordnung hält.

EDIT:

Rogehm wrote:

Dafür gibt es noch zu viele schlecht gemappte Gegenden auch bei uns in Germany.

Dann sollten in diesen Dörfern einmal die Feuerwehr- und Heimatvereine auf die Möglichkeiten OSM hingewiesen werden. Bei kommunalen Verwaltungen (bis auf ein paar Ausnahmen) läuft man nur gegen verschlossene Türen.

geri-oc wrote:

Hier ist aber auch ein Fehler, das die service als Fläche aber nicht als Weg da sind.

Ich dachte, ich hätte ein Beispiel gefunden,wo eigentlich alles passt...
Falls du zufällig die Mitte der Straße triffst, landest Du auf dem durch die Fläche gemappten Weg: http://graphhopper.com/maps/?point=47.6 … ation=true

Mistake 😄

Sorry. 🙂

In Russland wird street:area in osm.ru gerendert.
Beispiel: http://openstreetmap.ru/#map=18/55.7406 … 96&layer=K

Könnten wir testweise einen solchen Layer wie die Russen auch in osm.de einbauen?
Grüße,
Marek

marek kleciak wrote:

Könnten wir testweise einen solchen Layer wie die Russen auch in osm.de einbauen?
Grüße,
Marek

Das ist eine klasse Idee.

marek kleciak wrote:

Wir haben auch kein Muß für die Erfassung von einem Fluß als Fläche. Wenn das Projekt weiter organisch wächst, wird dies von allein passieren. Die Begründung ist eben stets die Verbesserung der Kartenqualität.

Die Kartenqualität wird dadurch nicht unbedingt besser. Wenn du den Fluss als Fläche erfasst, kannst du in anderen Maßstäben die Breite nicht mehr skalieren bzw. generalisieren. Dann muss man mit extrem komplexen und fehleranfälligen Algorithmen erst die Mittelachsen der Fläche ermitteln usw. usw. Klar, wir mappen nicht für den Renderer, aber solange niemand einen vernünftigen Algorithmus hinlegt, verschließen wir OSM allen möglichen Nutzungsbereichen...

TobWen wrote:

marek kleciak wrote:

Wir haben auch kein Muß für die Erfassung von einem Fluß als Fläche. Wenn das Projekt weiter organisch wächst, wird dies von allein passieren. Die Begründung ist eben stets die Verbesserung der Kartenqualität.

Die Kartenqualität wird dadurch nicht unbedingt besser. Wenn du den Fluss als Fläche erfasst, kannst du in anderen Maßstäben die Breite nicht mehr skalieren bzw. generalisieren. Dann muss man mit extrem komplexen und fehleranfälligen Algorithmen erst die Mittelachsen der Fläche ermitteln usw. usw. Klar, wir mappen nicht für den Renderer, aber solange niemand einen vernünftigen Algorithmus hinlegt, verschließen wir OSM allen möglichen Nutzungsbereichen...

Ich sehe hier kein Problem da Doppeltagging bleiben wird. Bei Straße highway= und area:highway=, bei Flüssen waterwar=river und waterway=riverbank.

Jojo4u wrote:

TobWen wrote:

Die Kartenqualität wird dadurch nicht unbedingt besser. Wenn du den Fluss als Fläche erfasst, kannst du in anderen Maßstäben die Breite nicht mehr skalieren bzw. generalisieren. Dann muss man mit extrem komplexen und fehleranfälligen Algorithmen erst die Mittelachsen der Fläche ermitteln usw. usw. Klar, wir mappen nicht für den Renderer, aber solange niemand einen vernünftigen Algorithmus hinlegt, verschließen wir OSM allen möglichen Nutzungsbereichen...

Ich sehe hier kein Problem da Doppeltagging bleiben wird. Bei Straße highway= und area:highway=, bei Flüssen waterwar=river und waterway=riverbank.

Das sehe ich auch so.

marek kleciak wrote:

Könnten wir testweise einen solchen Layer wie die Russen auch in osm.de einbauen?
Grüße,
Marek

Fänd ich klasse...

Jojo4u wrote:

Ich sehe hier kein Problem da Doppeltagging bleiben wird.

Ist im Bestand aber nicht so. Guck dir doch die Fußgängerzonen an. Inzwischen habe ich ein komplexes Regelweg zusammen, wie man "Lücken" zwischen Linienobjekten finden kann; teilweise interpoliere ich, teilweise muss ich aber virtuelle Linien per Hand nachziehen (und diese bei einer Veröffentlichung sogar wieder unter ODbL veröffentlichen).

Jojo4u wrote:

TobWen wrote:

marek kleciak wrote:

Wir haben auch kein Muß für die Erfassung von einem Fluß als Fläche. Wenn das Projekt weiter organisch wächst, wird dies von allein passieren. Die Begründung ist eben stets die Verbesserung der Kartenqualität.

Die Kartenqualität wird dadurch nicht unbedingt besser. Wenn du den Fluss als Fläche erfasst, kannst du in anderen Maßstäben die Breite nicht mehr skalieren bzw. generalisieren. Dann muss man mit extrem komplexen und fehleranfälligen Algorithmen erst die Mittelachsen der Fläche ermitteln usw. usw. Klar, wir mappen nicht für den Renderer, aber solange niemand einen vernünftigen Algorithmus hinlegt, verschließen wir OSM allen möglichen Nutzungsbereichen...

Ich sehe hier kein Problem da Doppeltagging bleiben wird. Bei Straße highway= und area:highway=, bei Flüssen waterwar=river und waterway=riverbank.

Aber ohne das name-Tag an area:highway und waterway=riverbank (neuerdings: natural=water + water=river)

RadFr wrote:

Aber ohne das name-Tag an area:highway und waterway=riverbank (neuerdings: natural=water + water=river)

Wie dann? Eine Relation zwischen Linien- und Flächenobjekt 🤣

Mein herzliches Dankeschön für Mapping von Straßen als Flächen.
Ich denke, es wäre toll eine Stadt als Demonstrator in Deutschland aufzubauen. Momentan ist es (nur) Moskau. Die Voraussetzungen dafür wären natürlich Luftbilder in top Qualität und einige Mapper die mitmachen. Hättet Ihr Vorschläge?

Grüße,
Marek

Einen name sollte/kann man schon setzen, allerdings darf der halt nicht gerendert werden.

PS Hier gibts es noch weitere (visualisierte) Beispiele für area:highway = http://umap.openstreetmap.fr/de/map/are … 015/15.249 Wenn ihr wollt könnt ihr dort auch eure eigenen Beispiele anzeigen lassen: Overpassabfrage - Export - kml-Datei - Datei in der Karte hochladen - Flächen den Ebenen zuordnen.

Wieso hat man sich gegen Folgendes entschieden, was deutlich einfacher abzuarbeiten wäre?

highway␣=␣...
area␣=␣yes

Obwohl ich mich fast schon frage, ob ein "area = no" bei geschlossenen Linien nicht sinnvoller wäre, wenn es kein Polygon darstellen soll 🤔

Der Unterschied ist dass bei area=yes und highway=* der Router darüber routet/routen soll (im Idealfall nicht am Rand entlang), während area:highway nur dafür da ist das es gerendert wird. Ersteres sind Plätze (Marktplatz...) die sich halt nicht als way darstellen lassen.

Hier: http://umap.openstreetmap.fr/de/map/are … 9/11.58529
sind die allerersten Flächen die so gemappt wurden.

Chrisss Gü wrote:

Der Unterschied ist dass bei area=yes und highway=* der Router darüber routet/routen soll (im Idealfall nicht am Rand entlang), während area:highway nur dafür da ist das es gerendert wird. Ersteres sind Plätze (Marktplatz...) die sich halt nicht als way darstellen lassen.

Wieso dann nicht "renderer = yes" (oder so) als Indiz, dass es ausschließlich für den Renderer ist? Eine Fläche ist es ja trotzdem immer.

TobWen wrote:

Wieso dann nicht "renderer = yes" (oder so) als Indiz, dass es ausschließlich für den Renderer ist? Eine Fläche ist es ja trotzdem immer.

Würde natürlich auch gehen, aber jetzt hat sich halt area:highway durchgesetzt (ca. 14000 mal)

Render=yes wird dir ganz schnell um die Ohren geschlagen. Tagging für den Renderer, ne? 😉

TobWen wrote:

Wieso hat man sich gegen Folgendes entschieden, was deutlich einfacher abzuarbeiten wäre?

highway␣=␣...
area␣=␣yes

Wegen Gründe.
Highway=pedestrian + area=yes funktioniert imho nicht. Mappt man nur fllächig muss man aufpassen dass Verbindungen an Kreuzungen überhaupt möglich sind. Und dann wird unschön außen entlang geroutet. Fügt zusätzlich noch Wege fürs Routing hinzu wirkt das wie ein Hack. Man weiß auch nicht wohin mit Name, access, usw. Wenn Doppeltagging dann mit getrenten Keys, danz klar.

EDIT: quote gewechselt.

Chrisss Gü wrote:

Würde natürlich auch gehen, aber jetzt hat sich halt area:highway durchgesetzt (ca. 14000 mal)

Aber bist du dir sicher, dass die nicht eine Highway-Fläche meinen (z.B. Fußgängerzone)? Wie viele davon sehen dies als Renderer-Anwendung? Man müsste prüfen, wie viel normale highway=* oder footway=* darüberführen. Wobei wir wieder bei der Analysekette sind, die ich jetzt eh durchführe 🙂

Jojo4u wrote:

Render=yes wird dir ganz schnell um die Ohren geschlagen. Tagging für den Renderer, ne? 😉

IMHO geht's genau darum, siehe #26.

Area:highway soll nicht nur schön aussehen. Damit soll auch gearbeitet werden könne. Flächenrouting ist möglich, vielleicht auch eine Art Spurassistent+.

TobWen wrote:

RadFr wrote:

Aber ohne das name-Tag an area:highway und waterway=riverbank (neuerdings: natural=water + water=river)

Wie dann? Eine Relation zwischen Linien- und Flächenobjekt 🤣

Witzbold.

Meinte damit nur, dass der Name des Flusses an den river gehört und nicht zusätzlich an die riverbank, was man oft findet/fand. Könnte dann genauso bei area:highway passieren.

Moin,

marek kleciak wrote:

Mein herzliches Dankeschön für Mapping von Straßen als Flächen.
Ich denke, es wäre toll eine Stadt als Demonstrator in Deutschland aufzubauen. Momentan ist es (nur) Moskau. Die Voraussetzungen dafür wären natürlich Luftbilder in top Qualität und einige Mapper die mitmachen. Hättet Ihr Vorschläge?

in Roßleben hat jemand(*) schon vor Jahren mal damit angefangen - und ist dafür virtuell fürchterlich verhauen worden ...

Gruß
Georg

(*) Name der Redaktion bekannt

RadFr wrote:

Meinte damit nur, dass der Name des Flusses an den river gehört und nicht zusätzlich an die riverbank, was man oft findet/fand. Könnte dann genauso bei area:highway passieren.

Dieses Proposal sieht das aber vor, wenn ich mich richtig erinnere. name auch an area:highway und bei area:crossing sogar name und name2.

Jojo4u wrote:

Flächenrouting ist möglich

Oh, gibt es schon Router, die das können? Ich bin ehrlich interessiert, denn momentan laufen die meisten immer am Rand lang - wenn überhaupt.

Dieses Proposal sieht das aber vor, wenn ich mich richtig erinnere. name auch an area:highway und bei area:crossing sogar name und name2.

Hmm, das hat sich geändert - wenn Du dort liest: What is definitely not necessarily? Street name=* number of lanes, surface, smoothness, maxspeed, address names etc. These attributes are a part of highways.

marek kleciak wrote:

Dieses Proposal sieht das aber vor, wenn ich mich richtig erinnere. name auch an area:highway und bei area:crossing sogar name und name2.

Hmm, das hat sich geändert - wenn Du dort liest: What is definitely not necessarily? Street name=* number of lanes, surface, smoothness, maxspeed, address names etc. These attributes are a part of highways.

Danke für die Klarstellung, hatte mich damit erst an zwei Kreuzungen beschäftigt, dann kann ich das da wieder rauswerfen.

TobWen wrote:

Oh, gibt es schon Router, die das können? Ich bin ehrlich interessiert, denn momentan laufen die meisten immer am Rand lang - wenn überhaupt.

Ich hätte einen (zum Vergleich mit Graphhopper). Der ist halt nur für Fussgänger und für ernsthafte Verwendung deutlich zu langsam. In dessen Beschreibung sind unten noch zwei Anwendungen verlinkt.

Hier:
http://umap.openstreetmap.fr/de/map/are … 2/11.60169
sieht man viele Löcher.
Grund: Kreuzungen getaggt nach dem Alten Schema: area:highway:crossing=yes
Kann jemand helfen dies automatisch in area:highway=crossing umzutaggen?
Wir haben sicherlich noch woanders solche Flächen.

marek kleciak wrote:

Hier:
http://umap.openstreetmap.fr/de/map/are … 2/11.60169
sieht man viele Löcher.
Grund: Kreuzungen getaggt nach dem Alten Schema: area:highway:crossing=yes
Kann jemand helfen dies automatisch in area:highway=crossing umzutaggen?
Wir haben sicherlich noch woanders solche Flächen.

Ich finde dass man solche Kreuzungen nicht mit area:highway=crossing taggen sollte, dann doch eher so wie im Wiki beschrieben:

Junctions

Minor␣road␣crossing␣major␣road
The␣major␣road␣is␣one␣area.␣The␣minor␣road␣gets␣split␣up␣into␣two␣areas␣left␣and␣right␣to␣the␣major␣road.
T-Junctions
The␣straight␣road,␣or␣major␣road␣stays␣one␣area,␣the␣minor␣road␣gets␣adjoined␣with␣the␣major␣or␣straight␣road.
Junctions␣with␣multiple␣street␣types␣merging
For␣complex␣junctions,␣where␣multiple␣street␣types␣cross␣and/or␣merge,␣the␣neutral␣value␣"junction"␣can␣be␣used.

Und selbst bei "komplexen" Kreuzungen kann man ohne area:highway=crossing auskommen: http://umap.openstreetmap.fr/de/map/are … 8/13.74758
Ich finde dann sollte man höchstens sowas wie crossing=yes nehmen.

Aus der Proposal Seite:

Reasons for "plumbers principle" :

More flexible rendering possible, especially for:
Pedestrian navigation.
Faster 3D rendering. Dividing of huge area elements in smaller segments = less big elements in the cache = faster vizualization in Apps and real time 3D.
More detailed maps: navigation with real crossing views.
Optimization of 3d terrain models by use of crossing areas. The crossing areas are still horizontal.
(Crossing areas are in the most cases flat and horizontal. This fact can be used for more realistic 3D visualization).
Better voice messages for navigation systems possible. Crossing areas reduces the number of voice messages.

Zur Erklärung: was bringt das für die Sprachansagen einer Navi?
Nehmen wir eine Kreuzung wie diese:
http://www.openstreetmap.org/#map=19/49.57598/11.01646

Falls ich dort wenden möchte, bekomme ich, wenn ich OSM Daten verwende, die Sprachansagen: Weiter geradeaus fahren/ Nach links wenden/ nach links wenden/weiter geradeaus fahren.

Habe ich diese Kreuzung auch als Fläche, kann man dies beim konvertieren berücksichtigen und bekommt nur eine Meldung: Bitte wenden.

Grüße,
Marek

Auf den vorgenannten Kartenlinks mit sichtbaren Straßenflächen zeigen sich zwei Darstellungsprobleme:

In den Zoomstufen 16 und kleiner ist es besser generalisierte Straßen fester Breite zu rendern. Nimmt man stattdessen die Straßenflächen, leidet die Erkennbarkeit enorm, weil die Straßen zu schmal werden.

In den Zoomstufen 17 und größer ist es besser die Straßen als Flächen darzustellen. Die Darstellung ist so realistischer, denn die generisch erzeugten Straßen sind zu breit und überdecken inkorrekterweise teilweise Gebäude.

Fazit: Erfaßt werden sollten die Straßen als Linien und als Flächen. So kann sich sich jeder Auswerter (Renderer, Router, ...) den jeweils passenden Teil raussuchen.

Gruß Klaus

PS: Was beim Rendern natürlich noch berücksichtigt werden muß, ist die farbliche Unterscheidung der Straßenflächen anhand des Straßentyps. Aber dies dürfte für die Renderer keine allzu schwere Übung sein.

marek kleciak wrote:

Aus der Proposal Seite:
...
Habe ich diese Kreuzung auch als Fläche, kann man dies beim konvertieren berücksichtigen und bekommt nur eine Meldung: Bitte wenden.

Grüße,
Marek

Ja da wären solche Flächen gut, um die Routingansagen zu verbessern. Ich habe mal geschaut und bin darauf gestoßen, dass es sogar schon einen angenommenen Tag dafür gibt: junction=yes.
Wiki: http://wiki.openstreetmap.org/wiki/Tag:junction%3Dyes
Proposal: http://wiki.openstreetmap.org/wiki/Prop … _junctions
(Obwohl natürlich 12 Abstimmungen nicht gerade viel sind)

Vorgeschlagen wurde auch highway=junction: http://wiki.openstreetmap.org/wiki/Prop … 3Djunction

Ich finde aber dass man zumindest nicht area:highway=* dafür nehmen sollte, da dessen Nutzung ja eher für das Rendering bestimmt ist.

Viele Grüße

toc-rox wrote:

In den Zoomstufen 17 und größer ist es besser die Straßen als Flächen darzustellen. Die Darstellung ist so realistischer, denn die generisch erzeugten Straßen sind zu breit und überdecken inkorrekterweise teilweise Gebäude.

Auswertung von width bei highway=* und ein sinnvoller Defaultwert sollten das Problem (das ich noch nicht beobachtet habe) beheben.

Ich habe im Jahr 2006 eine Masterarbeit zu diesem Thema betreut und anschließend die Ergebnisse mit exakten Katasterdaten verglichen. Grob gesagt: 80% geht sehr gut, 20% weicht deutlich ab.
Das Problem ist, dass die Generalizierungsvorschriften die wir z.B. bei der Gabelung haben zu deutlich verfälschten Ergebnissen führen.
Grüße,
Marek

GeorgFausB wrote:

in Roßleben schon vor Jahren mal damit angefangen - und ist dafür virtuell fürchterlich verhauen worden ...

Weil es mit der falschen Methode (highway=* + area=yes) getaggt war.

Inzwischen wurde es natürlich brav auf area:highway umgestellt.

Ich schreibe es nochmal hier, weil wahrscheinlich in dem Post mit Nürnberg die Nachricht untergegangen ist.
In Polen gibt es einen neuen Renderer von Straße als Fläche.

http://osmapa.pl/w/area/?lat=52.229&lon … m=19&ol=PB
Aktualisierung: 1x die Stunde.

Unterstützt grafisch alle Tags aus:
http://wiki.openstreetmap.org/wiki/Prop … ea#Tagging

Grüße,
Marek

Ich schreibe es nochmal hier, weil wahrscheinlich in dem Post mit Nürnberg die Nachricht untergegangen ist.

Nö, ist nicht untergegangen. Sind wohl alle dt. User erschlagen und sprachlos!

Kann man nicht den Autor der Map daraufhin ansprechen, die Tiles etwas nach Westen zu erweitern... Dann könnte man sich auch mit dt. Straßen etwas einarbeiten.

Toller Kreisel: http://osmapa.pl/w/area/?lat=53.43277&l … m=18&ol=PB

Anh. Auch wenn nur mit schwächerer Auflösung. Oder einen NRW Tile als "Test-Zone".

2.Anh. Kleine Nachteile: Mit Einblendung der Straßenflächen werden Namen abgeschnitten und keinerlei Richtung ist mehr erkennbar. Jedes kleine Teilstück erhält den Straßennamen.

Rogehm wrote:

kann man nicht den Autor der Map daraufhin ansprechen, die Tiles etwas nach Westen zu erweitern... Dann könnte man sich auch mit dt. Straßen etwas einarbeiten.

Natürlich ja. Wer übernimmt den Server und kümmert sich um die Technik?

Warum ist eigentlich dieses Prosposed http://wiki.openstreetmap.org/wiki/Prop … treet_area immer noch in diesem Stadium, könnte doch schon verabschiedet sein?

Wenn mir einer sagt, wie man es auf voting umschaltet, dann können wir es gleich machen.

marek kleciak wrote:

Wenn mir einer sagt, wie man es auf voting umschaltet, dann können wir es gleich machen.

Das Verfahren ist im Wiki unter Proposal process beschrieben.
Vor dem Voting kommt noch Schritt 4 Proposed.

Hmm, proposed ist sie schon.
Also auf Voting schalten, oder?

marek kleciak wrote:

Hmm, proposed ist sie schon.
Also auf Voting schalten, oder?

Nein. Hast du den verlinkten Abschnitt im Wiki "Proposal process" gelesen?
Bislang ist der Status "Draft" nicht "Proposed", "RFC start" ist leer.
Die Ankündigung auf der tagging mailing list mit Subject Line: "Feature Proposal - RFC - Street area" konnte ich nicht finden.
Wenn ein Vorschlag schon 4 Jahre läuft, kommt es auf 14 Tage mehr auch nicht an.

Alles klar. Danke Dir für die Erklärung.
Grüße!
Marek

Es gibt jede Menge Eigenschaften die selbstverständlich jeden Tag verwendet werden und noch auf Draft stehen.
http://wiki.openstreetmap.org/wiki/Cate … 22Draft%22
Wäre vielleicht mal ein Ansatz aufzuräumen und die Vorschläge zu verabschieden.

OK, ich habe es in "Proposed", "RFC start" umgeändert.
Grüße,
Marek

Dafür finde ich die einzelnen Werte noch nicht genug beschrieben. Z.B. crossing und traffic_island haben keine Beschreibung. Werden wege auf traffic islands als traffic_island, crossing oder footway/cycleway getagged? Wie werden kombinierte ungetrennte Fuß und Fahrradwege getagged?

Hast Du Recht. Traffic Island sind Bereiche die nicht befahrbar sind, gekennzeichnet durch eine höhere Bordsteinkante und üblicherweise Andere Oberfläche (z. B. Beton statt Asphalt). Die emergency Fläche ist die Fläche wo sich der Polizei /Rettungswagen usw. aufhalten kann ohne den Verkehr zu stören. Üblicherweise sind solche Bereiche in Deutschland mit weißen Querstreifen schraffiert. Die prohibited Flächen sind sonstige Trennungsflächen wo kein Auto ohne Schaden reinfahren kann, z.B. Mittelstreifen einer Autobahn mit der Plane in der Mitte.

Wege auf traffic_island sind ganz normal getaggt, also footway, cycleway oder path.
Ich werde diese Ergänzungen einbauen. Kombinierte ungetrennte Fuß und Fahhradwege sind auch der poln. Community aufgefallen auch dort gibt es einen Vorschlag: http://i58.tinypic.com/2ziuh3b.png
Findet Ihr das ok?
Grüße,
Marek

Wir arbeiten nun an der besseren Darstellung der Treppe in der 2D Karte:
area:steps=yes plus die Anzahl der Stufen. Stufen verlaufen senkrecht zum highway=steps
Wie in der http://wiki.openstreetmap.org/wiki/User … and_Inline beschrieben.
Macht mit. Angebot aus Polen steht: Wenn ein Server vorhanden ist, kann ganz Deutschland so abgebildet werden.

maxbe wrote:

TobWen wrote:

Oh, gibt es schon Router, die das können? Ich bin ehrlich interessiert, denn momentan laufen die meisten immer am Rand lang - wenn überhaupt.

Ich hätte einen (zum Vergleich mit Graphhopper). Der ist halt nur für Fussgänger und für ernsthafte Verwendung deutlich zu langsam. In dessen Beschreibung sind unten noch zwei Anwendungen verlinkt.

Das sollte kein Hexenwerk sein. Gerne dafür hier voten 😉
https://github.com/graphhopper/graphhopper/issues/82

Am Wochenende wird hoffentlich Nürnberg genau so gerendert wie momentan Polen. Wenn alles gut geht funktioniert das in einigen Tagen danach für ganz Deutschland. Also legt los 🙂

marek kleciak wrote:

OK, ich habe es in "Proposed", "RFC start" umgeändert.

Dann fehlt nur noch der letzte Schritt, die Ankündigung des RFC auf der tagging mailing list.

Na das finde ich mal Positiv es kommt Bewegung rein, dass mal was Verabschiedet wird. Dann hat man auch Argumente, dass landuses nicht an die Straßen gehören.

Seht man her: http://osmapa.pl/w/areade/?lat=49.46924 … m=19&ol=BP

Wie versprochen, zuerst Nürnberg zum Testen. Demnächst kommt auch der Rendering der Treppen mit Breiten und Anzahl der Stufen.

Die Seite mit Nürnberg wird also nicht aktualisiert.
Momentan läuft ein Import von Bayern ganz. Dann kann man diese Technik auch woanders in BY testen.
Haben andere Bundesländer auch Interesse?

Grüße,
Marek

Bayern läuft schon.
Es sind überraschend viele Flächen, einfach irre:
http://osmapa.pl/w/areade/?lat=49.5929& … om=7&ol=BP

Rendern von Polen und Bayern zugleich scheint eine ziemliche Belastung für den kleinen Server zu sein. Refresh kann nicht stündlich geschehen. Vielleicht habt Ihr eine Idee wo man die Technik unterbringen könnte?
Ich finde Rendering von Stufen nicht gelungen: sehe München Marienplatz.

Für die Kritiker ein mini Beispiel:
http://osmapa.pl/w/areade/?lat=50.03759 … m=18&ol=BP

Sieht das nicht besser aus als die Generalisierung?

marek kleciak wrote:

Sieht das nicht besser aus als die Generalisierung?

Kommt auf den Maßstab und die Zielsetzung der Karte an.
Ehrliche Antwort: Ein Luftbild ist mir lieber.

Aber das darf natürlich jeder machen, wie er will, solange andere (generalisierte) Kartenbilder dadurch nicht unmöglich gemacht werden. (Bitte wegen der Straßenflächen in bewohnten Bereichen nicht die Landnutzungen zerstückeln. Die Straßen sind Teil dieser Nutzung und können "darüber" gezeichnet werden.)

Ein Bild sind Pixel und keine Koordinaten+ Zusatzinfos. Deswegen entstand OSM.
Sehr schöne Luftbilder liefert Google 😉

Deine Frage war "SIEHT das nicht besser aus?".
Wenn Du gefragt hättest: "Haben solche Daten einen Mehrwert?" wäre die Antwort möglicherweise anders ausgefallen ;-)
(Unabhängig davon, dass ich keine Verwendung für Koordinaten von Gehsteigkanten habe.)

Eine präzise Antwort 😉
Danke für Dein Mapping in Nürnberg.
Grüße,
Marek

Eigentlich ist das Mappen vor Ort für mich ja auch Blödsinn - OSM brauch ich in Nürnberg praktisch nicht. Durch das ständige Fehlersuchen für OSM kenne ich die Örtlichkeit folgerichtig aktueller, als OSM sein könnte. Dummerweise sieht man dann auch immer, wie viele Fehler tatsächlich in den Daten sind 🤔. Man macht das aber ja in der Hoffnung, dass woanders jemand das auch "blödsinnigerweise" für einen selbst macht.
Aber:
Leider ist die DatenPFLEGE auch in D in einigen Bereichen -auch größeren Städten- scheinbar ein Fremdwort. Lieber werden beliebige Details von ortsfremden Mappern aus Luftbildern erfasst/interpretiert. Man kennt dann jeden Gullydeckel, aber die Gaststätte daneben ist seit zwei Jahren geschlossen und keiner ändert das. Das kann sehr frustrierend sein...

Erlangen:
http://www.openstreetmap.org/note/300338
oder
http://www.openstreetmap.org/note/327495

oder Würzburg:
http://www.openstreetmap.org/note/32589 … 7&layers=N

Ja, ich weiß: Jeder hat da so seine Prioritäten, aber Mikromapping und dann sowas hier:
http://www.openstreetmap.org/note/348014
ist kein Argument, mit dem man anderen OSM schmackhaft machen kann.

Hallo Pyram,
Menschen wie Du sind ein Garant dafür, dass OSM trotzde eine halbwegs gute Qualität liefert. Ich schlage mich im Alltag mit sog. "kommerziellen" Daten rum und da sind oft Dinge die angemahnt und seit 4 Jahren nicht geändert wurden.
Dagegen ist OSM ein Datenparadies. Trotzdem: ohne die wenigen Mapper die auf die Qualität achten und oft als "lästig" empfunden werden weil sie dem einen oder Anderen den lockeren Spaß verderben wäre OSM nicht das was es ist.

IMO ist area:highway=yes nicht richtig. Anstatt yes müsste da der Straßentyp hin.

Proposal: Values are the same as for the current highway=* tag, under the lists "roads" or "paths".

Done..

Die Bayern Karte wurde aktualisiert:
http://osmapa.pl/w/areade/?lat=48.83941 … om=7&ol=BP

marek wrote:

Haben andere Bundesländer auch Interesse?

Ja, klar. NRW!!! Aber der Server wird es nicht packen, fürchte ich.

Meine Frage: Ich würde gerne in einem Park auch die Wege erfassen mit highway:area=footway.
Gleichzeitig möchte ich ein erstes Tagging nach dem Proposal von Tordanik dort machen.
Das würde aber bedeuten, das man eigentlich auf dem Flächen-tag ein (z.B.) surface=paving_stones taggen muss. Wie sollte das mit späterem Renderversuchen sonst funktionieren?
Also doppelt taggen? Auf der Fläche und der Linie des Weges? Gibt es da schon Ideen, wie man das umsetzt?

@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&l … =19&ol=BPE

Halb transparente Darstellung der Tunnel:
http://osmapa.pl/w/area/?lat=50.30534&l … m=19&ol=BP

Der Wunsch aus in anderen Bundesländer zu rendern wurde angesprochen. Mal sehen was sich machen lässt.

Hallo!

marek kleciak wrote:

Zur Info. Neu: die Darstellung der Abbiegepfeile in der Karte
http://osmapa.pl/w/area/?lat=53.43169&l … =19&ol=BPE

Wow, das sieht toll aus!

marek kleciak wrote:

Der Wunsch aus in anderen Bundesländer zu rendern wurde angesprochen.

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.

marek kleciak wrote:

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.

marek kleciak wrote:

Zur Info. Neu: die Darstellung der Abbiegepfeile in der Karte
http://osmapa.pl/w/area/?lat=53.43169&l … =19&ol=BPE

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&l … 18&ol=POBR ,

sowie railway=rail und railway=tram:
http://osmapa.pl/w/area/?lat=51.10348&l … 18&ol=POBR

Ganz BRD schluckt der polnische Server nicht. Wir müssen nach einer anderen Lösung suchen.

marek kleciak wrote:

Neu in der a:h Karte - Visualisierung von man_made=bridge
http://osmapa.pl/w/area/?lat=52.30881&l … 18&ol=POBR

Das sieht doch ganz niedlich aus. Auch wenn die Spielerei eher an 3D erinnert als an die Darstellung von Brücken auf Karten.

marek kleciak wrote:

sowie railway=rail und railway=tram:
http://osmapa.pl/w/area/?lat=51.10348&l … 18&ol=POBR

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

marek kleciak wrote:

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ß?

Ich kenne das allgemein als "shoulder" [1], wenn man die genaue Funktion abstrahiert, die ja auch situationsabhängig sein kann.

[1] https://en.wikipedia.org/wiki/Shoulder_%28road%29

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:

1. 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.)

2. 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.
1. 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.

2. 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.

Gibt es eine Kreuzung, bei der auch Rad- und Fusswege als a:h erfasst sind?

Ich glaube schon, mache edit dazu, please wait a while.

Moin!

marek kleciak wrote:

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.

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.

seawolff wrote:

In dem Proposal steckt noch viel Arbeit.

seawolff wrote:

du hast das Proposal seit dem Start der RFC-Phase 37(!) mal geändert.. Das ist nicht der Sinn der RFC-Phase.

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

marek kleciak wrote:

Verstehe.
1. 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.

2. 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

zu 2.

Zumindest in DE gehört der Gehweg zur Straßenfläche.

area:highway=yes wiedergabe?

mit surface=

test:
nicht hier
overpass

Allroads wrote:

area:highway=yes wiedergabe?

mit surface=

test:
nicht hier
overpass

Schon wieder area:highway=yes. Siehe Posting #77.

marek kleciak wrote:

seawolff wrote:

du hast das Proposal seit dem Start der RFC-Phase 37(!) mal geändert.. Das ist nicht der Sinn der RFC-Phase.

Also was nun? 🙂

Du hast einen wichtigen Halbsatz gekürzt: "... und einige neue Inhalte hinzugefügt. Das ist nicht der Sinn der RFC-Phase."

Wenn du ein Ergebnis haben willst, beschränke das Proposal auf die Definition von a:h.

Wiki Proposal process wrote:

Proposed

Once the feature is fully described on its page, move on to "Proposed" Status.

Subscribe to tagging@openstreetmap.org mailing list[1] and send out an RFC (Request For Comments) on this list:
Subject: "Feature Proposal - RFC - (Feature Name)"
In the body: include a link to the proposal page on the wiki. Also copy the "Definition" from that page and paste it in the mail.

Set the status to "Proposed" and set the rfcStartDate=* value. (YYYY-MM-DD)
Spend time with others discussing and modifying the proposal.

Please discuss each proposed feature on its own discussion page.

Erweiterte Konzepte kannst du in ein zweites Proposal stecken.

marek kleciak wrote:

Wenn Dich das beruhigen sollte, kann ich die RFC zurücknehmen, dann wird aber weiterhin nach diesem Schema gearbeitet.

Das Tag a:h erscheint unumstritten.
Bislang wird in Deutschland eher die von flaimo vorgeschlagene einfache Variante verwendet.
a:h=junction finde ich nur vier mal in Dresden.
Es wäre wichtig, diesen Unterschied zu diskutieren und sich dann für eine Variante zu entscheiden.

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.

Gib doch einige Beispiele an, wo das Konzept gut umgesetzt ist.

Ich habe mir den Proposal http://wiki.openstreetmap.org/wiki/Prop … tures/kerb

Eine Bordsteinkante zu definieren scheint einfach.
Ich lese dort:
Draft start: 2010-12-12
RFC start: 2011-06-21

Seit RFC Start 21 Mal geändert, das letzte Mal vor zwei Tagen.
Da scheint also der Wunsch und Realität oft weit auseinander zu liegen und während der RFC Phase Inhalte geändert werden.

Dies: http://www.openstreetmap.org/way/366442470 ist eine Kreuzung die als Beispiel dienen kann

Der Renderer ist an dieser Stelle noch nicht soweit, bitte dies etwa 2 Stunden Später ansehen:
http://osmapa.pl/w/areade/?lat=49.47349 … m=19&ol=BP

Der Renderer für DE zeigt noch keine Abbiegepfeile die aus lanes=* und turn:lanes=* resultieren. Da sehe ich aber einen sehr wichtigen Mehrwert, denn dadurch werden Bereiche sichtbar, die gut gemappt sind, sowie welche wo es noch fehlt.

Aus der Diskussionsliste sowie Diskussion mit Rendering Profis habe ich eine sehr wichtige Sache hinzugefügt, auch wenn sie banal erscheint: http://wiki.openstreetmap.org/w/images/ … nction.jpg

Dadurch wird der Rendering dort erleichtert, wo sich eine Straße fließend in zwei aufteilt.

Ob wir a:h=junction + junction= roadclass oder a:h=crossing crossing=roadclass (so ist es jetzt) haben wollen:
Was sagt Ihr?

Viele Grüße,
Marek

marek kleciak wrote:

Ob wir a:h=junction + junction= roadclass oder a:h=crossing crossing=roadclass (so ist es jetzt) haben wollen:
Was sagt Ihr?

Mir persönlich gefällt besser area:highway=junktion + junktion=*, weil der Tag crossing=* schon für Fußgängerüberwege benutzt wird.

Aber: wofür brauchen wir, Straßetyp für area:highway=* anzugeben? Meiner Meinung nach wäre es besser, nur area:highway=yes zu nutzen. Gewühnscht mit surface=*.

Wir können area:highway=* für Autos und für Fußgänger diffirenzieren. Wer weiß, es kann vielleicht für Rendering benutzt werden. Beispeile:
area:highway=auto für highway=track|service|residential|unclassified|...|motorway
area:highway=pedestrian für highway=footway|pedestrian
area:highway=bicycle für highway=cycleway
... (weitere Werte können hinzugefügt sein)

Mit junktion=<roadclass> gibt es ein Problem: was soll ich dort schreiben, wenn z. B. highway=secondary und highway=tertiary sich kreuzen? junktion=secondary oder junktion=tertiary? Oder junktion=tertiary;secondary? 🙂

Entschuldigung, wenn die Antwort oben in dem Thema liegt, aber ich kann jetzt leider das ganzen Thema nicht lesen.

as soll ich dort schreiben, wenn z. B. highway=secondary und highway=tertiary sich kreuzen

Immer die höhere Klasse angeben, also in Deinem Beispiel heighway=secondary.

Ich habe diesne proposal mit a:h=yes begonnen aber die Mehrheit sagte, sie wünscht sich a:h=street category.
Und so ist es geblieben.
Surface kannst Du natürlich zusätzlich angeben, wobe man diese Daten aus dem Straßenvektor extrahieren kann.

marek kleciak wrote:

Surface kannst Du natürlich zusätzlich angeben, wobe man diese Daten aus dem Straßenvektor extrahieren kann.

...und wenn kein surface vorhanden, dann bitte rot-grün kariert rendern... was meinst du, wie schnell dann Surface da ist... 😄

🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂
Du hast mir den Tag gerettet streckenkundler.
Soll ich das in den Proposal aufnehmen? 😛

Hallo zusammen,

die Idee, die Straßenfläche zusätzlich zu erfassen finde ich auch spannend! Beim Einarbeiten in den Vorschlag ist mir allerdings folgendes aufgefallen (ich bitte um Korrektur, falls ich das schlicht falsch verstanden haben sollte):

Kreuzungsbereiche sollen, wenn mehr als 3 Wege aufeinandertreffen mit "area:highway=crossing" getaggt werden. Das halte ich persönlich für unglücklich gewählt, denn wir verwenden ja bereits highway=crossing für die Auszeichnung von Übergängen für Fußgänger und Radfahrer. Das macht die ganze Sache meiner Ansicht nach unintuitiv, da gleichlautende Werte für zwei unterschiedliche Dinge verwendet werden. Ist das eventuell auf eine direkte Übersetzung von "Kreuzung" und "crossing" zurückzuführen? Meiner Meinung nach wären a:h=junction (mein Favorit, da junction=* bereits in diesem Kontext genutzt wird) oder a:h=intersection besser geeignet. Wenn es denn unbedingt etwas mit "crossing" im Namen sein soll, böte sich a:h=street_crossing an 😉

Beste Grüße

Hallo Athemis,

der Proposal lag ruhig rum und die Leute haben angefangen zu mappen.
Wenn jemand verspricht die über Tausend a:h=crossing Dinge mit einem Bot umzutaggen dann können wir das mit der Änderung im Proposal natürlich gerne tun.

Deine Argumente verstehe ich, die machen auch Sinn. Nun, es ist bereits passiert. Was nun?
Ach so, schick mir bitte Kreuzungsbereiche die aus Düsseldorf die aus Deiner Sicht problematisch sind.
Wir können uns das gern gemeinsam ansehen.

Viele Grüße und danke für Deine Edits!

Marek

Hallo Marek,

marek kleciak wrote:

der Proposal lag ruhig rum und die Leute haben angefangen zu mappen.
Wenn jemand verspricht die über Tausend a:h=crossing Dinge mit einem Bot umzutaggen dann können wir das mit der Änderung im Proposal natürlich gerne tun.

Das sehe ich nicht so problematisch. Umtaggen geht per Bot sobald das Proposal akzeptiert wurde notfalls noch immer 😉 Das ist die Gefahr, wenn man nach einem Proposal taggt. Das ist in der Regel ein "bewegliches Ziel", Änderungen können (wenn sie gut begründet sind) vorkommen. Ähnliches hatten wir ja auch mit dem ÖPNV-Tagging. Es wurde bereits im Proposal-Status (OXOMOA bzw. PTP2) danach getaggt und im Diskussionsprozess bis zur endgültigen Annahme dann noch diverse Dinge verändert. Der Auf- und Umräumprozess dauert bekanntlich bis heute an 😛

marek kleciak wrote:

Deine Argumente verstehe ich, die machen auch Sinn. Nun, es ist bereits passiert. Was nun?
Ach so, schick mir bitte Kreuzungsbereiche die aus Düsseldorf die aus Deiner Sicht problematisch sind.
Wir können uns das gern gemeinsam ansehen.

Das mit a:h=crossing ist ja kein Problem, dass nur Spezialfälle betrifft. Es wird auch einwandfrei funktionieren, wenn es alle so einsetzen, wie vorgesehen, aber genau da sehe ich das Problem. Es ist geradezu prädestiniert für Missverständnisse und falschen Gebrauch, wenn man vom "normalen" Straßenmapping anhand von Linien kommt und es dort bereits ein highway=crossing gibt, das aber eine völlig andere Bedeutung hat. Du orientierst Dich ja in Deinem Proposal an den althergebrachten highway-Tags, was die Benutzung enorm vereinfacht, da man im Prinzip nicht umdenken muss, sondern einfach die bestehende Linie mit einer Fläche umgibt, entsprechend taggt und dem "highway" ein "area:" voranstellt. Da ist dann das a:h=crossing ein unschöner Bruch und wird sicherlich zu Verwirrung führen.

Da Du ein Beispiel möchtest, hier wäre eines: http://www.openstreetmap.org/#map=19/51.17597/6.80997
Ich habe dort einmal testweise versucht die Straßenflächen zu erfassen. Die Kreuzungsfläche habe ich dort aber zwar separat für "a:h=crossing" erfasst, aber zunächst nur mit "a:h=yes" getaggt. Im Kreuzungsbereich befinden sich mehrere Fußgängerüberwege. Wie gesagt, das kommt sich alles rein formal nicht ins Gehege, aber intuitiv sträubt sich alles in mir, einen Tag der highway=crossing beinhaltet doppelt in unterschiedlichen Bedeutungen zu verwenden.

Eine ultimative Lösung kann ich natürlich nicht anbieten, wie Du ja anmerktest, wird der Tag schon häufig benutzt. Das ändert aber nichts daran, dass er vermutlich nicht optimal ist. Da es sich aktuell noch um ein Proposal handelt, kann sich eigentlich niemand beschweren, wenn Du Dich in diesem Stadium entscheidest, Ungereimtheiten auszubügeln. Meine Befürchtung wäre nämlich, dass sich spätestens in der Abstimmungsphase jemand an genau demselben Punkt abarbeitet und das einem dann im Abstimmungsergebnis auf die Füße fällt. Allerdings sind bis dahin dann noch einige Tausend Einträge mehr hinzugekommen, die man dann auch noch ändern müsste. Ergo: Wenn ändern, dann so bald wie möglich 🙂

In Kürze:
Was denken die Anderen hier im Forum? Wenn´s machbar ist dann habe ich nichts dagegen.

Zu der Kreuzung:
Alles gut gemacht, mach weiter 😉

Hallo zusammen,

ich wähle area:highway=junction statt area:highway=crossing. Ich bin ganz einverstanden mit der Argumenten von Athemis.

Viele Grüße
Eduard

area:highway=junktion

hmm, area:highway=junction please 😉

marek kleciak wrote:

Ich habe mir den Proposal http://wiki.openstreetmap.org/wiki/Prop … tures/kerb
Seit RFC Start 21 Mal geändert, das letzte Mal vor zwei Tagen.

In diesem Jahr wurden ein Link und ein Leerzeichen geändert.
Natürlich sind in der RFC Phase Korrekturen möglich. Dafür ist sie da. Aber neue Vorschläge sollten nicht mehr eingefügt werden.
"kerb" ist natürlich kein Beispiel für ein erfolgreiches Proposal. ;-)

Dies: http://www.openstreetmap.org/way/366442470 ist eine Kreuzung die als Beispiel dienen kann
http://osmapa.pl/w/areade/?lat=49.47349 … m=19&ol=BP

Die dunklen Straßenflächen finde ich eher unschön.
Bis z=18 bevorzuge ich die klassische Darstellung.
Bei z=19 rendert die Standardkarte die Straßen zu dünn, aber das ließe sich auch noch korrigieren.
Aber der Vergleich zweier gerenderter Karten entscheidet nicht über den Sinn eines Datenkonzepts.

Ob wir a:h=junction + junction= roadclass oder a:h=crossing crossing=roadclass (so ist es jetzt) haben wollen:
Was sagt Ihr?

Die Vorteile solltest du uns nennen.
Ich sehe folgende Nachteile:
- es existieren zwei inkompatible Vorschläge
- die Mapper müssen eine zusätzliche Fläche erstellen
- auf vielen Stadtplänen sind Haupt- und Nebenstraßen unterschiedlich gefärbt.
Die Hauptstraße ist dann auf der Kreuzung mit konstanter Breite gefärbt, die Einmündungstrichter in der Farbe der Nebenstraße.
Eine solche Darstellung wäre ohne a:h=junction möglich, mit dieser Fläche kann man nur die gesamte Kreuzung wie die Hauptstraße färben.

marek kleciak wrote:

area:highway=junktion

hmm, area:highway=junction please 😉

Ja, danke 🙂

marek kleciak wrote:

Dies: http://www.openstreetmap.org/way/366442470 ist eine Kreuzung die als Beispiel dienen kann

Technisch ein Vorbild: Ja.

Aber man sieht hier das Problem von Luftbildmappern bzw. man kann die Karte auf diesem Niveau nicht aktuell halten. Der komplette Kreuzungsbereich wird seit längerem massiv umgebaut und schaut derzeit nicht mehr so aus - und wird nicht mehr so werden. Und jetzt müsste ich das anpassen, was wegen fehlender Luftbilder nicht geht, oder das jetzt Falsche löschen!? Geht das überhaupt, wenn in kürzester Zeit der nächste Luftbildmapper das wieder "ergänzt" 🙄

PS: An der Antalyastraße ganz in der Nähe habe ich die "ganz frisch" vom Luftbild abgemalte Straßenfläche grob an die mittlerweile geänderte Realität angepasst. Bin gespannt, wie lange das dauert, bis das wieder nach Luftbild korrigiert wird...

PPS: Bei der Hoffläche des Autohauses sollte man sich auch entscheiden, ob die Parkplatzflächen jetzt Teil von area:highway sind. Teilweise sind nur nur die Zufahrtsflächen zu den Stellplätzen inbegriffen, teilweise sind die Stellplätze Teil der "grauen Fläche" - was nun? Oder ist "area:highway" nur ein verbrämtes "surface=paved+highway=*"??

pyram wrote:

Bin gespannt, wie lange das dauert, bis das wieder nach Luftbild korrigiert wird...

note=<Information dass der Luftbild hier gar nicht stimmt>
Machen wir doch oft bei Gebäuden die "abadoned" sind, damit sie keiner "neu" erfindet.
Das Problem mit dem Ältern der Daten verschärft sich natürlich generell umso mehr wir in Detail gehen.
Wir können es nur durch mehr Mapper wettmachen. Aber die Tendenz gibt es glücklicherweise.

ob die Parkplatzflächen jetzt Teil von area:highway sind

Nein, sind nicht. Proposal: amenity=parking_space - drawing of parking areas along the street.
Zugegeben, icht im Sinne des Erfinders weil er hier nur Einzelparkplätze vorgeschlagen hat.
Ich fand aber in Erlangen (ein Dorf nördlich von Nürnberg 😉 ) Flächen die so getaggt wurden, dies brache mich auf die Idee: warum nicht, wenn dies schon so verwendet wird für kleiner Parkflächen?

PS: Ich schätze Deine sachliche Bemerkungen. Du bist dabei nicht persönlich sondern kümmerst Dich um die Sache. Darf ich Dich bitten sonstige Details der a:h in Nürnberg zu checken?

Grüße,
Marek

marek kleciak wrote:

Zugegeben, icht im Sinne des Erfinders weil er hier nur Einzelparkplätze vorgeschlagen hat.
Ich fand aber in Erlangen (ein Dorf nördlich von Nürnberg 😉 ) Flächen die so getaggt wurden, dies brache mich auf die Idee: warum nicht, wenn dies schon so verwendet wird für kleiner Parkflächen?

parking_space sollte wenn möglich immer einzeln getaggt werden und dann alle spaces mit einer Relation verbunden werden. Es ist aber auch erlaubt mit "capacity" mehrere spaces zusammen zu fassen. Den Kompromiss bin ich beim Verfassen des Proposals damals eingegangen. Das Proposal ist aber eher für komplexe Parkmöglichkeiten gedacht. Für einfache kleine Parkplätze solltest du meiner Meinung nach beim alten amenity=parking bleiben.

seawolff wrote:

Die dunklen Straßenflächen finde ich eher unschön.
Bis z=18 bevorzuge ich die klassische Darstellung.
Bei z=19 rendert die Standardkarte die Straßen zu dünn, aber das ließe sich auch noch korrigieren.

Ich finde die Farbe auch zu dunkel, allerdings ist diese Darstellungsart m.M.n. nur für den höchsten Zoom-Level sinnvoll.
Straße zu dünn, z=19: Na ja, das ist eben ein Dilemma. Ich muss es wiederholen: Es ist praktisch unmöglich, eine "richtige" Breite zu finden außer man macht´s dünner. Die Logik des Grafenroutings zwing uns zu generalisieren, und da passiert es, dass die Mittelachse Straße gar nicht richtig "sitzt". Macht man sie zu dick, verdeckt sie andere Elemente. Es ist kein Zufall das Here eine Technologie entwickelt bzw. entwickelt hat, mit der das Erfassen der Außenkante Straße möglich ist.

seawolff wrote:

- auf vielen Stadtplänen sind Haupt- und Nebenstraßen unterschiedlich gefärbt.
Die Hauptstraße ist dann auf der Kreuzung mit konstanter Breite gefärbt, die Einmündungstrichter in der Farbe der Nebenstraße.
Eine solche Darstellung wäre ohne a:h=junction möglich, mit dieser Fläche kann man nur die gesamte Kreuzung wie die Hauptstraße färben.

Die Straßendarstellung als Mittelachsen sollte für alle Layer bis auf den höchsten erhalten bleiben.
Auf dem höchsten Zoom Level spielt es keine Rolle welche Straßenkategorie das ist die Färbung zeigt: Dies ist Asphalt, dies ist ein Gehrweg, dies ist ein Radweg.. Für die Orientierung in einer unbekannten Kreuzung ist eine solche Darstellung hilfreich, ebenso für Fußgänger.
Diese Art der Erfassung macht das Navigieren für blinde Passanten besser:
Die Flächendarstellung zwingt zu mehr Präzision beim Erfassen der Daten und kann das Melden "Du bist auf der Außenkante Straße bzw. Du gehst gerade quer durch den Fahrradweg" erleichtern.
Ich habe gelernt das a:h Mapping viel Zeit in Anspruch nimmt. Man braucht Geduld, aber man korrigiert dadurch an vielen Stellen die Karte. Ein Gebäude das auf einem Fußweg mit einer Ecke liegt, weil es mit alten Yahoo Bildern abgezeichnet wurde, fällt sofort auf.

marek kleciak wrote:

Ob wir a:h=junction + junction= roadclass oder a:h=crossing crossing=roadclass (so ist es jetzt) haben wollen: Was sagt Ihr?

seawolff wrote:

Die Vorteile solltest du uns nennen.

Nicht unbedingt. Ich halte mich nicht für schlauer als der Rest der Mapper. Sie sollen entscheiden.

Ich habe den Vorschlag A. gemacht: a:h=crossing + crossing=roadclass
Athemis machte den Vorschlag B: a:h=junction + junction= roadclass

Um ganz ehrlich zu sein, kann ich persönlich mit beiden Vorschlägen leben.

Wer ist für A, wer ist für B ?

Bin für a:h=junction.
Crossing ist recht zweideutig, sollte lieber wie bisher auch für Übergänge verwendet werden.

R0bst3r wrote:

Bin für a:h=junction.
Crossing ist recht zweideutig, sollte lieber wie bisher auch für Übergänge verwendet werden.

+1

Die visualisierung der turn:lanes geht wieder, ich hinterlege ein Screenshot für alle Fälle. Marimil werkelt an dem Thema weiter.

http://wiki.openstreetmap.org/wiki/File … arimil.JPG

Hallo,

Ich möchte mich gerne auch einarbeiten in die Materie und euch dabei nicht "ins Gehege" kommen.
Da ich mich in Nürnberg auch tlw auskenne, habe ich mir mein "Hotel-Gebiet" ausgesucht.
Kann ich dort "fuhrwerken", sprich das tagging ausprobieren, ohne Konkurrenz?

http://www.openstreetmap.org/#map=17/49.46088/11.07709

Anh.: Oh Je , da gibt es ja massenweise Gebäudekorrekturen nachzuarbeiten. Ok. Muss ja gemacht werden...

Sicher Rogehm,
da gibt es extrem viel zu tun. Ich werde hier werkeln:
http://osmapa.pl/w/areade/?lat=49.43315 … m=15&ol=PB

Aus Polen kamen zwei Mal für a:h=junction sonst Enthaltung.
Wenn dies mit Bot machbar ist ( a:hcrossing-> a:h=junction), sollten wir uns drum kümmern.
Wer kann es umsetzen?

Hallo Marek,

marek kleciak wrote:

Zu der Kreuzung:
Alles gut gemacht, mach weiter 😉

Danke, werde ich 😉

marek kleciak wrote:

Aus Polen kamen zwei Mal für a:h=junction sonst Enthaltung.
Wenn dies mit Bot machbar ist ( a:hcrossing-> a:h=junction), sollten wir uns drum kümmern.
Wer kann es umsetzen?

Das Umtaggen per Bot sollte der allerletzte Schritt sein. Wichtig wäre, zunächst das Proposal im Wiki entsprechend anzupassen und die Änderungen auch in den Kreisen zu kommunizieren, die das Schema aktuell bereits anwenden, um zu vermeiden, dass a:h=crossing bei neu erfassten Kreuzungen verwendet wird. Soweit ich das sehe, wären das vor allem die polnische und die deutsche Community.
Da es bezüglich des Proposals offensichtlich Diskussionsbedarf und einige Baustellen gibt, wäre ich mit einem mechanischen Edit zu diesem Zeitpunkt sehr vorsichtig. Wenn das Proposal irgendwann in einer bestimmten Fassung angenommen ist, kann man darüber nachdenken, per Bot entsprechend der Mechanical Edit Policy die jeweiligen Anpassungen an das verabschiedete Schema vorzunehmen, aber solch eine mechanischer Bearbeitung muss gut begründet sein. Meiner Meinung nach reicht ein in Entwicklung befindliches Proposal als Grundlage da nicht aus. Darüber hinaus muss das auch auf der Mailing-Liste angekündigt und diskutiert werden. Auch da wäre meine Vorhersage, dass ein Proposal dort nicht aus ausreichender Grund angesehen würde.

Kurz:

• Wenn a:h=crossing zu a:h=junction geändert werden soll, muss dass möglichst schnell im Proposal umgesetzt und die Personen, die nach dem Schema taggen über die Änderung informiert werden, damit sich nicht mehr a:h=crossing ansammeln.
• Mechanischer Edit per Bot macht meiner Meinung nach erst nach Verabschiedung des Proposals Sinn und ist vorher auch problematisch zu begründen.

Beste Grüße

Alex

Hallo Arthemis,
danke 🙂.

Also ändern wir die Kreuzungsdefinition in:

area:highway=der höchste Wert der highway im Kreuzungsbereich
+
junction=yes/roundabout/y_junction

richtig?

Wenn ja, dann lade ich Dich zum Editieren und Bereinigen des Proposals ein. Wie schon geschrieben, ich halte mich für nicht schlauer als die Anderen und ein so wichtiges Thema soll ein gemeinsames Werk sein.

PS: Lieber Seawolff, sieh Dir bitte dies an: http://www.openstreetmap.org/way/319492481
deswegen wird es nie mit einer Straßenbreite als Funktion der Anzahl der Fahrspuren klappen.
Man müsste noch zusätzlich definieren wieviele Farspuren links bzw. rechts von der Mittelachse sind und selbst dann decken wir die Übergangsbereiche nicht richtig ab.

Da ist man mit a:h einfach schneller und generiert saubere Ergebnisse.

Grüße,
Marek

marek kleciak wrote:

area:highway=der höchste Wert der highway im Kreuzungsbereich
+
junction=yes/roundabout/y_junction

richtig?

Würde ich sagen, außer, es gibt begründete Einwände dagegen 🙂

Geändert.
Wie in #129 geschrieben: Macht bitte bei dem Proposal aktiv mit.

Grüße,
Marek

Und so sieht die a:h in der Ukraine aus:

http://osmapa.pl/w/areaua/?lat=48.6&lon … om=6&ol=BP

Wenn ich in dieses Beispiel aus der Ukraine hineinzoome, finde ich hier in der Mitte des Kreisverkehrs einen Supermarkt, der als zur Straßenfläche zugehörig eingezeichnet ist.

Ebenso finde ich hier auch die Waldstücke zwischen den Fahrbahnen als a:h eingezeichnet.

Meine Vorstellung war, nur die asphaltierten Flächen bzw. höchstens auch die angrenzenden Fußwege als a:h einzuzeichnen.

Franz

marek kleciak wrote:

PS: Lieber Seawolff, sieh Dir bitte dies an: http://www.openstreetmap.org/way/319492481
deswegen wird es nie mit einer Straßenbreite als Funktion der Anzahl der Fahrspuren klappen.
Man müsste noch zusätzlich definieren wieviele Farspuren links bzw. rechts von der Mittelachse sind und selbst dann decken wir die Übergangsbereiche nicht richtig ab.

Lieber Marek, ich bin kein Gegner von a:h und habe es selbst schon vor mehr als zwei Jahren benutzt.
Ich bewundere dein Engagement in dieser Sache.
Bei der allgemeinen Euphorie dieses Tag sofort zu beschließen fehlte jemand, der auf die (sinnvollen!)
Formalien hinwies und kritische Fragen zum Proposal stellt. Diese Rolle habe ich dann übernommen.

Das obige Beispiel ist gut. Es wäre schön, wenn ein Renderer alle Tags der Straße darstellt und ein anderer a:h darstellt.

Deine Frage

Ob wir a:h=junction + junction= roadclass oder a:h=crossing crossing=roadclass (so ist es jetzt) haben wollen:

hatte ich interpretiert als:
Ob wir eine eigene Fläche für die Kreuzung brauchen, die als junction oder roadclass getaggt wird, oder wir die von flaimo vorgeschlagene einfache Variante ohne Zusatzfläche haben wollen.
Diese Frage halte ich weiterhin für diskussionsbedürftig.
Die Begründung im Proposal "More flexible rendering possible..." stimmt nur teilweise, da sie die in Stadtplänen übliche Darstellung gerade nicht erlaubt.

Im Proposal fehlt noch eine Definition, wo genau die Grenzen der "crossing area" liegen.
Soll jede Einmündung als "crossing area" erfasst werden? Auch "service" und "track"?

Hallo Franz,

ich bin aus der Ukraine und kann dir antworten.

FvGordon wrote:

Wenn ich in dieses Beispiel aus der Ukraine hineinzoome, finde ich hier in der Mitte des Kreisverkehrs einen Supermarkt, der als zur Straßenfläche zugehörig eingezeichnet ist.

Ebenso finde ich hier auch die Waldstücke zwischen den Fahrbahnen als a:h eingezeichnet.

Dort sind area:highway=* falsch bezeichnet. Sie werden in Zukunft korrigiert sein.

FvGordon wrote:

Meine Vorstellung war, nur die asphaltierten Flächen bzw. höchstens auch die angrenzenden Fußwege als a:h einzuzeichnen.

Deine Vorstellungen sind hier richtig.

Viele Grüße
Eduard.

seawolff wrote:

Soll jede Einmündung als "crossing area" erfasst werden? Auch "service" und "track"?

Habe ich schon auf polnische Forum nachgefragt und von Marek weiß, dass es genau ohne service und niedriger sein sollte. Also residential, unclassified etc.

seawolff wrote:

Bei der allgemeinen Euphorie dieses Tag sofort zu beschließen fehlte jemand, der auf die (sinnvollen!)
Formalien hinwies und kritische Fragen zum Proposal stellt.

Wir sollten auch weiterhin ein wenig auf die Bremse treten. Nicht vergessen, wir reden hier über ein Proposal. Natürlich kann man danach mappen, das ist auch gut, denn bei der Anwendung fallen einem die Fallstricke, die vorhanden sind am ehesten auf (wie mir beispielsweise die Sache mit a:h=crossing), aber es ist ein Vorschlag, eine Skizze und wir sollten einen großen Teil unseres Eifers eher in die Überarbeitung der Dokumentation im Wiki investieren. Das muss dort in sich schlüssig sein, wenn das Proposal überhaupt eine Chance haben soll. Die Seite scheint mir aktuell sehr "organisch" gewachsen und ist entsprechend schwer zu durchblicken. Diverse Aspekte des Taggings werden an verschiedenen Stellen beleuchtet und scheinen sich sogar teilweise zu widersprechen. Hilfreich wäre z.B. ein kurz und bündig formulierter Tagging-Leitfaden anhand von Allerweltsbeispielen, also 2-3 "normalen" Kreuzungssituationen/Straßen, wo dann genau gezeigt wird, welcher Bereich wie und warum getaggt wird. Ich weiß, das ist im Prinzip alles schon vorhanden, aber eben auf verschiedene Stellen im Proposal verteilt und nicht gesammelt.

Wenn die Wiki-Seite sortiert und strukturiert ist, erleichtert das auch die Diskussion, da sich viele Fragen vermutlich auch nur daraus ergeben, dass man schlicht die richtige Stelle im Proposal nicht gefunden hat.

PS: Ich versuche mich da evtl. selbst an Verbesserungen, aber ich muss zugeben, dass ich selbst noch nicht in Gänze vom Verständnis des Proposals her durchgestiegen bin 😉

Athemis wrote:

Hilfreich wäre z.B. ein kurz und bündig formulierter Tagging-Leitfaden anhand von Allerweltsbeispielen, also 2-3 "normalen" Kreuzungssituationen/Straßen, wo dann genau gezeigt wird, welcher Bereich wie und warum getaggt wird

Ein guter Vorschlag. Ich werde mich darum kümmern.

Grüße,
Marek

Tja, das ist echte Wiki-Seite: hier stehen neue Regeln, dort - alte...

Bitte dieses Bild erneuen:
area:highway=yes -> area:highway=<street type>
area:highway=crossing -> area:highway=<street type> + junction=yes
access=<bus,taxi,etc> -> area:highway=* (vielleicht)
vielleicht usw.

Und noch einmal:
Leute, warum möchtet ihr nicht area:highway=yes, sondern area:highway=<street type> nutzen?

edward17 wrote:

Und noch einmal:
Leute, warum möchtet ihr nicht area:highway=yes, sondern area:highway=<street type> nutzen?

Weil man dann einfacher rendern kann. Und vielleicht in Zukunft einmal auf die Straße als Linie verzichten kann.

viw wrote:

edward17 wrote:

Und noch einmal:
Leute, warum möchtet ihr nicht area:highway=yes, sondern area:highway=<street type> nutzen?

Weil man dann einfacher rendern kann. Und vielleicht in Zukunft einmal auf die Straße als Linie verzichten kann.

Na, wenn die Mehrheit wählt "street type", dann möchte ich nicht wiedersprechen...
Aber, in diesem Fall soll diese Absatz geändert sein, oder?

wiki wrote:

A: The rendering of streets as surfaces, does not need such attribution, because the logical representation level; with roads drawn as centerlines, already contains this information
The attributtation with values: secondary, residential is used for correct rendering of streets as midlines. The area representation as proposed here, does not require in principle an additional information.

Das ist hier: http://wiki.openstreetmap.org/wiki/Prop … ._Comments

edward17 wrote:

Bitte dieses Bild erneuen:

Erledigt in allen Sprachversionen.

marek kleciak wrote:

edward17 wrote:

Bitte dieses Bild erneuen:

Erledigt in allen Sprachversionen.

Vielen Dank!

Soll dieser Platz als area:highway=<strassenkategorie> + juncition=y_junction bezeichnet sein?

edward17 wrote:

Und noch einmal:
Leute, warum möchtet ihr nicht area:highway=yes, sondern area:highway=<street type> nutzen?

Ich finde es wichtig es zu behalten.

Beim import von open data wisst mann nicht direct welcher highway type classification der area:highway hat, dann is wichtig um es zu importieren mit area:highway=yes.

Danach kann mann highway type taggen.

edward17 wrote:

Soll dieser Platz als area:highway=<strassenkategorie> juncition=y_junction bezeichnet sein?

Ja. Zum Vergleichen:
http://www.openstreetmap.org/way/366812699

Allroads wrote:

edward17 wrote:

Und noch einmal:
Leute, warum möchtet ihr nicht area:highway=yes, sondern area:highway=<street type> nutzen?

Ich finde es wichtig es zu behalten.

Beim import von open data wisst mann nicht direct welcher highway type classification der area:highway hat, dann is wichtig um es zu importieren mit area:highway=yes.

Dann wählt man einfach "road" als Typ.

Eine formelle Frage: ist ein Radweg ein Teil der Straßenfläche wenn eas auf der Straße verläuft?
Ich bin der Meinung: ja.
Das heißt, wenn wir eine a:h zeichnen dann soll sie den Radweg beinhalten.
Das heißt, wir brauchen keine Kreuzungsflächen solcher Radwege, weil sie bereits in der Kreuzungsfläche zweier Straßen beinhaltet sind.
Das Gleiche gälte dann auch für die Fußwege durch die Kreuzung.

Grüße,
Marek

Ja Radstreifen oder Radfahrstreifen sind Teil der Fahrbahn:
https://de.wikipedia.org/wiki/Radfahrstreifen

Wie verhält es sich mit markierten Parkbuchten, ob längs oder schräg, soll man die als amenity=parking_space taggen, was ja eigentlich auch nicht unbedingt im Wiki so gewünscht ist.
Jetzt mit der Straßen-Fläche lassen die sich aber erst ordentlich einzeichnen.

Richtig, a:h löst auch dieses Problem.
Wir haben Tagging der Parking als Fläche oder als Punktobijek bzw. Linie die sich dafür nicht eignet.
Eigentlich bräuchten wir dafür was Neues.
Habt Ihr Vorschläge?

Eigentlich bräuchten wir dafür was Neues. Habt Ihr Vorschläge?

Wir sollten hier nicht zu viele Sachen neu einführen. Rein theoretisch wäre das tag schon gut geeignet dafür mit Änderung der Beschreibung. Probleme: Es wird nirgendwo gerendert und das tag ist approved. Also da kann man höchstens eine Erweiterung beschreiben. Diese Flächen als amenity=parking zu markieren, halte ich für die schlechtere Lösung. Dann spiekt es später überall mit kleinen gelben Flächen.

Oft sind es ausgewiesene Anwohnerparkplätze, wo ich auch noch nichts gefunden habe. (access=private passt ja auch nicht, höchstens access=residents)

Hallo,

ich habe 2 Plätze in Wiki-Seite gefunden, die meiner Meinung nach korrigiert sein sollen:

1. Applies to: - ich denke, dass {{IconArea}} dort hinzugefügt sein soll.
2. In Tagging:
"highway=footway with footway=yes" -> "highway=footway with footway=crossing", nicht wahr?

Also, ein area tag mit footway funkt. auch über die mapnik-Standardkarte: https://www.openstreetmap.org/#map=18/50.96122/6.97771
Hier im Kölner Zoo hatte ich zuerst ein pedestrian getaggt. Es geht aber auch mit einem highway=footway + area=yes.
Man muss sich überlegen und noch weiter austesten, ob footway areas insgesamt getaggt werden können mit rendering, auch mit weiteren Attributen und wie das routing funktioniern könnte.. Bin hier noch nicht ganz sicher.
Möchte auch gerne in Köln den angrenzenden Park"Flora" mit flächigen Wegen taggen. Teste die Tage dies aus.
Also, wenn die Flächen eines Footways in verschiedenen Möglichkeiten gerendert werden, muss man sich da gegenseitig anpassen, oder? Doppeltagging wäre imho nicht sinnvoll.

Edit

Rogehm wrote:

Also, ein area tag mit footway funkt. auch über die mapnik-Standardkarte: https://www.openstreetmap.org/#map=18/50.96122/6.97771
Hier im Kölner Zoo hatte ich zuerst ein pedestrian getaggt. Es geht aber auch mit einem highway=footway + area=yes.

Dass "highway=*" mit "area=yes" von Mapnik dargestellt wird, ist nicht neu.
Es ist aber nicht der Sinn von OSM eine bestimmte Darstellung durch Mapnik zu erreichen (siehe auch DE:Taggen für den Renderer).
Auch "layer=1" dient nicht dazu, ein bestimmtes Renderergebnis zu erzwingen.

In OSM hat man sich dafür entschieden, Wege als Mittellinie zu erfassen.
Eine doppelte Erfassung ist nicht sinnvoll und schafft viele Probleme.
Deshalb entstand der Vorschlag, die Fläche der Wege mit a:h und nicht mit "highway" und "area=yes" zu taggen!

Also, wenn die Flächen eines Footways in verschiedenen Möglichkeiten gerendert werden, muss man sich da gegenseitig anpassen, oder?

Ja, man muss "highway=footway", "area=yes", "layer=1" schnellstmöglich löschen.

Der Kölner Zoo scheint an vielen Stellen für den Renderer gemalt.
Es gibt Attraktionen mit Namen "Luftballons" und "Bollerwagen", einen Teich der "Wasservögel" heißt und
ein Objekt namens "Persischer Wildesel", das gleichzeitig Attraktion, Sandfläche, Tier und Zaun ist und
sich zwischen einem Baum am Boden und einer Grasfläche auf Level 2 befindet.

Dass "highway=*" mit "area=yes" von Mapnik dargestellt wird, ist nicht neu.
Es ist aber nicht der Sinn von OSM eine bestimmte Darstellung durch Mapnik zu erreichen (siehe auch DE:Taggen für den Renderer).

Ja, und? Dann ist es doch gewollt. Sonst würde es nicht gerendert. Man könnte hier auch für andere Renderer taggen, z.B. Ist das Gebäude im Nachbar Area "Flora" für F4 getaggt.
Hat man damit ein Problem?
Die Wege sind alle als Mittelinie erfasst. Das "Rand" Routing ist so oder so nicht zu bewältigen, egal ob pedestrian oder footway. Da müssten die Routerprogramme sich was überlegen.
Hier wird erstmal nichts gelöscht. Entweder sind die Wege "Flächen" als "Footway" oder als "Pedestrian". Die anderen Fehler im Zoo werden noch behoben.
Ich sehe hier erstmal Konflikte zwischen dem Mapnik Stile und dem hiesigenProposal.

Zu welchem Blödsinn das führt, so wie im Kölner Zoo derzeit getaggt ist, kann man beim Routing sehen: Ganz tolle Route.

Zwei Fußwege übereinander, um Flächen und Mittellinien zu haben, ist völlig unbrauchbar. Es gibt einen Fußweg als Mittellinie und wenn man meint Flächen zu brauchen, dann muss das anders getaggt werden. Wenn es derzeit von Mapnik noch nicht gerendert wird, dann ist das so. Aber das soll hier auch nicht MS-Paint sein, wo es darum geht, ein schönes Bild mit geometrischen Figuren auf den Bildschirm zu malen. Ich kann seawolff nur vollumfänglich zustimmen.

Kontinentalverschieber wrote:

und wenn man meint Flächen zu brauchen, dann muss das anders getaggt werden. Wenn es derzeit von Mapnik noch nicht gerendert wird, dann ist das so.

+1. Daher tagge ich solche Flächen nur noch als area:highway=footway.
Je mehr wir solche Objekte haben, umso wahrscheinlicher ist es, dass man diese Objekte beim Rendern berücksichtigt.

Grüße,
Marek

Yo, immerhin führt der gleiche Router für das läppische Eintrittsgeld (Maut) für 17,50 den kürzesten Weg von hier nach dort. Also, alles noch in der Konstruktionsphase.

P.S. Die Flächen werden gerendert. Nicht das hier Missverständnisse aufkommen. Ist aber auch egal. Entweder area tagging von footwaw / pedestrian oder area:highway.

Kombiniertes Doppeltagging versuche ich mal morgen in Nürnberg, der schönen Stadt.

Und auf der Domplatte routet er gar nicht...

Aber das ändert nichts daran, dass das im Kölner Zoo kompletter Unsinn ist. Denn selbst wenn das ein hochgradig perfekter Router wäre, würde er im Kölner Zoo verzweifeln (und ein perfekter Renderer erst recht). Denn dort gäbe es einen flächigen Hochweg (layer=1) über einem linienförmigen Tiefweg (kein Layer --> layer=0). Diese beiden sind dann an Randpunkten bei ausbrechenden Wegen miteinander verknüpft und ergeben so ein lustigeres Wegesystem als jeder Baumseilgarten. Und die von seawolff beschriebene Wildeselanlage mit den Hängenden Gärten von Babylon ist da dann nur noch die Krönung.

Der Zoo ist wirklich ein Fall für den Kuriositätenthread, wenn man ihn von der Datenstruktur anschaut. Man lacht sich wirklich kaputt.

Rogehm, danke für Deine Hilfe in Nürnberg.
Es gibt dort bereits Einiges zu sehen
http://osmapa.pl/w/areade/?lat=49.4776& … =12&ol=BPN

😉

Der Zoo ist wirklich ein Fall für den Kuriositätenthread, wenn man ihn von der Datenstruktur anschaut. Man lacht sich wirklich kaputt.

Machs besser, ich halte dich nicht davon ab. Nur Rumgemotze kann ich auch. Außerdem war es auch noch Baustelle, die sich leider schlecht darstellen lässt.

Marek wrote:

Rogehm, danke für Deine Hilfe in Nürnberg.

Nö, war keine Hilfe, Aber Danke dafür. War nur Einarbeitung. Ich versuche, die "Ecke" noch fertigzustellen.

P.S. In der Hoffnung, auch in NRW demnächst "was zu sehen". Der Server scheint gut zu funktioniern mit den 1 h Updates.

Ich spreche das erneut an.
Mittlerweile wird in der poln. Version auch a:h=traffic_island+landuse=grass farbig unterstützt. service roads, bus und amenity=parking_space als Area gezeichnet bekommen auch leicht anderen Farbton als die üblichen a:h.

http://osmapa.pl/w/area/?lat=53.43303&l … =19&ol=BPo

Ich mag die Darstellung mit der Visualisierung der turn:lanes : http://osmapa.pl/w/area/?lat=52.39961&l … ol=PEFGABR

Sie ist leider in der Dt. Version noch nicht implementiert. Kommt aber.

Neuerdings gibt es sogar area:highway=bridge. IMO total falsch, eine Brücke ist kein highway.
https://www.openstreetmap.org/browse/way/268663549

Taggen für den Renderer!

Soll in diesem Bild area:highway=bridge durch man_made=bridge ersetzt sein?

Welcher Renderer? Höchstens Tagging für die Zukunft. Aber da gibt es ja genug "tote" Beispiele. Dieses tote Tagging wartet eben solange, bis es ins Leben gerufen wird. Genauso könnte man jedes 3D Tagging so bezeichnen. Tagging für den Renderer. What else?

Rogehm wrote:

Welcher Renderer? Höchstens Tagging für die Zukunft. Aber da gibt es ja genug "tote" Beispiele. Dieses tote Tagging wartet eben solange, bis es ins Leben gerufen wird. Genauso könnte man jedes 3D Tagging so bezeichnen. Tagging für den Renderer. What else?

Einerseits werden IMO unnötige MP-Relationen gemappt, mit der Begründung Vermeiden doppelter Linien und damit weniger zu speichernde Daten, andererseits wird totes Tagging produziert, was den Datenumfang erheblich vergößern dürfte.

Tagging für die Zukunft oder nicht? So manche haben da ihren eigenen Kochtopf.
Das Wiki ist ein inkonsistentes Gemurkse.

Beispiel:
http://wiki.openstreetmap.org/wiki/Prop … ea#Tagging

The existing approach, highway=* with area=yes can be extended with addition of drawing street surfaces with the tagging:
area:highway=value Values are the same as for the current highway=* tag, under the lists "roads" or "paths".

area:highway=yes for unknown road type.

Dann findet weiter unten area=highway=bridge usw.
BTW, area:highway=yes wurde IMO abgelehnt.

Demnach What else? zu urteilen, könnte man das Ganze auch einfach löschen. 😉

edward17 wrote:

Soll in diesem Bild area:highway=bridge durch man_made=bridge ersetzt sein?

Ja. a:h=bridge brauchen wir nicht, weil schon man_made=bridge existiert.

Rogehm wrote:

Dass "highway=*" mit "area=yes" von Mapnik dargestellt wird, ist nicht neu.
Es ist aber nicht der Sinn von OSM eine bestimmte Darstellung durch Mapnik zu erreichen (siehe auch DE:Taggen für den Renderer).

Ja, und? Dann ist es doch gewollt. Sonst würde es nicht gerendert.

Mapnik ist nur eines von vielen Programmen, das OSM-Daten auswertet.
Eine korrekte Darstellung in Mapnik beweist nicht, das die Daten korrekt sind.
Eine falsche oder fehlende Darstellung in Mapnik beweist nicht, das die Daten falsch sind.

"highway=*" mit "area=yes" wird benutzt, um ungerichtete Flächen abzubilden
(die dann keinen "highway=*" zusätzlich erhalten). Für eine Grundsatzdiskussion,
ob Wege als Linie erfasst werden sollen, kommst du 10 Jahre zu spät.

Man könnte hier auch für andere Renderer taggen, z.B. Ist das Gebäude im Nachbar Area "Flora" für F4 getaggt.

So wie man für Straßenflächen a:h und nicht ein nochmals "highway" verwendet,
so werden dort Gebäudeteile mit "building:part" und nicht "building" getaggt.

marek kleciak wrote:

a:h=bridge brauchen wir nicht, weil schon man_made=bridge existiert.

Streiche am besten den gesamten Abschnitt "Rendering of bridges".
"man_made=bridge" ist unabhängig von a:h.
Die Eissenbahnbrücke hat mit a:h auch nichts zu tun.

Bitte streiche auch den Abschnitt über stop lines.
Die Idee ist völlig unausgereift und verwirrend.
Die Datenstruktur passt nicht zu OSM und ist mit bestehenden Renderern nicht darstellbar.

Das Bild Mockup more complex example finde ich unseriös.
Es suggeriert, dass diese Darstellung mit den zuvor genannten Datenstrukturen erzeugt wurde.
Es enthält aber viele Details, die damit gar nicht umsetzbar sind, und widerspricht in Teilen der OSM-Karte darunter.
Vermutlich hast du das Luftbild mit Photoshop nachgemalt.
Ersetzte das Bild bitte durch ein echtes Renderergebnis.

Es würde dem Proposal sehr helfen, wenn man es auf den Kern a:h beschränkt.

Ich bitte, nächste Teile des Proposals möglichst schnell zu erneuen, weis sie veraltet sind, und deshalb Mappers in einen Irrtum verfallen.

In case of an intersection of two roads with different classes, e.g. tertiary and residential the area:highway=crossing gets additionally still tag crossing= <value of the street with higher priority>

- crossing -> junction, etc (hier)

Q: Which area:highway values should be used, when several different types of road meet, e.g. crossing of secondary and residential road? should area of residential road be splitted? Or one new mix tagging should be used?

A: The rendering of streets as surfaces, does not need such attribution, because the logical representation level; with roads drawn as centerlines, already contains this information

The attributtation with values: secondary, residential is used for correct rendering of streets as midlines. The area representation as proposed here, does not require in principle an additional information.

- soll entfernt sein (hier)

Dieses Bild - area:highway=bridge -> man_made=bridge
Dieses Bild - crossing=y_junction -> junction=y_junction

Und mit diesem Satz (hier) ist etwas falsch:

The nodes K of treet center line edges (red on the picture) must have common points with street areas.

Erledigt.
Danke für Deine Aufmerksamkeit!

Neu: rendering von way - highway=cycleway + cycleway=crossing
http://osmapa.pl/w/area/?lat=51.13176&l … 19&ol=BPoR
z
Yebra Streifen links oben ist falsch getaggt um den Unterschied aufzuzeigen.
DEmnächst kommt auch der Rendering von bicycle@path

Nachdem alle Tests abgeschlossen sind kann man auch die Dt. Seite upgraden.

Wow, das Thema ist ja ganz schön in Fahrt gekommen. Ich würde mich auch aus 3D-Sicht sehr über Straßenflächen freuen. 🙂

Was ich mir noch wünschen würde, wären einige Klarstellungen in Detailfragen. Speziell wäre es aus meiner Sicht sinnvoll, die folgenden Hinweise zu ergänzen:

• Parallele Ways sollten jeweils ihre eigene Straßenfläche haben, z.B. bei Autobahnen, aber auch bei mit separaten Way gezeichneten Radwegen etc.
• Flächen für Spuren (im weiteren Sinne), also z.B. area:highway=bus und area:highway=shoulder, sollten innerhalb der Straßenfläche liegen. Für 2D-Renderer macht das keinen Unterschied, aber für 3D wäre es eine große Hilfe.

Vielleicht ist insbesondere der erste Punkt sogar offensichtlich, aber dem Programmierer erleichtern solche Annahmen die Arbeit deutlich.

Tordanik wrote:

- Parallele Ways sollten jeweils ihre eigene Straßenfläche haben, z.B. bei Autobahnen, aber auch bei mit separaten Way gezeichneten Radwegen etc.
- Flächen für Spuren (im weiteren Sinne), also z.B. area:highway=bus und area:highway=shoulder, sollten innerhalb der Straßenfläche liegen. Für 2D-Renderer macht das keinen Unterschied, aber für 3D wäre es eine große Hilfe.

Absolut richtig. Kannst Du mir helfen und diese Hinweise in dem engl. Proposal einbauen?

Auch finde ich dad das Rendern der area:highway=emergency viel besser gelingen könnte, wenn man Deinen Vorschlag mit der Richtung einer Textur der Fläche zuweisen könnte. Ich habe jetz kein Beispiel zur Hand, aber es ist ofensichtlich das ein Spitzdreieck mit Kreuzschraffur schlecht aussieht, wenn man die Schraffur parallel zu einer der längeren Außenkanten hat.

Mit der Schraffur hast du absolut recht. Ich könnte mir zwar vorstellen, dass man die Schraffur automatisch so dreht, dass sie annehmbar aussieht, aber wenn man die Richtung so haben will, wie sie in der Realität ist, dann braucht man zwangsläufig ein direction-Tag o.ä.

PS: Ich habe die Klarstellungen jetzt im englischen Proposal ergänzt.

Lieben Dank für die Hilfe Tordanik!
JOSM hat doch die Fuktion die Einem erlaubt die Richtung zu messen, oder?

Falls ja, dürfte ich Dich noch bitten in dem Proposl auch den Tag für die Drehung der Schraffur einzubauen?
Du hast ja daran gewerkelt also kannst das sicherlich besser als ich.

Grüße,
Marek

Ja, JOSM hat einen Winkelmesser eingebaut. Benutze ich oft.

Habe jetzt mal einen Abschnitt zur Richtungsangabe für die Schraffur eingebaut. Ich hoffe das passt so. 🙂

Passt, sehr schön,
vielen Dank Tordanik!

Marek

marek kleciak wrote:

Erledigt.
Danke für Deine Aufmerksamkeit!

Danke für Deine Änderungen!
Ukrainische Version wurde nun auch aktualisiert.

3 kleine Fragen:

Ich tagge momentan den Stadtpark Nürnberg (Fußwege).

Wenn ein width tag angegeben ist, ist dieser eigentlich durch das Flächentagging sinnlos. Stehenlassen ?
Eine Fußgängerbrücke: Beide Tags? man_made=bridge + area:highway=footway ?
Ist mir immer noch nicht klar: Surface tagging auf der Fläche? Darf man auch schon Farben hinzufügen? Oder zu früh?

3D Elemente lassen sich mit der Fläche auch viel leichter hinzufügen. (Geländer, Zäune etc). Außerdem füge ich Bäume hinzu (die sich nicht auf der Strassenfläche befinden sollten).

Huch, noch eine vierte: Wie soll man mit flächigen Treppenwegen umgehen? Wichtig! Keine Treppe als building:part. Sondern Gelände. Auch nicht Standardstufenlänge.
Neue Ideen dazu?

Wenn ein width tag angegeben ist, ist dieser eigentlich durch das Flächentagging sinnlos. Stehenlassen ?

Ja.

Eine Fußgängerbrücke: Beide Tags? man_made=bridge + area:highway=footway ?

Ja
Hier ist ein Beispiel einer Brücke mit 2 Fahrstreifen, Busstreifen, zwei Radwegen und Fußweg in Nürnberg:
http://osmapa.pl/w/areade/?lat=49.45954 … =19&ol=BPN

Surface tagging auf der Fläche? Darf man auch schon Farben hinzufügen? Oder zu früh?

Es ist nie zu früh. Wenn Content vorhanden ist, wird der Rendering angepasst, auf dem höchsten Zoom Level.

Wie soll man mit flächigen Treppenwegen umgehen?

In Kürze unterstützt Marimil in seinem REndering dieses Schema:
http://wiki.openstreetmap.org/wiki/User … d_end_line

Hallo Marek,

hier sollte aus Konsistenzgründen ebenfalls "crossing" durch "junction" ersetzt werden.

Beste Grüße

Alex

Was ist davon zu halten?

MP-Relation highway=pedestrian + area=yes + area:highway=pedestrian.
Relation ist wegen Gebäuden und Fremdflächen auf der pedestrian-Fläche erforderlich.
IMO ist das area:highway hier falsch, oder?

RadFr wrote:

Was ist davon zu halten?

MP-Relation highway=pedestrian + area=yes + area:highway=pedestrian.
Relation ist wegen Gebäuden und Fremdflächen auf der pedestrian-Fläche erforderlich.
IMO ist das area:highway hier falsch, oder?

highway=pedestrian + area=yes ist hier falsch.

Wenn es eine begehbare Fußgängerzone (schließe ich aus dem Gebäude im Inneren der Fläche) ist, ist highway=pedestrian + area=yes richtig. Es muss ja routingfähig sein. Die street-areas sind dazu gedacht, vom Routing ausgeschlossen zu werden.

Ich sehe schon eine Menge Verwechslungen (und damit falsches Mapping) auf OSM zukommen.

edward17 wrote:

RadFr wrote:

Was ist davon zu halten?

MP-Relation highway=pedestrian + area=yes + area:highway=pedestrian.
Relation ist wegen Gebäuden und Fremdflächen auf der pedestrian-Fläche erforderlich.
IMO ist das area:highway hier falsch, oder?

highway=pedestrian + area=yes ist hier falsch.

Wenn ich das eben richtig gelesen habe, ist area:highway die reine Straßenfläche. Dies trifft da eindeutig nicht zu. Ergo Du liegst falsch.

RadFr wrote:

Wenn ich das eben richtig gelesen habe, ist area:highway die reine Straßenfläche. Dies trifft da eindeutig nicht zu. Ergo Du liegst falsch.

Vielleicht habe ich Deine Message falsch übersetzt und deswegen falsch geantwortet.

Ich habe eine Wiki Seite angefangen die aufzeigt wie man a:h aufteilt.
Erst Mal kommentarlos, ich hoffe dass es trotzdem helfen kann:

http://wiki.openstreetmap.org/wiki/Prop … guidelines

Eine kleine Frage:
Sollen Linien highway=footway + footway=crossing mit dem Polygon area:highway=* gemeinsame Punkte haben?

JA.
Dann können wir für die Blinden Navigation exakt sagen, wann sie vor der Kreuzung stoppen sollen.

Noch ein Mapping Beispiel wurde von dem User Javnik hinzugefügt:
http://wiki.openstreetmap.org/wiki/Prop … guidelines

Sehe ganz unten.
Grüße,
Marek

Hallo,
@Marek. Mit den älteren links sind die bisherigen Arbeiten nicht mehr zu sehen. Ein Aufruf über http://osmapa.pl/w/areade/
ergibt nur einen kleinen Bereich den neuen taggings. Wegen Unkenntnis im polnischen komme ich nicht auf den Zustand vom 26.08.;
Hast du einen neuen festen Link für das bayrische Tile? Ist das Tile über http://osmapa.pl/w/ erreichbar?

Ich hake nach, möglicherweise eine Server Absturz.
Ich habe es soeben auch beobachtet.

Ist width=* bei der highway=footway + footway=crossing-Linien im Renderer am http://osmapa.pl/w/area berücksichtigt?

edward17 wrote:

Ist width=* bei der highway=footway + footway=crossing-Linien im Renderer am http://osmapa.pl/w/area berücksichtigt?

Ja! Beim highway=cycleway + cycleway=crossing auch. Siehe: http://osmapa.pl/w/area/?lat=52.25545&l … m=19&ol=BP, zwei verschiedene width's.

Javnik wrote:

edward17 wrote:

Ist width=* bei der highway=footway + footway=crossing-Linien im Renderer am http://osmapa.pl/w/area berücksichtigt?

Ja! Beim highway=cycleway + cycleway=crossing auch. Siehe: http://osmapa.pl/w/area/?lat=52.25545&l … m=19&ol=BP, zwei verschiedene width's.

Danke! Dann werde ich diesen Tag benutzen.

Die Bayern a:h Seite wird gerade neu importiert. Ist also demnächst wieder funktionsfähig.

Die Bayern a:h Seite wird gerade neu importiert. Ist also demnächst wieder funktionsfähig.

Funkt. wieder. Wäre trotzdem schön, wenn die Bayern a:h Seite hier irgendwo verlinkt wäre. Oder ist schon?

Ich habe die http://wiki.openstreetmap.org/wiki/Prop … guidelines weiter ausgebaut (Wendehammer und dead end Mapping) und mit der Wiki Seite der a:h verlinkt.

Bitte denkt bei der Erfassung an die lanes=* and turn:lanes=* die werden zwar jetzt in BY noch nicht gerendert aber dies soll sich in Kürze verändern.

pyram wrote:

http://www.openstreetmap.org/note/300338

Vor allem der kommentar von gsperb man solle einfach von den Seiten des Verkehrsverbundes kopieren... Der User ist mir zuvor schonmal aufgefallen das er alle meine Bugs relativ schnell fixt auch wenn sie relativ weit auseinander liegen. Auf Nachfrage hab ich nur die Antwort bekommen das er auf den Weg nach Hause mit dem Motorrad Bugs abfährt und ich das mit dem Urheberrecht lockerer sehen soll...

Ich halte das generell mit den Buslinien (im Gegensatz zu Bushaltestellen) für unsinnig wenn man nicht eine Datenquelle hat die man übernehmen darf, da sie genauso schlecht physisch greifbar sind wie Grenzen, Postleitzahlen etc.

pyram wrote:

http://www.openstreetmap.org/note/327495

Ich habe diesen bugreport hinzugefügt und der Bug ist mir bei dem dir angesprochenen Luftbildermapping aufgefallen. Das kann man relativ gut dazu nutzen zumindest einige Daten mal zu überprüfen ob sie generell Sinn machen. Selber nachprüfen fällt mir schwer da ich zur Zeit nicht in Erlangen wohne.

Manchmal hat man halt einfach keine Lust vor Ort zu gehen weil man wo anders ist, es zu kalt/warm ist. Selbst mit Luftbildermapping kann man noch sehr viel Grobes dazutragen, wie Häuser oder Wälder (in Ländern wie Schweden fehlen auch noch etliche Straßen). Was mir ein bisschen fehlt wäre ein task manager um mal wirklich ganz Deutschland einfach mit grundlegendem wie Häuser abzudecken

Tordanik machte eine Ankündigung an die
Tagging-Mailingliste mit dem RFC area:highway:

https://lists.openstreetmap.org/piperma … 26278.html

Seit Mitte August hat sich die Anzahl der a:h Elemente in der Datenbank nahezu verdoppelt.

Danke Tordanik!

Grüße,
Marek

Soll die Fläche unter Straßenbahn-Gleisen mit einem besonderen Tag gemappt sein?
Beispiel (bitte Bing-Layer clicken): http://www.sammyshp.de/fsmap/#19/48.03265/37.79137
So sieht das jetzt aus: http://osmapa.pl/w/areaua/?lat=48.03264 … m=19&ol=BP

Warum sind Fahrrad-Linien hier rot, und hier nicht? Ich möchte sie rot sehen, weil sie in Realität so sind 🙂 Siehe Bing hier: http://www.sammyshp.de/fsmap/#19/48.03072/37.78962

Solche Flächen sind normale Kreuzungsflächen weil die autos über solche Elemente fahren dürfen.

In der polnischen Version werden Neuerungen ausprobiert und viele Diskussionen geführt.
Diese und andere Änderungen die noch kommen, wie zum Beispiel Rendering von a:h=taxi, a:h=bus_stop a:h=(footway mit cycleway), besserer Rendering von steps, Abbiegepfelie in kleineren Zoomstufen, Rotation der Texturen z.B. für a:h=emergency +direction=*, Rendering von http://wiki.openstreetmap.org/wiki/Key:road_marking

Also es ist noch viel zu tun für einen einzelnen Mapper.
Deswegen aktualiziert er NOCH NICHT die Deutsche und Ukrainische Version.
Das kommt aber. Wenn jemand von diesem Forum dabei helfen kann wäre ich und Marimil sehr verbunden 😉

Grüße,
Marek

Edit: sieh Dir dieses Element in 2,3 Stunden auf der osmapa an: http://www.openstreetmap.org/way/368477819
Rot werden area:highway=cycleway gezeichnet, ich weiß nicht ob das bereits in der ukrainischen Version funktioniert, glaube aber schon.

edward17 wrote:

Soll die Fläche unter Straßenbahn-Gleisen mit einem besonderen Tag gemappt sein?

Auf den Kreuzungen nicht, außer kannst du landuse=railway oder a:h=tram benutzten.

edward17 wrote:

Warum sind Fahrrad-Linien hier rot, und hier nicht?

Eigentlich ist das test-area. Deine schauen ok aus, siehe auch normaler Benutzung.

"Breaking news" 🙂
man_made=bridge werden im OSM Standard Stil gerendert:
http://www.openstreetmap.org/way/305509688
via @shtosm

marek kleciak wrote:

sieh Dir dieses Element in 2,3 Stunden auf der osmapa an: http://www.openstreetmap.org/way/368477819
Rot werden area:highway=cycleway gezeichnet, ich weiß nicht ob das bereits in der ukrainischen Version funktioniert, glaube aber schon.

Vielen Dank! Es ist nun rot 😉

Ich schüttele mit den Augen! Was ist das denn jetzt? Wer hat das denn eingebracht? Revolution der Andersdenkenden? Volle Umarmung und schmatz!!!

http://www.openstreetmap.org/#map=18/50.94120/6.96594

Anh.: Na, dann mache ich doch mal die Kölner Brücken fertig...

Alle man_made=bridge werden seit gestern so gerendert.
Wir haben also was bewegt: Die Skizze kennst Du doch -> http://wiki.openstreetmap.org/wiki/File … opViev.JPG

Grüße,
Marek

Wir haben also was bewegt: Die Skizze kennst Du doch -> http://wiki.openstreetmap.org/wiki/File … opViev.JPG

@Marek: Natürlich
Ich werde die Tage eine deutsche Site von http://wiki.openstreetmap.org/wiki/Tag: … e%3Dbridge erstellen.
Außerdem alle Kölner Brücken mit der Fläche taggen. Jetzt kommt aber hoffentlich auch bald die Trennung in 3D, wobei ich versuche, die Pfeiler gesondert zu taggen. Auf dem Umriss sollten die eigentlich nicht zu sehen sein. Ich hoffe 3D zieht nach.

Die neue Tabelle in http://wiki.openstreetmap.org/wiki/Prop … treet_area finde ich super.
Momentan stolpere ich jedoch mit dem tagging highway=pedestrian & area=yes und hier area:highway=pedestrian. Das beisst sich. Evtl. auch higway=footway + area=yes.
Hier sollte eine Einigung erzielt werden. Durch das parallele Flächenrendering gibt es einen Konflikt.

Momentan stolpere ich jedoch mit dem tagging highway=pedestrian & area=yes und hier area:highway=pedestrian. Das beisst sich. Evtl. auch higway=footway + area=yes.

Richtig. area:highway=pedestrian habe ich nicht vorgesehen, wegen des Konflikts.
Vielleicht hat das der User den ich um die Kodifizierung der Tabelle gebeten habe, doch noch aufgenommen.
Ich entferne das gleich.

Na ja, da kommt mir ein neuer Gedanke. Jetzt werden ja schon die area's für pedestrian und footway in der Standardkarte gerendert.
Möchte man da die weiteren Wege für die mapnik als area verhindern durch das tagging a:h=X ? Könnte sich in Zukunft als sehr konfliktreiche Konstellation darstellen.
Eigentlich ist das hiesige Flächentagging mit a:h doch prädisteniert für 3D und Flächen in der natürlichen Darstellung (z.B. Farben oder auch Pflasterrendering)
Das kann bestimmt nicht durch die Mapnik geleistet werden. Also muss es erlaubt sein, auf der Strassenfläche neben den Standardwerten für die mapnik auch noch in Zukunft genauere Werte für die Oberfläche taggen zu können, die halt durch verschiedene Maps ausgewertet werden können. Im Prinzip bedeutet das:
Eine Fläche highway=pedestrian + area=yes könnte mit Zusatztags wie area:highway=pedestrian + surface=paving_stones + paving_stones:shape + paving_stones:colour beschrieben werden. Das wäre absolut genial, fände ich.

marek kleciak wrote:

Momentan stolpere ich jedoch mit dem tagging highway=pedestrian & area=yes und hier area:highway=pedestrian. Das beisst sich. Evtl. auch higway=footway + area=yes.

Richtig. area:highway=pedestrian habe ich nicht vorgesehen, wegen des Konflikts.
Vielleicht hat das der User den ich um die Kodifizierung der Tabelle gebeten habe, doch noch aufgenommen.
Ich entferne das gleich.

In der Tabelle steht:
area:highway yes For unknown road type.

Der unbekannte Straßentyp wird doch mit highway=road getaggt. Logisch wäre dann area:highway= road und nicht area:highway=yes

Rogehm wrote:

Na ja, da kommt mir ein neuer Gedanke. Jetzt werden ja schon die area's für pedestrian und footway in der Standardkarte gerendert.
Möchte man da die weiteren Wege für die mapnik als area verhindern durch das tagging a:h=X ? Könnte sich in Zukunft als sehr konfliktreiche Konstellation darstellen.
Eigentlich ist das hiesige Flächentagging mit a:h doch prädisteniert für 3D und Flächen in der natürlichen Darstellung (z.B. Farben oder auch Pflasterrendering)
Das kann bestimmt nicht durch die Mapnik geleistet werden. Also muss es erlaubt sein, auf der Strassenfläche neben den Standardwerten für die mapnik auch noch in Zukunft genauere Werte für die Oberfläche taggen zu können, die halt durch verschiedene Maps ausgewertet werden können. Im Prinzip bedeutet das:
Eine Fläche highway=pedestrian + area=yes könnte mit Zusatztags wie area:highway=pedestrian + surface=paving_stones + paving_stones:shape + paving_stones:colour beschrieben werden. Das wäre absolut genial, fände ich.

highway=pedestrian + area=yes (a) und area:highway=pedestrian (b) sind zwei Paar Stiefel.
IMO hat (b) an (a) nichts zu suchen. Immer noch nicht begriffen? 🙄

http://forum.openstreetmap.org/viewtopi … 97#p528397

Der unbekannte Straßentyp wird doch mit highway=road getaggt. Logisch wäre dann area:highway= road und nicht area:highway=yes

Richtig. Ich hab´s geändert.

Eine kleine Idee:
Wir haben das Problem die Parkplätze entlang einer Straße zu taggen wenn sie als Fläche erfasst sind.
Es ist weder amenity=parking noch amenity parking_space

warum nicht: area:highway=parking?

Wir haben das Problem die Parkplätze entlang einer Straße zu taggen wenn sie als Fläche erfasst sind.
Es ist weder amenity=parking noch amenity parking_space

Meinst du nicht, amemity=parking_space könnte man so flexibel auslegen, ggf. ergänzend beschreiben, das es in dieses Schema passt?
Ich meine, wenn du die Flächen immer wieder erweiterst auf noch nicht festgelegte Renderer, wird das ganze sehr inkombatibel zum bisherigen tagging.

Da gibt es ja z.B. auch http://wiki.openstreetmap.org/wiki/DE:Key:parking:lane
Was aber natürlich nicht die eigentliche Parkfläche beschreibt. Diese könnte ja wirklich durch area:highway=parking beschrieben sein, wenn man also auch parking_lane oder parking_space gleichzeitig taggt. Wird aber nur dann funktionieren, wenn der Mapper, der die "Parkfläche" mappt, gleichzeitig den Strassen-tag parking_lane auf diese Fläche abstimmt.
Ich sehe hier wie auch z.B. beim Waldflächentagging eine sehr viel größere Mapping Verantwortung der User (auch der Anfänger - die das evtl. (wahrsch.) übersehen).
Das ginge so lange gut, bis das Proposal nicht approved ist. Danach möchte auch die mapnik mitspielen, wie wir auch in vielen Beispielen in jüngster Vergangenheit gesehen haben.

marek kleciak wrote:

Eine kleine Idee:
Wir haben das Problem die Parkplätze entlang einer Straße zu taggen wenn sie als Fläche erfasst sind.
Es ist weder amenity=parking noch amenity parking_space

warum nicht: area:highway=parking?

Die Parkplätze gehören zu den POIs und sollen deshalb die Tags haben, die die Suchen nach ihnen ermöglichen (amenity=parking oder amenity parking_space).

Diese Objekte sollen einen von ober genannten amenity-Tags haben. Irgendein area:highway=*? Möglich, aber nur in der Kombination mit amenity=*.

Die Suche kann man ausbauen. Was anderes ist entlang der Strasse nach dem Parken zu suchen
und etwas anderes einen überwachten Parking in der Innenstadt.

Ich aktualisierte ukrainische Übersetzung des Proposals und fand etwas interessantes:

http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area#Tagging wrote:

Note: don´t use area:highway = pedestrian because of already existing rendering of highway = pedestrian as area.

Warum sollen wir immer area:highway=<road type> benutzen außer highway=pedestrian? Nur denn der Standart Stil es rendert? Wenn der Standart Stil morgen highway=motorway + area=yes rendern wird, werden wir auf area:highway=motorway verzichten? Das ist aber Quatsch!

Ich vorschlage, nur area:highway=pedestrian zu benutzen, ohne highway=pedestrian + area=yes.
Vielleicht highway=pedestrian + area=yes für "deprecated" erklären.

edward17 wrote:

Ich aktualisierte ukrainische Übersetzung des Proposals und fand etwas interessantes:

http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area#Tagging wrote:

Note: don´t use area:highway = pedestrian because of already existing rendering of highway = pedestrian as area.

Warum sollen wir immer area:highway=<road type> benutzen außer highway=pedestrian? Nur denn der Standart Stil es rendert? Wenn der Standart Stil morgen highway=motorway + area=yes rendern wird, werden wir auf area:highway=motorway verzichten? Das ist aber Quatsch!

Ich vorschlage, nur area:highway=pedestrian zu benutzen, ohne highway=pedestrian + area=yes.
Vielleicht highway=pedestrian + area=yes für "deprecated" erklären.

Es geht nicht nur darum, was gerendert wird und somit auf der Karte sichtbar ist, sondern auch, wie es für andere Zwecke taugt - ich denke hierbei besonders an Routing.

Ein Routing über Plätze (wenn vorläufig auch nur am Rand entlang) ist oft notwendig. Das betrifft Fußgängerzonen genauso wie highway=service und manche Wohnstraße => "echte" Plätze. Deswegen highway=* und area=yes.

Straßenflächen dagegen dürfen als Fläche nicht routbar sein. Wo soll der Router entlangführen? Außenrand, Innenrand, eigentliche Linie? Außerdem wird ein Router in Kurven auf die innere Straßenseite wechseln, wenn ihm das kürzer erscheint - und das nicht ohne störende Ansage. Zumal bei Flächen kein oneway=yes oder punktförmige barrier=* wirken. Deshalb ist es wichtig, die Straßenflächen (area:highway=* für's Auge) von den Plätzen (highway=* und area=yes für's Routing) zu trennen.

Wenn ein Router wegen Plätzen anfangen muss, area:highway=* auszuwerten, kann er diese nicht mehr von den Straßenflächen unterscheiden...

Fazit:

good: highway=pedestrian und area=yes
bad: area:highway=pedestrian
good: area:highway=motorway
bad: highway=motorway und area=yes

Auf keinen Fall ist highway=pedestrian + area=yes "deprecated"! (nur für die übereifrigen Ästheten ohne technischen Bedacht, die gleich das Wiki ändern würden)

Garmin-User,
über Routing über Plätze - ich bin mit dir einverstanden. Nebenbei gesagt: gibt es eine Realisierung?

Aber, wie soll ich die Fläche dieser Straße mappen:
http://www.openstreetmap.org/way/23539477
Auch highway=pedestrian + area=yes? Das finde ich nicht so gut, weil in Realität nur eine Fusgängerstraße existiert, und wir so in OSM-Datenbank zwei entsprechende Objekte haben werden.
Hier ergibt sich auch die Frage, ob man bei solchen highway=pedestrian einen Flächerouting braucht. Meiner Meinung nach nicht. Das ist doch kein Platz! 🙂

edward17 wrote:

Garmin-User,
über Routing über Plätze - ich bin mit dir einverstanden. Nebenbei gesagt: gibt es eine Realisierung?

Aber, wie soll ich die Fläche dieser Straße mappen:
http://www.openstreetmap.org/way/23539477
Auch highway=pedestrian + area=yes? Das finde ich nicht so gut, weil in Realität nur eine Fusgängerstraße existiert, und wir so in OSM-Datenbank zwei entsprechende Objekte haben werden.
Hier ergibt sich auch die Frage, ob man bei solchen highway=pedestrian einen Flächerouting braucht. Meiner Meinung nach nicht. Das ist doch kein Platz! 🙂

Diese Straße ist zwar Fußgängerzone, aber keine Fläche. Also korrekt mit highway=pedestrian, aber ohne area=yes getaggt. Hier dürfte area:highway benutzt werden, um die "Straßen"-Fläche darzustellen.

Das weiter oben zitierte "Note: don´t use area:highway = pedestrian because of already existing rendering of highway = pedestrian as area." trifft dort nicht zu, denn das ist kein highway=pedestrian als Fläche.

Unlogisch ist jetzt einerseits der Vergleich von area:highway=pedestrian + area=yes mit motorway und andererseits das Vorzeigen einer Fußgängerzone ohne area. Das zeigt doch, dass die Problematik noch nicht ganz klar ist.

Garmin-User wrote:

Fazit:

good: highway=pedestrian und area=yes
bad: area:highway=pedestrian
good: area:highway=motorway
bad: highway=motorway und area=yes

Auf keinen Fall ist highway=pedestrian + area=yes "deprecated"! (nur für die übereifrigen Ästheten ohne technischen Bedacht, die gleich das Wiki ändern würden)

Das Problem ist doch (lediglich) das Routing...

Ich verweise mal auf: http://forum.openstreetmap.org/viewtopi … =23129&p=6

Sven

streckenkundler wrote:

Garmin-User wrote:

Fazit:

good: highway=pedestrian und area=yes
bad: area:highway=pedestrian
good: area:highway=motorway
bad: highway=motorway und area=yes

Auf keinen Fall ist highway=pedestrian + area=yes "deprecated"! (nur für die übereifrigen Ästheten ohne technischen Bedacht, die gleich das Wiki ändern würden)

Das Problem ist doch (lediglich) das Routing...

Ich verweise mal auf: http://forum.openstreetmap.org/viewtopi … =23129&p=6

Sven

Das Problem ist die Trennung von Straßenflächen und begeh-/befahrbaren Plätzen. Was die Router mit highway=* und area=yes nicht hinbekommen haben, bekommen sie auch mit area:highway=* nicht hin. Routing wird weiterhin nur auf Linien geschehen. Bei Plätzen könnte ein Renderer für's Routing virtuelle Linien errechnen, eben weil Linien notwendig sind. Wie aber soll der Renderer bei Flächen z.B. die Richtung einer Einbahnstraße bestimmen, wenn deren Rand einen geschlossenen (langgezogenen) "Kreis" darstellt? Oder was ist mit Barrieren, die dann einfach umfahren werden können, obwohl man in echt nicht vorbei käme?

Ich denke, wenn OSM gut und weiterhin interessant sein will, sollte es sich an die üblichen Elemente und deren Vervollständigung/Pflege halten. Besseres Aussehen z.B. durch Straßenflächen kann ein Goody sein, was OSM von kommerziellen Kartenherstellern abhebt. Das sollte aber nicht andere Anwendungsmöglichkeiten (Routing) stören.

streckenkundler wrote:

Das Problem ist doch (lediglich) das Routing...
Ich verweise mal auf: http://forum.openstreetmap.org/viewtopi … =23129&p=6

Garmin-Users Argumente passen schon: Abgesehen vom Aufwand, alle Flächen zu prüfen, ob sie eher ein "Platz" oder ein "Streifen" sind, wäre es schon hilfreich, Flächen mit Verkehr in beliebiger Richtung von Flächen mit gerichtetem Verkehr zu unterscheiden. Da es die beliebigen Richtungen eigentlich nur bei Fussgängerzonen gibt, spielt highway=pedestrian tatsächlich eine besondere Rolle.

Grüße, Max

Abgesehen vom Aufwand, alle Flächen zu prüfen, ob sie eher ein "Platz" oder ein "Streifen" sind, wäre es schon hilfreich, Flächen mit Verkehr in beliebiger Richtung von Flächen mit gerichtetem Verkehr zu unterscheiden.

Deswegen kehren wir wohl zu a:h=pedestrian zurück. Dies soll für "Streifen" gelten. Gleiche Stimmen kamen in dem Poln. Forum.

Im Prinzip ist doch nur die Begründung falsch, warum a:h=pedestrian nicht genutzt werden sollte. Sollte doch eher sein "Note: Don't use area:highway=* for plazas and similiar features. These are desribed by highway=* combined with area=yes. Use area:highway only to add an area representation for linear highways where a way tagged highway=* without area=yes exists. This applies mostly but not exclusively to highway=pedestrian." Oder so.

Lieber errt, ergänze das doch so in dem Proposal. Finde ich gut. Viele Grüße, Marek

Ich hab das (leicht erweitert) mal ergänzt, ich hoffe, das macht es etwas klarer.

Seh gut, ich hab´s gesehen.
Viele Dank Errt!
Grüße,
Marek

Bitte "desribed" durch "described" ersetzen.

Und, was denkt Ihr über Ersetzung "This applies mostly but not exclusively to highway=pedestrian" durch "This applies mostly but not exclusively to highway=pedestrianand highway=footway"?

Ups, Typo. Danke, habs korrigiert.

Ich weiß nicht, footway hab ich jetzt noch nicht so oft als Fläche gesehen. Aber wenn du das für sinnvoll hältst, pass es an - dafür ist es ja ein Wiki 😉

edward17, richtig!
Darf ich Dich um diese Wiki Ergänzung bitten?

Viele Grüße,
Marek

marek kleciak wrote:

Darf ich Dich um diese Wiki Ergänzung bitten?

Ja, natürlich!
Erledigt. Ich habe auch viele {{Tag|<key>|<value>}}-Templates hinzugefügt 😉

Vielen Dank, Leute!

P. S. Ich dachte, dass nur der Autor des Proposals es (oder ihn?) ändern kann. Vielleicht irrte ich mich.

Der Autor des Proposals ist damit voll einverstanden, weil er momentan krank ist und außerdem keiner, der es besser weiß als die Anderen Mapper. Es ist unser gemeinsames Werk.

Der Verkehrsverbund Rhein-Ruhr (VRR) berichtet, dass die neue Version der VRR-App OpenStreetmap-Daten verwendet. So würden detaillierte Haltestellenumgebungspläne angezeigt und Fußgänger-Routing sei ebenfalls möglich.

http://blog.openstreetmap.de/blog/2015/ … iz-nr-267/

Das wäre doch wirklich mal was wo Flächenmapping wirklich einen guten Nutzen hätte.

Gibt es für diese Gegend gute Luftbilder?

Und, was denkt Ihr über Ersetzung "This applies mostly but not exclusively to highway=pedestrian" durch "This applies mostly but not exclusively to highway=pedestrian and highway=footway"?

Ist schon richtig. Eine Fläche, die keine Line hat ( imho quasi nur pedestrian + area ) sollte für sich stehen bleiben. Wichtig wäre dann, das diese Fläche trotzdem vom Renderer der area:highway Flächen mit berücksichtigt wird ( als Fußgängerbereich ). Im Moment werden auch Flächen mit highway=footway und highway=path von der Mapnik gerendert. Hier ist i.d.R. eine Line des footways durch die Fläche getaggt. Jetzt ist die Frage, wie geht man damit um? Es geht z.B. um befestigte Flächen (Plätze) innerhalb eines Parks. Die Fläche highway=footway(path) wäre dann kongruent der Fläche area:highway=footway(path). Natürlich genauso wie die Fußgängerzonen. Hier sehe ich noch Klärungsbedarf.
Eigentlich wäre das kein Problem (für's Renderering und für's Routing), wenn hier die Fläche doppelt getaggt ist. Aber natürlich absolut nicht gerne gesehen und unschön.
Wie gesagt, vielleicht berücksichtigt der area:highway Renderer alle solche Flächen, auch wenn diese nicht mit a:h getaggt sind. Über Oberflächenrendering reden wir noch nicht.

@Marek: Gute Besserung. Obwohl wenig Zeit, vielleicht schaffe ich es in den nächsten Tagen, die deutsche Seite wenigstens etwas aufzuarbeiten ( obwohl für das Proposal nicht gar so wichtig, aber für das Verständnis der deutschen Mapper sehr wohl ). Edit: Sorry, wegen Unpässlichkeiten und Terminen werde ich es leider doch nicht schaffen, obwohl ich es gerne übernommen hätte.

Hier ist es so getaggt, was ich meinte:
http://osmapa.pl/w/areade/?lat=48.7801& … m=18&ol=BP
http://www.openstreetmap.org/#map=19/48.77976/9.18391

Keine wirkliche Fußgängerzone, jedoch befestigte (innerstädtische) Fläche.
Jedoch meine ich: a:h=footway würde hier besser passen.

Ist die osmapa.pl für dieses tagging jetzt auf Baden-Württemberg ausgedehnt?

Rogehm wrote:

Hier ist es so getaggt, was ich meinte:
http://osmapa.pl/w/areade/?lat=48.7801& … m=18&ol=BP
http://www.openstreetmap.org/#map=19/48.77976/9.18391

Keine wirkliche Fußgängerzone, jedoch befestigte (innerstädtische) Fläche.
Jedoch meine ich: a:h=footway würde hier besser passen.

Das ist so ein typisches Beispiel, bei dem highway=(path) + area=yes überhaupt nicht hinpasst. Es handelt sich zwar um "Plätze", jedoch sind für's Routing die Fußwege eingezeichnet. Man braucht dann den Rand dieser Flächen nicht für Routing.

Aber man kann diese bei der Kartenerstellung nicht ausschließen - anderenorts führen Wege aus mehreren Richtungen zum Platz ohne zusätzlich eingezeichnete Wege durch den Platz, die Route würde nicht (am Rand) hindurchführen können. Die Regelsätze gelten schließlich allgemein.

Vielleicht sollte wirklich klar geregelt werden:
Variante 1: Alle Ways sind am Effektivsten als Linie zu mappen (effektiv bedeutet: einfach einzutragen, Daten nutzbar, street-areas lassen sich per Luftbild nachtragen)
Abweichungen:
Variante 2: Plätze (Centerline nicht definierbar) ohne zusätzlich eingetragene Wege bekommen highway=* + area=yes
Variante 3: Straßen-/Wegflächen bekommen die Centerline mit highway=* und die Fläche mit area:highway=*
-Plätze mit Beschränkungen (barrier=*) an Ein-/Ausgängen/-fahrten benötigen als Fläche zwingend Variante 3
-bei motorway, trunk, *ary, *_link, junction=roundabout und Einbahnstraßen nur Variante 1 oder Variante 3 anwendbar
-bei highway=turning_circle Variante 2 oder Variante 3 möglich (etwaigen weiterführenden path/footway korrekt anschließen), Variante 1 immer "unschön"

Das ließe sich auf alle übrigen Straßen-/Wegtypen anwenden - dann braucht man auch keine Ausnahmen zu definieren.

Rogehm wrote:

Hier ist es so getaggt, was ich meinte:

http://www.openstreetmap.org/#map=19/48.77976/9.18391

Die Vorplätze
https://www.openstreetmap.org/browse/relation/5470352
https://www.openstreetmap.org/browse/relation/5470351
https://www.openstreetmap.org/browse/relation/5470353
sind mit area=yes und area:highway getaggt. Letzteres ist IMO eindeutig nicht angebracht.

Soweit ich weiß, ist Baden Württemberg noch nicht gerendert. Die Mapper aus Polen haben nur einen kleinen Server. Wenn jemand einen Server zur Verfügung stellt, können wir ganz DE rendern. Was ist mit OSM.de?

@Marek: Hast recht, es sind wohl erste Renderversuche in Ba-Wü.
Wie erfolgreich der tagging Vorschlag jetzt schon ist, sieht man hier (Abfrage dauert ... );
http://overpass-turbo.eu/s/biF

Demnach sollte man das Proposal recht zügig fertigstellen und zur Abstimmung bringen. Wird wohl eine der großen Erfolgtaggings werden...
Trotzdem sollte man den Mappern es nicht verweigern oder gar verbieten, mögliche area tags zu taggen.
Jetzt heisst es eigentlich, was kann ( deckungsgleich ) als area und als area:highway getaggt werden. Wenn sich beides gegenseitig auschliesst und das nicht geklärt ist, sehe ich erhebliche Pobleme in der anfänglichen Akzeptanz hauptsächlich auf Fußgängerflächen, Radwegen und (noch) Brückenwegen und Treppenwegen. Da muss noch nachgebessert werden.
Die Brückenfläche abzustützen mit man_made=bridge ist die eine Sache, aber es gibt verschiedene Wege darauf. D.h. man_made=bridge gehört überhaupt nicht in dieses Proposal, die Wege auf dieser Fläche dagegen schon.

Rogehm wrote:

@Marek: Hast recht, es sind wohl erste Renderversuche in Ba-Wü.
Wie erfolgreich der tagging Vorschlag jetzt schon ist, sieht man hier (Abfrage dauert ... );
http://overpass-turbo.eu/s/biF

Demnach sollte man das Proposal recht zügig fertigstellen und zur Abstimmung bringen. Wird wohl eine der großen Erfolgtaggings werden...
Trotzdem sollte man den Mappern es nicht verweigern oder gar verbieten, mögliche area tags zu taggen.
Jetzt heisst es eigentlich, was kann ( deckungsgleich ) als area und als area:highway getaggt werden. Wenn sich beides gegenseitig auschliesst und das nicht geklärt ist, sehe ich erhebliche Pobleme in der anfänglichen Akzeptanz hauptsächlich auf Fußgängerflächen, Radwegen und (noch) Brückenwegen und Treppenwegen. Da muss noch nachgebessert werden.
Die Brückenfläche abzustützen mit man_made=bridge ist die eine Sache, aber es gibt verschiedene Wege darauf. D.h. man_made=bridge gehört überhaupt nicht in dieses Proposal, die Wege auf dieser Fläche dagegen schon.

Das Proposal ist, wie ich sehe, doch eindeutig (gegenseitiger Ausschluß).
Probleme sehe ich da überhaput keine, wenn von vorn herein eine klare Linie gefahren wird, und zwar von allen.
Der Unterschied zwischen beiden bzw. deren Anwendung wurde im Forum schon mehrfach verdeutlicht.

Warum im "Applies to:" steht keine {{IconArea}}? Darf ich das korrigieren (also {{IconArea}} hinzufügen)?

Natürlich, es ist ein Fehler.

marek kleciak wrote:

Natürlich, es ist ein Fehler.

Erledigt.

Ich babe mir vorgenommen die Strecke zwischen München und Nürnberg als area:highway zu schließen.
Vielleicht hätte jemand von Euch Lust mitzumachen?
Der momentane Stand:
http://www.osmapa.pl/w/areade/?lat=49.4 … =11&ol=BPN

1022 Mapper verwenden a:h und wir haben über 34.000 a:h Elemente in der Karte.
Ich habe den User Marimil gebeten, in den nächsten Tagen auch Dresden zu rendern; ich habe dort einige a:h Flächen gesehen und die Bing Auflösung ist dort sehr gut.

Grüße,
Marek

das man die zwei linien am straßenbelagrand aber nicht exakt überall parallel machen kann find ich blöd. sowas sollte man mal integrieren, das man ways aneinander fest binden kann und einen abstand setzen. deswegen bevorzuge ich eher width=*, zumindest auf weiter strecke, abseits von orten.

bzgl. Dresden: hier https://www.openstreetmap.org/note/2610 … 6&layers=N und hier https://www.openstreetmap.org/note/273244 gab es dazu auch bereits schon einige Diskussionen

Dresden und Leipzig mit area:highway :
http://www.osmapa.pl/w/areade/?lat=51.1 … =10&ol=BPN

Ein Tipp an die Mapper: Zebra Streifen werden gerendert dort, wo ihr der Linie highway=footway zusätzlich den Atributt footway=crossing verpasst.

marek kleciak wrote:

Ein Tipp an die Mapper: Zebra Streifen werden gerendert dort, wo ihr der Linie highway=footway zusätzlich den Atributt footway=crossing verpasst.

Jede Kreuzung, unabhängig vom Zebra? Fände ich gut, das noch zu ändern, das stört mich an diesem französischen Stil auch immer, obwohl ich die Stylisten bewundere, die Streifen senkrecht zur Strasse aufmalen können, obwohl sie nur einen Node haben 😉

Zebra Streifen Mittellinie (highway=footway +footway=crossing) wird nur dort gezeichnet und als Zebra Streifen gerendert, wo es tatsächlich vorhanden ist.
lanes=* in Verbindung mit turn:lanes ergibt etwa folgendes Bild:
http://osmapa.pl/w/area/?lat=53.42703&l … l=FBoPRQEG

Für das Gebiet Polens wird a:h auch mit dem Wert für surface=* gerendert:
http://osmapa.pl/w/area/?lat=51.09829&l … om=19&ol=s

Habt Ihr gute Texturen bzw. Vorschläge dafür, dann bitte melden.
Grüße,
Marek

marek kleciak wrote:

Habt Ihr gute Texturen bzw. Vorschläge dafür, dann bitte melden.

Man kann existierende area:highway=footway-Texturen für surface=paving_stones nutzen.

Welche Textur dafür nehmen?

@Marek Kann man dieses Proposal nicht mit dem deinem verbinden? Gibt es schon Fortschriite mit dem Proposal Paving_stones? Hab es die Tage nicht mehr verfolgt.

Schöne Grüße an Tordanik.
Es ist sein Proposal. Ich fände es gut.
Viele Grüße!
Marek

Es ist sein Proposal. Ich fände es gut.

Ich auch. Darf ich schon mal einen Link dahin in deinem Proposal hinzufügen?

Aber sicher, gern, fände ich gut. Ich bin nicht der Eigentümer dort.

Es ist sein Proposal.

Ich bin nicht der Eigentümer dort.

Widerspruch? 🙂

Jedem Proposalisten, Proposanten, Proposalerstellern ???? sei seiner Idee gegönnt und man fuhrwerkt nicht ohne Frage herein.

... mach ich wahrscheinlich erst morgen. Danke, Marek.

Na ja, ich weß nicht wie Tordanik das sieht. Ich persönlich habe nichts dagegen wenn man mich informiert und in dem Proposal Dinge ergänzt. Ich mag es nur nicht wenn man den Verfasser nicht informiert.

marek kleciak wrote:

Welche Textur dafür nehmen?

Die Texture, die jetzt für area:highway=footway benutzt werden.

marek kleciak wrote:

Na ja, ich weß nicht wie Tordanik das sieht.

Also mir ist es wichtig, dass die beiden Proposals kompatibel sind, und ich sehe das auch problemlos gegeben. Natürlich kann (und sollte) ein Renderer beides zusammen berücksichtigen.

Dennoch finde ich, dass es gut ist, dafür zwei getrennte Proposals zu haben, weil ich finde, dass ein Proposal sich möglichst um ein Thema kümmern soll (natürlich unter Berücksichtigung von Entwicklungen anderswo), und das dafür gut. Die beiden Themen sind ja auch unabhängig voneinander - man kann Pflaster taggen, ohne gleichzeitig die Straßenfläche einzutragen, und umgekehrt.

Tordanik wrote:

Also mir ist es wichtig, dass die beiden Proposals kompatibel sind, und ich sehe das auch problemlos gegeben. Natürlich kann (und sollte) ein Renderer beides zusammen berücksichtigen.

+1

Auf alle Fälle passen die Proposals zusammen und ergeben mit entsprechenden Rendering auch wirklich Sinn.
Und es ist gut, das beides getrennt abgehandelt wird. Also Arm raus, sich anvisieren und Daumen hoch.
Soll heißen: Bitte arbeitet an ein Gesamtkonzept. Alle gepflasterten Flächen mit entsprechendem Rendering sollte ein Ziel sein, worauf hingearbeitet werden könnte.
@Marek: Habe erst mal nur einen kleinen Link unter "See also" hinterlegt.
@Tordanik: Vielleicht ergreifst du auch die Chance, evtl. dein Vorschlag gerendert zu sehen und berücksichtigst das in deinem Proposal.

Leider gibt es noch sehr minimales tagging mit paving_stones:pattern, und dann noch möglichst in Polen.
Ich habe einen Weg gefunden und diesen mit entsprechenden area:highway ergänzt. Mal sehen, was daraus wird...

... Anh.: Und wird auch schon gerendert, natürlich erstmal nur mit dem Standardmuster. Hier hat der Kollege noch eine Menge Arbeit, wenn er mitspielt und das möchte. Fände ich aber großartig.

Die Strecke München-Nürnberg ist nun halbwegs fertig (Eine Fahrtrichtung, nur zum Teil die zweite)
http://www.osmapa.pl/w/areade/?lat=48.8 … m=8&ol=BPN

Ich habe Marimil gefragt, ob er nun nach Sachsen such Berlin in die Pipeline aufnehmen kann.
Mal sehen.

marek kleciak wrote:

Die Strecke München-Nürnberg ist nun halbwegs fertig.

Worin liegt der Vorteil gegenüber einem "width"-Tag am "highway"-Objekt?

@Marek: Bin böse auf dich! Hättest ja mal mitteilen können, das auch NRW gerendert wird. 🙁 😄
Siehe: http://www.osmapa.pl/w/areade/?lat=50.8 … =17&ol=BPN

Ubrigens: Das Rendering ist in 1 h durch !

1. Dass man den Versatz der Mittelachse zu den Fahrspuren nicht braucht Sehe : http://www.openstreetmap.org/way/319492481.
2. Dass die quer verlaufende Mittelachse der Straße kein falsches Ergebnis liefert. Siehe: http://www.openstreetmap.org/node/267223204
3. Dass die Gabelungen der Straßen richtig wiedergegeben werden.

Grüße,
Marek

Bei komplexen, innerstädtischen Kreuzungen sehe ich einen Informationsgewinn.
Aber bei Autobahnen nahezu konstanter Breite fällt der Nutzen im Verhältnis zum Aufwand doch sehr gering aus.
Welche Anwender sollen die Flächendarstellung der Autobahn nutzen?

seawolff wrote:

Worin liegt der Vorteil gegenüber einem "width"-Tag am "highway"-Objekt?

Es sieht halt in hohen Zoomstufen hübscher aus.

Auswertungen wie: "Zeig' mal alle Bundesstraßen mit einer Breite bis 2 Meter" sind damit natürlich nicht möglich.

Chris

Worin liegt der Vorteil gegenüber einem "width"-Tag am "highway"-Objekt?

Erganzend zu #268 und eigene Meinung:

- Eines der besten Qualitätstools, die ich kenne. Das Flächentagging zwingt einen geradezu, alle Wege und Wegattributte richtig und so genau wie möglich zu taggen.

- Endlich die Integration und der Wandel der 1D-Ways in die (leider noch) 2D-Welt der OSM.

- Endlich ist die korrekte Erfassung der Seitenstreifen / Parkbuchten / Grünstreifen etc. möglich. Das war bisher ein Krampf ohnesgleichen.

- Im weiteren Verlauf lassen sich vielleicht endlich auch Freitreppen, Rampen, Schienenschotter, Strassenlinien (endlich auch die Doppellinie) darstellen. Der weiteren Fantasie ist durch die Realität begrenzt.

- Das einigermaße korrekte Rendering der Straßenfläche, ob Asphalt, Beton, Pflaster oder andere lassen noch viele Spielräume offen, die der OSM bestimmt gut tun und Spaß machen.

Ich bin dabei.

Um weiter Öl ins Feuer zu gießen:
In S3DB 2.0 werden auch folgende Dinge möglich sein: http://wiki.openstreetmap.org/wiki/File … eights.png
Dazu wird die Straßenfläche und die Attributierung von der Mittelachse verwendet.
Eine hervorragende Diplomarbeit zu diesem Thema ist in einem Monat fertig.

chris66 wrote:

Es sieht halt in hohen Zoomstufen hübscher aus.

Schönheit liegt im Auge des Betrachters. Ich finde die Standardkarte hübscher als die von Marek verlinkte Darstellung.
Bei gleichem Füllmuster wäre das Renderergebnis von Mareks Flächen und eine aus der Mittellinie und Breite errechneten Fläche auf vielen Autobahnabschnitten nahezu identisch.

Auswertungen wie: "Zeig' mal alle Bundesstraßen mit einer Breite bis 2 Meter" sind damit natürlich nicht möglich.

Ja, "width" ist immer sinnvoll.

Rogehm wrote:

Worin liegt der Vorteil gegenüber einem "width"-Tag am "highway"-Objekt?

- Eines der besten Qualitätstools, die ich kenne. Das Flächentagging zwingt einen geradezu, alle Wege und Wegattributte richtig und so genau wie möglich zu taggen.

Das verstehe ich nicht. Wieso zwingt mich das Flächentagging "maxspeed", "lanes" oder "access" zu setzen? Erkenne ich dadurch, wenn ein Wegattribut falsch ist?

- Endlich die Integration und der Wandel der 1D-Ways in die (leider noch) 2D-Welt der OSM.

Was ist dein Wunschziel? Jede Asphaltschicht und jeder Bordstein als 3D-Objekt? ;-)

- Im weiteren Verlauf lassen sich vielleicht endlich auch Freitreppen, Rampen, Schienenschotter, Strassenlinien (endlich auch die Doppellinie) darstellen. Der weiteren Fantasie ist durch die Realität begrenzt.

Bei vielen Freitreppen und einigen Rampen ist eine Flächendarstellung sicherlich sinnvoll.
Die Schotterfläche lässt sich durch die Mittellinie des Gleises und eine Breite sehr gut beschreiben.
Strassenlinien lassen sich m.E. sinnvoller als Eigenschaft des "highways" angeben und auswerten.
Ich befürchte, du siehst OSM eher als Malprogramm, denn als Geodatenbank.

- Das einigermaße korrekte Rendering der Straßenfläche, ob Asphalt, Beton, Pflaster oder andere lassen noch viele Spielräume offen, die der OSM bestimmt gut tun und Spaß machen.

Das verstehe ich auch nicht. "surface" wird auch ohne Flächen als Eigenschaft gesetzt und ausgewertet.

@seawolf: Meine Antwort mal ohne den "Zitat"-Wahnsinn.

- mit dem Tag width muß jedesmal der Weg unterbrochen werden, wirklich nur sinnvoll bei Engstellen und kleinen Straßen.
Daher wird dieser Tag sinnvollerweise auch dort hauptsächlich angewendet. Die eigentlichen Breiten aller Standardstraßen werden wohl niemals erfasst werden in einzelne Abschnitte und jedesmal mit dem Maßband nachgemessen. Da ist die Flächenerfassung über Sat-Bilder deutlich sinnvoller. Die Straßenbreite ergibt sich automatisch durch das Flächenzeichnen.

- Qualitätstool deswegen, weil im Hinblick einer späteren, deutlich verbesserten Darstellung der Fläche ( mit einem vielleicht neuen Renderer oder dem bisherigen in Zukunft ) alle möglichen Oberflächenstrukturen dargestellt werden können. Das erzwingt eine sehr genaue Erfassung der Flächen sowie der Way-Lines mit den wichtigen Attributen und weiteren (z.B. Pflaster) in der Zukunft, um alles korrekt darzustellen.
Natürlich sind solche Dinge wie maxspeed und access nicht Ziel dieser Darstellung, soll es aber auch nicht sein. Wichtig ist die 1:1 Darstellung der Wirklichkeit, damit stimmt es wieder. Die OSM soll die Wirklichkeit widerspiegeln.

- Wunschziel: Ja! Alles so genau darstellen, wie es geht, auch in 3D, eben wie es der momentane Stand der Technik und Möglichkeiten zulässt.

- Malprogramm: Nein. Alle Möglichkeiten nutzen. Die Kombination aus Spiegel der Erdoberfläche und seinen ganzen Eigenschaften, die man dort nicht sieht, sollte wohl das oberstes Ziel der OSM sein. Oder habe ich da was ganz falsch verstanden.

- Surface wird erfasst und ausgewertet. Das soll alles so bleiben und zusätzlich wird es demnächst und jetzt schon visualisiert.

- Ich gebe zu, die jetzige Visualisierung über den Server von Marimil ist noch lange nicht optimal, z.B. stört das Abdecken der Namen. Aber hier stehen wir ja noch am Anfang eines langen Weges. Und ich finde, der Weg ist das Ziel....

Rogehm wrote:

die jetzige Visualisierung über den Server von Marimil ist noch lange nicht optimal, z.B. stört das Abdecken der Namen. Aber hier stehen wir ja noch am Anfang eines langen Weges. Und ich finde, der Weg ist das Ziel....

So ist das. Ich finde es toll, was ein einziger Autodidakt auf die Beine gestellt hat, aber ich vermisse hier Vorschläge, Skizzen, wie man es besser machen kann. Vor Allem aber wundert mich, dass wir in Deutschland niemanden finden der ein Server zur Verfügung stellt, damit wir endlich ganz Deutschland rendern können.

Moin,

ich finde die "Straßenmalerei" 😉 ja auch in vielen Bereichen sinnvoll - um nicht zu sagen - notwendig.
Wie z.B. in besiedelten Bereichen, bei Verzweigungen allgemein (auch auf Autobahnen) - also überall da, wo es unregelmäßig wird.

Aber wie seawolff sehe ich keinen nennenswerten Vorteil bei km-langen gleichmäßigen Abschnitten - sei es nun Autobahn oder Landstraßen - also jedenfalls keinen rechten gemessen am Aufwand.

Da müsste ein Renderer auch mit tags am way zurecht kommen können.
Ich sehe allerdings auch ein, dass es da in den Übergangen zu Darstellungsproblemen kommen kann, die sich aber durch entsprechendes Positionieren an dieser Stelle minimieren lassen.

Gruß
Georg

marek kleziak wrote:

Für das Gebiet Polens wird a:h auch mit dem Wert für surface=* gerendert:
http://osmapa.pl/w/area/?lat=51.09829&l … om=19&ol=s
Habt Ihr gute Texturen bzw. Vorschläge dafür, dann bitte melden.

Leider finde ich die ausgewählte Textur absolut nicht passend. Dort ist unbehauenes Natursteinpflaster getaggt, besser wäre cobblestone:flattened.
Man findet sicher genug OpenSource Texturen im Netz. z.B. hier: http://opengameart.org/textures oder hier: http://www.texturemate.com/
oder hier: http://www.goodtextures.com/
Pflaster z.B. http://www.goodtextures.com/group/111/floors-plain.html
Lizenz / Open Source müsste noch geprüft werden.

marek kleciak wrote:

Rogehm wrote:

die jetzige Visualisierung über den Server von Marimil ist noch lange nicht optimal

Ich finde es toll, was ein einziger Autodidakt auf die Beine gestellt hat, aber ich vermisse hier Vorschläge, Skizzen, wie man es besser machen kann.

Als technische Visualisierung eines Tags ist die Karte gut geeignet, als Universalkarte ungeeignet.

Ausgehend von der üblichen Mapnikkarte würde ich folgende Verbesserungen der Straßendarstellung sehen:
1. breitere Straßen in Z=18-19
2. Straßenbreite in Abhängigkeit von "lanes" und "width" in Z=17-19
3. Darstellen von "area:highway" als Fläche gleicher Farbe unter dem highway in Z=17-19
(d.h. man sieht die Flächen meist nur als Ausrundungen in Kreuzungen)
4. Darstellung weicher Übergänge bei Änderungen von "lanes" in Z=17-19
Der Nutzen nimmt von 1-4 ab, der nötige Aufwand nimmt zu.

Eine Darstellung von "area:highway" unter dem highway ist natürlich viel aufwändiger als ein Overlay.

@Rogehm: bei Autobahnen wird meist derselbe Regelquerschnitt verwendet. Eine Überprüfung alle 10-20 km aus dem Luftbild genügt. Nur dort, wo sich die Spuranzahl ändert, muss man auch "width" anpassen. Das wäre sehr viel einfacher als Mareks Flächenmalerei gewesen und zudem viel wartungsfreundlicher.

Du siehst offenbar eine Karte mit möglichst natürlicherer Textur als Qualitätsmaßstab und möchtest dafür einfache, geometrische Objekte (Asphaltfläche, Doppellinie) in die Datenbank schreiben. Das ist aber nur ein (selten nachgefragtes) Produkt einer Geodatenbank und nicht das oberstes Ziel von OSM. Andere Karten (Universalkarten mit Farbcodierung der Straßenklassen, Eisenbahnkarten, Lärmkarten) oder Anwendungen wie Routing erfordern andere Daten.

Deshalb verwendet OSM ein eher funktions- als oberflächenbasiertes Datenmodell. In Einzelfällen kann es sinnvoll sein, dieses durch Flächen als Hilfsobjekte für den Renderer zu ergänzen, etwa bei breiten Freitreppen oder komplexen Kreuzungen. Allgemein wird sich das Flächenmodell für Straßen aber nicht durchsetzen.

@seawolf: Alles richtig, was du sagst. Außer

Allgemein wird sich das Flächenmodell für Straßen aber nicht durchsetzen.

Ich möchte klarstellen, das ich nicht der Ansprechpartner von diesem Tagging in DE West bin, habe auch noch keinerlei Autobahn dahingehend getaggt. Dort ist es ja so wie im wirklichen Leben. Rauf auf die Bahn, runterspulen, wieder runter. Da braucht's kein kompliziertes Flächentagging. Wichtig wären imho innerstädtische Bereiche, Altstadt - schmale Gassen und Strassen, sehr verwinkelte und komplizierte Durchfahrten. Insbesondere die ergänzende Information für den LKW-Verkehr, der ja in der letzten Zeit durch fehlerhafte Navis Schlagzeilen gemacht hat. Inwieweit sich die Informationen dahingehend auswerten lassen, ist wohl noch Zukunftsmusik.
Weiterhin Parkmöglichkeiten entlang der Straße, und Darstellung der Fahrbahnmarkierungen, wobei ich darauf hinarbeiten werde, die wichtigsten wie z.B. die Doppellinie ins tagging mit aufzunehmen.
Weiterhin, nicht gar so wichtig, aber informativ für jederlei Person: Die Erfassung und Visualisierung der Surfaces. Auch nur einfache Parkwege oder Freizeitgelände. Halt erstmal dort, wo es für viele Menschen wichtig ist, genaue Informationen zu erhalten: Wie sieht es dort aus? Kann ich mit meiner Beweglichkeit und Möglichkeiten dort entlang? Das gilt für Pflasterflächen, geteerte Zoowege, Freitreppen und, und, und.
Kurz gesagt: Die Erfassung der Fläche von Wegen liegt bei mir schwerlastig im nichtmobilen Bereich, also nicht Strassen sondern Wege.
Ein Fahrzeug kommt mit jedem Navi zurecht, der auch nur visuell andeutungsweise den Weg vorgibt. Ein Rollstuhlfahrer dahingehend möchte "sehen", was auf ihm zukommt. Und die Tages- und Freizeitplanung aller hängt ab von den Informationen, die man erreichen kann.
OSM ist gut dafür geeignet, wenn man die Türen aufmacht für noch mehr Infos, noch mehr Karten... die auf jedermann zugeschnitten sein können. Das eigentliche Problem: Die OSM ist immer noch zu unbekannt!!! Und nur durch erweiterte Features, die sonst keine Karte anbietet, wird diese DB erfolgreich weitergeführt werden können.
... leider sehe ich hier nur wenige Anhänger dieser, noch theoretischen, OSM-Science Fiction. Aber der Beginn ist gemacht!

Rogehm wrote:

Wichtig wären imho innerstädtische Bereiche, Altstadt - schmale Gassen und Strassen, sehr verwinkelte und komplizierte Durchfahrten.

+1

Rogehm wrote:

Das eigentliche Problem: Die OSM ist immer noch zu unbekannt!!! Und nur durch erweiterte Features, die sonst keine Karte anbietet, wird diese DB erfolgreich weitergeführt werden können.

Ich würde das "nur" in "nur durch erweiterte Features" streichen. Könnte man nicht auch Otto Normalkartenleser dadurch überzeugen, dass OSM auch für ihn Vorteile hat durch

• Aktualität (zumindest in manchen deutschen Ballungszentren, aber auch in manchem kleinen Ort sind wir GM und Co. doch schon sichtbar überlegen, oder?)
  
• Genauigkeit (hier gilt genau dasselbe)
  
• Abdeckung (in sog. 3.-Welt-Ländern sind GM und Co. doch oft sehr dürftig, OSM mancherorts schon eher brauchbar)?
  

Aber das wird OT, sorry. Was bleibt: ja, vielleicht könnte das Mappen schwieriger Örtlichkeiten mit Straßen als Flächen auch für die Bekanntheit von OSM hilfreich sein; aber obwohl ich sehr mit dem Straßen-Flächen-Mapping sympathisiere, glaube ich, dass wir Otto Normalkartenleser und Erika Musterfrau eher durch Aktualität, Genauigkeit und evtl. noch Abdeckung überzeugen. (Ach ja, und dann ist natürlich das Routing wichtig, das Otto und Erika leider nicht von den Kartendaten unterscheiden können, sondern damit identifizieren, sodass unser Default-Router auf osm.org doch ein wichtiges Aushängeschild ist und noch besser werden muss ...)

(Edit: Typos entfernt)

Seawolff wrote:

Allgemein wird sich das Flächenmodell für Straßen aber nicht durchsetzen.

Lieber Freund Seawolff, meine prophetische Kräfte lassen ein Wenig nach, daher kann ich nicht urteilen, ob Du Recht hast. Ich kann hier nur von dem Wahnsinn berichten die Stercke Nürnberg - München als a:h zu zeichnen.

1. Erste Überraschung: Die Autobahnbreite variiert bei gleicher Anzahl der Fahrspuren. Es ist nicht viel, etwa die Breite des Trennstreifens, trotzdem ist es da. Fü autonom fahrende Fahrzeuge kann dies schon wichtig sein.
2. Ich schwöre, ich habe es versucht: Die Breite der Autobahn zu messen. Keine Chance. Selbst um 03.30 fahren dort Autos.
3. Auf der Strecke Nürnberg München fand ich nur 3 bis 4 Abschnitte wo mir das Mapen langweilig wurde und wo ich gesagt hätte: lass mal hier mit width arbeiten.

Was bringt mir das auf der Autobahn: noch nie die Schreie der Freundin erlebt die kreischt, links, links LINKS NEEEIN doch RRRREECHTS? Einer der Mapper der ein Kommentar in der a:h Diskussionsseite eine Spur hinterlassen hat schrieb zurecht, dass dieses Schema gewisse Änderungen in der bisheriger Herangehensweise voraussetzt. Generell werden, wenn man den a:h Vorschriften folgt, die Punkte an denen eine Gabelung beginnt, viel früher beginnen als bisher.

Sonst geht das Mappen der Autobahnen deutlich schneller als der Kreuzungen in einer Stadt. Auch wenn a:h in der Stadt viel wertvoller ist als auf der Autobahn.

Viele Grüße,
Marek

@Marek: #282 +1
Bist ja richtig gut drauf. Scheint wohl Spaß zu machen, Autobahnflächen zu erfassen. Mit meinem Kleinkram komme ich wirklich nur stückelsweise weiter, weil vorher noch viele Korrekturen zu machen sind. Wer sich auf dieses Thema einlässt, sollte das komplette OSM-Straßen-Tagging beherrschen (inkl. deinem) und muß extrem genau arbeiten. Ich glaube, von meinem Motto: "Gut schätzen und mappen" muss ich mich wohl verabschieden. Aber es gibt zum seelischen Ausgleich ja auch noch massenweise ungetaggte ways in anderen europäischen Ländern (z.B. Spanien).

Anh.: Ich glaube, beim Autobahn-Flächen Tagging müsste man sich auch um den Seitenstreifen kümmern (shoulder=*). So passt das nicht.
Leider ist dieses tag nicht gepflegt und nur als älteres Proposal im OSM Wiki. Dass passt so nicht mit der Gesamtfläche der Autobahn.

Übrigens: Berlin ist jetzt drauf.
Hier war jemand fleißig:
http://www.osmapa.pl/w/areade/?lat=52.5 … =12&ol=BPN

Danke!

Ich habe einen kurzen Abschnitt zum Thema Mapping Vorschriften hizugefügt.
Es geht darum, wann junction=y_junction verwendet wird und welche Auswirkung auf dies auf das Rendern von Lanes haben soll:
http://wiki.openstreetmap.org/wiki/Prop … g_of_lanes

Übrigens: Berlin ist jetzt drauf.

Dafür ist NRW wieder raus. Nur noch Restfragmente. Schade. Bei den wenigen Usern, die sich damit beschäftigen, könnte man eigentlich auch ganz DE rendern. Auch wenn nicht mehr viel zu sehen, den Rendering Fehler mit dem überbreiten Gehweg kann ich mir nicht erklären: http://www.osmapa.pl/w/areade/?lat=50.8 … =19&ol=BPN
Vielleicht abwarten. Leider nervt das switchen der gerenderten Länder etwas. Ich weiß, der Server....

Ich habe einen kurzen Abschnitt zum Thema Mapping Vorschriften hizugefügt.
Es geht darum, wann junction=y_junction verwendet wird und welche Auswirkung auf dies auf das Rendern von Lanes haben soll...

Das heißt, wenn man mit der junction-Fläche etwas in die Nebenstraße geht, um saubere Ubergänge zu haben oder Stand-(Ampel-) Linien gleichzeitig zu erfassen, würde keine Mittellinie gerendert werden?
Schön wäre auch, darauf hinzuarbeiten, genauere Mittellinien zu rendern.

Erg. Vielleicht ist es sogar sinnvoll, in diesem Tagging die Doppellinie, die ja auch auf den Sat Layern zu sehen ist, als eigene Linie zu taggen und damit "nur" innerhalb der hiesigen Renderer dargestellt wird.. Vorschlag (als Fläche und Linie): area:highway=double_line oder als area:highway=emergency_(double_)line

P.S. Ich habe mal die Wiki in den jeweiligen See also / See back ergänzt. Bitte darauf achten, das man die tagging-Vorschläge "zusammenhält".

marek kleciak wrote:

Übrigens: Berlin ist jetzt drauf.
Hier war jemand fleißig:
http://www.osmapa.pl/w/areade/?lat=52.5 … =12&ol=BPN

Danke!

Ich habe mich bisher zum Thema zurückgehalten, weil meine Meinungsbildung zum "sieht nur schön aus" und "bringt was für Auswertungen" noch nicht ganz abgeschlossen ist. Jedoch halte ich es für unzureichend, wenn nur die Flächen akribisch erfasst werden und man großzügig über weitere für das routing erforderliche Details hinweg sieht.

Warum werden z.B. hier https://www.openstreetmap.org/edit#map= … 3/13.51473
die turn:lanes an den highways nicht gleich mit erfasst? An anderen Stellen sieht das zum Glück anders aus. Gerade in Innenstädten fehlen allzu oft die turn:lanes. Aber gerade dort werden sie eher benötigt als etwa auf Autobahnen.

@Marek:
Ich will den Thread nicht kapern, wollte aber nur mal auf die Notwendigkeit weiterer Daten neben area:highway hinweisen, damit ein echter Mehrwert entsteht. Dazu gehören auch Ampeln, Zebrastreifen uvm. 😉
Leider sehe ich auch die Darstellung der turn:lanes auf der deutschen Version z.B. hier http://www.osmapa.pl/w/areade/?lat=51.3 … =17&ol=BPN nicht, obwohl sie erfasst sind. 🙁

Ich muss den Marimil bitten, in DE auch die turn:lanes zu rendern.
Für mich ist das Thema a:h unzertrennlich mit der Erfassung von lanes, turn:lanes, Zebrastreifen und Ampeln verbunden.
Egal wo ich mit a:h Mapping angefangen habe, fand ich irgend Etwas was fehlte.
So gesehen finde ich in dieser Art zu Mappen auch die Chance, Mängel zu endecken und zu beheben, die sonst kaum auffallen.

Hallo Leipzig, klasse:
http://www.osmapa.pl/w/areade/?lat=51.3 … =17&ol=BPN

Danke und Grüße!

Marek

Ich habe in den a:h mapping guidelines auf ein Problem hingewiesen:
http://wiki.openstreetmap.org/wiki/Prop … ralel_ways

Möglicherweise erreichen wir an diesem Wochenende die Zahl von 40.000 gemappten a:h.

Ich habe in den a:h mapping guidelines auf ein Problem hingewiesen

Hier widerspricht man sich aber. Bei baulich nicht getrennten ways sollte doch keine verschiedene Fahrtrichtungen, also gerichtete ways getaggt sein. (Die kurze Schraffur - was ja eigentlich area:highway=emergency wäre - macht hier Probleme?).
Das es dieses tagging oft gibt und daraus wieder getrennte Fahrflächen gemacht werden sollen, erschwert die Angelegenheit. Rein theoretisch müsste man die Mittellinie (einfach oder doppelt) ja doch irgendwie in dieses tagging Schema mit aufnehmen - ist ja nichts anderes als eine emergency area, dann eben nur als line. Und wenn diese emergency line zusätzlich attributiert wird während des Flächentagging, kann der Renderer die Information daraus ableiten.

Beitrag geändert.

Rogehm wrote:

marek kleciak wrote:

Ich habe in den a:h mapping guidelines auf ein Problem hingewiesen

Hier widerspricht man sich aber. Bei baulich nicht getrennten ways sollte doch keine verschiedene Fahrtrichtungen, also gerichtete ways getaggt sein. (Die kurze Schraffur - was ja eigentlich area:highway=emergency wäre - macht hier Probleme?).

Nun, wir haben ja außer area:highway auch lanes und turn:lanes. Diese richtig in dem von mir gezeigten Beispiel zu taggen ist eine ziemliche Herausforderung. Es wird viele einfacher, auch weniger Fehleranfällig sein, wenn man diese Wege getrennt mappt. Auch ein entsprechedes Taggingschema für area:highway wäre in solchen Fällen sehr komplex, befürchte ich.

Wir haben schon über 40.000 a:h Elemente in der Datenbank.
1074 Mapper beteiligten sich an dem a:h Mapping.

Hat noch jemand Fragen, Zweifel, Hinweise, Vorschläge bezüglich a:h?
Ich denke wir könnten irgendwann abstimmen.

marek kleciak wrote:

... Es wird viele einfacher, auch weniger Fehleranfällig sein, wenn man diese Wege getrennt mappt. Auch ein entsprechedes Taggingschema für area:highway wäre in solchen Fällen sehr komplex, befürchte ich.

...

Ich hatte einmal vorgeschlagen, statt der ganzen turn:lanes und restrictionen im Detail einer Kreuzung die einzelnen Spuren zu mappen (highway=lane). Das wäre einfach, entsprechend der Wirklichkeit und fehlerunanfällig, da Router diese highways auch zum routen nutzen.
(http://wiki.openstreetmap.org/wiki/File … swalde.png) - obere Bildreihe mit "Spuren"

turn:lanes-User: Sorry, wenn ich wieder einmal davon anfange, aber in Detailbereich einer Kreuzung könnten ways als "lanes" (oder wie auch immer) mehr Übersicht bringen.

a:h geht ein Wenig in diese Richtung. Ist also in meinen Augen eine Zwischenstufe zu der Lösung, die Du vorgeschlagen hast. Wir haben momentan zu wenig Luftbilder in guter Auflösung um überall einzelne Spuren zu mappen.

Interessant: betrachtet man z.B. diese Kreuzung: http://www.openstreetmap.org/way/368373068
dann wird man sehen, dass der, "klassische" OSM Generalisierungsansatz hier nicht zutrifft.
Generalisierte OSM Karte führte an dieser Stelle für diejenigen die diese Gegend nicht kennen immer wieder dazu, dass die Fahrer falsch abgebogen sind. Leider habe ich die vorherige Version als Screeenshot nicht gespeichert.

geri-oc wrote:

...
Ich hatte einmal vorgeschlagen, statt der ganzen turn:lanes und restrictionen im Detail einer Kreuzung die einzelnen Spuren zu mappen (highway=lane). Das wäre einfach, entsprechend der Wirklichkeit und fehlerunanfällig, da Router diese highways auch zum routen nutzen.
(http://wiki.openstreetmap.org/wiki/File … swalde.png) - obere Bildreihe mit "Spuren"

turn:lanes-User: Sorry, wenn ich wieder einmal davon anfange, aber in Detailbereich einer Kreuzung könnten ways als "lanes" (oder wie auch immer) mehr Übersicht bringen.

Ich dachte, das Thema wäre ausdiskutiert und diese deine Meinung hat sich nach meiner Wahrnehmung nicht als mehrheitsfähig heraus kristallisiert. Deshalb erspare ich mir, all die Argumente, welche gegen die Einzelerfassung der lanes als way sprechen, zu wiederholen.

Weshalb du jetzt hier im Thread zu Flächen wieder damit anfängst, erschließt sich mir ebenfalls nicht.

Ich denke auch dass der Zug erst Mal abgefahren ist.
Bei turn:lanes haben wir knapp 140.000 Elemente in der Karte.
http://taginfo.openstreetmap.org/keys/turn%3Alanes
Wichtig ist mir, dass die Mapper die Vorteile von turn:lanes in Kombination mit a:h sehen.

Marimil überarbeitet gerade die a:h Karte und möchte auch in DE die turn:lanes auf dieser Karte visualisieren.
Angekündigter Termin: zweite Novemberhälfte.
Also bitte fleißig beides mappen 🙂

marek kleciak wrote:

...
Bei turn:lanes haben wir knapp 140.000 Elemente in der Karte.
http://taginfo.openstreetmap.org/keys/turn%3Alanes
...

Das sind aber nur die turn:lanes. An *forward und *backward kommen noch mal über 110.000 hinzu. 😉
guggsdu http://forum.openstreetmap.org/viewtopi … 24#p559324

Edit: Grobmotorisch bedingte Schreibfehler 🙄

Umso besser. Es wäre schön, Bereiche die mit turn:lanes gut abgedeckt sind und gute Luftbilder haben, auch mit area:highway zu erfassen. Wenn ich der Karte: http://taginfo.openstreetmap.org/keys/turn%3Alanes#map glauben soll, ist das vor Allem Deutschland und Polen.

marek kleciak wrote:

Umso besser. Es wäre schön, Bereiche die mit turn:lanes gut abgedeckt sind und gute Luftbilder haben, auch mit area:highway zu erfassen. Wenn ich der Karte: http://taginfo.openstreetmap.org/keys/turn%3Alanes#map glauben soll, ist das vor Allem Deutschland und Polen.

Du hast nicht ganz unrecht, wenn man bedenkt, dass sich die turn:lanes in USA über eine größere Fläche verteilen. Die ersten vier sind aktuell:

Statistik wrote:

Austria 10004
Germany 124325
Poland 21387
United States of America 23358

Wie sieht das mit a:h Mapping für einzelne Länder aus?
Grüße,
Marek

marek kleciak wrote:

Wie sieht das mit a:h Mapping für einzelne Länder aus?
Grüße,
Marek

Da muss ich mal schauen 🤔
Meine Daten zu turn:lanes stammen von Netzwolf, den wir ja leider hier vergrault haben. Zum Glück lässt er seine Auswertungen noch laufen.
Vielleicht kann dir da einer unserer Auswertungs-Gurus da weiterhelfen. Mir fehlt dazu Equipment und knowhow.

Ich wäre sehr traurig wenn wir den lieben Netzwolff vergrault hätten.
Es ist ja normal, dass wir in einem so komplexen Projekt unterschiedliche Meinungen zu verschiedenen Themen haben. Die Diskussionen unter alten Mapper sollten ja eher sachbezogen und nicht persönlich sein.

Viele Grüße,
Marek

marek kleciak wrote:

Ich wäre sehr traurig wenn wir den lieben Netzwolff vergrault hätten.
Es ist ja normal, dass wir in einem so komplexen Projekt unterschiedliche Meinungen zu verschiedenen Themen haben. Die Diskussionen unter alten Mapper sollten ja eher sachbezogen und nicht persönlich sein.

Viele Grüße,
Marek

Das wir ihn vergrault haben, ist wohl von mir etwas pauschal gesagt. Ich erinnere mich an die damalige Diskussion. Wenn wer auch immer so mit mir in der Forumsöffentlichkeit umgesprungen wäre, hätte ich wohl ähnlich reagiert.Er schweigt hier zwar konsequent. Aber gänzlich ohnes Interesse an OSM auch hier im Forum scheint er nicht zu sein.
Auch ich vemisse seine sachliche und fachlich fundierte Art, sich hier einzubringen.

Unser Kollege Netzwolff hat die Frage gestellt, in welcher Reihenfolge man die a:h erfassen sollte.
Nun denke ich, dass vor Allem die Kreuzungen die als gefährlich in einer Stadt gelten, die kann man schnell googeln.
Danach die innenstädtischen motorway, primary, trunk road Kreuzungen. Bis man bei den secondary und tertiary roads ankommt wird dies wohl eine Weile dauern.

marek kleciak wrote:

Unser Kollege Netzwolff hat die Frage gestellt, in welcher Reihenfolge man die a:h erfassen sollte.
Nun denke ich, dass vor Allem die Kreuzungen die als gefährlich in einer Stadt gelten, die kann man schnell googeln.
Danach die innenstädtischen motorway, primary, trunk road Kreuzungen. Bis man bei den secondary und tertiary roads ankommt wird dies wohl eine Weile dauern.

Und wenn ihr schon dabei seid, schaut doch bitte gleich nach, ob die Fahrspuren, Ampeln und Zebrastreifen vollständig und richtig erfasst sind. Ohne die ist die Information über die Flächendarstellung nur halb so viel (oder noch weniger) wert. Kreuzungen sind meist nur gefährlich, weil Ortsunkundige Orientierungsprobleme haben bei der Suche, wie es wo weitergeht.

http://wiki.openstreetmap.org/wiki/Prop … allel_ways

Due to the recent approach not physical street dividers are ignored.
For instance:
http://wiki.openstreetmap.org/w/images/ … Lanes0.jpg
This mapping makes advanced lane rendering impossible.

warum können wir so nicht machen?

Solange das den Regeln widerspricht, muss man es aus "mapping guidelines" entwerfen. Meiner Meinung nach ist es besser, diese "Kapitel" gar nicht schreiben, als schlechtes Beispiel zeigen.

+1 wobei ich a:h=divider besser fände.

edward17 wrote:

warum können wir so nicht machen?

Es wird halt zunehmend schwerer zum auswerten. Daher würde ich darum bitten, wenigstens kein Multipolygon anzulegen.

Sieh Dir bitte diese Strasse an:
https://www.openstreetmap.org/way/223981874
teoretisch müsste man sie in der Mitte mit der Straße https://www.openstreetmap.org/way/364988566 verbinden und daraus eine Strasse machen. Es gibt aber viele Mapper die sagen, dass sich das für eine so kurze Strecke sich nicht lohnt und die Karte ist übersichtlicher, wenn man diese Straße genau so zeichnet, wie sie gezeichnet ist.

Die Frage, wie lange müssen solche Strecken sein, damit man sie miteinander verbindet ist eine Grauzone.
Für solche Abschnitte würde ich den existierenden Vorschlag empfehlen.

Es gibt noch ein weiteres Problem: Das richtige Taggen solch komplexer Strecken mit lanes und turn:lanes. Es ist sehr einfach hier Fehler zu machen. Und das richtige Rendern von lanes ist kaum möglich:
Im Gegensatz zu den komerziellen Karten fehlt uns hier nämlich in der lanes Definition der Übergang. Hätten wir die Kategorie "Gabelung" von z.B. zwei lanes zu drei für eine Strecke, dann wäre das Problem vom Tisch.

marek kleciak wrote:

Sieh Dir bitte diese Strasse an:
https://www.openstreetmap.org/way/223981874
teoretisch müsste man sie in der Mitte mit der Straße https://www.openstreetmap.org/way/364988566 verbinden und daraus eine Strasse machen. Es gibt aber viele Mapper die sagen, dass sich das für eine so kurze Strecke sich nicht lohnt und die Karte ist übersichtlicher, wenn man diese Straße genau so zeichnet, wie sie gezeichnet ist.

Die Frage, wie lange müssen solche Strecken sein, damit man sie miteinander verbindet ist eine Grauzone.
Für solche Abschnitte würde ich den existierenden Vorschlag empfehlen.

Es gibt noch ein weiteres Problem: Das richtige Taggen solch komplexer Strecken mit lanes und turn:lanes. Es ist sehr einfach hier Fehler zu machen. Und das richtige Rendern von lanes ist kaum möglich:
Im Gegensatz zu den komerziellen Karten fehlt uns hier nämlich in der lanes Definition der Übergang. Hätten wir die Kategorie "Gabelung" von z.B. zwei lanes zu drei für eine Strecke, dann wäre das Problem vom Tisch.

Eine Straße:
Es fehlt eine durchgezogenen Linie - sogar Doppellinie wird als eine Straße behandelt. Warum an kurzen Stücken "Ausnahmen" machen? Es wird mit Detailmapping immer schwieriger alles an einen way zu taggen - auch die Auswertung wird dadurch auch nicht einfacher.

Klar ist es verständlicher, wenn der Verlauf dem tatsächlichen Verlauf entspricht - aber das ist in OSM nicht gewollt.

Ich bin der Meinung den tatsächlichen Verlauf zu mappen - auch sollten z.B Verkehrsinseln als Fläche mit getrennten ways gemappt werden (dürfen) - und nicht wegen Navis nur als node in den way.

Hier sind aber flüchtig betrachtet noch Fehler:

- an der südöstliche Parkplatzstraße fehlt die Verbindung zu der nördlichen "Fahrbahn".
- am nördlichen Radweg fehlt m.E. foot=yes (oder taggen wie südlichen way)

Tordanik wrote:

edward17 wrote:

warum können wir so nicht machen?

Es wird halt zunehmend schwerer zum auswerten. Daher würde ich darum bitten, wenigstens kein Multipolygon anzulegen.

Warum denn?
Und handelt es sich nur um Multipolygone mit inner-Teilnehmern oder um überhaupt alle Multipolygone?

edward17 wrote:

Tordanik wrote:

edward17 wrote:

warum können wir so nicht machen?

Es wird halt zunehmend schwerer zum auswerten. Daher würde ich darum bitten, wenigstens kein Multipolygon anzulegen.

Warum denn?
Und handelt es sich nur um Multipolygone mit inner-Teilnehmern oder um überhaupt alle Multipolygone?

Also es geht mir konkret nur um Straßenflächen und Multipolygone mit inner-Teilnehmern.

Für meine Zwecke ist die Haupt-Herausforderung bei Straßenflächen das Berechnen von Spuren in der Fläche. Das ist an sich schon recht herausfordernd, weil man ja in einer Fläche erst mal keine Richtung hat. D.h. man muss auf Basis der Highway-Ways eine Liniensequenz der Fläche zuordnen (wobei es Stolperfallen gibt, wie z.B. einmündende Wege ohne junction area), und dann die Fläche praktisch umrechnen in einen Breitenverlauf längs der Straßenlinie. Machbar ist es denke ich. (Sicher weiß ich das erst, wenn ichs mal programmiert habe.)

Wenn jetzt aber noch Multipolygone hinzukommen, erschwert sich diese Aufgabe nochmal. Dann stellt sich ja z.B. die Frage, welche Spuren rechts und welche links am Loch vorbeigehen. Auch wird die Spurberechnung (weil die Spuren ja nicht als Geometrie eingezeichnet sind) sicher nicht hundertprozentig mit den Löchern etc. zusammenpassen. Letztlich wird so halt ein bereits anspruchsvolles Problem nochmal schwerer und kaum mehr sauber zu lösen.

Ich hoffe ich habe das einigermaßen verständlich beschrieben...

Den Einwand von User edward17 kann ich durchaus nachvollziehen.
Ich habe ein (nicht mehr ganz frisches) Beispiel aus München (schon 2012 von Marek).
Hier muss (müßten) eine Durchfahrt, innere Parkflächen und innere Sperrflächen gleichzeitig zum a:h getaggt werden. Lohnt hier eine Aufsplittung der a:h, um ein MP mit "inner" Flächen zu vermeiden?
http://www.osmapa.pl/w/areade/?lat=48.2 … =18&ol=BPN
Ich meine auch, das durchaus MP mit Inner "verbaut" worden sind in der letzten Zeit, finde es jedoch nicht auf Anhieb (Polen?).
Und wenn MP nicht gewollt sind, sollte das eindeutig im Proposal beschrieben werden.

Das würde ich von dem Straßentyp abhängig sehen. Eine Residential mit 2 Fahrspuren ohne Mittelstreifen würde ich nicht mit lanes rendern wollen, sprich auch so lassen wie sie in dem obigen Beispiel ist. Und bei größeren Straßen erübrigt sich meistens diese Frage.

Lass uns Mal nach weiteren "kniffligen" Beipielen suchen.

Bitteschön: Ein MP mit inner in Nürnberg.
http://www.osmapa.pl/w/areade/?lat=49.4 … =18&ol=BPN

Erg.: Ich bin der Meinung, innerhalb dieses Schemas sollten MP mit "Inner" Anteilen nicht "verboten" werden. Manchmal ist es fast gar nicht anders lösbar. Es handelt sich ja auch nicht um komplexe MP. Und die Straßen- und Wegeführung bleibt ja erhalten. Hier braucht niemand irgendwelche Routingfunktionen. Man kann letztlich vielleicht irgenwann mal die Fläche mit den Way-Routing visuell, z.B. in einer zukünftlichen App, vereinen und sieht die Straßenflächen (womöglich in 3D) mit den entsprechenden Spuren und Hindernissen.... (Science Fiction OSM)

Auch in Hamburg sind nun die a:h sichtbar:

http://www.osmapa.pl/w/areade/?lat=53.5 … =19&ol=BPN

OsmAnd unterstützt Darstellung von area:highway=*:
http://wiki.openstreetmap.org/wiki/File … _2.2.2.png
Vielleicht kann dieses Beispiel in entsprehende Teil des Proposals (nähmlich hier) hinzugefügt werden.

Hoffentlich kann man das auch irgendwo wieder abschalten. 😉

Ist das Absicht, diese Flächen auch mit Namen zu versehen, so wie hier? Wenn ja, welchen der beiden bei junction=yes?

Falls der Name dran bleiben soll, müsste man beim Rendern berücksichtigen, dass man den wieder wegbekommt, sonst steht der an jeder Strasse mehrmals:

Grüße, Max

Nein, Namen haben jetzt an a:h nichts zu suchen. Das sind wohl noch alte Daten, zu Anfang wollten wir noch die Namen dran haben.

marek kleciak wrote:

Nein, Namen haben jetzt an a:h nichts zu suchen.

Fein, danke. Finde ich gut. Man könnte beim Rendern die Flächen nämlich zusammen mit den "highway=* area=yes" abarbeiten. Das wäre billig zu haben, aber dort sind Namen in der Regel erwünscht und eine extra Regel für area:highway wäre dann schon wieder weniger billig.

Nein, Namen haben jetzt an a:h nichts zu suchen.

Habe die Namen in den a:h Bereichen der Grusonstr. mal gelöscht ( Marek war hier fleißig ) und die Beschreibung dahingehend ergänzt.
Man sollte alle Bereiche noch mal durchsuchen mit a:h und name. Z.B. hierüber http://overpass-turbo.eu/s/d0X . Und dann aufräumen.

gibt es eigentlich ein "werkzeug" womit man bei straßenflächen eine exakte parallelität immer wieder herstellen kann, falls die verschoben wurde, ähnlich dem rechtwinklig machen bei gebäuden (taste q)?

Chenshi wrote:

gibt es eigentlich ein "werkzeug" womit man bei straßenflächen eine exakte parallelität immer wieder herstellen kann, falls die verschoben wurde, ähnlich dem rechtwinklig machen bei gebäuden (taste q)?

Nö, so nicht. Die Straßen haben Kurven. Die Stoßkanten zum nächsten a:h sind beliebig schräg. Einzig die parallele Linie (JOSM Shift+P + Potlatch Funktionsfläche unten rechts) lässt sich auch mit Kurven realisieren. Dann muss man diese als Fläche und mit dem nächsten area verbinden.

Landesamt für Vermessung Lodz hat mir die Außenkanten Strasse für Lodz / Polen als dxf Daten versprochen. Mal sehen ob dies die Arbeit beschleunigt. Falls ja, könnte man hierzulande um entsprechende Datensätze fragen.

Sorry...

Ich jedenfalls kann mit diesen Darstellungen wie hier:
http://www.osmapa.pl/w/areade/?lat=49.4 … =18&ol=BPN
überhaupt nichts anfangen!

Erst machen wir aus dummen Luft"bilder" "Karten": wir erfassen linienhafte Strukturen, abstrahieren diese zu Straßennetzen, garnieren dies mit POIs, etc...
Jetzt wird mit einer unglaublichen Akribie jede Verbiegung des Bordsteines erfasst (ich hätte weder Lust noch Zeit dazu) und es entstehen wieder "Bilder". Keine Straßennamen und Klassifizierungen mehr zur Orientierung?
Zudem werden die Konstrukte in ID immer schlechter bearbeitbar. Klar, JOSM punktet hier mit Ausblenden, aber wie sehr muss man sich da erst einarbeiten...

Mir erschließt sich der Mehrwert dieser Arbeit nicht 🙁

Ich weiß nicht, ob man diese Anstrengungen nicht besser in Gebiete auf der Welt stecken sollte, wo die Straßen (und Karten) noch gänzlich fehlen...

..., aber macht was ihr wollt.

..., aber macht was ihr wollt.

Genau. Und OSMAND (V2.2) spielt ja jetzt auch mit.
Heute wollte ich mal ein Problem in Österreich / Schweiz ansprechen. "Begegnungszonen"
Siehe http://forum.openstreetmap.org/viewtopic.php?id=52926

Hier sind wohl alle Verkehrsteilnehmer gleichberechtigt. Jeder muss Rücksicht gegeneinander aufzeigen. Fußgänger sind natürlich die schwächste "Verkehrsgruppe". Es gibt ein besonderes Verkehrszeichen. Und es gibt keine Gehwege. Also prädestiniert für eine Straßenfläche.
Einzige Voraussetzung maxspeed=20 und alle sind brav.
Leider gibt es kein eigenes Tag für diese Flächen. Sieht jemand eine Möglichkeit, diese in das a:h Tagging zu integrieren? Es gibt leider kein spezielles highway-tag. Die Schweizer haben dies meist mit living_street gelöst, womit A nicht ganz so glücklich ist.
Ich finde, als Verkehrsfläche gehört dies unbedingt in die a:h tagging group.

Anh.: Vielleicht könnte man sich auf einen unbekannten Way- Tag einigen, um diese evtl. Fläche hier aufzunehmen.
z.B. area:highway=road, solange es keinen eigenen tag gibt.

P.S. Ach, gibt es doch schon. Sorry, übersehen. Hat jemand andere Ideen?

Rogehm wrote:

Hat jemand andere Ideen?

a:h sollte immer denselben Wert haben wie der h. Falls die Österreicher sich entschließen sollten, einen neuen highway-Wert einzuführen (was ich für keine gute Idee halte), dann geht damit automatisch ein neuer a:h-Wert daher. Solange eine solche Straße aber als living_street o.ä. getaggt ist, gilt das natürlich auch für den a:h.

Wann geht dieser Vorschlag http://wiki.openstreetmap.org/wiki/Prop … treet_area in Vote start? RFC start: steht seit 15.08.2015

changchun_1 wrote:

Wann geht dieser Vorschlag http://wiki.openstreetmap.org/wiki/Prop … treet_area in Vote start? RFC start: steht seit 15.08.2015

Vermutlich nie. Das ist kein Proposal, sondern eher eine Sammlung teils sinnvoller und teils unausgereifter Vorschläge.
Der RTC ist durch die vielen inhaltlichen Ergänzungen ohnehin überholt.
Der ältere Vorschlag area:highway wäre dagegen recht einfach zur Abstimmung zu bringen.
Zur Zeit scheint das Interesse an dem Thema aber gering zu sein.

Ekhm,
gerade gestern hatten wir die Zahl 50.000 area:highway überschritten.
1227 Mapper haben zuletzt area:highway gemappt.

http://taginfo.openstreetmap.org/search … %3Ahighway

@marek: Ja, das ist ein tolles Ergebnis. Eigentlich ein Selbstläufertagging. Aber gibt es schon Server für die visuelle Bereitstellung zumindest in Eu?
Ich denke, daran haperts. Leider auch, weil zu wenig Verbesserungen eingereicht werden.
Ich denke, wir sollten Marek unterstützen und uns als DE-Community hier stärker einbringen (Wiki / Server / Verbesserungsvorschläge ).
Im Moment ist es für die Abstimmung noch zu früh.
@marek: Kann der polnische Server nicht noch mehr DE-Bundes-Länder unterstützen? Durch den recht geringen Zugriff sollte das doch eher nicht das Problem sein. Umso eher kommt man dem Ziel näher.

Erg.:

sewolf wrote:

Vermutlich nie. Das ist kein Proposal, sondern eher eine Sammlung teils sinnvoller und teils unausgereifter Vorschläge.
Der RTC ist durch die vielen inhaltlichen Ergänzungen ohnehin überholt.

Das ist nicht ok. Das Tagging ist wohl durchdacht. Vielleicht sollte man eine gewisse "Formulierungsstraffung" für das eigentliche Proposal hinbekommen. Aber das hatte ich oben schon erwähnt.

marek kleciak wrote:

gerade gestern hatten wir die Zahl 50.000 area:highway überschritten.
1227 Mapper haben zuletzt area:highway gemappt.

Ich gehöre zu diesen Mappern. "area:highway" ist auch kaum umstritten.
Würde jemand das Proposal von flaimo wieder aktivieren, könnte die Abstimmung in vier Wochen (vermutlich erfolgreich) beendet sein.
Die sonstigen Ideen in deinem Proposal verhindern, dass man darüber abstimmen kann.

seawolff wrote:

Die sonstigen Ideen in deinem Proposal verhindern, dass man darüber abstimmen kann.

Lieber Seawolff,
ist Deine Meinung.
Die Hauptdifferenz zwischen meinem und Flaimo´s Proposal sind nach wie vor Kreuzungsbereiche aufgeteilt in junction = <yes /y_junction/roundabout>.
Dies ist der "Kern der Erfindung".

Du hast im letzten Jahr vorgeschlagen, wenn ich mich recht entsinne, dass man aus meinem Proposal den Abschnitt: Lane dividers along the street entfernt um die Abstimmung zu vereinfachen.
Das kann man machen, ansonsten gibt es gute Gründe für diese Komplexität.

Lieber Rogehm,
leider hat sich die Situation nicht verändert. Der Marimil, der den Renderer geschrieben hat, ist jederzeit bereit die Software zur Verfügung zu stellen, wenn jemand ein Rendering Server zur Verfügung stellt. Der Server von Marimil ist zu klein dafür.

Viele Grüße an Euch beide!
Marek

Hallo,
jemand hat mich wegen a:h angesprochen. Vielleicht geht es in einigen Wochen mit dem Rendering von area:highway für ganz Deutschland. Mal sehen..

Ich stehe dieser Art des Mappings noch sehr skeptisch gegenüber...

Solche Darstellungsfehler sind hoffentlich noch "Kinderkrankheiten", oder?

Natürlich. Momentan macht der Renderer von Marimil "nur" das Rendern von area:highway als Fläche. Die gerenderten Flächen werden auf die darunter liegenden Kachel gelegt. Dadurch verschwinden Teile der Beschriftung.

Das Ziel ist aber die a:h in den Hauptrenderer in den Zoomlevel 19 bzw auch 18 einzubauen. Dann verschwinden solche Artefakte.

Zu dem Nutzen von area:highway - Welcher Navi Display wäre für den Fahrer mehr ansprechbar, A oder B ?
Sehe: http://wiki.openstreetmap.org/wiki/File … ighway.jpg

Grüße,
Marek

marek kleciak wrote:

Zu dem Nutzen von area:highway - Welcher Navi Display wäre für den Fahrer mehr ansprechbar, A oder B ?
Sehe: http://wiki.openstreetmap.org/wiki/File … ighway.jpg

Marek, da bin ich Oldschool - B!
Vermutlich weil ich immer noch mit einem GPSMAP60 zu Fuß, mit dem Fahrrad, dem Motorrad und dem Auto proma klarkomme 🙂

Diese vorgesetzten pseudo 3D Ansichten kann mein Geodätenkopf schneller aus 2D Informationen herleiten. So denke ich immer noch, was will der Künstler mir alles sagen?
Geneigte ebene Ansichten enthalten nun mal nicht mehr Informationen als orthogonale Ansichten, außer perspektivische Verzerrungen.

Ich bevorzuge auch B

B.

Auf einem Navi-Display würde ich mich für A entscheiden.

Allerdings fehlt in dem Beispiel ja noch das Drum-Herum... also Rad-,Fußwege und Hintergrundflächen. Aber rein vom Prinzip bevorzuge ich eine Ansicht die die Gegebenheiten der Straße so anzeigt wie sie real vorhanden sind. Am Computer, wenn ich Zeit habe - bevorzuge ich die andere Darstellung (als Kartenansicht).

marek kleciak wrote:

Zu dem Nutzen von area:highway - Welcher Navi Display wäre für den Fahrer mehr ansprechbar, A oder B ?
Sehe: http://wiki.openstreetmap.org/wiki/File … ighway.jpg

B ist ansprechender.
Beim Navigieren soll die Straßenführung so einfach wie möglich und dadurch mit kurzem Blick schnell erfassbar sein. Flächen sind da unpraktisch, weil das Gehirn mit Verarbeitung einer weiteren Dimension beschäftigt wird.

Garmin-User wrote:

Flächen sind da unpraktisch, weil das Gehirn mit Verarbeitung einer weiteren Dimension beschäftigt wird.

Wo ist denn da eine weitere Dimension? Die gelbe Straße ist auf dem Display doch auch eine gelbe "Fläche"... Es ist halt einfach nur eine stilisierte Fläche.

Im übrigen sehe ich es genau anders herum - Während ich auf auf einen Blick sehe wie die Straße in Version A verläuft, muss ich bei Version B das stilisierte Bild im Kopf erst wieder aufwendig auf die Realität abbilden. Bei Version A guck ich auf's Display und sehe das, was ich (aus anderem Blickwinkel) auch in der Realität sehe.

Aber es gibt ja grundsätzlich verschieden arbeitende Gehirne ;-)

firstAid wrote:

Garmin-User wrote:

Flächen sind da unpraktisch, weil das Gehirn mit Verarbeitung einer weiteren Dimension beschäftigt wird.

Wo ist denn da eine weitere Dimension? Die gelbe Straße ist auf dem Display doch auch eine gelbe "Fläche"... Es ist halt einfach nur eine stilisierte Fläche.

Im übrigen sehe ich es genau anders herum - Während ich auf auf einen Blick sehe wie die Straße in Version A verläuft, muss ich bei Version B das stilisierte Bild im Kopf erst wieder aufwendig auf die Realität abbilden. Bei Version A guck ich auf's Display und sehe das, was ich (aus anderem Blickwinkel) auch in der Realität sehe.

Aber es gibt ja grundsätzlich verschieden arbeitende Gehirne ;-)

Ich befinde mich gedanklich beim Fahren immer am "Momentan"-Punkt und fahre eine Linie (die im Grunde der Breite meines Autos entspricht). An ungewöhnlichen Kreuzungen mit mehreren Möglichkeiten kann man Linien, die sich zudem an einem zentralen Punkt treffen, schnell abzählen. Wenn die Kreuzung samt Straßen als Fläche dargestellt werden, überblickt man das nicht mehr, insbesondere wenn der automatische Zoom greift.

Zur "weiteren Dimension"...
Schnelle Punkt-Linien-Auffassung: "Man befindet sich hier und muss da lang."
Weitere Dimension: "Wo auf der Fläche befindet man sich und wie muss man die Fläche durchqueren um dahin zu kommen."

Ich glaube, wenn die Anzeige zu exakt an der Realität ist, ist man zuviel mit (unbewussten) Vergleichen beschäftigt - ein Abkoppeln der reinen Navigations-Informationen wird schwerer.

Garmin-User wrote:

Ich glaube, wenn die Anzeige zu exakt an der Realität ist, ist man zuviel mit (unbewussten) Vergleichen beschäftigt - ein Abkoppeln der reinen Navigations-Informationen wird schwerer.

Möglich. Spontan würde ich sagen Ansicht A ist besser - aber du hast schon auch recht, denn wenn ich mir jetzt noch die Radwege, die Fußwege und und und als Flächen vorstelle, wird es wieder schwieriger.

Nun, ich muss euch Recht geben. Wenn das Umfeld einer Karte 2-D ist, hat das Gehirn Schwierigkeiten, annähernd "gewohnte" Ansichten mit der 2D Umgebung zu vermischen und muss eindeutig mehr Aufwand (Denkarbeit) leisten, um das sinnvoll umzusetzen. Im allgemeinen lehnt der Mensch jede übermäßige Anstrengung des Gehirns ab ( "Ist mir viel zu anstrengend, auf das Navi zu schauen....; Da bekommt man ja Kopfschmerzen...; etc...").
Wichtig wäre, eine Verbindung des a:h tagging mit einer 3D OSM Welt hinzubekommen, was ja noch etwas 'Zukunftmusik' ist, aber keineswegs unrealistisch. Stellt euch mal die F4 Map mit den a:h gerenderten Straßen vor. Hier ein kleines Video, wo das Gehirn gar nicht viel tun braucht, weil alles so leicht umsetzbar ist.

Hi all,

Sorry to write this in English, but it will take me to much effort to do this in German. As there is much discussion in this thread about the usefulness and possibility of area:highway=x rendering, I thought I would share some of the latest development work on my ArcGIS Renderer for OpenStreetMap (not yet publicly available).

It shows two example areas of the city of Szczecin, Poland, located near the Poland/Germany border, and for the second image with the large flyovers an extra Google Maps comparison.

The rendering shows area:highway features tagged and rendered with surface=x, which means the rendering will show differentiation based on surface, e.g. "asphalt" or "sett". Unfortunately, since most of the area:highway features tagged and digitized in this area are main roads consisting of asphalt, you won't see much differentiation, except the small areas forming the "Mazurska" residential road in the lower right part of the first image. Besides rendering of area:highway features, you can also see the renderer fully resolving man_made=bridge as areas based on the layer=x tag in the second image of the large road junction near the Oder / Odra river. Based on test-renderings of the area, I discovered issues with the layer=x tagging of the road lines and road areas and bridges at this large junction, and actually went in to correct this using JOSM, allowing you to see the this correctly resolved.

The rendering of area:highway only kicks in at high zoom and large scale, before that, you just see the normal road classification. I have chosen to display surface over road classification, as I think it adds something new at large scales (>1:2500), and at these large scales and highly zoomed in, road classification starts to become less important. Thus, showing surface is really nice I think.

There is one exception to the surface=x based rendering: area:highway features tagged as area:highway=cycleway are rendered as an overlay layer together with "emergency" road markings in a flat muted red color. This is because I think clearly showing them as cycleways is far more important than knowing the actual surface. Most of the area:highway=cycleway features added as areas, will be in cities anyway, and paved by default in some way, so "surface" is less important than the fact that you can actually easily spot them on the map by their reddish color.

Anyway, I noticed a lot of area:highway features currently lack a surface=x. I know there has been written about the possibility of automatically deriving this information from the corresponding line element, but frankly, knowing this would entail global scale geoprocessing operations on millions upon millions of features, I think this is unrealistic, and then I am not even considering the problems with way and area features not exactly matching at end points / nodes.

I therefore would like to encourage everybody to at least, as a minimum, to additionally add surface=x to area:highway features.

Marco Boeringa
The Netherlands

Wow, good job Marco.
I will try to add the surface indormation in Szczecin together with mapper d3mol3k.

mboeringa wrote:

I know there has been written about the possibility of automatically deriving this information from the corresponding line element, but frankly, knowing this would entail global scale geoprocessing operations on millions upon millions of features, I think this is unrealistic, and then I am not even considering the problems with way and area features not exactly matching at end points / nodes.

It is true that copying some tags to the areas would help with some less complex use cases. However, this is not a panacea, as some information cannot be simply copied (in particular, anything way direction dependent). So we have to take care to make sure that ways and areas can be matched.

The proposal does currently enable this, so this is not meant as a criticism. I simply wanted to point out that these operations are not "unrealistic", but actually necessary – at least for some use cases, including accurate lane rendering.

Tordanik wrote:

It is true that copying some tags to the areas would help with some less complex use cases. However, this is not a panacea, as some information cannot be simply copied (in particular, anything way direction dependent). So we have to take care to make sure that ways and areas can be matched.

Hi Tordanik,

Yes, I actually fully concur with your observations. In fact, to enable the proper rendering of the traffic junction with flyovers in Szczecin example, I did just that: I made sure ways and areas matched by fixing "over-" or "undershoots" (not exactly the right term here), and connecting up through common nodes, and fixing layer tagging as well. One extra thing I encountered, and that extents upon what is already documented: it would be desirable to also closely match up man_made=bridge features with area:highway=x and highway=x features, as otherwise the layered rendering of bridges may interfere with the display of area:highway or highway features (or the other way around depending on how you look at it...).

That said, my main concern was and is that it is probably difficult or impractical, even in a perfect situation, to fully automatically derive area attributes from ways based on common nodes or overlapping geometry topology.

Adding surface=x, as you also point out as being a "less complex use case", solves the main dilemma's. Actually, I think with surface, we have the main tag useful for area rendering anyway. There is not much sense in adding attributes like speed, access restrictions directly to an area, since the most common and accepted visualizations for these type of attributes is line. This is different for surface=x, as traditionally large scale maps, e.g. in the form of GIS or CAD files, typically list and show surface as the main attribute of areas of roads.

Tordanik wrote:

The proposal does currently enable this, so this is not meant as a criticism. I simply wanted to point out that these operations are not "unrealistic", but actually necessary – at least for some use cases, including accurate lane rendering.

As argued above, I agree it would be desirable to properly follow the tagging guide lines as described at the area:highway pages, especially the "Mapping guidelines":

http://wiki.openstreetmap.org/wiki/Prop … guidelines
http://wiki.openstreetmap.org/wiki/Prop … treet_area
http://wiki.openstreetmap.org/wiki/Prop … ea:highway

Weder surface noch den Straßentyp sollte man an der Fläche angeben. Dies sind redundante Informationen, die nur zu Unstimmigkeiten führen. Der Renderer kann diese Information dem Weg entnehmen, wenn korrekt gemappt wurde. Wenn unvollständig gerendert wird, falls falsch gemappt wurde, hilft dies, die Qualität zu erhöhen.
Wenn man area:highway=residential bis area:highway=motorway durch area:highway=carriageway ersetzt,
Die bisher verwendeten Werte mögen für anfänglichge Renderingexperimente sehr hilfreich gewesen sein, jedoch halte ich sie als dauerhafte Lösung für strukturell unpassend.
Es wäre im Editor viel einfacher zu handhaben, wenn man nur einen Fahrbahnfläche hätte. Es ist nur ein Preset erforderlich und es erscheint kaum möglich, verschiedene Fahrbahnflächentypen je nach Straßentyp im Editor sinnvoll zu rendern, was die Eingabe fehleranfälliger machen würde.

Eine Ausnahme sehe ich allerdings. Es wäre durchaus sinnvoll, surface für Teilflächen definieren zu können. Beispiele:

• eine Asphaltstraße, die in Straßenmitte wegen einer Straßenbahn Plastersteine hat
• ein betonierter Bushaltestellenbereich
• eine alte Straße mit Sommerweg
• Gepflasterte Kreuzungsbereiche

In der Regel werden dies aber zusätzliche überlagerte Flächen sein müssen. Ich denke, diese fehlen noch im Proposal. In manchen Fällen mag auch mal die Junction-Fläche dazu geeignet sein.

Zwischendurch haben wir 63000 area:highway Elemente in OSM.

Es wäre vielleicht an der Zeit über Rendering dieser Elemente in Mapnik nachzudenken.

Oder?

marek kleciak wrote:

Es wäre vielleicht an der Zeit über Rendering dieser Elemente in Mapnik nachzudenken.
Oder?

Meine Meinung: bitte nicht!
Die Lesbarkeit der Kartendarstellung ist in meinen Augen schlechter. Ich halte es für eine Spezialdarstellung im Lageplandesign.

Dies soll sich auf die höchste Zoomstufe beschränken und ist in meinen Augen besser.

Vergleiche:
http://wiki.openstreetmap.org/w/images/ … proach.JPG

mit
http://wiki.openstreetmap.org/w/images/ … opViev.JPG
(allerdings ohne Namen rendern an den Kanten).

Dieser Vorschlag wurde bereits realisiert. Wir rendern schon man_made=bridge in der Karte.

Der Rest wäre nur eine logische Fortsetzung.

marek kleciak wrote:

Dieser Vorschlag wurde bereits realisiert. Wir rendern schon man_made=bridge in der Karte.

Schon, sieht aber nicht schön aus. Objekte auf der Brücke (in diesem Fall die Gleise), sollten auch AUF der Fläche zu sehen sein und nicht von ihr fast überdeckt.

Hier sieht es besser aus: http://www.openstreetmap.org/#map=19/51 … 4&layers=N. Gefällt mir aber auch noch nicht so richtig, weil die Brückpfeiler die Brücke ja nicht unterbrechen, sondern diese auf den Pfeilern aufliegt.

In Mapnik ist aber auch man_made=brigde (schöner): http://www.openstreetmap.org/#map=18/50.94151/6.96614

Du siehst in der obigen Skizze ein Mockup von dem Proposal.
Umgesetzt wurde dies so, wie Du schreibst.
Sehe z.B.: http://www.openstreetmap.org/#map=19/52.51878/13.40224

In ZL 19 und meinetwegen auch 18 fände ich es praktisch. Wer so weit reinzoomt, will keine Übersicht haben, sondern Details, und dann sollte das Rendering auch die exakten Straßenränder hergeben, wenn die Datenbank sie hat.

Unterhalb stört es niemanden, wenn die Straßen Linien fixer Breite bleiben. Ich finde sie in Mapnik generell zu breit seit dem letzten Update. Dicht benachbarte, unverbundene Straßen wie die hier (die B 14 / B 19 bleibt unten, die K 2573 steigt nach Süden stark an) verschmelzen mir in kleineren Darstellungen schon zu leicht.

--ks

+1.

Ich habe eine Skizze gemacht, wie die a:h in jetzigem level 19 aussehen könnte:

http://wiki.openstreetmap.org/wiki/File … dlines.jpg

Waren nicht schon einmal die lanes:* im Zoom 19?

Ja, schon. Nur denke ich, sollen wir erst Mal überhaupt eine Fläche zeichnen.
Es ist kein Hexenwerk.

Ich hab da ein Farbvorschlag gemacht: https://github.com/gravitystorm/openstr … -246173053

marek kleciak wrote:

Ich habe eine Skizze gemacht, wie die a:h in jetzigem level 19 aussehen könnte:
http://wiki.openstreetmap.org/wiki/File … dlines.jpg

Wenn es so in Z19 angezeigt wird, ist es erträglich.
Persönlich würde ich eine helleres Grau bevorzugen und die linienförmigen Straßen/Informationen auf der Fläche, zwecks besserer Lesbarkeit, darstellen.
Dann hat die Straßenfläche was von Landuse/Landcover.

Etwa so: http://wiki.openstreetmap.org/wiki/File … Bright.jpg ?