[Talk-de] Gratulation!

[Ulf Lamping]

qbert biker schrieb:
>> Wenn du warten willst, bis die OSM Community eine Lösung für deine 
>> Probleme gefunden hat, wirst du wahrscheinlich lange warten.
> 
> Um was gehts denn bei OSM? Der einzelne kann nicht die Welt
> vermessen. Auf der einen Seite wird gejubelt, dass OSM in 
> jeder Hinsicht besser waere als alles andere und wenns konkret
> wird, sinds Probleme des einzelnen?

Du hast eine etwas seltsame Wahrnehmung von OSM.

>> Haben sich die Routing Entwickler "zusammengesetzt" und mal 
>> aufgeschrieben wie sie es sich vorstellen, bzw. wo die Probleme sind?
> 
> Ich fuer meinen Teil habe jedenfalls die Probleme schon des
> oefteren hier in der Liste angesprochen. 

Ja, aber keine sichtbaren Lösungen (oder auch nur eine Auflistungen was 
geht und was nicht) angeboten. Klar, hinstellen und sagen "wenn ihr 
meinem Rat folgt wird die Welt besser" kann jeder.

>> Gibt es inzwischen Routing Software, die man guten Gewissens als 
>> brauchbar betiteln kann, ohne bei jeder zweiten Antwort "ja, aber" zu
>> sagen?
> 
> Umso besser und exakter das Attributsmodell ausformuliert ist,
> desto exakter kann der Routingentwickler priorisieren. Wenn es
> ein Tag gibt, das die Eignung zum Motorradfahren anzeigt, kann
> ich es auswerten. Wenn OSM bei den Strassen nur den ueblichen
> Einheitsbrei attributiert und das auch noch schwammiger als
> bei anderen Anbietern, ist auch das Routingergebnis schwammig.

Die Routing Lösungen die ich bislang gesehen habe waren von der 
Benutzung so mies, das ich garnicht weiter probieren wollte. Das 
motiviert "keinen" Mapper hier Energie zu investieren.

>> Sorry, aber sich hinzustellen und zu sagen: "Die Daten taugen nicht" ist 
>> zu einfach.
> 
> Das ist nicht die Aussage. Die Aussage ist, dass das 
> Attributsmodell von OSM schlechter ist als das der
> Konkurrenz, was das Routing angeht. 

Das ist im gegebenen Kontext aus meiner Sicht die gleiche Aussage.

>> Was wir brauchen ist Router-Software:
>> - die für den Mapper sinnvoll anwendbar ist
>> - dem Mapper sichtbar macht, welche Regeln verantwortlich sind
>> - bei denen sich zumindest die Router-Entwickler mal auf Regeln einigen
> 
> Ist eigentlich ganz einfach. Zuerst brauchts ein 
> Attributsmodell, das einerseits dokumentiert ist und
> sich andererseits auch nicht staendig veraendert. Das Wiki
> ist zum Brainstorming eine tolle Sache, ersetzt aber nicht 
> eine richtige Dokumentation und Versionierung.

Du bist schlicht im falschen Projekt. Geh bitte zu Teleatlas oder Navteq 
und hör auf dauernd hier rumzunerven.

Wenn wir da hinkommen, würde ich das sogar begrüßen. Aber drauf zu 
warten bis das passiert "und dann mach ich was" ist etwas seltsam.

>> *Dann* gehe ich nämlich davon aus, daß die Mapper auch gerne den Routern
>> folgen und ihre Daten entsprechend eintragen - nämlich dann wenn sie 
>> einen Sinn darin sehen es zu tun.
> 
> Die Rueckkopplungsschleife ist weit gefasst und schnelle
> Ergebnisse gibts nicht. Fuer eine sichtbare Verbesserung beim
> Routing muss ein bekanntes Attribut erst in der Flaeche 
> angewendet werden, bevor es wirksam wird. Das ist der
> fundamentale Unterschied zur Visualisierung mit den Kacheln.
> Da traegt man ein und ein paar Minuten sieht man, obs geklappt
> hat. 

Dieser Absatz ist in sich nicht schlüssig. Wenn ein Tag nur wenig 
verwendet wird, taucht es auch auf den Kacheln nicht auf. Wenn ich Daten 
geändert habe könnte ich die sofort mit dem Router überprüfen. Genau 
darum geht es: Bei den bisherigen Routern die ich gesehen habe ist es 
völlig intransparent für den Mapper warum etwas geroutet wird, da kommt 
bei den Mappern wenig Motivation für Änderungen am Tagging auf.

Anstatt hier rumzumaulen was alles nicht geht, brauchen wir Leute die 
zeigen was bereits geht und zwar so, daß die Mapper es auch verstehen 
und anwenden wollen. Danach können wir gerne Lösungen für die noch 
vorhandenen Probleme suchen. Dann sind viele Mapper vielleicht sogar 
bereit ihr Mapping-Verhalten zu ändern - wenn es ihnen selbst sichtbar 
hilft ...

Gruß, ULFL