wieso gibt es keinen landuse=highway?

landuse ist mehr eine großflächige Nutzung, die auch passende Wege miteinschließt. Es gab aber mal irgendwo einen highway=area Ansatz, den ich nicht schlecht fand, und ich denke auch, dass sich sowas in Zukunft durchsetzen wird.

ich nutze manchmal highway=service, area=yes für große asphaltierte Flächen bei Fabriken und so. Wird auch gerendert

Um genauer zu sein gibt es für Straßen area:highway=residential/unclassified/… Allerdings ist es unerlässlich, den highway auch als reinen Weg einzuzeichnen.

Für Plätze hat sich eher highway=* und area=yes durchgesetzt.

Beim landuse gibt es aber nichts. Entweder sie gehört zum umgebenden landuse mit dazu, oder sie liegt zwischen den beiden.

das area für plätze verwendet wird war mir schon klar, aber generell geben momentan die wege nur richtungen an, aber keinerlei informationen zur geografischen ausdehnung dieser flächen. und aber irgendeiner zoomstufe wird jeder kleine landuse landuse rießig dargestellt. es spricht eigentlich nicht dagegen landuse detailierter zu verwenden. für flüsse wird das ja auch bereits in ähnlicher art umgesetzt. es wird nicht nur waterway=river gemappt, sondern auch waterway=riverbank um die geografische ausbreitung anzuzeigen und für bahnstrecken gibt es landuse=railway. wieso sollte man das dann nicht konsistent machen und auch bei highways einführen?

ich finde die visuelle darstellung in der höchsten zoomstufe momentan eher unbefriedigend. für karten die kleine bereiche anzeigen sollen bzw ev auch für zukünftige augmented reality anwendungen auf smart phones die nur die konkrete nähere umgebung zeigen, sollte es potentiell mehr informationen zur detailierten darstellung geben.

Jedenfalls sollte man, wenn man für die Straße schon einen Streifen frei lässt, diesen Streifen mit einem entsprechenden landuse versehen können.

Probleme sehe ich folgende:

  1. Das werden sehr viele und sehr komplizierte Multipolygone; oder noch mehr Einzelflächen mit doppelt gezogenen Dummy-Trennlinien dazwischen.
  2. Die Straßengrenzen nach außen müssen ebenfalls doppelt gezogen werden, oder man stückelt alles zu Multipolygongrenzen zusammen.
  3. Praktisch kann man derzeit die Straßenflächen gar nicht so genau erfassen. Die Lage ist genauso viele m daneben, wie die Straße breit ist. Außerdem sind die für Straßen frei gelassenen Streifen meistens zu breit.
  4. Wegen (3) sind später Korrekturen nötig. Diese Korrekturen sind wegen 1+2 sehr mühsam.
  5. Das Erfassen ist an sich schon mühsam und benötigt ein Vielfaches an Zeitaufwand. Und das zu einem Zeitpunkt, wo die Karte noch sehr lückenhaft ist und ein paar km weiter noch überhaupt nichts erfasst ist.
  6. Beachte, dass in deinem DORIS-Beispiel die Straßen in dieser Zoomstufe nicht zusätzlich linear gezeichnet werden, sondern NUR als graue Flächen. (Von highway=* würde sozusagen nur der Name gerendert werden.) In OSM wird es immer eine Mixtur geben aus Straßen mit landuse=* und welchen ohne. Die ohne müssten auch in hohen Zoomlevels linear gezeichnet werden. Diese verschiedene Darstellung von Straßen desselben Typs in einer Karte ist furchtbar und erfordert vom Renderer, zu erkennen, welche Straßen einen landuse “zugeordnet” haben und welche nicht.
  7. Die amtlichen Karten basieren in verschiedenen Zoomlevels auf verschiedenem Datenmaterial. OSM benutzt für alle Zoomlevels das selbe Datenmaterial. In OSM kann es vorkommen, dass in mittleren Zoomlevels, wo die Straßen abstrakt mit verschiedenfarbigen Linien dargestelt werden, trotzdem noch ein grauer Straßenlanduse daneben hervorschaut, weil die Straße an der Stelle zufällig breiter ist als die Linie. Das sieht dann sehr seltsam aus. Die Renderer müssten in so einem Fall den Straßenlanduse unterdrücken und den landuse daneben bis zur Straße durchzeichnen, was insofern eine Herausforderung ist, als erst das richtige benachbarte Flächenobjekt herauszufinden ist, und dann noch die Grenzen zwischen benachbarten Flächenobjekten zur Straße weitergezogen werden müssten (siehe den Streit um die Seegrenze zwischen Slowenien und Kroatien, was vom Prinzip her dasselbe ist).

Weil es nirgendwo auf der Welt eine Gegend gibt, auf denen Strassen als Selbstzweck gibt. Der Zweck der Strassen als Gegend muss sich immer einem anderen Flächentyp unterordnen. Zudem sehe ich keine zusätzliche Information in einem “landuse=highway”.

Warum kommst du auf so eine Idee, was steckt hinter deiner Frage?

Wyo

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!