Machs besser, ich halte dich nicht davon ab. Nur Rumgemotze kann ich auch. Außerdem war es auch noch Baustelle, die sich leider schlecht darstellen lässt.
Nö, war keine Hilfe, Aber Danke dafür. War nur Einarbeitung. Ich versuche, die “Ecke” noch fertigzustellen.
P.S. In der Hoffnung, auch in NRW demnächst “was zu sehen”. Der Server scheint gut zu funktioniern mit den 1 h Updates.
Ich spreche das erneut an.
Mittlerweile wird in der poln. Version auch a:h=traffic_island+landuse=grass farbig unterstützt. service roads, bus und amenity=parking_space als Area gezeichnet bekommen auch leicht anderen Farbton als die üblichen a:h.
http://osmapa.pl/w/area/?lat=53.43303&lon=14.51194&zoom=19&ol=BPo
Ich mag die Darstellung mit der Visualisierung der turn:lanes : http://osmapa.pl/w/area/?lat=52.39961&lon=16.93551&zoom=18&ol=PEFGABR
Sie ist leider in der Dt. Version noch nicht implementiert. Kommt aber.
Neuerdings gibt es sogar area:highway=bridge. IMO total falsch, eine Brücke ist kein highway.
https://www.openstreetmap.org/browse/way/268663549
Taggen für den Renderer!
Welcher Renderer? Höchstens Tagging für die Zukunft. Aber da gibt es ja genug “tote” Beispiele. Dieses tote Tagging wartet eben solange, bis es ins Leben gerufen wird. Genauso könnte man jedes 3D Tagging so bezeichnen. Tagging für den Renderer. What else?
Einerseits werden IMO unnötige MP-Relationen gemappt, mit der Begründung Vermeiden doppelter Linien und damit weniger zu speichernde Daten, andererseits wird totes Tagging produziert, was den Datenumfang erheblich vergößern dürfte.
Tagging für die Zukunft oder nicht? So manche haben da ihren eigenen Kochtopf.
Das Wiki ist ein inkonsistentes Gemurkse.
Beispiel:
http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area#Tagging
The existing approach, highway= with area=yes can be extended with addition of drawing street surfaces with the tagging:
area:highway=value Values are the same as for the current highway=* tag, under the lists “roads” or “paths”.*
*area:highway=yes for unknown road type. *
Dann findet weiter unten area=highway=bridge usw.
BTW, area:highway=yes wurde IMO abgelehnt.
Demnach What else? zu urteilen, könnte man das Ganze auch einfach löschen. 
Ja. a:h=bridge brauchen wir nicht, weil schon man_made=bridge existiert.
Mapnik ist nur eines von vielen Programmen, das OSM-Daten auswertet.
Eine korrekte Darstellung in Mapnik beweist nicht, das die Daten korrekt sind.
Eine falsche oder fehlende Darstellung in Mapnik beweist nicht, das die Daten falsch sind.
“highway=" mit “area=yes” wird benutzt, um ungerichtete Flächen abzubilden
(die dann keinen "highway=” zusätzlich erhalten). Für eine Grundsatzdiskussion,
ob Wege als Linie erfasst werden sollen, kommst du 10 Jahre zu spät.
So wie man für Straßenflächen a:h und nicht ein nochmals “highway” verwendet,
so werden dort Gebäudeteile mit “building:part” und nicht “building” getaggt.
Streiche am besten den gesamten Abschnitt “Rendering of bridges”.
“man_made=bridge” ist unabhängig von a:h.
Die Eissenbahnbrücke hat mit a:h auch nichts zu tun.
Bitte streiche auch den Abschnitt über stop lines.
Die Idee ist völlig unausgereift und verwirrend.
Die Datenstruktur passt nicht zu OSM und ist mit bestehenden Renderern nicht darstellbar.
Das Bild Mockup more complex example finde ich unseriös.
Es suggeriert, dass diese Darstellung mit den zuvor genannten Datenstrukturen erzeugt wurde.
Es enthält aber viele Details, die damit gar nicht umsetzbar sind, und widerspricht in Teilen der OSM-Karte darunter.
Vermutlich hast du das Luftbild mit Photoshop nachgemalt.
Ersetzte das Bild bitte durch ein echtes Renderergebnis.
Es würde dem Proposal sehr helfen, wenn man es auf den Kern a:h beschränkt.
Ich bitte, nächste Teile des Proposals möglichst schnell zu erneuen, weis sie veraltet sind, und deshalb Mappers in einen Irrtum verfallen.
Dieses Bild - area:highway=bridge → man_made=bridge
Dieses Bild - crossing=y_junction → junction=y_junction
Und mit diesem Satz (hier) ist etwas falsch:
Erledigt.
Danke für Deine Aufmerksamkeit!
Neu: rendering von way - highway=cycleway + cycleway=crossing
http://osmapa.pl/w/area/?lat=51.13176&lon=17.06414&zoom=19&ol=BPoR
z
Yebra Streifen links oben ist falsch getaggt um den Unterschied aufzuzeigen.
DEmnächst kommt auch der Rendering von bicycle@path
Nachdem alle Tests abgeschlossen sind kann man auch die Dt. Seite upgraden.
Wow, das Thema ist ja ganz schön in Fahrt gekommen. Ich würde mich auch aus 3D-Sicht sehr über Straßenflächen freuen. 
Was ich mir noch wünschen würde, wären einige Klarstellungen in Detailfragen. Speziell wäre es aus meiner Sicht sinnvoll, die folgenden Hinweise zu ergänzen:
Parallele Ways sollten jeweils ihre eigene Straßenfläche haben, z.B. bei Autobahnen, aber auch bei mit separaten Way gezeichneten Radwegen etc.
Flächen für Spuren (im weiteren Sinne), also z.B. area:highway=bus und area:highway=shoulder, sollten innerhalb der Straßenfläche liegen. Für 2D-Renderer macht das keinen Unterschied, aber für 3D wäre es eine große Hilfe.
Vielleicht ist insbesondere der erste Punkt sogar offensichtlich, aber dem Programmierer erleichtern solche Annahmen die Arbeit deutlich.
Absolut richtig. Kannst Du mir helfen und diese Hinweise in dem engl. Proposal einbauen?
Auch finde ich dad das Rendern der area:highway=emergency viel besser gelingen könnte, wenn man Deinen Vorschlag mit der Richtung einer Textur der Fläche zuweisen könnte. Ich habe jetz kein Beispiel zur Hand, aber es ist ofensichtlich das ein Spitzdreieck mit Kreuzschraffur schlecht aussieht, wenn man die Schraffur parallel zu einer der längeren Außenkanten hat.
Mit der Schraffur hast du absolut recht. Ich könnte mir zwar vorstellen, dass man die Schraffur automatisch so dreht, dass sie annehmbar aussieht, aber wenn man die Richtung so haben will, wie sie in der Realität ist, dann braucht man zwangsläufig ein direction-Tag o.ä.
PS: Ich habe die Klarstellungen jetzt im englischen Proposal ergänzt.
Lieben Dank für die Hilfe Tordanik!
JOSM hat doch die Fuktion die Einem erlaubt die Richtung zu messen, oder?
Falls ja, dürfte ich Dich noch bitten in dem Proposl auch den Tag für die Drehung der Schraffur einzubauen?
Du hast ja daran gewerkelt also kannst das sicherlich besser als ich.
Grüße,
Marek
Ja, JOSM hat einen Winkelmesser eingebaut. Benutze ich oft.
Habe jetzt mal einen Abschnitt zur Richtungsangabe für die Schraffur eingebaut. Ich hoffe das passt so.
Passt, sehr schön,
vielen Dank Tordanik!
Marek
Danke für Deine Änderungen!
Ukrainische Version wurde nun auch aktualisiert.
3 kleine Fragen:
Ich tagge momentan den Stadtpark Nürnberg (Fußwege).
Wenn ein width tag angegeben ist, ist dieser eigentlich durch das Flächentagging sinnlos. Stehenlassen ?
Eine Fußgängerbrücke: Beide Tags? man_made=bridge + area:highway=footway ?
Ist mir immer noch nicht klar: Surface tagging auf der Fläche? Darf man auch schon Farben hinzufügen? Oder zu früh?
3D Elemente lassen sich mit der Fläche auch viel leichter hinzufügen. (Geländer, Zäune etc). Außerdem füge ich Bäume hinzu (die sich nicht auf der Strassenfläche befinden sollten).
Huch, noch eine vierte: Wie soll man mit flächigen Treppenwegen umgehen? Wichtig! Keine Treppe als building:part. Sondern Gelände. Auch nicht Standardstufenlänge.
Neue Ideen dazu?
