Hallo,
Stephan Wolff wrote:
Wollte man Osmarender beibringen, Einheiten bei "width" auszuwerten,
müsste man das Programm ergänzen und an hunderte Teilnehmer verteilen.
Für Mapnik sind unhandliche Umrechnungen nötig. Bei Datenbankabfragen
(etwa nach den 100 leistungsstärksten Kraftwerken) vervielfacht sich
der Aufwand. Diese Regeln müssen für jede Auswertung erneut durchlaufen
werden. Der Aufwand ist nicht klein und wird wohl meist unterbleiben.
Es ist trotzdem nicht akzeptabel, diese Arbeit den Mappern aufzubuerden,
egal wie trivial die Umrechnung ist. Da bin ich ein ziemlicher Hardliner
- nur weil irgendein Programmierer es nicht hinkriegt, die Daten richtig
auszuwerten, darf es fuer den Mapper nicht schwieriger werden. Der
Mapper hat es eh schon schwer genug. Die Mapper sind bei uns die
Arbeitspferde, denen muessen wir es so leicht wie moeglich machen.
Auch eine Editor-Unterstuetzung hilft uns hier nicht, denn der Mapper
wuerde "width=700cm" eingeben, der Editor das auf "7m" umrechnen, und
der Mapper sich dann beim naechsten wundern, wieso seine Angabe nicht
"richtig" ankam. (Noch schlimmer bei Einheiten, bei denen nicht einfach
der Dezimalpunkt verschoben wird.)
Was Osmarender betrifft, es gab frueher einen Praeprozessor, den man vor
Osmarender laufen lassen musste, um Segmente umzudrehen. Es gibt heute
noch ein Skript, das Kuestenlinien schliessen muss, damit Osmarender
damit arbeiten kann. Es gibt einen Postprozessor fuer Bezierkurven. Ich
sehe nicht, wieso man nicht einen "Einheiten-Umrechnungs-Praeprozessor"
schreiben soll (oder, wie vorgeschlagen, einen Osmosis-Task dafuer bauen).
Und "an hunderte Teilnehmer verteilen", was meinst Du damit? Das ist
doch bei uns Standard, dass Software veraendert wird und Leute sich eine
neue Version runterladen. Das kann nun wirklich kein Argument sein.
Das ist eine Variation, mit der eine robuste Auswertung gut klarkommen
kann. Dann ist es auch keine zusätzliche Fehlermöglichkeit, weil einfach
beides funktioniert.
Wer kann und will eine solche robuste Auswertung in SQL implementieren?
Wenn SQL das falsche Mittel ist, dann muss die Auswertung eben anders
implementiert werden. Es ist nicht die Aufgabe des Mappers, sich
darueber den Kopf zu zerbrechen.
Ein Validator kann einfacher auf "Zahl" als auf "Zahl mit zulässiger
Einheit" testen. Falsche Zahlen kann ein Validator nie erkennen. Eine
Einheit mitzuführen bringt keinen Vorteil.
Da bin ich aber entschieden anderer Ansicht.
Mapnik, Osmarender und sicherlich die meisten OSM-Anwendungen greifen
direkt auf die Texte der Tags zu. Dort müssten komplexere und langsamere
Abfragen implementiert werden.
Die meisten Nutzer machen eh schon irgendwelche Vorverarbeitungsschritte
- etwas mit Osmosis ausschneiden oder diffs mit Osmosis herunterladen
zum Beispiel, da wuerde ein zusaetzlicher "und bitte rechne alle
Einheiten nach diesem Schema hier um"-Schritt auch nicht stoeren. Die
Reit- und Wanderkarte wie auch die OpenCycleMap haben sogar beide einen
massiven Vorverarbeitungsschritt, in dem sie einen Grossteil der Tags
auf eigene Nomenklatur umsetzen, bevor er mit osm2pgsl in die Datenbank
wandert.
Meiner Ansicht nach ist das der richtige Weg, diese Vorverarbeitung
einfacher zu machen, so dass sich jeder leicht zusammenbauen kann,
welche Tags er will und wie er die gern ausgewertet haette (zum Beispiel
spraeche auch nichts gegen ein aufgebohrtes osm2pgsql, das Tag-Werte
erst an eine Umformroutine uebergibt, bevor die in die Datenbank kommen).
Der falsche Weg ist es, von Nutzern die Einhaltung von immer mehr Regeln
zu verlangen, bloss weil der Datenauswerter ein einfacheres Leben haben
will.
Hat ein Mensch einen Vorteil, wenn das selbe Modell einer Windmühle
einmal mit "generator:output:electricity=100 kW" und ein anderes Mal als
"generator:output:electricity=0.1 MW" beschrieben wird? Mir wäre
"generator:output:electricity=0.1" mit der eindeutigen Definition
"Werte in MW" lieber.
Deshalb sollst Du ein Tool nutzen, das Dir die Daten so umbaut, wie sie
Dir am liebsten sind. Jemand anders will vielleicht fuer schnelles
Rendering die Generatoren in 3 Groessenklassen unterteilen und will gar
keine konkrete Zahl mehr, sondern nur noch "small","medium","large".
Jemand drittes hat eine Software, die mit Kommazahlen nicht so gut
umgehen kann und haette gern alles in vollen Watt. Deine
Herangehensweise wuerde bedeuten, dass ihr Euch alle auf eine Loesung
einigen muesst - wenn statdessen jeder nimmt, was er kriegt, und es
geeignet umwandelt, gibt es diesen laestigen Abstimmungsbedarf (der aufd
em Ruecken der Mapper ausgetragen wird) nicht.
Bye
Frederik
--
Frederik Ramm ## eMail [email protected] ## N49°00'09" E008°23'33"
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
