[Talk-de] Relevanz, OSM und Wikipedia

So Apr 5 17:45:08 UTC 2009

Hallo.

Am Sonntag 05 April 2009 17:36:15 schrieb qbert biker:
> > Niemand hat was gegen ein "Regelwerk", so lange es ausschließlich
> > Konstruktiv ist.
> Schön um den Kern herumgewunden. Ein Regelwerk muss schon ein
> falsch und richtig kennen, bzw. ein drinnen und draussen, sonst
> nutzt es nix. 

Nein.
Das KA-Schema kennt kein "falsch". Es kennt nur ein "in unseren Augen gut".
Es gab wirklich viele Leute, die gesagt haben: Ihr spinnt doch, jedem Haus die 
komplette Adressinfo mit zu geben! Jedes Haus bekommt den Straßennamen und den 
Ortsnamen mit dran, völlig überflüssige Redundanz!

Jetzt wissen wir:
Ja, es ist aus Datenbank-Sicht schon unschön, aber seit wir das haben, kann 
eine Suchfunktion eben zu jedem POI eine vollständige Adresse anzeigen. Die 
Zugehörigkeit-mittels-Abstand-oder-Polygon-Fraktion hat es meines Wissens noch 
nicht geschafft, jede Straße zuverlässig einem Ort zuzuordnen, obwohl das 
schöner/effizenter/besser wäre.

Da mittlerweile sogar mein Garmin zu nem Restaurant die komplette Adresse 
anzeigen kann, sehe ich das aktuelle als Prima an und benutze es!

Schau dir die Reit- und Wanderkarte an. Es gibt jetzt eine formale Definition 
der Wanderweg-Symbole. Und das nur weil bei vielen Mappern der "ich will auch 
auf diese Karte"-Effekt eingesetzt hat.

> Im Moment wird das nur über die Applikationsschiene
> durchgedrückt und das ist sehr fehleranfällig. 

Finde ich ganz und gar nicht!

Du hast einen Renderer und/oder ein Navi und du trägst Daten ein. Dann kann es 
entweder funktionieren oder nicht. Funktioniert es nicht, korrigiert man es.

Hat man keine Anwendung sondern nur ein Regelwerk, dann muss man entweder die 
Einhaltung formaler Regeln prüfen (Validator) oder man riskiert dass gut 
gemeinte Einträge mit Tippfehlern und/oder falsch verstandenem Konzept in der 
Datenbank sind, die keiner findet.

> Was nicht
> gerendert wird, wird von vielen als falsch aufgefasst, vielleicht
> ist die neue Sache einfach noch nicht bei den Renderern
> nachgezogen. 

Kann ich nicht bestätigen.
Zeigt es der Renderer falsch an, dann gibt es das Problem, denn dann wollen 
andere Leute dass es richtig angezeigt wird. Wird es aber gar nicht angezeigt, 
dann ist das anderen eigentlich egal. Die Bewertung ob richtig oder falsch 
wird eigentlich gar nicht vorgenommen, da sich keiner dran stören muss.

> Schön wäre aber eine knackige Zusammenfassung, die
> dann auch eine Weile gültig ist auch Basis für die
> Applikationsentwicklung. 

Ja, kann man ja machen.
Knackige Beschreibung/Motivation für die Mapper, formale Definition für beide 
und der Anwendungsentwickler kann loslegen. Dann noch schnell zwei, drei Fälle 
irgendwo passend mappen dass der Anwendungsentwickler was zum Testen hat und 
Bingo!

Wenn dann die Anwendung die Daten nutzt und der Entwickler sagen kann: "Seht 
her, hier das Autobahnkreuz Köln-Süd, das kann man sich jetzt mit einer 
realistischen 3D-Darstellung mit allen Fahrstreifen und der Art der 
Mittellinien anzeigen lassen." Dann hast du gewonnen und wir sind auf einem 
Nenner angekommen. Dann glaube ich dir dass dein Modell echt gut ist!

Die Gefahr ist einfach viel zu groß, dass deine formale Definition eine 
Design-Schwäche hat, die man ohne Ausprobieren gar nicht erkennt. Ich kenne 
dich nicht und kann das im Einzelfall nicht beurteilen, aber ich würde mich 
hier nie auf etwas verlassen da sich jemand nur so in der Theorie ausgedacht 
hat. Ich will sehen, dass es funktioniert. Mit Beispieldaten wo ich sehen 
kann, wie es gemacht wurde bzw. was ich machen muss um ein vergleichbares 
Ergebnis zu bekommen.

> > Okay. Das Hammer-Argument warum das bisher mit einfach irgendwo abzweigen
> > lassen Probleme machst, bist du noch immer schuldig geblieben.
> Weil es Schätzometrie ist. Es ist Unsinn, mit Gewalt ungenau
> einzutragen. Wenn die Auflösung 5-10m ist und ich 300m daneben
> liege, ist das schlicht und einfach ein Fehler von 3000%.

Es ist aber immer noch ein Fehler von 300 Metern. Und wenn eine 
Autobahnausfahrt vom Navi 300 Meter früher angezeigt wird, dann werde ich sie 
dennoch finden können wenn ich genau genug suche. ;-)

> > Du hast zwar erwähnt, dass man damit keine wirklich realistischen
> > spurtreuen
> > Abbildungen machen kann, aber das ist Theorie.
> Kauf dir ein kommerzielles Navi und du wirst sehen, dass es
> keine Theorie ist. Nur weil OSM noch nicht so weit ist, bedeutet
> das nicht dass andere schon längst weiter sind.

Okay, ein so neues Navi habe ich nicht und werd ich mir auch nicht kaufen.
Ich finde dein Argument gut. Ehrlich.

Aber ich will sehen, dass irgendjemand das mit (von ihm selbst gemappten) OSM-
Daten macht. Ich will sehen, dass jemand entweder das in einem 
selbstgeschriebenen Programm umsetzt oder die Daten in das Format eines 
solchen Navis konvertieren kann.

Dann kann man das ausprobieren, bekommt direkt Feedback, kann sehen ob es 
taugt. Es sollte ja kein Problem darstellen so ein Programm zu schreiben ohne 
dass es flächendeckend passende Daten dafür gibt.

> Der OSM-Pragmatiker hat keine Modellvorstellung und irgendeine
> Anwendung im Kopf und alle anderen potentiellen Anwendungen
> sind ihm egal. Mapnik zeigt die Ausfahrt richtig an und damit
> ist der Auftrag erfüllt, wen interessieren schon 300m hin oder
> her, wenn es die spurgenaue Abbildung noch nicht gibt. Wenn es
> sie aber gibt und die 300m plötzlich nicht mehr egal sind, muss
> man alles nacharbeiten, wenn man sich denn doch noch auf eine
> Methode einigt. Aber OSMler haben ja Zeit ;)

Personalaufwand, Arbeitsstunden, das ist bei OSM völlig irrelevant. 
Insbesondere wenn es um Autobahnen geht. Ich verspreche dir, dass wenn es 
wirklich cool ist, dass dann innerhalb weniger Monate alle Autobahnausfahrten 
in Deutschland nach deinem Schema getagged werden.

OSM hat genug Arbeitskraft zur Verfügung. Sie zu kanalisieren geht nur über 
Anreize, nicht über Regeln. Und OSM hat eben *keinen* Businessplan nach dem 
wir unbedingt in einem Jahr fotorealistische Abbiegevorschriften haben müssen.

> Der normierende Zwang der Anwendung. Wenn man Bilder rendern will
> und Routing betreiben wird man zwangsläufig auf die Tatsachen
> stossen, die andere schon seit 30Jahren in ihre Programme einbauen.
> Trotzdem wollen viele OSMler von diesem Modell weg, weil ihnen
> Flächen vertrauter sind als blosse Linien und das Modell dazu.
> Bzw. immer mehr bekommen Zugang zu Flächendaten der Vermessungsämter
> und finden die schöner.

Ja, sollen sie machen. Flüsse zeichnen wir auch schon lange flächig PLUS als 
Linie ein. Man kann das mit Straßen auch machen wenn man seine Quelle für 
ausreichend gut hält.

> > Warum du jetzt aber noch mehr Dinge abstrahieren willst, ist nicht mehr
> > derartig einleuchtend und benötigt mehr Überzeugungskraft mit Hilfe von
> > coolen
> > Beispielen. ;-)
> Einfach auf das Display eines Navis schaun. Sogar auf den meisten
> Werbebildchen ist die spurgenaue Darstellung gut sichtbar, incl.
> Beschränkungen (z.B. Kombilinie durchgezogen/gestrichelt).
> Eine 'coolere' Anwendung kann ich nicht bringen.

Du kannst noch nichtmal diese Anwendung bringen. Du kannst erzählen, dass "die 
anderen" sowas haben, aber ob man das mit OSM-Daten überhaupt machen kann, 
weiß noch keiner.

Ich habe vor zwei Jahren mal die Idee gehabt, dass ich unbedingt auch Ansagen 
produzieren möchte a la "rechts halten auf die A 8 Richtung München". dazu 
muss man irgendwie hinterlegen, welcher Ort an welcher Kreuzung als Fernziel 
angegeben ist.
Ich habe auch hier geschrieben und wollte das schon pro Forma mal normiert 
haben. Es hat keine Sau interessiert. OSM funktioniert einfach anders. Aber 
alles was man in einem freien Navi bzw. mittels bekannter Datenformate 
überhaupt abbilden kann, kann man mit OSM-Daten abbilden.

Erst der Beweis, dass es funktioniert, dann erzeugt man Motivation das zu 
komplettieren.

> Auch eine Einstellung. Wenn man es sich nicht vorstellen kann,
> dass ein anderer eine höhere Genauigkeit nutzen kann, macht man
> es eben ungenau, obwohl die exakte Darstellung keine Sekunde
> Mehrarbeit darstellt. Für die einen sind 300m total unwichtig,
> ist ja nur die ungeliebte Autobahn und der andere will seinen
> Haltestellenpfosten gleich im Zentimeterraster genau haben.

Du kapitulierst also nur weil nicht *alle* die selben Prioritäten haben?
Ich glaube nicht, dass jemand sagt: Nein, ich will es unbedingt so haben dass 
es ungenauer ist". Es ist nur vielen den Aufwand nicht Wert, hier irgendwas 
nochmal zu mappen ohne den klar erkennbaren Vorteil.

> Meine Kritik ist auch nicht, dass eine kleine Gruppe aus
> Hintertupfing frei experimentiert - die Kritik ist dass immer alle
> in jedes Experiment mit einbezogen werden, ob sie wollen oder
> nicht.

Ist das so?
Ich habe hier eine Teststraße für Straßennamen in einer Straßen-Relation. Ich 
hatte noch nicht die Zeit zu schauen ob ich das in einen Renderer einbauen 
kann, aber ich würde wetten, dass es keinen stört, dass ich hier ein 
Datenmodell teste dass ich nicht formal definiert habe und das bisher "falsch" 
ist. Wenn ich den Aufwand treiben würde, das in diversen Anwendungen 
einzubauen, wäre es irgendwann richtig.

Ich beziehe niemanden mit ein, schon gar nicht unfreiwillig.

Gruß, Bernd

-- 
<Alanna> Saying that Java is nice because it works on all OS's is like
         saying that anal sex is nice because it works on all genders.

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 836 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20090405/7e04c5c9/attachment.sig>