[Talk-de] guidepost
Mirko Küster
webmaster at ts-eastrail.de
Di Jan 12 16:32:28 UTC 2010
>> Ein Guidepost macht im Routingablauf und
>> insbesondere als access keinen Sinn, warum muss der trotzdem dahingehend
>> ausgewertet werden?
> Eigentlich steh ich der Sache eher neutral gegenüber, aber das ist Naiv!
> Immerhin ist "bicycle=yes" ohne irgwendwelchen kontext etabliert als "da
> dürfen Fahrräder durch". Es gibt keine "access"-Tags, die *zwingend*
> wären.
Ja, etabliert, weil einst so niedergeschrieben und man kannte es nicht
anders. Man hat aber damals noch nicht daran gedacht, dass man ein
Fahhrad=Ja (Nicht Fahrrad darf da durch) auch noch anderweitig gebrauchen
könnte und so ein neutrale Aussage auf den Anwendungsfall
Zugangsbeschränkung festgenagelt. Nun kann man ewig und drei Tage darauf
bestehen das bis zum sannkt Nimmerleinstag so stehen zu lassen, oder man
reformiert endlich mal aufgrund der Erfahrungen und Visionen von heute. Ich
hatte schon einige Besipiele gebracht wo sich mehrere access überschneiden
und aufgrund des Umstandes das nur ein Tag geht nicht darstellen lassen.
Auch nicht durch Trennung mit Semikolon, weil man damit nicht
Tagübergreifend die Verbindung zwischen den Werten aufzeigen kann.
Das klappt nur solange wie Schlüssel1=Wert1;Wert2;Wert3 exakt zu
Schlüssel2=Wert1;Wert2;Wert3 steht. Ein kleiner Fehler reicht und es käme
beispielsweise ein Schlüssel1=Wert3;Wert2;Wert1 exakt zu
Schlüssel2=Wert2;Wert1;Wert3 und schon passt es nicht mehr, was aber ausser
der Erfasser selbst keiner erkennen kann. Da gab es bisher keine Antwort zu.
Ignorieren hilft aber nicht das Problem zu lösen, Hauptsache man muss nichts
ändern.
Und ich sehe überhaupt keinen Grund eine konkrete Anwendung so zu stricken,
das man eben nur routingrelevante Dinge einbezieht, wo ein Guidepost mit
bicycle=yes schon in der Vorverarbeitung rausfallen würde. Wer das nicht
macht wird bei einem so offenem System wie unserem immer gehörig die Kacke
greifen. Überall finden sich irgendwelche Dinge die nirgends dokumentiert
sind und bei einer Auswertung über alles mit einbezogen würden.
> Selbst ein späterer Mapper könnte bei einem Node, der Teil eines Weges ist
> davon ausgehen, dass dieses Tag einfach an dem Weg hätte stehen sollen und
> "korrigiert" das dann.
Das ist naiv. Dann hat er die zum Tag gehörende Erklärung nicht gelesen, den
Kontext nicht erfasst und durch Unwissenheit murks gemacht. Das passiert
weitaus öfters. Promintestes Beispiel ist highway=service vs.
highway=services. Das kleine s am Ende entscheidet über Zufahrsstraße oder
Raststätte. Wer da blind über Tagwatch oder OSMDOC agiert, bekommt die
highway=services oft als Schreibfehler von highway=service präsentiert. Wer
dann den Hintergrund nicht kennt, macht fix aus Raststätten Zufahrsstraßen.
> Anders sähe es aus, wenn bicycle=yes *immer* ein anderes Tag brauchen
> würde um
> Sinn zu machen. Das ist aber nicht so.
Dem ist aber sowas von so. Ein bicycle=yes / no kommt nicht aus irgendeiner
Eingebung sondern muss einen Grund haben. Zusammen mit Highway entspricht
das einem Gesetz oder einem Schild vor Ort. Als Punkt beispielsweise
zusammen mit einer Barriere. Durch was ist denn ein bicycle=yes ohne alles
begründet? Standest du da und eine Stimme sagte zu dir, dass dort Fahhräder
lang dürfen? Und ja, es gibt auch unfertig gemapptes. Genau dafür gibts aber
Note oder FIXME, oder man kann es anderweitig dokumentieren. Du kannst
natürlich auch 3 Punkte als Wegverländerung, Access ohne alles und eine
Schüssel mit drei Klösen malen. Da muss ich aber damit rechnen das kaum
einer versteht was dahinter stecken soll. Denn das ist nunmal nicht üblich
und undokumentiert kanns keiner erahnen.
Und in dem Fall ziehts auch nicht. Guidepost mit bicycle=yes ist klar
definiert und dokumentiert und soll eben nicht für access stehen. Der Fall
ist eigentlich klar.
Gruß
Mirko
Mehr Informationen über die Mailingliste Talk-de