[Talk-de] guidepost

[Mirko Küster]

> Dann hast du wohl das falsche Wort verwendet. Valide heißt
> gültig/richtig, was du vielleicht meinst ist üblich.

Ich verwende aus gutem Grund keine Wischi Waschi Umschreibungen. Wir sind 
teilweise auf einer Stufe wo undokumentierte Paralelentwicklungen mehr 
verwaschen und verwirren, die Entwicklung eher behindern als fördern. 
Deswegen werde ich mich da auch nie hinstellen und zu alles und jedem sagen 
das es kein Falsch gibt und die Leute noch dazu ermutigen auch teilweise 
überflüssige Paralelentwicklungen zu verfolgen, die dann undokumentiert 
nichtmal als solche erkennbar sind.

> Das hat mit Chaoseinstellung überhaupt nichts zu tun. Das hat was damit
> zu tun, das vieles von den Problemen wie z.B. die Endlosdiskussionen bei
> Radwegen genau aus dieser Haltung "ich habe recht und du hast Unrecht"
> herkommt.

Da war es schlichtes verwaschen. Als man das ganze einführte hat keiner 
daran gedacht, dass es gefühlte und vorgeschriebene Fahrradwege gibt. Wenn 
ich das dann noch so lasch verfasse ist klar das alle in eine Soße taggen. 
Was danach passierte war nicht besser. Man erklräte den Tag als verbrannt 
und hat den path kurzerhand missbraucht, statt dem eigentlichen Tag gleich 
einen Zusatz für die jeweilige Richtung zu geben. Danach hat man gleich 
wieder designated verbrannt und offical erklärt. Das Ergebniss und der 
Streit ist nur die logische Folge. Nun haben wir 3 Taggingmöglichkeiten für 
ein und dasselbe. Und das wird sich auch nie ändern, wenn man sich nicht 
klar zu einem richtig und falsch bekennt.

> Wenn wir Probleme sehen, sollten wir versuchen diese zu lösen. Das kann
> aber nicht darin bestehen zu sagen: "du siehst das falsch, und du mußt
> dich anpassen", sondern: "ok, da ist ein Problem, was können wir machen
> um es möglichst schmerzfrei für alle zu lösen".

Du hast noch immer kein klares Problem benannt, nur ein mögliches 
konstruiert. Ich habe hier noch keine Stimme gehört die ein wirkliches 
existentes Problem benennt. Was sagen die wirklich betroffenen, die Routing 
Maintainer? Solange keiner erklärt das ein bicycle=yes auf einem Guidepost 
in der Praxis zu nachvollziehbaren Problemen führt, solange ist es schlicht 
keines.

> In den Map Features ist dokumentiert, das bicycle=no bedeutet, daß man
> da nicht mit dem Fahrrad durchdarf. Es ist dort *nicht* dokumentiert,
> daß dieses Tag nur in Verbindung mit xy eingesetzt werden muß.

Auf welcher Seite? Unvollständige und wiedersprüchliche Angaben sind im Wiki 
Alltag. Es gebietet aber die pure Logik das ein Verbot nicht aus heiterem 
Himmel kommt. Entweder steht ein Schild, oder eine Barriere. Ein bicycle=no 
ohne alles fällt wohl unter göttliche Eingebung, und das ist orakeln.

> Wenn ich ein Schild tagge, hat das mit Orakeln irgendwie nichts zu tun.

Wir taggen bis auf Ausnahmen wie Stopp Schilder keine Schilder ansich, 
sondern verwerten die Information, welche wir dann mit den richtigen Tags 
auf das richtige Objekt legen.

> Ist dir bis heute nicht aufgefallen, daß das durchaus in der Realität
> auch mal anders aussieht und das "Ende-Schild" schlicht auch mal
> vergessen wird?

Das ist Richtig. Normal gilt dann bis zu nächsten Einmündung, wo das keine 
Anwendung findet ist es ein Fehler Straßenbaubehörde, welche ich dann darauf 
hinweisen kann und was dann vielleicht berichtigt wird. Das ist dann aber 
nicht mein Problem, was ich dann genauso Fehlerhaft als Krücke umsetzen 
muss. Fehler sind immer mal drin. Sich gegenseitig ausschließende 
Verkehrszeichen, die Dr. Barsch Straße, wo einer die B Folie abgekratzt hat, 
oder wie zuletzt in Halle, wo der braune Abschaum dutzende Straßenschilder 
mit Rudolf Heß Straße Folien überklebte. Deswegen taggen hier Menschen und 
keine Drohnen. Wir taggen die Realität, die hat aber auch mal Fehler, die 
man hinterfragen kann und nicht leidenschaftslos in die DB Prügeln muss.

> Wenn Mapper A ein Schild einträgt und Mapper B danach mehr Infos hat und
> die Infos vom Node nimmt und an den passenden Wegabschnitt hängt habe
> ich damit überhaupt kein Problem. Wenn du jetzt aber kommst und sagst, A
> hat was falsch gemacht weil er es nicht gleich "richtig" gemacht hat -
> damit habe ich ein Problem.

Wenn da ein note=FIMXE etc. dranhängt und das so als unvollständige Angabe 
kennzeichnet, ist das ja noch zu verschmerzen. Ansonsten muss ich davon 
ausgehen das hier ein Fehler vorliegt, den ich berichtige oder entferne. Die 
kann man nicht bis zum Sankt Nimmerleinstag so stehen lassen, nur wegen 
eventuell und vielleicht. Siehe Garrys Checks. Wenn es ans aufräumen geht, 
hört man nur ein lautes Pfeifen. Die wenigen die sich dem mal annehmen 
kommen dann nicht mehr hinterher. Die Fälle die mir so unterkamen waren 
allerdings andere. Ganze Stadtteile wo Verkehrszeichen vollständig getaggt 
neben den Straßen lagen, die gleichen Informationen teilweise nochmal 
korrekt auf den Wegen selber. Kannst du wieder unüblich nennen, ich nenne 
das schlicht falsch.

> Es gibt da zwei unterschiedliche Vorgehensweisen:
>
> a) Ersetzung: class weg, highway hin - klappt meist ohne größere
> Probleme, ist halt Arbeit und dauert ein bisschen
>
> b) Umwidmung: bisherige Definition umdefinieren, erweitern,
> einschränken, Defaults ändern, ... - gibt meist einen ziemlichen und
> langanhaltenden Ärger

Es geht nicht ohne Schmerzen. Wenn wir verlässliche und brauchbare Daten 
wollen, nicht in einer Niesche herumkrauchen wollen, muss man mit den 
Anforderungen mitgehen und suboptimal werdene Tags reformieren und notfalls 
das Pferd nochmal neu Satteln. Es wird immer welche geben die bei egal 
welcher Entscheidung rumnölen. Mit Status Quo bewegst du dich aber in den 
Stillstand.

> Ich habe überhaupt nichts dagegen, wenn wir das Tagging ändern wenn
> etwas nicht paßt. Aber es so zu ändern das man schon gleich wieder
> wissentlich in den nächsten Ärger reinläuft - da hab ich was gegen.

Es gibt nicht den einzig wahren Weg mit dem alle zufrieden sind. Egal welche 
Entscheidung fällt, es gibt Kontra. Frederik hatte da letztens eine gute 
Umschreibung im Zusammenhang mit dem OSMF Rat. In der Entscheidungsfindung 
hat die effizienteste Lösung Prirorität, nicht die wo am wenigsten Gemeckert 
wird.

> Daher halte ich es für ungeschickt, ein Tag mit einer spezifischen und
> etablierten Bedeutung wie bicycle=yes/no auf einmal für etwas anderes
> wiederzuverwenden. Das fällt nämlich klar unter Kategorie b).

Ein bicycle=yes/no ist neutral und sagt nur aus das es in irgendeiner weise 
für Fahrräder geeignet/ungeeignet ist, näheres ist offen. Bestens geeignet 
wo eine nähere Beschreibung aus der Logik folgt oder nicht weite beschrieben 
werden muss. Beförderung im ÖPNV, Fahrzeugtypen die in einer Werkstatt 
bedient werden anstatt das man für jede Werkstatt ein exclusives Haupttag 
braucht, Treppen mit Rampen... die Möglichkeiten sind vielfach. Die 
Verbindung mit access ist eine gemachte, einzig aus dem Grund, weil man 
damals noch nicht weiter dachte und das einfachste und kürzeste genommen 
hat. Das ist kein Naturgesetzt was sich nicht ändern lässt.

Heute sind wir schlauer und die Anforderungen gestiegen. Ein schlichtes 
vehicle=yes/no ist in vielen Fällen unzureichend. Mitlerweile sind z.B. 
einige Straßen für festgelegte Zeitfenster für Skater offen. Mit einem 
inline_skates=yes kommst du da oft nicht weiter. Mit hour_on/off klappts 
auch nur, wenn nur ein exclusives Verbot besteht und kein weiteres hinzu 
kommt. Ist auf der Straße beispielsweise noch Markt, musst du dafür noch 
Sperrzeiten am selben Weg unterbringen. Wehe wenn noch ein LKW Sperrfenster 
dazu kommt. Geht so nicht.

Nun kann man einen Latte an Tags dranhängen oder zwölfunddreißig Relationen 
basteln, oder men reformiert das ganze auf eine Syntax, die es kompakt und 
unabhängig verpackt, wobei man in einem Abwasch gleich den Tag ansich 
konkretisieren kann. Das könnte mal so ins blaue folgendermaßen ausshen:

access: Mo-So 21.00-23.00:inline_skates=yes
access:Mo-Fr 00.00-07.00,13:00-00.00; Sa-Su off:hgv=no
access:We 08.00-13.00:all=no

Ja, alles Mist. Und damit ja keiner Meckert, lassen wir alles so wie es ist. 
Und da wo man Fahrräder geeignet/ungeeignet jenseits von Access brauchen 
könnte, erfindet man stattdessen für alles einen weiteren Tag. 
guidepost:*=yes/no, repair:*=yes/no, bus:*=yes/no, tram:*=yes/no, 
train:*=yes/no, ferry:*=yes/no , stair:*=yes/no...

Gruß
Mirko