Vor allem der kommentar von gsperb man solle einfach von den Seiten des Verkehrsverbundes kopieren… Der User ist mir zuvor schonmal aufgefallen das er alle meine Bugs relativ schnell fixt auch wenn sie relativ weit auseinander liegen. Auf Nachfrage hab ich nur die Antwort bekommen das er auf den Weg nach Hause mit dem Motorrad Bugs abfährt und ich das mit dem Urheberrecht lockerer sehen soll…
Ich halte das generell mit den Buslinien (im Gegensatz zu Bushaltestellen) für unsinnig wenn man nicht eine Datenquelle hat die man übernehmen darf, da sie genauso schlecht physisch greifbar sind wie Grenzen, Postleitzahlen etc.
Ich habe diesen bugreport hinzugefügt und der Bug ist mir bei dem dir angesprochenen Luftbildermapping aufgefallen. Das kann man relativ gut dazu nutzen zumindest einige Daten mal zu überprüfen ob sie generell Sinn machen. Selber nachprüfen fällt mir schwer da ich zur Zeit nicht in Erlangen wohne.
Manchmal hat man halt einfach keine Lust vor Ort zu gehen weil man wo anders ist, es zu kalt/warm ist. Selbst mit Luftbildermapping kann man noch sehr viel Grobes dazutragen, wie Häuser oder Wälder (in Ländern wie Schweden fehlen auch noch etliche Straßen). Was mir ein bisschen fehlt wäre ein task manager um mal wirklich ganz Deutschland einfach mit grundlegendem wie Häuser abzudecken
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.
@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.
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?
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
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.