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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
