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
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.
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:
- breitere Straßen in Z=18-19
- Straßenbreite in Abhängigkeit von “lanes” und “width” in Z=17-19
- 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) - 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
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!
+1
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)
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.
- 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.
- Ich schwöre, ich habe es versucht: Die Breite der Autobahn zu messen. Keine Chance. Selbst um 03.30 fahren dort Autos.
- 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.56998&lon=13.31508&zoom=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/Proposed_features/area_highway/mapping_guidelines#Rendering_of_lanes
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.89056&lon=7.18408&zoom=19&ol=BPN
Vielleicht abwarten. Leider nervt das switchen der gerenderten Länder etwas. Ich weiß, der Server…
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”.
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=19/52.56723/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.34102&lon=12.38481&zoom=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.34401&lon=12.37816&zoom=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/Proposed_features/area_highway/mapping_guidelines#Paralel_ways
Möglicherweise erreichen wir an diesem Wochenende die Zahl von 40.000 gemappten a:h.
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.
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.
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:Kreuzungsbilder_Dippoldiswalde.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.