[Talk-de] Beschriftung von kurzen Straßenstücken steuern

[Dirk Stöcker]

On Mon, 1 Sep 2008, Tordanik wrote:

> Es ist nicht zu vernachlässigen, dass mit dem Vorhandensein einer Lösung
> für die Lieblingsanwendung des Mappers der Anreiz fehlt, Zeit in eine
> Lösung zu investieren, die allen Anwendungen zugute käme. Gleicher
> Effekt bei den Anwendungsprogrammierern: Populäre Anwendungen werden
> sich dann vielleicht – im Wissen, dass für sie optimiert wird – nicht
> die Mühe machen, solche Lösungen zu implementieren, die universeller
> wären (ich nenn das mal das „Internet-Explorer-Problem“).
>
> Für eine Verwendung anwendungsspezifischer Hints spricht daher für mich,
> wenn möglichst viele der folgenden Punkte erfüllt sind:
> * Die Hints lassen sich für eine ganze Gruppe von Anwendungen einsetzen
> etwa für die meisten oder gar alle Renderer/Router/…
> * Das Problem lässt sich nicht oder nur schwer algorithmisch lösen.
> * Das Problem liegt an bestimmten örtlichen Besonderheiten und ist nicht
> der „Normalfall“.
>
> Beim konkreten Beispiel „osmarender:renderName“ – das aber inhaltlich
> nicht Hauptanliegen dieser Mail sein soll – trifft all dies in den
> vielen Anwendungsfällen kaum zu. Ich folgere daraus nicht, dass ich die
> hints noch vor Lösung des Problems löschen würde – nicht einmal, dass
> das Tag in jedem Einzelfall überflüssig sind –, aber halte den
> Relation-Ansatz mit autonomer Verteilung der Labels durch die Software
> klar für die bessere Lösung.

Du übersiehst hier eine zentrale Problematik: Es gibt keine 
Standardisierung für entsprechende Render-Hints. Automatisierte Generierung 
von Karten ist ein wahrscheinlich noch lange fruchtbares Forschungsgebiet 
und die Kartengeneralisierung ist etwas, was man lange lernen muss, um 
schöne Karten zu produzieren.

Der bisherige Ansatz osmarender-spezifische Tags zu haben ist ein 
Startpunkt. Niemand hindert die anderen Renderer daran diese Tags auch zu 
nutzen. Irgendwann hat sich ein sinnvoller Satz an Renderinghinweisen 
herausgebildet und man kann über eine Standardisierung nachdenken.

Warum erwartest Du, dass von Anfang an eine perfekte Lösung existiert? So 
funktioniert die Welt nicht.

Ich würde z.B. Tags einführen, die die Anzeige gewisser Stadtnamen 
steuert. Z.B. Abhängig vom Kartenmaßstab. Es gibt Städte (und wird es 
immer geben), die aufgrund der Bevölkerungszahl eigentlich vollkommen 
unwichtig sind, aber trotzdem in einer Karte zu erscheinen haben und 
andere, die besser unterdrückt werden sollten. Auch wenn man sich noch so 
anstrengt, dass läßt sich automatisch nicht lösen.

Ein anderes Standardbeispiel ist eine Kirche. Unter Umständen ist es 
sinnvoll Autobahnen und Straßen etwas zu verschieben, um eine Kirche auch 
in kleineren Maßstäben darstellen zu können. Das kann kein Renderer 
entscheiden. Hier ist menschliches Geschick gefragt.

Wenn Du in OSM nur die Realität mappen willst, dann stell Dir solche 
Rendering-Hints einfach als Teil der Realität vor - Sind sie nämlich auch 
- allerdings aufgrund gewisser gesellschaftlicher Wertevorstellungen, die 
nicht so einfach zu erkennen sind.

> Zum Schluss noch: Die Vorteile ließen sich ebenso erzielen,
> würden die anwendungsspezifischen Tags in eigenen Datenbanken
> gespeichert. Man kann Editoren so anpassen, dass sie nur interessante
> Tags anzeigen, ja. Man kann sie aber auch anpassen, dass sie Daten aus
> mehreren Quellen entnehmen und auch passend wieder hochladen. Verzichtet
> man auf die Speicherung in der Hauptdatenbank, hätte man für diesen
> Bereich auch ein für allemal das Problem aus der Welt geschafft, ob es
> irgendwelche Einschränkungen (Umfang der Daten, „Relevanz“ der Anwendung
> – de.WP lässt grüßen) dafür geben soll, was für anwendungsspezifische
> Daten „erlaubt“ sein sollen.

Wo soll der Vorteil einer parallelen Datenbank liegen?

Die Nachteile liegen auf den Hand:
- verschiedene Logins - Nutzer können zweite Datenbank nicht ändern
- Nutzer finden zweite Datenbank überhaupt nicht
- Daten bleiben nicht synchron

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)