[Bremen] Tobias mal wieder destruktiv (2)

[715371]

Am 17.12.2014 um 14:27 schrieb Ulrich Lamm:
> 
> Am 17.12.2014 um 12:29 schrieb 715371:
> 
>> Am 17.12.2014 um 09:33 schrieb Ulrich Lamm:
>>> Änderungssatz: 27520617
>>
>> Die Radwege waren großteils von mir eingezeichnet und getaggt. Am
>> Tagging wollte ich etwas ändern und das hatte ich auch gemacht, bis du
>> selbst es geändert hast. Das hier ist nur ein revert zu dem was ich
>> gemacht habe.
>>
>>> Weg: Auf den Häfen (284118039)
>>
>> Wo ist das Problem? cycleway=opposite_track, fertig.
> Zum Einen hattest du notorisch oneway:bicycle=no getaggt, was nur angemessen ist, wenn auf der Fahrbahn in beiden Richtungen geradelt werden darf.

Kontext? Woran getaggt?

Geht es um solche Objekte wie highway=path/cycleway?

Auch wenn ich nicht mehr so sehr davon überzeugt bin: Weshalb ist das
falsch? Für Fußgänger ist der Weg keine Einbahnstraße, das oneway=yes
könnte es aber dazu machen. ;)

BTW: Das habe ich nicht notorisch gemacht, sondern einmal für "meine"
Sachen aus obigen Grund.

> 
> Zum Anderen ist ohne separate Zeichnung nicht darzustellen, Wo und wie das mit dem Linksabbiegen in die Kleine Meinkenstr.  und auf den linken Radweg des Rembertirings geregelt ist.

Was wurde denn da nicht deutlich?

Ich schaue es mir einfach nochmal vor Ort an. Aber das was ich da sehe
finde ich nicht gut.

https://www.openstreetmap.org/#map=19/53.07611/8.81889

Was willst du mit diesen vielen highway=cycleway sagen?

> Last not least ist angesichts der immer noch großen Zahl von Falschfahrern die schon jetzt von zwei gängigen Renderern erkannte Notierung die bessere. 

1. Nenne mir die Renderer.
2. Wer sollen Falschfahrer sein? Das ist eine Wertung, die hier nicht
weiterhilft. Meine Edits (manchmal auch reverts) sind auf dem Niveau
von: Vorher hatte ich es falsch gemappt und würde es gerne anders
machen, ich bin gegen die Änderungen eines anderen Mappers die er an
meinen Beiträgen vornimmt und ein Mapper hat so viele Fehler in seinen
Edits, dass ich keine Lust habe alles zu überprüfen.

> (siehe oben: Korrektes Tagging, das von Renderern verstanden wird, ist kein Fehler, sondern bestmögliches Tagging.)

Nein. Genau das nicht. Es geht nicht darum wie ein Renderer etwas
darstellt, sondern ob er es darstellen könnte. (Und es geht natürlich
auch um das was schon benutzt wurde und was die Community für gut hält...)

Das was du meinst ist eher Tagging für den Renderer. Das ist dann in der
Praxis so:
Ah! Renderer XYZ rendert auf meine highway=cycleway mit oneway=yes einen
blauen Pfeil - mit oneway:bicycle=yes nicht. Auch wenn ich eigentlich
vorher für oneway:bicycle=yes war, ändere ich das dann mal lieber
einfach in oneway=yes.

Oder ein prominentes Beispiel an dem auch ich beteiligt bin:
highway=bus_stop obwohl schon das neue Schema (bis auf das) umgesetzt
wurde. Weil dieses neue Schema aber nicht von den meisten Renderern
unterstützt wird, dann einfach den Tag vom alten noch mit dran machen.
Es ist halt geduldet. Solange genug andere es OK finde, kann man da mal
eine Ausnahme machen, finde ich.

Soweit ich das sehe ist separates erfassen broken: Man braucht
relationen um Features von der Fahrbahn zu bekommen (name etc) oder
taggt diese redundant noch einmal an den Radweg.

Damit es ordentlich gerendert werden kann, müsste zumindest die Relation
existieren und die Rollen passen. Das ist aber auf jeden Fall nicht
billig, weil man beim rendern erst einmal noch in die Relationen schauen
muss, ob der Weg nun straßenbegleitend ist oder nicht. Wenn man keine
Relationen benutzt, muss man diese Infos als Tag an die Fahrbahn und an
den Radweg taggen.

Das ist aufwändig. Ich bin dafür, dass man so etwas mal umsetzt, aber
nicht für jede Straße:

Wenn man jeder Zeit die Straße überqueren kann - warum sollte in der OSM
das dann nicht möglich sein. Auch wenn man das per area-relation lösen
könnte, halte ich das für unnötig.

Ich war nun einmal der Mapper, der die meisten dieser separat
eingezeichneten Wege in Bremen erfasst hat. Und das halte ich an vielen
Stellen für unnötig. Es gibt meistens einfach keine weitere Information.