Hi,
Am 09.03.2012 23:27, schrieb Stephan Wolff:
Moin!
Am 09.03.2012 02:00, schrieb Christian Müller:
Stephan Wolff<[email protected]> schrieb:
Das empfinde ich eigentlich als nachrangig. Wenn das Modell gut ist,
lässt sich der Renderer so anpassen, dass der Output erzeugt wird,
den man will/braucht.
Kein Datenmodell beschreibt die reale Situation vollständig.
Das habe ich auch nicht behauptet!
Für jede Anwendung ist ein anderes Datenmodell ideal. Ein gutes
Modell, das jedes Renderergebnis liefern kann, gibt es nicht.
Auch das habe ich nicht behauptet, aber Du wirst doch einsehen, dass es
Modelle gibt, die es einfach machen, verschiedene Varianten an
Renderoutput zu erzeugen/zu errechnen, wohingegen andere, weniger
universelle Modelle es Dir schwerer machen, das zu erreichen. Der
Erfolg von OSM an sich beruht ja schon darauf, im Grunde kein starres
Tagging-Schema für die Basisgeometrie zu fordern (gefordert zu haben?),
bis auf den generischen Zwang, Informationen in key-value-pairs abzulegen.
auftaucht.. "nebeneinander existieren" klingt nach Redundanz..
Es klingt nur so. Zudem wäre Redundanz nur ein Schönheitsfehler aber
kein Ausschlußgrund für eine Koexistenz.
Komischerweise sieht man das im Falle von nebeneinandergezeichneten
secondaries aber offenbar nicht so. Lustig.
Hat jemand kritisiert, dass die Wege redundant sind? Das sind sie nicht.
Doch das sind sie.
Sie widersprechen der üblichen "highway"-Definition.
Das wurde hier behauptet und es ist Unsinn, weil es, orientiert man sich
an den Angaben im Wiki, nicht stimmt.
http://wiki.openstreetmap.org/wiki/Key:highway
The *highway tag* is the primary tag used for highways.
Nun, ich tagge Straßen, keine Häuser, keine Grünanlagen mit dem
Highwaytag und selbst wenn es jemandem, der sich für Spuren und die
Details nicht interessiert, komisch vorkommen mag, dass ein und die
gleiche Straße mehrfach beschrieben wird.
Wenn ich die Straße (wieder im Blicke derer, die sich nicht für Spuren
interessieren) mehrfach beschreibe, bezeichnet man das gemeinhin als
Redundanz. Die ist nicht unbedingt erstrebenswert, aber auch nicht
verboten. Sie wird in OSM bereits an X Stellen verwendet - entweder aus
Bequemlichkeitsgründen oder um Kompatibilität abzubilden, z.B. auch im
ÖPNV-Schema, wo Doppelinfos in stop_position, platform, stop_area, etc.
erlaubt sind.
Du verwendest in deiner Variante vom Januar die Krücke "detail_exists",
ich tagge eben die Infos, die der Straße gemein sind, mehrfach - so
what? Das wiederspricht keiner üblichen Definition - es ist kompatibel.
Relationen erfordern immer eine Sonderbehandlung. Ein Modell mit exakt
zwei Spuren pro Relation wäre für den Router noch recht einfach, aber
für die Mapper sehr aufwändig. Ein Modell, das alle
nebeneinanderliegenden Fahrspuren zusammenfasst, wäre ungünstig für den
Router.
Das braucht man gar nicht und ich weiß jetzt auch nicht, wie Du in
dem Zshg.
darauf gekommen bist. Es gibt eine Relation pro Spur - das ist ja
das Schöne.
Und turn_restriction dürfte mittlerweile schon recht lange von den
Routern
gehandhabt werden.. In gosmore z.B. schon mind. 4 Jahre..
Ich sprach von einem Spurwechsel vor der Ampel. Eine turn_restriction
Relation hat damit nichts zu tun.
Wovon Du sprachst, steht noch im Quote, siehe oben. Ich habe das
Gefühl, dass wir aneinander vorbeireden. Ich habe den falschen
Unterstellungen zu meinem Konzept, in den letzten mails genügend
entgegengesetzt, um die meisten Kritikpunkte zu entkräften - wenn man
sich damit nicht beschäftigen will und weiterhin Tunnelblick fährt, kann
ich das nicht ändern. Speziell zum Spurwechsel vor der Ampel habe ich
mittlerweile ganze 3! Methoden aufgezeigt, wie Spurwechselinfos erhalten
werden können, ohne Geisterwege (Querstraßen) einzuzeichnen, die auch
wieder Aufwand bedeuten würden und Newbies abhalten, Dinge zu ändern:
1) Zusammenhang ist über den Kreuzungspunkt herstellbar, einen
Algorithmus zum finden der Spuren, in die es erlaubt ist zur Fahrzeit zu
wechseln, habe ich in einer der letzten mails zum Thema angegeben
2) und 3) sind auf der Wiki-Seite zum Konzept zu finden (lane_group
relation, um diese Infos direkt zu erfassen, oder Erfassen der area
aller lanes, um dann mit IS_IN zu arbeiten)
Aus der Unkonkretheit deiner Mail ("Relationen erfordern immer eine
Sonderbehandlung") ließ sich leider nicht darauf schließen, welches Ziel
deine Kritik genau hatte. Deshalb habe ich Dir ebenso unkonkret und
allgemein nochmal beschrieben, mit welcher Einfachheit das Konzept
daherkommt:
eine Spur mappen
TR erstellen und Abbiegebeschränkung erfassen
die Summe aller Spuren und TRs enthält präzise Informationen über
die Kreuzung und Layout
Je nachdem, was der Anwender konkret wissen will, lassen sich mittels
gezielter Suche und Selektion in diesen Informationen wesentlich mehr
Anfragen beantworten, als die Kritiken der letzten mails dazu dies in
oberflächlicher Art und Weise behauptet haben.
Christian, bitte berücksichtige die von vielen Teilnehmern geäußerten
Kritikpunkte. Es wird dir nicht gelingen, die wichtigsten Tag und
Relationen umzudefinieren.
Bitte sprich für Dich selbst und nicht für eine imaginäre Masse.
Vielleicht hast Du ja in deiner eigenen Überzeugung sogar die mails
überlesen, in denen Zustimmung zum Einzelspurmapping signalisiert wurde
und meinen Konsens dazu, bessere highway-values für Spuren zu finden
ignoriert. An letzterem Punkt reiben sich viele auf, ohne zu sehen,
dass es momentan keine Alternativen gibt. Sie wollen nicht verstehen,
dass der Prozess der Veränderung es durchaus erlaubt, ein
highway=secondary_link in ein highway=secondary_lane zu wandeln, wenn
die Zeit dafür reif ist. Momentan würde das bestehende Router vor
unlösbare Aufgaben stellen. Der Finalismus in den meisten Kritiken ist
das fatale, als wenn etwas in OSM endgültig wäre.
Gruß
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
