[Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)

[Sebastian Hohmann]

Dimitri Junker schrieb:
>> Und wo steht das?
> 
> 
> Nirgendwo, aber es gibt Indizien. 1. Ist alles in OSM symetrisch es sei denn 
> es ist speziell markiert. Jedem Mapper war bisher klar, daß wenn er 
> cycleway=track setzt ein Router diese Info für beide oder für keine 
> Richtung nutzen kann, es also besser ist bei nur einseitigem Fahrradweg 
> dies anders zu mappen (Extraweg) da es sonst wertlos ist. 
> Da es für Einbahnstraßen extra die opposite-Tags gibt folgt, daß ohne dort 
> von einem Fahrradweg ausgegangen werden kann der in gleicher Fahrtrichtung 
> benutzbar ist wie die Straße. Das bedeutet zwar alles nicht, daß irgendwer 
> das so definiert hat, aber da sich viele Mapper wohl ähnliche Gedanken 
> gemacht haben werden es viele wohl so genutzt haben als ob es so definiert 
> wäre.
> 

Ja.. ;) So wie häufig bei OSM (gerade bei 'älteren' Tags) ist es 
hauptsächlich Interpretationssache. Jemand anders kann das vielleicht 
wieder komplett anders sehen.

>> Jedes Schema hat seine Vor- und Nachteile. Hauptsache wir entscheiden
>> uns mal für eins das funktioniert.
> 
> 
> Ich würde bei Deinem Proposal zuerst einmal das right/left/both 
> zurückstellen.
 >

Wie soll ich das machen? Das Ganze basiert doch darauf.

> Wenn bei meinem Proposal was rauskommt kannst Du es dann 
> daran anpassen. Das würde die Diskussion zu Deinem Proposal auf die 
> wesentlicheren Teile beschränken, ob das right/left vorne oder hinten steht 
> ist Dir wahrscheinlich relativ egal wenn es denn funktioniert.

Ich hätte es schon gerne so wie es im Moment in meinem Proposal steht 
(deshalb stehts ja auch so da), wenn es aber gute Argumente für ein 
anderes Schema gibt (also das tatsächlich BESSER nicht nur anders ist), 
dann kann man es natürlich ändern.

> Allerdings wäre die Methode mit right/left als value nicht mit meiner 
> Alternative 1 vereinbar die Du eigentlich favorisierst. Vereinbar wäre
> cycleway:right=yes
> usw. Wenn Du wirklich das Vorhandensein und den Typ trennen willst.

Hmm, um das Trennen von Vorhandensein- und Typ-Definition geht es mir 
weniger, eher darum dass es einfacher ist, wenn man nicht so viele 
mögliche und lange Hauptschlüssel hat.

Zudem eine Definition (also auch Vorhandensein) mit..

cycleway:left=track

..ein bisschen ähnlich wäre wie:

parking=multi-storey

Statt:

amenity=parking
parking=multi-storey

Der Vergleich hinkt ein bisschen, da 'amenity' eher eine größere 
Kategorie ist. Aber wenn man 'cycleway' als Kategorie ansieht und 
'cycleway:left' als ein möglicher Wert davon, ist es doch wieder 
ähnlich. Wobei man das amenity=parking vermutlich dafür angibt, um 
zunächst mal die Informationen 'amenity' und 'parking' zu haben, ohne 
sich um die Details kümmern zu müssen. Und man kann eben alle 'amenity' 
auslesen, ohne die einzelnen Werte kennen zu müssen. Genau das mache ich 
auch, bloss eben auf einem viel kleineren Level. Insofern wäre es wohl 
eher möglich es anders zu machen, auch wenn es mir irgendwie nicht gefällt.

> Alternativ könnte ich auch folgendes vorschlagen:
> 
> Will man verschiedene Eigenschaften (values) für beide Seiten setzen kommt 
> das right/left/both in den Key, will man die Existens eines Keys, der also 
> sonst mit yes gesetzt würde auf eine Seite beschränken wird statt yes right 
> oder left benutzt.
> 
> Sag mir Bescheid ob ich dies zusätzlich aufnehmen soll. Schließlich soll 
> mein Proposal kein Widerspruch zu Deinem sein, sondern den right/left 
> Anteil nur verallgemeinern.
> 

Du meinst also genauso wie in meinem Proposal? Bei Features die als Wert 
definiert werden, könnte es aber problematisch werden:

highway=bus_stop

Müsste dann entweder heißen:

bus_stop=right

Oder:

highway:right=bus_stop

Vielleicht ist es garnicht so gut möglich eine allgemeine Methode zu 
definieren, da es allgemein bei den Tags keine festgelegte Systematik 
gibt, sondern eben alles so gemacht wird wie es gerade passt.

Gruß