Hallo,
Ulf Lamping wrote:
Es ist für einen Mapper wesentlich leichter, einen Zahlenwert und evtl.
die Maßeinheit aus einer Drop-Down-Box auszuwählen, als irgendwas
einzutragen und dann zu raten ob das jetzt "gestimmt" hat.
Wenn der Mapper dabei sowohl "700", "cm" als auch "7", "m" auswaehlen
kann, soll es mir recht sein.
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.)
Wieso ein Mapper sich drüber wundern würde, wenn sein Editor aus 700cm
beim Tag maxwidth automatisch 7m macht, müßtest du nochmal genauer
erklären.
Ich denk mir halt, der Mapper wird doch einen Grund haben, warum er
700cm eingibt und nicht 7m. Meistens werden das Faelle sein, wo die
Angabe 700cm eben irgendwo abgelesen ist und deshalb naheliegender als
7m. Umgekehrt, wenn ich die Breite eines Flusses mit 10m abschaetze und
das so eintrage, und der Editor macht mir daraus 1000cm, dann denke ich
"Holla, so genau wollte ich das eigentlich nicht angeben...".
Grundsaetzlich finde ich, dass der Editor dem Mapper da nicht
dazwischenfunken sollte. Bei einigen Sachen ist es relativ eindeutig,
z.B. bei den Hoechstgeschwindigkeiten macht Potlatch das schon ganz gut
mit den Schildern, und eine Hoechstgeschwindigkeit wird auch gewiss
nirgens in Meter pro Sekunde angegeben.
Dabei wird es immer Ausnahmen geben, z.B. wenn jemand abstruse Werte von
einem alten Typenschild abschreibt und einträgt (weil er das nicht
umrechnen kann oder will). Es sollte halt klar sein, das es dann eher
nirgendwo angezeigt / ausgewertet wird.
Ja, genau - ist ja bei Tags auch so: Wenn ich partout irgendwas obskures
erfassen will, kann ich das machen, und eventuell gibt es sogar obskure
Karten, die das rendern, aber im 08/15-Rendering ist es dann eben nicht
drin.
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.
Alle drei von dir genannten Anwendungen wären mit einer eindeutigen
Angabe (wie auch immer die aussieht) gut bedient
Nein, denn wenn diese eindeutige Angabe "small", "medium", "large" ist,
dann kann einer, der die Leistung als Zahl will, damit nichts mehr
anfangen. Steht die Leistung als Zahl drin, muesste der, der nur drei
Groessenklassen will, diese "zeitaufwendig" im SQL umrechnen. Und so weiter.
und alle drei haben
viel Arbeit beim aufdröseln von konfusen Strings die irgendwie Zahlen
enthalten. Und das nicht nur bei diesem einen Tag, sondern bei ziemlich
vielen!
Ein "konfuser String, der irgendwelche Zahlen enthaelt" ist in jedem
Fall ein Problem. Es ist nicht so, das ich fuer "konfuse Strings, die
irgendwelche Zahlen enthalten" bin und Stephan dagegen; es ist lediglich
so, dass Stephan den Benutzern eine Masseinheit vorschreiben und dann
lediglich die einheit-lose Zahl speichern will, waehrend ich die
Benutzer anhalten will, die Masseinheit mit anzugeben.
Das wird sich in den meisten Faellen hoechstwahrscheinlich auf ein paar
wenige Werte beschraenken - auf "V" und "kV" bei Spannungen, auf "kW",
"MW" und "GW" bei Kraftwerken, auf "m" und "cm" bei Laengen. - Wenn die
Leute irgendwelche komischen Punkte oder Leerzeichen in ihre Werte
reinschreiben oder sowas wie "5-6m" oder das unselige (oft von den
Editoren eingeschmuggelte) Semikolon genutzt wird, hat mit der Frage
"Einheit oder nicht" nichts zu tun.
Bye
Frederik
PS: zur Illustration die in Europa vorkommenden "voltage"-Werte samt
Anzahl (nur die, die > 10x vorkommen). Sind diese Werte plausibel und
tatsaechlich alle in Volt?
30390 <tag k="voltage" v="15000"/>
9785 <tag k="voltage" v="110000"/>
7823 <tag k="voltage" v="1500"/>
6638 <tag k="voltage" v="25000"/>
6588 <tag k="voltage" v="3000"/>
2895 <tag k="voltage" v="750"/>
1453 <tag k="voltage" v="380000"/>
1322 <tag k="voltage" v="220000"/>
962 <tag k="voltage" v="20000"/>
916 <tag k="voltage" v="10000"/>
705 <tag k="voltage" v="400"/>
634 <tag k="voltage" v="600"/>
609 <tag k="voltage" v="800"/>
558 <tag k="voltage" v="400000"/>
356 <tag k="voltage" v="150000"/>
348 <tag k="voltage" v="1000"/>
343 <tag k="voltage" v="600;750"/>
283 <tag k="voltage" v="35000"/>
183 <tag k="voltage" v="132000"/>
165 <tag k="voltage" v="220000;110000"/>
141 <tag k="voltage" v="380000;110000"/>
119 <tag k="voltage" v="850"/>
117 <tag k="voltage" v="380"/>
110 <tag k="voltage" v="380000;220000"/>
100 <tag k="voltage" v="330000"/>
92 <tag k="voltage" v="500000"/>
91 <tag k="voltage" v="65000"/>
89 <tag k="voltage" v="11000"/>
67 <tag k="voltage" v="33000"/>
64 <tag k="voltage" v="380000;220000;110000"/>
60 <tag k="voltage" v="30000"/>
49 <tag k="voltage" v="60000"/>
46 <tag k="voltage" v="0"/>
38 <tag k="voltage" v="22000"/>
35 <tag k="voltage" v="fixme"/>
34 <tag k="voltage" v="110000;20000"/>
33 <tag k="voltage" v="400000;150000"/>
33 <tag k="voltage" v="130000"/>
29 <tag k="voltage" v="1200"/>
24 <tag k="voltage" v="unknow"/>
22 <tag k="voltage" v="3300"/>
21 <tag k="voltage" v="1250"/>
20 <tag k="voltage" v="750000"/>
18 <tag k="voltage" v="550V"/>
18 <tag k="voltage" v="550"/>
15 <tag k="voltage" v="66000"/>
15 <tag k="voltage" v="6000"/>
14 <tag k="voltage" v="150000;60000"/>
13 <tag k="voltage" v="275000"/>
13 <tag k="voltage" v="110000;0"/>
12 <tag k="voltage" v="900"/>
12 <tag k="voltage" v="70000"/>
12 <tag k="voltage" v="110000;35000"/>
11 <tag k="voltage" v="1550"/>
10 <tag k="voltage" v="38000"/>
10 <tag k="voltage" v="35000;35000"/>
10 <tag k="voltage" v="35000/10000"/>
--
Frederik Ramm ## eMail [email protected] ## N49°00'09" E008°23'33"
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
