[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