[Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)

[Frederik Ramm]

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 frederik at remote.org  ##  N49°00'09" E008°23'33"