Hallo. Am Mittwoch 06 Mai 2009 09:55:24 schrieb Nop: > Genau darum geht es: Wie willst Du das verhindern? Und zwar so allgmein > formuliert, daß es in jedem Renderer zuverlässig umsetzbar ist?
In dem man dem Renderer sagt, welcher Relation-Typ welches Tag vererbt.
Dass es prinzipiell sinnvoll ist, möglichst viele Tags zu vererben ist ja das
eine, aber praktisch würde ich jetzt so vorgehen:
* highway-kategrie sollte beim way verbleiben.
Z.B. nicht alle Landesstraßen sind secondary und irgendwie wäre das ganze
sehr fehleranfällig wenn man versuchen würde, die highway-Kategorie von oben
herab durch eine Relation zu dirigieren.
* name sollte in den für andere Zwecke (Busroute, Wanderweg) genutzten
Relationen den Namen der Relation beschreiben und nicht vererbt werden. Bei
einem speziellen Realtion-Typ, der nur eine stark unterteilte, lange Straße
zusammenhalten soll (keine ahnung ob es solche Relationen gibt), sollte der
Name vererbt werden. Ein Name an einem Straßenstück wird als alternativer
Name benutzt (z.B. Brückennamen)
* ref wird von Straßen-Relationen vererbt, von anderen Relationen nicht.
Mehrfachvererbung erzeugt mehrfache Werte.
Alles andere habe ich entweder hier vergessen oder interessiert den Renderer
nicht.
Jeder Renderer den ich bisher kenne arbeitet nach einem Whitelist-Verfahren.
Nimmt was er kennt und ignoriert den Rest. Ob jetzt irgendwo im Wiki steht,
dass alles vererbt werden muss oder nicht, ist eigentlich egal. Wenn es den
Renderer gar nicht interessiert, interessiert ihn auch nicht ob und wie es
vererbt wird.
> Jetzt hast schon in dem einfachen Beispiel Relationen, von denen Du
> mehrfache Werte zulassen würdest und andere, von denen Du keine oder nur
> einfache Vererbung haben willst - und keine definierte Regel, wie man
> das unterscheiden könnte
Doch. Ich kenn mich mit den benutzten Relation-Typen nicht aus, aber AFAIK
gibt es nur einen Typen ("road"?), der für eine Zusammenfassung z.B. einer
Bundesstraße steht. Bei diesem Typen vererbt man ref, bei allen anderen nicht.
Es muss ja keineswegs eine Regel existieren, die alle Renderer gleich umsetzen
können. Rendert ein Renderer keine Ref-Angaben, lässt er's halt weg. Machst du
einen Renderer für Busrouten, interessiert dich vermutlich die ref der
Buslinie mehr als die Ref der Straßenverwaltung.
> und auch keine Möglchkeit ein "die beiden oder
> auch eine andere"-Ref zu erzeugen.
?
Nur weil in den OSM-Daten keine echten Arrays möglich sind, muss man doch
nicht den Kopf in den Sand stecken. Ein Renderer darf meinetwegen gerne in
seinem Programmcode mit den Daten arbeiten und dabei seine Datentypen frei
benutzen.
Ansonsten nimmt man halt das ";"-Konstrukt und hängt die Werte mit ;
aneinander.
> Nehmen wir noch eine neue, unbekannte
> Relation hinzu (ich darf ja jederzeit neue Typen eintragen oder den Way
> weiteren Relationen zuordnen), und das Chaos ist komplett.
Nein, denn wenn ich eine neue highway-Kategorie erfinde, die ich viel toller
finde als alle anderen, dann gibt es ebenfalls kein Chaos, weil einfach die
Renderer meine Straße ignorieren.
Warum machst du's dir immer so schwer? Es gibt momentan einen Regelsatz in
jedem Renderer, welche Angaben wie interpretiert werden. Das funktioniert
überall so. Unbekannte Daten erzeugen keine Ergebnisse und auch kein Chaos.
Warum sollte das jetzt plötzlich anders werden?
Gruß, Bernd
--
»Niemand hat die Absicht, eine Mauer zu errichten«
- Walter Ulbricht (SED), 1961
»Es hat niemand vor, einen Überwachunsstaat in Deutschland zu errichten«
- Wolfgang Bosbach (CDU), 2007
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
