[Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags
Thomas Ineichen
osm.mailinglist at t-i.ch
Fr Jun 4 22:54:28 UTC 2010
Hallo steffterra,
am Freitag, 4. Juni 2010 um 21:41 schrieb steffterra:
> Am 04.06.2010 um 20:42 schrieb Frederik Ramm:
>> Ich habe die Auffahrt-Problematik nicht praesent; falls Du gerade
>> vorschlaegst, ein "ref=A3" an eine Auffahrt zu setzen, die auf die A3
>> fuehrt, so wuerde ich dem widersprechen - "ref=A3" soll m.E. nur an
>> Strassenstuecke, die Teil der Autobahn sind.
> Dem muss ich nun widersprechen - und nicht nur weil genau das
> etablierte Praxis ist ;-) Laut einem sehr alten Wikieintrag für
> motorway_link gilt folgendes (und ist imho auch weit verbreitet
> etabliert und steht wohl auch deshalb im wiki):
> "Die Verbindungen zwischen zwei Autobahnen sollten gewöhnlich mit
> dem ref=* derjenigen Autobahn markiert werden, zu der sie führen"
Ich glaube, das hat sich vor allem durchgesetzt, weil dann der Router
so schön sagen kann "fahren Sie rechts auf die A3". Was *wirklich*
alles zur A3 gehört, darüber lässt sich lange philosophieren. Als ich
in der Schweiz die Autobahnrelationen erstellt habe (es sind bei uns
zum Glück nicht so viele), habe ich in die Hauptrelationen nur die
Autobahnen selbst (ohne Zu- und Abfahrten) aufgenommen, die bereits
mit ref=* getagten motorway_links aber so belassen.
http://www.openstreetmap.org/browse/relation/27877
[Ob diese *Gesamt*-Relation notwendig ist, darüber lässt sich
ebenfalls streiten - praktisch ist sie allemal.]
> (Ich habe diesen Satz nun um den destination-key erweitert)
*Nur* ein destination=* bzw. ein destination_ref=* an die motorway_
links wäre meiner Meinung nach am besten, aber etablierte Systeme kann
und darf man nicht einfach so umstellen.
> werden. Diese Art die motoway_links, trunk_links und secondary_links
> (etc.) zu mappen bringt absolute _direkt nutzbare_ Vorteile für
> Routingsoftware gegenüber dem "Nichtmappen", ebenso wie der destination-key.
Das Nützliche ist eben nicht immer richtig, und das Richtige nicht
immer nützlich.. ;)
> Der ref- und der destination-key jedoch schon, weil er eben vom
> Auffahrtsschild abgelesen wurde und sich auch auf anderen
> Hinweisschildern für die Autobahn wieder findet. Das gleiche gilt
> für Abfahrten: Auf der AB findet man dort den Hinweis auf die
> Bundesstraße und den Zielort zu dem sie führt. Perfekt im
> destination und ref-Tag der Abfahrt untergebracht! (siehe obige Argumentation!)
<Überspitzung>Schreiben wird doch an alle Strassen destination=Rom;
bekanntlich führen ja alle Wege dahin</Überspitzung>
Wenn man den ref auch benutzt um anzugeben, auf welchen ref die
Strasse hinführt, dann Verwässert man die Bedeutung des ref-Keys..
>>> Darf ich mal eine Grundsatzfrage stellen? Ich lese ja erst seit
>>> kurzem mit. aber ich bemerke immer wieder zwei Lager: die einen, die
>>> am liebsten _alles_ in Relationen packen würden und die Verfechter
>>> der Meinung, das kurze prägnante neue Zusatztags viele Vorteile
>>> bieten. Was sind denn die großen Vorteile von Relationen für _alles_?
Aus der Sicht des Informatikers: weniger Redundanz.
Wenn mehrere Elemente das gleiche Key-Value-Paar haben, dann kann man
diesen Wert in der Relation speichern, anstatt an jedem Objekt
einzeln. Z.B. könnte man alle Ways einer Strasse und die dazugehörigen
Häuser in eine Relation packen, um dann der Relation ein "name=
Bahnhofstrasse" zu verpassen.
Da bei OSM aber (zum Glück) nicht alle Informatiker sind und eine
Umsetzung für die Editoren nicht ganz einfach ist, sollte man es sich
immer gut überlegen, wann und ob man eine Relation einsetzen möchte.
>> (Leute machen das manchmal, weil sie auf
>> einfache Weise alle Haeuser von Hundertwasser aus der Datenbank laden
>> wollen, das geht mit einer Relation gut, aber ich halte das fuer einen
>> Missbrauch).
Der Übergang zum Missbrauch ist sehr fliessend. Sobald es sich um mehr
als eine (1) gemeinsame Eigenschaft handelt (z.B. "Autobahn" und "in
der Schweiz"), gibt bisher kein anderes OSM-Werkzeug, welches so
schnell und einfach ein Ergebnis liefert wie die Relation.
Gruss,
Thomas
Mehr Informationen über die Mailingliste Talk-de