Hallo, Frederik Ramm schrieb: > Wir, mit unserem "Crowdsourcing"-Ansatz, haetten hier die Chance, das > beste beider Welten miteinander zu vereinen. Unsere automatischen > Renderer koennten das Gros der Arbeit tun, aber ueberall dort, wo wir > Menschen sehen, dass die Resultate suboptimal sind, koennten wir > geeignete "Hints" einbauen: "Hier muss man bei Zoomstufen x-y etwas > schummeln und diese Strasse um 500m nach rechts verschieben" oder so. > Mit solchen Tools koennte es uns gelingen, kartographisch ansprechende > Werke zu erzeugen, die dem, was irgendwelche Software aus Standarddaten > automatisch berechnet, haushoch ueberlegen ist.
Das ist im Ansatz richtig und in der Tat ein potentieller Vorteil für unseren Mapping-Ansatz, insofern erst einmal Dank für die neue Perspektive, die ich in dieser Form noch nirgends ausgedrückt gesehen habe. Allerdings hat der anwendungsorientierte Optimierungsansatz unter Umständen ebenfalls Nachteile, so ist der Aufwand dann auch teilweise abhängig von der Anzahl der unterstützten Anwendungen. Das ist insofern ein wichtiger Punkt, als ein wesentlicher und oft herausgestellter Vorzug von OSM darin besteht, dass mit der Verfügbarkeit von Rohdaten eine Vielzahl kreativer Anwendungen möglich sein soll – und das ist um so eher denkbar, je mehr Probleme mit universellen statt anwendungsspezifischen Konzepten gelöst wurden. 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. 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. Tordanik _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
