>> 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 _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de