wieso gibt es keinen landuse=highway?

diese infos können aber niemals so genau für die darstellung ausgewertet werden wie flächen, sonst hätte man es bei flüssen ja auch so umgesetzt. was machst du bei einer straße die über eine länge von 50m von 3 auf 2 spuren verengt wird? den way in zig teilstücke aufsplitten mit unterschiedlichen breitenangaben?

Ich zeichne bei guten Luftbildern die Straßen immer doppelt ab.
Einmal die Linie und dann noch die Fläche als highway mit area=yes.
Man darf die Areas dann nur nicht mit den Ways verbinden, sonst gibt es Routingprobleme.

In Asseln hab ich das ja auch so gemacht, wie man in dem Beispiel oben sieht.

highway + area ist schlecht wegen dem Routing. Auch wenn man es nicht verbindet, kann es sein, dass man die Fläche trifft. Über highway + area muss man aber routen, da man sonst an den Plätzen scheitert.

Daher hatte man sich in Dortmund meine ich auf area:highway geeinigt.

also wird das eh bereits aktiv gemappt? vielleicht können wir hier mal die unterschiedlichen taggingweisen zusammentragen und analysieren. was war der grund area:highway und nicht landuse=highway zu verwenden?

Halte ich für sehr problematisch.
Man muss aufpassen dass hier nicht jemand zB. aufgrund vom JOSM Validator oder keepright
die Flächen mit den Straßen verbindet.

Zweitens, macht es die Routerprogrammierung schwieriger. Man stelle sich zB vor, jemand
wählt als Startpunkt der Route eine solche Fläche und der Router findet keine Verbindung
zum Straßennetz…

Chris

landuse=highway wäre nach meinem Verständnis alles was zur Straße gehört. Also Fußweg, Fahrbahn, Radweg, Grünstreifen bei Autobahnen etc.

area:highway=* war so angelegt, dass man für jeden Teil der Fahrbahn einen anderen value nehmen kann. Bspw. für dei Wohnstraße area:highway=residential, für den Fußweg area:highway=footway etc. Die Values entsprechen dabei den gleichen Bedeutungen, wie auch schon bei normalen linienförmigen highways.

Dabei ist es sinnvoll, sowohl der Fläche als auch dem Weg jeweils die zusatztaggs zu spendieren, die sinnvoll sind. Bspw. ist eine Fläche nicht gerichtet. Ein oneway=yes wäre also nicht sinnvoll. surface und smoothness oder tracktype kann man aber ruhig beiden Objekten anhaften. Zumindest sollte aber der linienförmige Weg alle Taggs bekommen.

DENN immer dran denken: Der Router wird nur die Linie nutzen.

Das Schema ist aber noch nicht wirklich ausgereift. Wenn da noch Ideen vorhanden sind, nur her. Das einzige was mir wichtig ist, ist dass die flächige Straße kein highway=* bekommt, weil das das Routing ad absurdum führt.

Den größten Kritikpunkt an diesem Mikromapping sehe ich, wie Edbert schon angesprochen hat, in der Verfügbarkeit der Luftbilder. Wenn die weg sind, kann man an den betreffenden Straßen nicht mehr viel machen.

Zu dem Renderer: Die Renderer haben idR für (fast) jede Zoomstufe einen eigenen Style. Da gibt es kein Problem.

Deshalb hab ich auch überall note=don’t connect (routing problems) zu auf die Areas gemacht.

Natürlich bin ich auch für ein highway:area oder ähnliches Tag.

Es muss eine eindeutig unterschiedliches tagging haben damit es nicht stört. ein highway=x, area=yes stört und ich habe schon 2x jeweils eine Flächen gelöscht die kein Platz waren.

Ich sehe es nicht ein das manche mit ihrem dämlichen Mikromapping auch noch das routing kaputt machen dabei sind die Infos die wir normalerweise haben niemals so genau. Selbst die Luftbilder haben üblicherweise recht heftige Lagefehler.

width und lanes geben dem Renderer auch schon gute Infos über die Breite.

Einfach löschen ist aber auch nicht richtig.
Dann wenigstens drin lassen ohne Attribute mit nem Node.
Das Einzeichnen war ja schließlich auch Arbeit und bei langen Straßen nicht wenig!

Übrigens: Blöd nur, dass keine Straße an jeder Stelle exakt gleich breit ist!

also ich hab das jetzt mal ausprobiert indem ich mal landuses verwendet habe, die bereits gerendert werden. ich finde das mapnik das ohne großartige modifikationen wunderbar darstellen könnte. auf hohen zoomstufen wird nur der name der straße gerendert, die linie selbst aber weggelassen, bei niedrigeren zoomstufen überdeckt der gerenderte way dann den landuse. auf das routing würde es keinen einfluss haben, da ein landuse=highway genauso wenig informationen dafür enthält als wie ein landuse=forest:

man könnte das ganze auf einer zoomstufe 19 umsetzten, die bis auf weiteres über den zoom-schieberegler (noch) nicht erreichbar ist. dann würde sich für otto-normal-mapper nichts ändern.

Sieht doch wunderbar aus!
Was man dann noch bräuchte wär ein highway-type=primary|secondary|… damit der Renderer weiß,
wie er das ganze darstellen soll.

Es wäre schonmal ein Fortschritt wenn mapnik Gebäude nach/über Straßen zeichnen würde. Der Fall das eine Straße die keine Brücke ist über eingezeichneten Gebäuden liegt sollte recht selten sein. Das Problem das die Straßen (in Altstädten) schmaler ist als gerendert dagegen verhältnismäßig häufig.

BBO

Dieses Problem erledigt sich fast von alleine, wenn man das in früheren Diskussionen vorgeschlagene (und hier auch schon erwähnte) area:highway=primary/secondary/… verwendet - dann bringt man das nämlich direkt im Wert gut unter. Unter den genannten Alternativen ist das ohnehin das beste Tagging. Denn es handelt sich hier weder um einen landuse (dafür ist es viel zu kleinteilig) noch ein highway=* + area=yes (das wäre ein Platz, nicht die Fläche einer Straße).

Ein Urteil darüber, ob der Ansatz mit einer Fläche um jeden Way überhaupt sinnvoll ist, oder ob man doch lieber etwas wie Area-Relationen (sehr kompliziert, aber beschreibt wohl einen kompletten Spurquerschnitt einschließlich Spuren, Spurtrennern etc.) oder schlicht Spur-Ways einsetzen sollte, traue ich mir jetzt noch nicht zu.

Ein area:highway ist natürlich gut für ein primitives Rendering, bei dem die ganze Fläche in einer einheitlichen Farbe angemalt wird und es der Umrandung egal ist, ob sie ein Bordstein oder eine Linie ist und an was sie grenzt.
Ob es aber auch für komplexere Darstellungen taugt, und ob es vielleicht sogar zu viel Mapping-Aufwand ist (hat man erst mal man alle Spuren, einschließlich Gehwege, als Ways eingezeichnet, gibt es für die Flächenausdehnung der Straße kaum mehr Spielraum), kann ich nicht einschätzen, bevor ein solcher fortgeschrittener Fall tatsächlich mal in Software implementiert ist.

Um es kurz zu machen, mir drängt sich bei diesem Thema die Frage auf ob hier Jemand am Heiligen Abend zu stramm am Glühwein genippt hat. :wink:
landuse=highway? - Wollen wir demnächst dann mit dem Zollstock losziehen und die Straßenbreite checken?
Laßt es bei einem Gedankenspiel, aber macht nicht mehr (Unsinn) daraus!

mfG Michael

im prinzip müsste man nur prüfen ob bei zwei aneinander grenzenden area:highway flächen unterschiedliche werte eingetragen sind. wenn ja, dann sollte ein dunkelgrauer trennstrich gerendert werden, wenn es zwei flächen gleicher art sind, dann nicht.

troll-kommentar ohne jeglichen konstruktiven inhalt. einfach ignorieren.

Moin,

Ein prinzipieller Mordsaufwand - nur um dann die (meisten) direkt asphaltierten primary/secondary/tertiary/unclassified/residential-Übergänge mit fälschlichen Bordsteinen, Regenrinnen oder Linien zu trennen?

Gruß
Georg

Genau so ist es. landuse=highway schließt sich ja quasi schon aus, da sich ja eine Straße um als solche erkenntlich zu sein von der Umgebungsfläche unterscheiden muß, außerdem entspräche das ja eher der Landnutzung “Ashpaltfläche (das gibt natürlich nicht mal das Material an) ohne Nutzungsangabe mitten in der Landschaft”. Ich benutze da z.B. highway=residential mit area=yes, was gerendert wird, aber unter Umständen etwas schräg aussieht. Irgendwelche Router, sollen oder können das auch lernen. Jetzt weiß ich auch warum ich bisher kein extra highway=service für Bustaschen auf der gleichen Fahrbahn gemappt habe. Das ist ja nur eine Spur wenn auch mit Nutzungsbeschränkungen. Warum soll die ausgerechnet extra sein, wenn man z.B. sonst auch nur einen Linie für zwei Fahrstreifen mappt? Der obige Fall der highway=residential ist ein etwas größerer einseitig begradigter Wendekreisel ohne Nutzungseinschränkung in einer Anwohnerstraße der offenbar nach späterer Verlängerung der Straße jetzt nur noch als Buswendeschleife und Haltstelle dient.

ich habe für area:highway jetzt mal ein proposal angefangen: http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway .
in den kommentaren wird als alternative die verwendung von relationen mit type=area genannt. allerdings ist es mangels praktischen beispielen für mich unverständlich: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area . vielleicht kanns mir wer auf deutsch erklären.

Cooool, ich werde gleich mal meinen Heimatort mit dem Schema area:highway=primary taggen. Später ändern auf etwas anders ist einfach, wenn schonmal alles vorhanden ist.

poste die bbox dann bitte in die wiki comments, damit ich das ev als real life example im proposal anführen kann.