wieso gibt es keinen landuse=highway?

Dann sperr mal die nächste Autobahn ab. Wenn dich die Auto- und Lkw-Fahrer lynchen, wird dir einfallen, welchen Zweck die Straßen haben. :wink:

und was ist da der unterschied zu jedem anderen element was man von sat-bildern abzeichnet? die können genauso gut versetzt sein und werden trotzdem eingezeichnet.

tritt ebenfalls für alles zu.

wenn wir uns nach dem am schlechtesten gemappten teil von OSM orientieren würden, würde es gar keinen fortschritt bei den karten geben und wir würden heute immer noch nur straßen anhand von gps tracks einzeichnen und sonst nichts.

dann müsste der renderer angepasst werden um die jeweiligen zoomstufen korrekt anzuzeigen. man könnte zB noch eine weitere zoomstufe zur jetzigen dazugeben, die nur gerendert wird wenn was mit landuse=highway vorhanden ist.

doris hat nur in ballungsgebieten diesen hohen detailierungsgrad. am land fehlen auch diese informationen, daher gibt es die hohen zoomstufen an der stelle einfach nicht. für den renderer sollte es einfach sein festzustellen ob auf einer kachel was mit landuse=highway vorkommt oder nicht und dementsprechend zu rendern.
mapnik zeigt auch keine radparkplätze. deswegen werden sie trotzdem gemappt und es hat sich daraus dann eine radfahrkarte entwickelt. mann kann ausserdem hinterfragen ob es überhaupt im normalen mapnik gerendert werden sollte oder dsfür nicht ein spezieller “urban-renderer” für begrenzte flächen herangezogen wird.
aber kartenrenderer sind ja nicht der einzige anwendungsfall (siehe zweites posting von mir).

ich möchte auch noch sagen, dass es natürlich keine pflicht sein soll so zu mappen und für kleine dörfer am land sicherlich overkill ist, aber es sollte zumindest potentiell die möglichkeit bestehen mit OSM konkurrenzfähige karten machen zu können, die mit den kommerziellen anbietern mithalten können.

Hallo flaimo

Selbstverständlich geht das auch mit OSM. Siehe zum Beispiel Dortmund Asseln.
Ich muss allerdings sagen, dass ich das Editieren in diesen hochgenau aber leider nicht fehlerfrei gemappten Gebieten als ausgesprochen schwierig/anstrengend empfand. Jetzt, wo die hochauflösenden Luftbilder für Dortmund nicht mehr zur Verfügung stehen, ist es nahezu unmöglich geworden, irgend etas noch anpassen zu wollen.

Der Weg der Wahl war entweder zweimal highway=, einmal als Weg + einmal als Fläche oder highway= als Weg +area:highway=* als zugehörige Fläche zu benutzen.

Ich sehe ein landuse=highway höchstens bei Autobahnen und Schnellstraßen. Da kann es sinnvoll sein per landuse die Zwischen- und Neben-Flächen (Auf-/Abfahrten, Böschungen, Park-/Rastplätze, Tankstellen, …) als zur Autobahn / Schnellstraße zugehörig zu kennzeichnen. Leider beisst sich das dann gerne mit bereits erfassten Details wie landuse=forest, natural=scrub usw.

PS: Deine Shift-Taste funktioniert nicht.
Dadurch sind deine Beiträge nur schwer zu lesen.

Edbert (EvanE)

Du hast nicht ordentlich gelesen. Der Unterschied ist, dass die anderen Objekte normalerweise groesser sind als die Strassen. D.h. der Lagefehler ist klein in Relation zu den Abmessungen. Bei den Strassen trifft das aber grundsaetzlich nicht zu.

OSM ist EINE Datenbank, aus der die Renderer ihre Informationen fuer die Kartenerzeugung holen. Wir haben nicht fuer jede Zoomstufe eine eigene Datenbank, deshalb koennen die automatisch erzeugten Karten auch nicht beliebig gut werden.

Wenn du anfaengst, in dieser Datenbank mit den Landuses ein Mikrotagging zu betreiben, dann wird das zwar auf einer Detailkarte besser aussehen. Darunter leidet dann aber gleichzeitig eine groebere Uebersichtskarte, weil statt groesser zusammenhaengender Landusegebiete nun ploetzlich nur noch ein unbrauchbarer Flickenteppich zur Verfuegung steht.

Wenn man also die Strassen unbedingt als Flaechen erfassen will, dann sollte bei den Tags klar werden, dass das reine Zusatzinformationen sind, die das “normale” Tagging nicht beeinflussen oder ersetzen duerfen. Sonst richtet man damit viel mehr Schaden an als man Nutzen hat.

Gruss
Torsten

Es steht jedem Renderer frei, die Infos die aus width=* oder lanes=* hervorgehen, auch in hohen Zoomstufen darzustellen. Fleißige Leute können sicher auch noch proposals für Standspuren oder anderes starten.

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.