Tordanik machte eine Ankündigung an die
Tagging-Mailingliste mit dem RFC area:highway:
https://lists.openstreetmap.org/pipermail/tagging/2015-August/026278.html
Seit Mitte August hat sich die Anzahl der a:h Elemente in der Datenbank nahezu verdoppelt.
Danke Tordanik!
Grüße,
Marek
Soll die Fläche unter Straßenbahn-Gleisen mit einem besonderen Tag gemappt sein?
Beispiel (bitte Bing-Layer clicken): http://www.sammyshp.de/fsmap/#19/48.03265/37.79137
So sieht das jetzt aus: http://osmapa.pl/w/areaua/?lat=48.03264&lon=37.79139&zoom=19&ol=BP
Warum sind Fahrrad-Linien hier rot, und hier nicht? Ich möchte sie rot sehen, weil sie in Realität so sind 
Siehe Bing hier: http://www.sammyshp.de/fsmap/#19/48.03072/37.78962
Solche Flächen sind normale Kreuzungsflächen weil die autos über solche Elemente fahren dürfen.
In der polnischen Version werden Neuerungen ausprobiert und viele Diskussionen geführt.
Diese und andere Änderungen die noch kommen, wie zum Beispiel Rendering von a:h=taxi, a:h=bus_stop a:h=(footway mit cycleway), besserer Rendering von steps, Abbiegepfelie in kleineren Zoomstufen, Rotation der Texturen z.B. für a:h=emergency +direction=*, Rendering von http://wiki.openstreetmap.org/wiki/Key:road_marking
Also es ist noch viel zu tun für einen einzelnen Mapper.
Deswegen aktualiziert er NOCH NICHT die Deutsche und Ukrainische Version.
Das kommt aber. Wenn jemand von diesem Forum dabei helfen kann wäre ich und Marimil sehr verbunden 
Grüße,
Marek
Edit: sieh Dir dieses Element in 2,3 Stunden auf der osmapa an: http://www.openstreetmap.org/way/368477819
Rot werden area:highway=cycleway gezeichnet, ich weiß nicht ob das bereits in der ukrainischen Version funktioniert, glaube aber schon.
Auf den Kreuzungen nicht, außer kannst du landuse=railway oder a:h=tram benutzten.
Eigentlich ist das test-area. Deine schauen ok aus, siehe auch normaler Benutzung.
“Breaking news” 
man_made=bridge werden im OSM Standard Stil gerendert:
http://www.openstreetmap.org/way/305509688
via @shtosm
Vielen Dank! Es ist nun rot 
Ich schüttele mit den Augen! Was ist das denn jetzt? Wer hat das denn eingebracht? Revolution der Andersdenkenden? Volle Umarmung und schmatz!!!
http://www.openstreetmap.org/#map=18/50.94120/6.96594
Anh.: Na, dann mache ich doch mal die Kölner Brücken fertig…
Alle man_made=bridge werden seit gestern so gerendert.
Wir haben also was bewegt: Die Skizze kennst Du doch → http://wiki.openstreetmap.org/wiki/File:F3DBbridgeTopViev.JPG
Grüße,
Marek
@Marek: Natürlich
Ich werde die Tage eine deutsche Site von http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dbridge erstellen.
Außerdem alle Kölner Brücken mit der Fläche taggen. Jetzt kommt aber hoffentlich auch bald die Trennung in 3D, wobei ich versuche, die Pfeiler gesondert zu taggen. Auf dem Umriss sollten die eigentlich nicht zu sehen sein. Ich hoffe 3D zieht nach.
Die neue Tabelle in http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area finde ich super.
Momentan stolpere ich jedoch mit dem tagging highway=pedestrian & area=yes und hier area:highway=pedestrian. Das beisst sich. Evtl. auch higway=footway + area=yes.
Hier sollte eine Einigung erzielt werden. Durch das parallele Flächenrendering gibt es einen Konflikt.
Richtig. area:highway=pedestrian habe ich nicht vorgesehen, wegen des Konflikts.
Vielleicht hat das der User den ich um die Kodifizierung der Tabelle gebeten habe, doch noch aufgenommen.
Ich entferne das gleich.
Na ja, da kommt mir ein neuer Gedanke. Jetzt werden ja schon die area’s für pedestrian und footway in der Standardkarte gerendert.
Möchte man da die weiteren Wege für die mapnik als area verhindern durch das tagging a:h=X ? Könnte sich in Zukunft als sehr konfliktreiche Konstellation darstellen.
Eigentlich ist das hiesige Flächentagging mit a:h doch prädisteniert für 3D und Flächen in der natürlichen Darstellung (z.B. Farben oder auch Pflasterrendering)
Das kann bestimmt nicht durch die Mapnik geleistet werden. Also muss es erlaubt sein, auf der Strassenfläche neben den Standardwerten für die mapnik auch noch in Zukunft genauere Werte für die Oberfläche taggen zu können, die halt durch verschiedene Maps ausgewertet werden können. Im Prinzip bedeutet das:
Eine Fläche highway=pedestrian + area=yes könnte mit Zusatztags wie area:highway=pedestrian + surface=paving_stones + paving_stones:shape + paving_stones:colour beschrieben werden. Das wäre absolut genial, fände ich.
In der Tabelle steht:
area:highway yes For unknown road type.
Der unbekannte Straßentyp wird doch mit highway=road getaggt. Logisch wäre dann area:highway= road und nicht area:highway=yes
highway=pedestrian + area=yes (a) und area:highway=pedestrian (b) sind zwei Paar Stiefel.
IMO hat (b) an (a) nichts zu suchen. Immer noch nicht begriffen? 
http://forum.openstreetmap.org/viewtopic.php?pid=528397#p528397
Richtig. Ich hab´s geändert.
Eine kleine Idee:
Wir haben das Problem die Parkplätze entlang einer Straße zu taggen wenn sie als Fläche erfasst sind.
Es ist weder amenity=parking noch amenity parking_space
warum nicht: area:highway=parking?
Meinst du nicht, amemity=parking_space könnte man so flexibel auslegen, ggf. ergänzend beschreiben, das es in dieses Schema passt?
Ich meine, wenn du die Flächen immer wieder erweiterst auf noch nicht festgelegte Renderer, wird das ganze sehr inkombatibel zum bisherigen tagging.
Da gibt es ja z.B. auch http://wiki.openstreetmap.org/wiki/DE:Key:parking:lane
Was aber natürlich nicht die eigentliche Parkfläche beschreibt. Diese könnte ja wirklich durch area:highway=parking beschrieben sein, wenn man also auch parking_lane oder parking_space gleichzeitig taggt. Wird aber nur dann funktionieren, wenn der Mapper, der die “Parkfläche” mappt, gleichzeitig den Strassen-tag parking_lane auf diese Fläche abstimmt.
Ich sehe hier wie auch z.B. beim Waldflächentagging eine sehr viel größere Mapping Verantwortung der User (auch der Anfänger - die das evtl. (wahrsch.) übersehen).
Das ginge so lange gut, bis das Proposal nicht approved ist. Danach möchte auch die mapnik mitspielen, wie wir auch in vielen Beispielen in jüngster Vergangenheit gesehen haben.
Die Parkplätze gehören zu den POIs und sollen deshalb die Tags haben, die die Suchen nach ihnen ermöglichen (amenity=parking oder amenity parking_space).
Diese Objekte sollen einen von ober genannten amenity-Tags haben. Irgendein area:highway=? Möglich, aber nur in der Kombination mit amenity=.
Die Suche kann man ausbauen. Was anderes ist entlang der Strasse nach dem Parken zu suchen
und etwas anderes einen überwachten Parking in der Innenstadt.
Ich aktualisierte ukrainische Übersetzung des Proposals und fand etwas interessantes:
Warum sollen wir immer area:highway= benutzen außer highway=pedestrian? Nur denn der Standart Stil es rendert? Wenn der Standart Stil morgen highway=motorway + area=yes rendern wird, werden wir auf area:highway=motorway verzichten? Das ist aber Quatsch!
Ich vorschlage, nur area:highway=pedestrian zu benutzen, ohne highway=pedestrian + area=yes.
Vielleicht highway=pedestrian + area=yes für “deprecated” erklären.
Es geht nicht nur darum, was gerendert wird und somit auf der Karte sichtbar ist, sondern auch, wie es für andere Zwecke taugt - ich denke hierbei besonders an Routing.
Ein Routing über Plätze (wenn vorläufig auch nur am Rand entlang) ist oft notwendig. Das betrifft Fußgängerzonen genauso wie highway=service und manche Wohnstraße => “echte” Plätze. Deswegen highway=* und area=yes.
Straßenflächen dagegen dürfen als Fläche nicht routbar sein. Wo soll der Router entlangführen? Außenrand, Innenrand, eigentliche Linie? Außerdem wird ein Router in Kurven auf die innere Straßenseite wechseln, wenn ihm das kürzer erscheint - und das nicht ohne störende Ansage. Zumal bei Flächen kein oneway=yes oder punktförmige barrier=* wirken. Deshalb ist es wichtig, die Straßenflächen (area:highway=* für’s Auge) von den Plätzen (highway=* und area=yes für’s Routing) zu trennen.
Wenn ein Router wegen Plätzen anfangen muss, area:highway=* auszuwerten, kann er diese nicht mehr von den Straßenflächen unterscheiden…
Fazit:
good: highway=pedestrian und area=yes
bad: area:highway=pedestrian
good: area:highway=motorway
bad: highway=motorway und area=yes
Auf keinen Fall ist highway=pedestrian + area=yes “deprecated”! (nur für die übereifrigen Ästheten ohne technischen Bedacht, die gleich das Wiki ändern würden)
Garmin-User,
über Routing über Plätze - ich bin mit dir einverstanden. Nebenbei gesagt: gibt es eine Realisierung?
Aber, wie soll ich die Fläche dieser Straße mappen:
http://www.openstreetmap.org/way/23539477
Auch highway=pedestrian + area=yes? Das finde ich nicht so gut, weil in Realität nur eine Fusgängerstraße existiert, und wir so in OSM-Datenbank zwei entsprechende Objekte haben werden.
Hier ergibt sich auch die Frage, ob man bei solchen highway=pedestrian einen Flächerouting braucht. Meiner Meinung nach nicht. Das ist doch kein Platz!
