Am 14.02.2011 03:02, schrieb Frederik Ramm:
Ich denk mir halt, der Mapper wird doch einen Grund haben, warum er
700cm eingibt und nicht 7m.
Ich glaube, du unterstellst in sehr, sehr, sehr vielen Fällen dem Mapper
eine Intention, die nie da war - "ist halt so geworden" - trifft es in
vielen Fällen wohl eher ;-)
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...".
Ja, das ist ein Punkt für die Angabe der Masseinheit.
Grundsaetzlich finde ich, dass der Editor dem Mapper da nicht
dazwischenfunken sollte.
Das ist gut für jemanden der weiß was er tut und schlecht für jemanden
der sich nicht so auskennt oder sich nicht erinnert und erst nachschauen
muß.
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.
Das "small", "medium", "large" wird bei der Detailgenauigkeit der Mapper
eh nicht passieren. Das ist eine Erfindung von dir.
Wenn man auf seiner Karte so eine 3er Klassifizierung (z.B. kleines,
mittleres und großes Icon) haben möchte muß man diese entsprechend
umrechnen, klar. Das ist aber nicht das Problem, das kriegt man hin. Das
Problem sind drei verschiedene Schreibweisen, vier verschiedene
Maßeinheiten und was weiß ich sonst noch an Varianten.
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.
Bei Spannungen "V" und bei Längen "m" sind bei OSM eigentlich inzwischen
einheitenlos Standard - wenn man denn von den Engländern mit "ft" absieht.
Ich kann jetzt kein prinzipielles Problem erkennen sich auf "kW" (oder
sogar "W") zu einigen. Außer vielleicht, daß GW in "W" ausgedrückt ein
wenig unhandlich wird. Aus meiner Sicht macht das letztlich allen
Beteiligten das Leben leichter.
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.
Kannst du einen Editor nennen, der Semikolons "einschmuggelt"?!?
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?
Bei den Zahlenwerten gehe ich davon aus, ja. Die Einträge mit "unknow"
und "fixme" machen die Verarbeitung allerdings schonmal nicht leichter.
Bei "550V" ist die Angabe V nun wirklich redundant. Die Werte, die
kleiner 10 mal vorkommen hast du gnädig unter den Tisch fallen lassen,
erfahrungsgemäß lauern hier die wirklich üblen Sachen.
Jetzt kannst du natürlich sagen: Alles unter 10 mal interessiert mich
nicht, allerdings fehlen damit laut "long tail" sehr viele Werte die man
eigentlich schon auch haben möchte - gerade bei einer special interest
map. Und da geht dann die Arbeit erst so richtig los - mit SQL möchte
ich sowas nicht lösen müssen.
Gruß, ULFL
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"/>
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
