Hallo allerseits!
Ich habe angefangen in Nürnberg Straßen als Flächen zu zeichnen (area:highway=yes)
Kann mir jemand von Euch helfen der Ring um die Stadtmitte (B4R) zu vervollständigen?
Ich würde gerne testen, wie das gerendert in der Karte aussehen könnte.
Schau dir mal den Bereich um den Leipziger Hauptbahnhof (v.a. nach Süden und Westen) an. Die großen Straßen haben dort area:highway=*-Flächen. (Ich repariere gerade Multipolygone dort)
Ist area:street eigentlich etabliert? ich sehe, dass osm2pgsql area:highway verarbeitet, area:street aber nicht.
und es sind nur ca 20-30 area:street überhauptt weltweit eingetragen. Dagegen aber 157 area:highway.
Das sollte man schnellstmöglich angleichen, ansonsten ist **kein Rendern mit Mapnik möglich!
**
Gruss
walter
Jo, aber richtig heftig.
https://taginfo.openstreetmap.org/keys/area:highway → 15329
https://taginfo.openstreetmap.org/keys/area:street → 21
nun denn, damit sieht es doch noch besser aus. Ich hoffe, Marek hat sich nur vertan.
Gruss
walter
Ich habe mich deutlich vertan. Die Hitze macht mir zu schaffen 
Klar, es geht um area:highway
Könnte/sollte man solche Experimente nicht vielleicht auf einem Test-Server oder wenigstens in einem kleinen Dorf machen statt mitten in einer Großstadt auf dem Livesystem?
Bye
Frederik
Ich dachte bislang immer, dass wir nicht für die Renderer mappen ???
Die Darstellung eines jeden beliebigen Tags kann jeder Renderer darstellen wie es ihm (bzw. dem Ersteller des Styles) gefällt.
Es gibt momentan - aus meiner Sicht - jedoch immer mehr Aktivitäten, die genau in diese Richtung (wir mappen für den Renderer) gehen. Manche davon - wie 3D-Mapping - haben auf jeden Fall den Effekt, dass man damit eine erhebliche Außenwirkung erzielen kann.
Darüber hianus führen diese Aktivitäten meiner Meinung nach auch dazu, dass zum einen die Datenerfassung erheblich aufwendiger wird, zum großen Teil (oft noch) nicht einmal Tools für die Erfassung existieren und die Datenmodelle im Hintergrund immer komplexer und fehlerträchtiger werden. Auch hier kann z.B. 3D als Beispiel dienen.
Das Paretoprinzip https://de.wikipedia.org/wiki/Paretoprinzip und die Erfahrung zeigt mir, dass die ersten Schritte meisten sehr einfach sind und man einen großen Hub erreicht. Danach wird jedoch viel Energie benötigt, um den Rest zum Optimum zu schaffen.
Ob der Fokus auf diese zusätzlichen Punkte wichtig ist, mag jeder für sich selbst entscheiden. Das ist ja das Prinzip bei OSM, dass es hier keine zentrale Lenkung gibt.
Ich persönlich bin momentan der Ansicht, dass es noch genug Basisarbeit in OSM gibt, die erst einmal (weltweit) erledigt werden sollte.
Wenn der letzte HKTS ( http://www.netzwolf.info/kartografie/openlayers/overpass_pois2?zoom=17&lat=50.72871&lon=7.09679&tags=vending%3Dexcrement_bags und http://wiki.openstreetmap.org/wiki/DE:Tag:vending=excrement_bags ) erfasst ist, dann werde auch ich mich auf andere Sachen stürzen.
Edit: Typo
Nein, für den Renderer Mappen" (oooommmm) besteht dann, wenn man etablierte Tags dazu verwendet, etwas so zu rendern, wie man es gerne hätte, ohne dass diese Tags zu dem Objekt passen.
z.B. highway=service für eine in der realität schmale Residential zu verwenden, weil einem die Straßenbreite bei Mapnik zu groß dargestellt wird.
Oder den Endpunkt einer Strasse mit recycling=yes zu taggen, weil einen das Symbol für Recycling an einen Wendeplatz erinnert. (Sorry, was blöderes besseres fiel mir gerade nicht ein).
area:highway=secondary oder area:highway=service ist ein neuer key, um etwas neues auszudrücken, was sonst nicht anders geht.
Gruss
walter
ps: Dass mir area=yes als zusätzlicher Tag zur normalen Strasse besser gefällt, hat ja niemanden interessiert - aber das ist ein anderes Thema 
Laut http://taginfo.openstreetmap.org/compare/area:highway
ist das Experiment bereits 15329 Mal verwendet und hat 3 verschiedene Renderer.
Ich würde da nicht mehr von einem Experiment reden, sondern überlegen wie wir dies auf der Hauptseite anzeigen. Es geht hier um ganz normales Mappen.
Es erinnert mich ein wenig an die Kritik zu Anfang von dem 3D Mapping. Ich schätze dass wir dieses Jahr die Marke von 1 Million 3D Gebäude brechen. 
Viele Grüße,
Marek
Ich glaube du hast da etwas falsch verstanden. Ich gehe mal davon aus, dass Marek so vernünftig ist und diese Flächen nicht mit highway=* taggt und die bestehenden Straßen-Ways nicht löscht.
In Leipzig habe ich heute (ich wollte kaputte Multipolygone per OSMI suchen und reparieren) ein Straßenflächenmapping entdeckt, das ein besonders heller Mapper wie folgt gemacht hat. Er hat sehr große Multipolygone angelegt, die die Straßenflächen ganzer Stadtviertel abgebildet haben (ein MP pro Viertel!) und diese mit highway=unclassified + area=yes getaggt. Dazu noch eine note=“nicht mit anderen Straßen verbinden, damit das Routing intakt bleibt”. Zum Glück hat er seinen Fehler schon vor einiger Zeit eingesehen und die MPs in kleinere zerhackt und auf area:highway=yes umgestellt. Ich bin heute mit dem Messer nochmal ran und habe die MPs weiter aufgeteilt und vielerorts auf normale Flächen umgestellt.
Neue Sachen sind in OSM prinzipiell kein Problem, solange die Abwärtskompatibilität nicht leidet. Ohne Neuerung hätten wir heute noch keine Gebäude in OSM!
In diesem Fall ist das Problem, daß diese Flächen nicht wie die Gebäude neben anderen Strukturen liegen, sondern daß sie die normalen Ways überdecken und damit die Mehrheit der Mapper beim Editieren behindern, ganz besonders Anfänger dürfte es abschrecken überhaupt was anzulangen bzw. es ist sehr wahrscheinlich, daß bald unbeabsichtigte Verbindungen entstehen.
Von daher bin ich der Meinung: Ganz schlechte Idee die Daten viel schwerer editierbar zu machen nur um die Karte mit Straßenflächen auszumalen.
bye, Nop
Hi,
nachdem das Problemchen mit area:street geklärt wurde, hab ich mal ein wenig gebastelt:
zeigt die Verteilung von allen area:highway=* im zentralen Europa. Woanders gibt es die auch noch, aber hier ist die Mehrzahl.
und dieses QGIS Image
zeigt die Situation im Norden von Nürnberg.
In Mapnik werden diese area:highway weiss dargestellt, da sie als area:highway=yes getaggt sind und dem Renderer daher Informationen fehlen. Die Mehrzahl der über 15000 Area-Tags sind aber area:highway= getaggt. z.B. area:highway=primary. Das fehlt mMn nach hier bei Makek’s Tests.
Zudem hatte ich angenommen, dass die Areas die aktuellen Straßen ersetzen würden; hier sind aber beide Datensätze überlagert. Irgendwie noch nicht ausgegohren - aber dafür sind Test ja da.
Um Frederik ein wenig zu ärgern, mach ich das mal in meinem Dorf anders. 
Ich erwarte aber Beschriftungsprobleme und das Routing könnte auch Ärger bekommen. (Routing über Plätze hatten wir ja schon)
Gruss
walter
Nein, natürlich nicht. Dann könnte man alle OSM Navis in die Tonne kloppen.
http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway
naja, wenn das nicht TvdR ist Sorry, aber hier wird ewas “hingemalt”, was dann gut aussieht aber ansonsten keinerlei Funktion hat. (*)
Eine Lösung, wo die Highways durch Areas erstetzt werden oder auch nur area=yes dazu bekommen, erscheint mir langfristig sinnvolller. Ist natürlich schwierig - besonders für die Router - aber bei den Plätzen/Fußgängerzonen wurden da doch schon vernünftige Lösungen erreicht, oder?
Gruss
walter
ps: sollte ich mich irren, könnt ihr mich ja aufklären. Soo tief steck ich da nicht drin - und kann deshalb wohl auch einfacher über den Tellerrand blicken.
*) Nun denn, im Wiki wird das sogar als Vorteil herausgestellt.
Ich sehe das bis auf Weiteres analog zu waterway=river (Linie) und natural=water|waterway=riverbank (Fläche).
Da braucht man die waterway-Linie weiterhin wegen der Flussrichtung.
Ebenso braucht man die highway-Linie bei allen Richtungsabhängigkeiten, vom area-Routing ganz zu schweigen.
Theoretisch bekäme man eine Richtung per Umlaufsinn der Fläche hin, aber das wäre eine Riesenumstellung und - fehlerträchtig.
Moin,
was kann man mit dem “Malen nach Zahlen” eigentlich erreichen, dass nicht auch durch ein simples width=* ersetzbar wäre?
Der Vergleich mit Flüssen hinkt ja an der Stelle, dass Strassen “künstlicher” und regelmäßiger daherkommen.
Gruss Christian
Jo, das ist wohl der pragmatische Ansatz.
Gut, mach ich so weiter.
Frage @marek: welche 3 Renderer stellen das dar? Ich dachte erst, Mapnik wäre dabei aber irgendwie ziert der sich bei mir im Dorf.
Mapnik rendert nur “highway=xxx; area=yes” aber das geht ja nicht.
Gruss
walter
Ungeeignetes Tagging bei Flüssen dürfte weniger Ärger machen als bei Straßen.=> Aufpassen!
Mich würde vorher eine vernünftige Definition von “Straßenfläche” interessieren. Soll das hier nur die eigentliche Fahrbahn für den motorisierten Verkehr sein? Gehört die Verkehrsinsel nicht dazu, aber der Gehsteig schon? Oder ist der Gehsteig eine eigene Fläche? Oder wird der Rad-/Gehweg bei unterschiedlichem Oberflächenbelag in zwei Flächen aufgeteilt??
Oder wäre es nicht sinnvoller die Gehsteigkanten (fürs Blindenrouting) zu erfassen?
Was macht das higway=stop an der Haltelinie (http://www.openstreetmap.org/node/3655368618)? Das Stoppschild steht doch ersatzweise an der Ampel (http://www.openstreetmap.org/node/25418955)!? Und die Ampel sollte doch gleichzeitig am Fußgängerüberweg stehen (http://www.openstreetmap.org/node/25418955). Die Routinganweisung könnte momentan so lauten: Stoppschild in X Metern - Fußgängerüberweg nach 6 Metern - Ampel nach 13 Metern). Das kann man nicht wollen.
Und da gibt es noch “street:area=traffic_island” (Way: 360837675 | OpenStreetMap; offenbar, wenn gepflastert). Ansonsten wird gerne “landuse=grass” für Fahrbahnteiler genutzt (wenn dort irgendetwas wächst; halte jedenfalls ich für suboptimal).
Alles in Allem etwas chaotisch und Fragen über Fragen 
Nimm es nicht persönlich Marek. Grundsätzlich kann das jeder gerne eintragen und vielleicht helfe ich ja auch mit - aber nur, wenn das Gesamtkonstrukt schlüssig ist.
Ich verstehe zum Beispiel nicht, warum http://www.openstreetmap.org/way/360833812 im nördlichen Bereich innerhalb des Kreuzungsbereichs liegt und im Südlichen außerhalb?
Was willst Du einem Router mit diesem Weg sagen: http://www.openstreetmap.org/way/361113017 (überschneidet im südlichen Bereich den gemappten Gehsteig ohne genmeinsamen Punkt und endet im Norden im Nichts)?
Und warum nutzt Du für so ein Detailmapping in Nürnberg nicht die hochaufgelösten Luftbilder? Potlach und Bing ist dafür doch ein klein wenig “untermotorisiert”.
Erlangen würde sich da anbieten
Damit kann man erreichen, dass detailverliebte Anfänger Verkehrsinseln nicht als Fußgängerzone eintragen (Way: 306751274 | OpenStreetMap v1)
Es sind beileibe nicht alle Straßen und Wege parallele Linien (nur mal so als Beispiel: http://binged.it/1MBUKcC oder http://binged.it/1I3i1A4)). Width ist eine Generalisierung, die für Router sicherlich leichter auszuwerten wäre.
Für eine präzise Erfassung solcher Details (Gehsteigkanten, Parkbuchten etc.) unterhalten die größeren Stadte wie München und Nürnberg sogar eigene Vermessungsabteilungen. So sinnlos kann es also hoffentlich nicht sein
Allerdings benötigt man da hochpräzise Luftbilder - und die gibt es nicht überall und die werden nicht zuverlässig in der Zukunft zur Verfügung stehen. Darin sehe ich eines der schwerwiegendsten Probleme.
PS: Persönlich wende ich mich immer mehr von der Standardkarte ab (und ich zeige sie Interessierten auch nicht mehr als Erstes!), weil das ewige “auch das soll noch dargestellt werden” mittlerweile ein eher abschreckendes kontrastschwaches kunterbuntes Kartenbild ergibt. Für solche Details blende ich viel lieber ein Luftbild ein 