Unsinniges Routing bei highway=* mit area=yes

hurdygurdyman wrote:

Da sind nicht nur die Spuren mit highway=* einzeln erfasst, sondern auch noch mehrere higway=primary mit area=yes für mehrspurige Bereiche und auf Brücken mit gemeinsamen nodes.

Da kann man nur sagen: Garbage in - Garbage out. 😉

Osmand kann nicht simulieren

wenn Du mit simulieren eine offline-Routenberechnung von A nach B meinst (ohne GPS),
doch das kann er.

hurdygurdyman wrote:

Ich sehe da nur den Ausweg, diese area-highways mit access=no vom routing zu verbannen und die Wiki entsprechend zu ändern. Das area-tagging werden wir wohl nicht verhindern können. Vielleicht kann da auch QA-Tool helfen.
Mapfactor habe ich schon informiert.
Hat jemand schon ähnliche Erfahrungen mit anderen Routern dazu? Ist access=no eine Lösung?

Trash!
Aber OSM ist ja eine Spielwiese. 😉
Regeln sind ja verpönt.

chris66 wrote:

wenn Du mit simulieren eine offline-Routenberechnung von A nach B meinst (ohne GPS),
doch das kann er.

Bin nicht der große Osmand-Kenner. Wie?

Long-click on Map (B) : Ziel setzen, Long-click on Map (A) : Route von hier.

Radeln wrote:

...
Trash!
Aber OSM ist ja eine Spielwiese. 😉
Regeln sind ja verpönt.

Stimmt. Eigentlich stehts da http://wiki.openstreetmap.org/wiki/DE:Key:area unter Straßenflächen deutlich:
Wenn Strassen mit area=yes getagged werden wird davon ausgegangen, dass keine Strassenlinien darin verlaufen, d.h. innerhalb der Fläche gibt es keine Richtung). Beachte: Zur Zeit gibt es keinen Konsens, wie Strassen (ausser highway=pedestrian), welche mit area=yes bezeichnet sind interpretiert werden sollen.
Sollte man das nicht noch klarer ausdrücken. Ich stelle mir folgenden Zusatz vor:
Werden Straßenflächen erfasst, auf denen Straßenlinien verlaufen, muss die Straßenfläche zusätzlich mit acces=no getaggt werden, um fehlerhaftes routing über deren Außenkanten zu verhindern.
Entsprechende Verweise an anderer Stelle machen wohl auch Sinn.

Nein, für Straßenflächen soll das dafür vorgesehenen area:highway genutzt werden. 😎

chris66 wrote:

Long-click on Map (B) : Ziel setzen, Long-click on Map (A) : Route von hier.

Danke, habe es probiert.
Osmand erzeugt auch eine Route über die Bordsteinkanten und Brückengeländer 🤣 😠 🙄
edit:
...und schlägt eine vierte linke Spur vor 🤔

Ohne in Tagginschemata eingreifen zu wollen: Es gibt Routingalgorithmen über Flächen. Die sind wohl in OSM nicht implementiert.
Das Problem solcher Algorithmen sind aber die Einbahnstraßen. Für Indoor Mapping wäre das aber nicht verkehrt.
Stellen wir uns einen runden Innenhof in einem Einkaufszentrum un den kürzesten Weg zwischen 2 Punkten.
Wäre der Routing schlau, suchte er nach direkter Verbindung beider Punkte über area=yes...

chris66 wrote:

Nein, für Straßenflächen soll das dafür vorgesehenen area:highway genutzt werden.

Ist aber erst ein Proposal http://wiki.openstreetmap.org/wiki/Prop … ea:highway

Wäre der Routing schlau, suchte er nach direkter Verbindung beider Punkte über area=yes...

Das ist klar, beim vorliegenden Fall hat schlicht der Mapper den Unterschied zwischen ungerichteten Plätzen(area=yes) und
gerichteten Straßenflächen(area:highway) nicht verstanden.

bei (a) sollte ein Router den kürzesten Weg innerhalb der Fläche suchen, bei (b) die Fläche ignorieren und
über den Vektor routen.

chris66 wrote:

Nein, für Straßenflächen soll das dafür vorgesehenen area:highway genutzt werden. 😎

Dann wäredas Tagging highway=pedestrian + area=yes wohl hinfällig.

hurdygurdyman wrote:

Leider haben OSRM, OpenRouteService, Cloudmade oder mapquest hier kein aktuelles Material, um in diesen den Fehler nachvollziehen zu können, und Osmand kann nicht simulieren.

OSRM sagt: "data: 121009 06:59Z"
Openrouteservice: "OSM-Data for Routing: 11.03.12"
Cloudmade hat tatsächlich mal wieder aktualisiert (dem Rendering nach), irgendwann mal nach nach Juni.
Mapquest hängt gerade auch etwas zurück, datieren kann ich es nicht. Sollten aber nur wenige Wochen sein.
Cloudmade und Mapquest geben als Lizenz noch CC-BY-SA an, sind also auf einem Stand vor der Lizenzumstellung.

OSRM sollte also aktuell genug sein, finde ich 😉

Man muss allerdings beachten, dass Cloudmade und Openrouteservice ziemliche Scheiße zusammenrouten, da sie Turn Restrictions ignorieren und damit fürs PKW-Routing absolut ungeeignet sind (und damit auch alle darauf aufsetzenden Dienste/Apps).
Openrouteservice schimmelt augenscheinlich kräftig vor sich hin, während Cloudmade durch frische Daten wenigstens mal wieder gezuckt hat.

hurdygurdyman wrote:

Radeln wrote:

...
Trash!
Aber OSM ist ja eine Spielwiese. 😉
Regeln sind ja verpönt.

Stimmt. Eigentlich stehts da http://wiki.openstreetmap.org/wiki/DE:Key:area unter Straßenflächen deutlich:
Wenn Strassen mit area=yes getagged werden wird davon ausgegangen, dass keine Strassenlinien darin verlaufen, d.h. innerhalb der Fläche gibt es keine Richtung). Beachte: Zur Zeit gibt es keinen Konsens, wie Strassen (ausser highway=pedestrian), welche mit area=yes bezeichnet sind interpretiert werden sollen.
Sollte man das nicht noch klarer ausdrücken. Ich stelle mir folgenden Zusatz vor:
Werden Straßenflächen erfasst, auf denen Straßenlinien verlaufen, muss die Straßenfläche zusätzlich mit acces=no getaggt werden, um fehlerhaftes routing über deren Außenkanten zu verhindern.

Wäre dann Taggen für den Router.

Dann wäredas Tagging highway=pedestrian + area=yes wohl hinfällig.

Nicht unbedingt. Langgestreckte Fussgängerzonen könnte man mit area:highway+way und große "platzhafte" mit
area=yes ohne zusätzliche ways taggen.

Cobra wrote:

Cloudmade und Mapquest geben als Lizenz noch CC-BY-SA an, sind also auf einem Stand vor der Lizenzumstellung.

Sicher? das nur aus der Attributierung zu schliessen, halte ich für etwas leichtsinnig.
Gruss
walter

wambacher wrote:

Cobra wrote:

Cloudmade und Mapquest geben als Lizenz noch CC-BY-SA an, sind also auf einem Stand vor der Lizenzumstellung.

Sicher? das nur aus der Attributierung zu schliessen, halte ich für etwas leichtsinnig.
Gruss
walter

Darf ich bitten, zum Thema zurückzukommen. Es geht nicht um Datenaktualität. Fakt ist, dass zwei Programme (Navigator Free und Osmand) hier mit den Daten nicht klarkommen.

@ Radeln:
Nein, das ist kein taggen für den router, denn generell ist ja das routen über die Kanten eines highway-areas bisher erlaubt.

hurdygurdyman wrote:

chris66 wrote:

Nein, für Straßenflächen soll das dafür vorgesehenen area:highway genutzt werden.

Ist aber erst ein Proposal http://wiki.openstreetmap.org/wiki/Prop … ea:highway

Die Wahl zwischen einer missbräuchlichen Nutzung eines bestehenden Tags, mit der man sogar Fehler in Anwendungen verursacht, und dem Einsatz eines genau für diesen Zweck gedachten Proposals sollte doch leicht fallen...

Und zu der späteren Anmerkung: Es handelt sich beim Einzeichnen eines Platzes mit access=no, wo eigentlich eine breite Straße verläuft, schon um Tagging für den Router. Denn auch wenn so ein fehlerhaftes Routing verhindert wird, werden Renderer und andere Anwendungen dort immer noch einen Platz zeichnen, statt wie eigentlich korrekt die linienhafte Straße in der Breite an die Straßenfläche anpassen zu können.

(Der Fehler besteht allerdings nicht im Setzen von access=no, was immerhin den Schaden begrenzt, sondern darin, überhaupt highway=* + area=yes statt des zutreffenderen area:highway=* zu verwenden.)

chris66 wrote:

Dann wäredas Tagging highway=pedestrian + area=yes wohl hinfällig.

Nicht unbedingt. Langgestreckte Fussgängerzonen könnte man mit area:highway+way und große "platzhafte" mit
area=yes ohne zusätzliche ways taggen.

Eben, auch in Fußgängerzonen gibt es Straßen und Plätze. Für erstere war "highway=pedestrian + area=yes" noch nie passend (was manche nicht davon abgehalten hat, es zu verwenden); für letztere ist dieses Tagging weiterhin das Mittel der Wahl.

Die Grenze zwischen den beiden Fällen mag im Fall von Fußgängerzonen in Einzelfällen etwas schwierig zu ziehen sein, aber das ändert nicht grundsätzlich etwas daran, dass es zwei Fälle sind.

Dann fasse ich mal zusammen:
area=yes in Verbindung mit highway=* soll zur 2D-Darstellung von Straßenflächen außer bei highway=pedestrian nicht verwendet werden, um unsinniges routing zu verhindern, weil area=yes in diesen Fällen ein routing über die Flächenkanten erzeugen würde. Eine derartige Verwendung fällt unter "Taggen für den Renderer".
Für die 2D-Darstellung von Straßenflächen ist area:higway=* das Mittel der Wahl, auch wenn dies noch im Proposal-Stadium steckt.

Zusatz:
Da ich keine Ahnung habe, welcher Renderer schon area:highway=* auswertet und darstellt, befürchte ich tagging-wars, weshalb das proposal schnellstmöglich zur Abstimmung kommen sollte, um den key dann in der Wiki zu dokumentieren.

Fazit:
Ich fange dann mal an, so etwas wie dieses:
http://www.openstreetmap.org/browse/relation/2390077
entsprechend umzubauen.

Dann ist aber nichts mehr zu sehen, z.B. die Tankstelle südlich, das wird dem Ersteller möglicherweise nicht gefallen

berndw wrote:

Dann ist aber nichts mehr zu sehen, z.B. die Tankstelle südlich, das wird dem Ersteller möglicherweise nicht gefallen

Falsch ist falsch und wo soll denn "Wir taggen nicht für Renderer" greifen wenn nicht in solchen Fällen? Mit dem Ersteller stehe ich in Kontakt und habe auf diesen thread verwiesen. Außerdem möchte ich verhindern, dass irgendwer unbedarft diesen Beispielen folgt, was zwar "schön" anzusehen ist, aber nicht den Konventionen entspricht.

hurdygurdyman wrote:

Fazit:
Ich fange dann mal an, so etwas wie dieses:
http://www.openstreetmap.org/browse/relation/2390077
entsprechend umzubauen.

In dieser Relation http://www.openstreetmap.org/browse/relation/2390077 sind aber auch einige Parkflächen, die als solche erfaßt werden sollten IMHO.

Radeln wrote:

In dieser Relation http://www.openstreetmap.org/browse/relation/2390077 sind aber auch einige Parkflächen, die als solche erfaßt werden sollten IMHO.

Nicht nur dort, aber erst mal werden die Fehler beseitigt und dann wird ein regnerischer Abend ohne vernünftiges Fernsehprogramm (, was ja immer öfter vorkommt,) genutzt. Die Lagegenauigkeit der bing high res ist dort recht gut für's Sofamappen 🙂 Ich weiß sogar welche access=private/customer usw. sind 😉

Moin!

hurdygurdyman wrote:

Dann fasse ich mal zusammen:
area=yes in Verbindung mit highway=* soll zur 2D-Darstellung von Straßenflächen außer bei highway=pedestrian nicht verwendet werden

Auch für andere Werte von highway kann "area=yes" sinnvoll sein, etwas für Wendebereiche in Sackgassen oder Rangierflächen für LKW, allgemein bei ungerichtetem Verkehr.
"highway=residential" mit "area=yes" wird laut taginfo mehr als 17.000 mal verwendet.
Aber für Straßen nutzen wir highway als Linie.

Da ich keine Ahnung habe, welcher Renderer schon area:highway=* auswertet und darstellt, befürchte ich tagging-wars, weshalb das proposal schnellstmöglich zur Abstimmung kommen sollte, um den key dann in der Wiki zu dokumentieren.

Es genügt vermutlich, wenn man die falsche Verwendung von "highway=*" mit "area=yes" entfernt und den oder die Ersteller auf die Konventionen hinweist. Vermutlich hat der Mapper nicht böswillig gehandelt und beginnt auch keinen editwar.
Es gibt keinen Anspruch auf dokumentierte Tags oder Renderregeln für jede gewünschte Anwendung.
Wer Interesse an Straßenflächen hat, kann "area:highway=*" auch ohne Abstimmung verwenden oder auswerten.

Viele Grüße
Stephan

Vielleicht können wir den Maintainer des deutschen Styles dazu überreden das Tag zu unterstützen. 😉

seawolff wrote:

...
Auch für andere Werte von highway kann "area=yes" sinnvoll sein, etwas für Wendebereiche in Sackgassen oder Rangierflächen für LKW, allgemein bei ungerichtetem Verkehr.
"highway=residential" mit "area=yes" wird laut taginfo mehr als 17.000 mal verwendet.
Aber für Straßen nutzen wir highway als Linie.

Wendebereiche in Sackgassen bekommen von mir am entsprechenden node ein highway=turning_circle. Und wie schon erwähnt sollen ways mit highway=* nicht über Flächen mit highway=* verlaufen, da das zu den bekannten Fehlern führt.

Vermutlich hat der Mapper nicht böswillig gehandelt und beginnt auch keinen editwar.

Der mir bekannte Mapper hat "gutwillig" gehandelt um die Straßenfläche sichtbar zu machen und dabei leider das entstehende und in der Wiki dokumentierte routing-Problem nicht bedacht. Ein Antwort von ihm fehlt mir noch 🙁

Es gibt keinen Anspruch auf dokumentierte Tags oder Renderregeln für jede gewünschte Anwendung.
Wer Interesse an Straßenflächen hat, kann "area:highway=*" auch ohne Abstimmung verwenden oder auswerten.

..und genau das mache ich jetzt.

Hallo,

hurdygurdyman wrote:

seawolff wrote:

...
Auch für andere Werte von highway kann "area=yes" sinnvoll sein, etwas für Wendebereiche in Sackgassen oder Rangierflächen für LKW, allgemein bei ungerichtetem Verkehr.
"highway=residential" mit "area=yes" wird laut taginfo mehr als 17.000 mal verwendet.
Aber für Straßen nutzen wir highway als Linie.

Wendebereiche in Sackgassen bekommen von mir am entsprechenden node ein highway=turning_circle. Und wie schon erwähnt sollen ways mit highway=* nicht über Flächen mit highway=* verlaufen, da das zu den bekannten Fehlern führt.

Vermutlich hat der Mapper nicht böswillig gehandelt und beginnt auch keinen editwar.

Der mir bekannte Mapper hat "gutwillig" gehandelt um die Straßenfläche sichtbar zu machen und dabei leider das entstehende und in der Wiki dokumentierte routing-Problem nicht bedacht. Ein Antwort von ihm fehlt mir noch 🙁

Es gibt keinen Anspruch auf dokumentierte Tags oder Renderregeln für jede gewünschte Anwendung.
Wer Interesse an Straßenflächen hat, kann "area:highway=*" auch ohne Abstimmung verwenden oder auswerten.

..und genau das mache ich jetzt.

Ich beobachte "area:highway=*" auch mit wohlwollen. Wenn ich mir es richtig überlege läuft es auf eine solche Tag-Gruppe hinaus und man kommt nicht umhin, das einzuführen... Ich werde es wohl auch bald einsetzen.

stimmt Sven zu.

streckenkundler wrote:

Ich beobachte "area:highway=*" auch mit wohlwollen. Wenn ich mir es richtig überlege läuft es auf eine solche Tag-Gruppe hinaus und man kommt nicht umhin, das einzuführen... Ich werde es wohl auch bald einsetzen.

stimmt Sven zu.

Dann wäre wohl der nächste Schritt, dass die Renderer "area:highway=*" auch auswerten und darstellen, damit das "Tagging für..." ein Ende haben kann. In die Richtung habe ich aber keinerlei Beziehungen und Ahnung 🙁

Jetzt spinne ich mal weiter:
Wenn sich "area:highway=*" etabliert, könnte man damit auch Fälle wie die Kronenbrücke in Freiburg http://www.openstreetmap.org/?lat=47.99 … 01&zoom=18 (ich liebe dieses Beispiel 🙂 ) optisch aufwerten, indem die Brückenflächen entsprechend getaggt werden. Dann käme auch der momentan dort stattfindende Test eines örtlichen Mappers mit einer Relation type=bridge http://www.openstreetmap.org/browse/relation/207475 zu einem guten Ende. Die momentane "Krücke" highway=service" für die Brückenfläche zur Verhinderung des routing über diese müsste dann nur durch area:highway=primary ersetzt werden. Zur Routenverhinderung wurden auch die gemeinsamen nodes der Brückenfläche mit den kreuzenden highway entfernt, was dann mindestens keepright! auf den Plan ruft 🙄

Also:
Dringend das proposal "area:highway=*" zur Abstimmung bringen und die Renderer zur Darstellung des tags bringen.

chris66 wrote:

Vielleicht können wir den Maintainer des deutschen Styles dazu überreden das Tag zu unterstützen. 😉

Das ist derzeit nicht wirklich trivial.

Das derzeitige area:highway entstand damals erstmal nur aus dem Grund, dass man eine Straßenfläche erfassen wollte, um Straßen von den ungerichteten Plätzen unterscheiden zu können. Größere Gedanken ans Rendern hat man damals nicht verschwendet. Problematisch sind bspw. die Kreuzungsflächen, wenn man die highway-Klasse rendern möchte. Ebenso der Straßenname bzw. die oneway-Pfleile müssen aus dem Way gerendert werden, an Stellen mit area:highway sollte der Weg ansonsten aber transparent sein.

Man müsste als erstmal alle Straßen ohne besondere Merkmale rendern, dann die area:highway-Flächen und dann die besonderen Merkamale der Straßen (Name, Einbahnstraßenpfeile). Für das Problem mit den Kreuzungen muss aber erst noch eine Lösung im Datenmodell gefunden werden. AFAIK ist da Marek dran, sich etwas auszudenken. Das sollten wir dann aber wenn in einem separaten Thread diskutieren.

aighes wrote:

Problematisch sind bspw. die Kreuzungsflächen, wenn man die highway-Klasse rendern möchte. Ebenso der Straßenname bzw. die oneway-Pfleile müssen aus dem Way gerendert werden, an Stellen mit area:highway sollte der Weg ansonsten aber transparent sein.

Man müsste als erstmal alle Straßen ohne besondere Merkmale rendern, dann die area:highway-Flächen und dann die besonderen Merkmale der Straßen (Name, Einbahnstraßenpfeile). Für das Problem mit den Kreuzungen muss aber erst noch eine Lösung im Datenmodell gefunden werden. AFAIK ist da Marek dran, sich etwas auszudenken. Das sollten wir dann aber wenn in einem separaten Thread diskutieren.

Hmmm 🤔
Wie wäre es, wenn highway:area=* etwas heller oder teiltransparent in dem highway=*entsprechender Farbe unter den highway=* liegen würde. Dann sähe man beides, aber könnte auch den Unterschied und die Erfassung erkennen.
Oder wie bei highway=pedestrian über gleichem area wie z.B. hier: http://www.openstreetmap.org/browse/way/40444087
Die Karte lässt für den schneidenden Weg die schwarzen Außenlinien weg (oder legt den unter die Fläche?). Potlatch stellt den Weg mit gestrichelten Außenlinien dar.

Moin!

hurdygurdyman wrote:

Wenn sich "area:highway=*" etabliert, könnte man damit auch Fälle wie die Kronenbrücke in Freiburg http://www.openstreetmap.org/?lat=47.99 … 01&zoom=18 (ich liebe dieses Beispiel 🙂 ) optisch aufwerten, indem die Brückenflächen entsprechend getaggt werden.

Die aktuellen Versuche die Brücke durch "highway=service" und "area=yes" oder durch nicht existierende Tunnel hübsch zu malen, sind völlig sinnlos und führen in diversen Anwendungen zwangsläufig zu Fehlern.
Benachbarte Brücken hat es noch schlimmer erwischt. Sie sind als "building=bridge" mit gleichem layer wie die Straße bezeichnet.
So etwas gehört auf eine Spielwiese, aber nicht in die Hauptdatenbank. Ein lokaler Mapper sollte dort aufräumen.

Die momentane "Krücke" highway=service" für die Brückenfläche zur Verhinderung des routing über diese müsste dann nur durch area:highway=primary ersetzt werden.

Das genügt allgemein nicht, da die Brücke breiter als die Fahrbahn ist. Oft läuft mehr als ein Weg über dieselbe Brücke (Fahrbahn, Gegenfahrbahn, Rad- und Fußweg, evtl. Bahngleise). Dann braucht man eine Relation, um diese Wege zusammenzufassen.

Also:
Dringend das proposal "area:highway=*" zur Abstimmung bringen und die Renderer zur Darstellung des tags bringen.

"area:highway" ist eine bloße Hilfsfläche für den Renderer. Detaillierte Angaben zu den Fahrspuren [1] sind wichtig für gutes Routing, Fahrspurassistenten, evtl. Verkehrsanalysen und ermöglichen eine relativ gute Abschätzung der Fahrbahnfläche.

Also besser:
Erst "lanes" erfassen und rendern (vielleicht mit 3m Breite pro Spur) und für Brücken auch die Relation der darüberführenden Wege auswerten.
Dann überlegen, ob "area:highway" einen zusätzlichen Nutzen bringt, der den Aufwand rechtfertigt.

Viele Grüße
Stephan

[1] http://wiki.openstreetmap.org/wiki/Lanes

seawolff wrote:

Moin!
...
Viele Grüße
Stephan

Die Versuche zum Hübschmachen werden vom lokalen Mapper durchgeführt.
Die benachbarten Brücken waren auch schon länger verhunzt. Auch lokale Mapper.
Ich stehe mit einem lokalen Mapper in Kontakt.

Mit Relationen hier zu Arbeiten macht erst Sinn, wenn aufgeräumt wurde.

Die Funktion von area:highway war mir auch vor deinen Ausführungen schon klar.

Und an der Erfassung von lanes nach http://wiki.openstreetmap.org/wiki/Lanes wird schon offline gearbeitet. Schwierig wird es in dem Bereich auch, weil die ganzen über die Spur-highways verstreuten Relationen wieder zurechtgerückt werden müssen.
Die Mischung aus Mappen nach http://wiki.openstreetmap.org/wiki/Lanes und der Verwendung von area:highway scheint mir für die Zukunft nicht nur hier viel versprechend, um den Konflikt zwischen den Ansprüchen des Routers und des Kartenlesers im Mikrobereich gerecht werden zu können.

Die Mischung aus Mappen nach http://wiki.openstreetmap.org/wiki/Lanes und der Verwendung von area:highway scheint mir für die Zukunft nicht nur hier viel versprechend, um den Konflikt zwischen den Anspruchen des Routers und des Kartenlesers im Mikrobereich gerecht werden zu können.

So ist das! Daher: http://wiki.openstreetmap.org/wiki/Navi … p_Garching
Ich lade zum Weißwurst und Bier ein 😉

Hallo,

Mit der Anwendung von area:highway=* als auch von http://wiki.openstreetmap.org/wiki/Lanes werden zwei Dinge passieren: 1. eine hinreichend saubere Darstellung der Straßensituation auf der Karte (das, was man sieht) und zum 2. ein hinreichend sauberes Routing der Strecke (da, wo man hin will). Denn es sind ja auch zwei verschiedene Dinge (die im Kopf des Menschen zusammengehören): Die Kartendarstellung: das was ich sehe und die Pfeile des Navis, die mir anzeigen, wohin ich will. Streng genommen würde es darauf hinauslaufen daß es eine Routingebene geben müsste oder muß oder gibt, die die Wege- und Straßeninformationen zur Zielfindung endhält und das es zum anderen eine Ebene der Kartendarstellung gibt, die man z.B. im Web-Browser sieht. Beides ist gleichermaßen wichtig.

In mir keimt auch so die Vermutung daß auch Renderer diese Dinge unterscheiden werden müssen. Übrigens könnte und müsste man diese Dinge auch auf Eisenbahn-, und Wasserwege-Ebene betrachten. Da hat man ja auch z.B. Waterway=riverbank für die Fläche und Waterway=river für die Linie (so wende ich es an) oder landuse=railway für die Fläche und railway=* für die Strecke als solches... in All diesen Fällen vermeide ich es, der entsprechenden Linie einen gemeinsamen Stützpunkt mit der Fläche zu geben, da wo ich es vorfinde, trenne ich es. Linie ist Linie und Fläche ist Fläche...

meint Sven

Genau so ist es Sven! Eigentlich gibt es zu dem oben beschriebenen Ansatz meiner Meinung nach keine Alternative wenn wir noch mehr aus der Karte machen wollen. Es bleibt sich auf ein Schema zu einigen.

marek kleciak wrote:

Genau so ist es Sven!

Ich sehe, wir verstehen uns... 🙂

streckenkundler wrote:

Da hat man ja auch z.B. Waterway=riverbank für die Fläche und Waterway=river für die Linie (so wende ich es an) oder landuse=railway für die Fläche und railway=* für die Strecke als solches... in All diesen Fällen vermeide ich es, der entsprechenden Linie einen gemeinsamen Stützpunkt mit der Fläche zu geben, da wo ich es vorfinde, trenne ich es. Linie ist Linie und Fläche ist Fläche...

Und genau dies meckert JOSM dann an -> überschneidende Linien

Dann wird diese Ausnahmeregel dem JOSM hinzugefügt damit er ruhiger wird.

Radeln wrote:

Und genau dies meckert JOSM dann an -> überschneidende Linien

In diesem Sinne ist das dann auch kein Fehler. Ein Fehler wäre es, wenn sich zwei Straßenlinien schneiden, ohne einen gemeinsamen Stützpunkt zu haben. Eine Straßenlinie, die einene Fläche als area:highway=* schneidet und keinen gemeinsamen Stützpunkt haben, ist für mich kein Fehler. Ebenso, bei Gewässern: ein Waterway=river und schneidet die abgegrenzte Fläche Waterway=riverbank und der Schnittpunkt hat keinen gemeinsamen Stützpunkt. Ja, JOSM meckert... Sehe ich aber nicht als Fehler. Wenn man an diesen stellen Stützpunkte verwendet, müßte man, um Routingfähig zu bleiben, diesen Stützpunkten Restriktionen auferlegen, also "Route auf dem Linienobjekt weiter" oder aber Linien, die eine Fläche umgrenzen werden generell beim Routing ignoriert. bei ersterem würde das einen erhöhten Tagging-Aufwand bedeuten, den ich aber für unsinnig halte, bei letzerem weiß ich nicht, ob diese fixe Idee überhaupt funktioniert.

Sven

marek kleciak wrote:

Dann wird diese Ausnahmeregel dem JOSM hinzugefügt damit er ruhiger wird.

Und irgendwann gibts dann die Ausnahme von der Ausnahme. 😉
Rin in die Kartoffel, raus aus der Kartoffel.

Und irgendwann gibts dann die Ausnahme von der Ausnahme.

Nein. Es ist eine klar spezifizierte, begrenzte Sache. Wr müssen nur dafür Sorge tragen, dass es an richtegen Stellen ankommt, damit auch andere Qualitätstools diese Feature unterstützen.

hüstel:

Darf ich zum Thema zurück bitten, das nicht "überschneidende Linien und das Gemecker darüber durch JOSM" heißt.

streckenkundler wrote:

Wenn man an diesen stellen Stützpunkte verwendet, müßte man, um Routingfähig zu bleiben, diesen Stützpunkten Restriktionen auferlegen, also "Route auf dem Linienobjekt weiter" oder aber Linien, die eine Fläche umgrenzen werden generell beim Routing ignoriert. bei ersterem würde das einen erhöhten Tagging-Aufwand bedeuten, den ich aber für unsinnig halte, bei letzerem weiß ich nicht, ob diese fixe Idee überhaupt funktioniert.

Oder aber, man würde einfach wie bisher auf Flächen mit area:highway (oder waterway=riverbank, etc.) nicht routen. Wo ist genau das Problem? Nur weil zwei Linien einen gemeinsamen Punkt haben, heißt das ja noch lange nicht, dass ich von der einen auf die andere routen darf. Oder lotsen wir demnächst Autofahrer über Fußwege, nur weil die gemeinsame Punkte haben.

errt wrote:

Oder aber, man würde einfach wie bisher auf Flächen mit area:highway (oder waterway=riverbank, etc.) nicht routen.

Genau! Das meinte ich mit meiner Aussage:

streckenkundler wrote:

...oder aber Linien, die eine Fläche umgrenzen werden generell beim Routing ignoriert.

🙂

Sven

errt wrote:

Oder aber, man würde einfach wie bisher auf Flächen mit area:highway (oder waterway=riverbank, etc.) nicht routen. Wo ist genau das Problem? ...

Das war auch noch nie hier die Idee, darüber zu routen. Im Gegenteil, das dient der klaren Unterscheidung zu highway=* in Verbindung mit area=yes, was einige Programme dazu verleitet über die Kanten des area zu routen. Siehe thread-Beginn.

@Sven: Klang für mich nach: "Nie über eine geschlossene Fläche routen", so eng muss man das aber ja nicht sehen.

Gut. Dann bin ich mit dem Thema im reinen. 🙂
area:highway ist gut.
highway=* mit area=yes ist böse.

Ich habe mich bisher darum gedrückt, eine der beiden Varianten selbst anzuwenden, bin ja noch nicht so lange bei und taste mich an einiges Schritt für Schritt ran...

Sven

streckenkundler wrote:

Gut. Dann bin ich mit dem Thema im reinen. 🙂
area:highway ist gut.
highway=* mit area=yes ist böse.

Ich habe mich bisher darum gedrückt, eine der beiden Varianten selbst anzuwenden, bin ja noch nicht so lange bei und taste mich an einiges Schritt für Schritt ran...

Hallo Sven

So krass kann man das nicht sehen.
Es gibt Straßenflächen (vor allem bei highway=service), auf denen überall gefahren werden darf und kann.
Nicht jede Fußgängerfläche ist ein highway=pedestrian z.B. Schulhöfe. Die sind besser mit highway=footway + area=yes getaggt.

Edbert (EvanE)

Hallo Edbert,

so wie ich das Proposal http://wiki.openstreetmap.org/wiki/Prop … ea:highway verstehe, kann es doch genauso auf die von dir angesprochenen Fälle angewendet werden, oder hab ich da einen Knoten im Kopf? Es geht doch darum, Straßenflächen sauber zu definieren, um diese Routing-Geschichte zu verbessern.

Sven

streckenkundler wrote:

Hallo Edbert,

so wie ich das Proposal http://wiki.openstreetmap.org/wiki/Prop … ea:highway verstehe, kann es doch genauso auf die von dir angesprochenen Fälle angewendet werden, oder hab ich da einen Knoten im Kopf? Es geht doch darum, Straßenflächen sauber zu definieren, um diese Routing-Geschichte zu verbessern.

Sven

Noch einmal: highway=* in der Kombination mit area=yes als zulässige Kombination mit der Erlaubnis zum ungerichteten Routen über diese Fläche kann verwendet werden, wenn diese Fläche nicht von einem oder mehreren highway=* als gerichteter graph geschnitten wird.

hurdygurdyman wrote:

highway=* in der Kombination mit area=yes als zulässige Kombination mit der Erlaubnis zum ungerichteten Routen über diese Fläche kann verwendet werden, wenn diese Fläche nicht von einem oder mehreren highway=* als gerichteter graph geschnitten wird.

[Plopp] "Au..." ... <Knoten geplatzt>

Ach so... na sag das doch gleich... 😄

duck und weg...

Sven

Moin!

streckenkundler wrote:

hurdygurdyman wrote:

highway=* in der Kombination mit area=yes als zulässige Kombination mit der Erlaubnis zum ungerichteten Routen über diese Fläche kann verwendet werden, wenn diese Fläche nicht von einem oder mehreren highway=* als gerichteter graph geschnitten wird.

Ach so... na sag das doch gleich... 😄

Leider nicht ganz richtig:
Die Kombination "highway=pedestrian" , "area=yes" mit darüberführendem "highway=service" findet man oft für innerstädtische Plätze mit markiertem Zufahrtswegen für Kfz.
Auch die umgekehrte Kombination (service-Fläche mit Fußweg) könnte für Hafen- oder Speditionsflächen mit markierten Fußwegen sinnvoll sein.

Gruß
Stephan

seawolff wrote:

...
Leider nicht ganz richtig:
Die Kombination "highway=pedestrian" , "area=yes" mit darüberführendem "highway=service" findet man oft für innerstädtische Plätze mit markiertem Zufahrtswegen für Kfz.
Auch die umgekehrte Kombination (service-Fläche mit Fußweg) könnte für Hafen- oder Speditionsflächen mit markierten Fußwegen sinnvoll sein.

Für den ersten Fall gebe ich dir recht ( http://wiki.openstreetmap.org/wiki/DE:Key:area unter "Straßenflächen"). Hatte ich vergessen, hier noch mal zu erwähnen 🙁
Der zweite Fall macht IMHO nur Sinn, wenn diese Fußwege durch Markierungen auf der highway=service-Fläche vorgeschrieben sind. Innerhalb der area-highways kann beliebig über die Fläche geroutet werden (sieh Wiki-link), und normalerweise dürfen sich auf diesen sich auch Fußgänger frei bewegen.

seawolff wrote:

Moin!

streckenkundler wrote:

hurdygurdyman wrote:

highway=* in der Kombination mit area=yes als zulässige Kombination mit der Erlaubnis zum ungerichteten Routen über diese Fläche kann verwendet werden, wenn diese Fläche nicht von einem oder mehreren highway=* als gerichteter graph geschnitten wird.

Ach so... na sag das doch gleich... 😄

Leider nicht ganz richtig:
Die Kombination "highway=pedestrian" , "area=yes" mit darüberführendem "highway=service" findet man oft für innerstädtische Plätze mit markiertem Zufahrtswegen für Kfz.

Oder wie oft zusehen, mit highway=pedestrian, was IMHO überhaupt keinen Sinn macht.

Radeln wrote:

...
Oder wie oft zusehen, mit highway=pedestrian, was IMHO überhaupt keinen Sinn macht.

Der einzige Un-Sinn besteht dabei darin, dass so nicht über die Kanten des area geroutet wird, sondern z.B. schön gerade oder quer über den Platz 🙄
Na ja, solange die router i,d.R. noch nicht frei über Flächen routen können oder wollen...

hurdygurdyman wrote:

seawolff wrote:

...
Leider nicht ganz richtig:
Die Kombination "highway=pedestrian" , "area=yes" mit darüberführendem "highway=service" findet man oft für innerstädtische Plätze mit markiertem Zufahrtswegen für Kfz.
Auch die umgekehrte Kombination (service-Fläche mit Fußweg) könnte für Hafen- oder Speditionsflächen mit markierten Fußwegen sinnvoll sein.

Für den ersten Fall gebe ich dir recht ( http://wiki.openstreetmap.org/wiki/DE:Key:area unter "Straßenflächen"). Hatte ich vergessen, hier noch mal zu erwähnen 🙁
Der zweite Fall macht IMHO nur Sinn, wenn diese Fußwege durch Markierungen auf der highway=service-Fläche vorgeschrieben sind. Innerhalb der area-highways kann beliebig über die Fläche geroutet werden (sieh Wiki-link), und normalerweise dürfen sich auf diesen sich auch Fußgänger frei bewegen.

Wenn du an die Fußwege nicht glauben magst nimm dir einfach Radwege.

• hmpf* - falschen Thread erwischt. Sorry dafür!!!
  

[del
Zusammen mit einem Kollegen ("It's so funny" ; Johan) aus den Niederlanden habe ich mal zu Versuchszwecken begonnen einige Stellen mit change:lanes zu taggen. Von den ursprünglichen Werten left, right, ... sind wir eher wieder abgekommen. Johan hat richtigerweise bemerkt, dass wir ja nur dann taggen, wenn ein Wechsel nicht erlaubt ist. Daher probieren wir es jetzt einmal mit folgenden Werten:

• yes (Wechsel erlaubt; äquivalent zu both)
  
• not_right (nicht nach rechts; äquivalent zu left)
  
• not_left (nicht nach links; äquivalent zu right)
  
• no (kein Wechsel erlaubt; äquivalent zu none)

Wenn wir ein paar Erfahrungswerte haben, melde ich mich wieder.

imagic wrote:

Zusammen mit einem Kollegen ("It's so funny" ; Johan) aus den Niederlanden habe ich mal zu Versuchszwecken begonnen einige Stellen mit change:lanes zu taggen. Von den ursprünglichen Werten left, right, ... sind wir eher wieder abgekommen. Johan hat richtigerweise bemerkt, dass wir ja nur dann taggen, wenn ein Wechsel nicht erlaubt ist. Daher probieren wir es jetzt einmal mit folgenden Werten:

• yes (Wechsel erlaubt; äquivalent zu both)
  
• not_right (nicht nach rechts; äquivalent zu left)
  
• not_left (nicht nach links; äquivalent zu right)
  
• no (kein Wechsel erlaubt; äquivalent zu none)
  

Wenn wir ein paar Erfahrungswerte haben, melde ich mich wieder.

Gute Idee 🙂
Gehört aber wohl besser hier gepostet:
http://forum.openstreetmap.org/viewtopi … 39#p284839
Habsm mal dort zitiert.