Hallo,
Stephan Wolff wrote:
Wir muten den Mappern an anderer Stelle zuviel zu. Wenn ein Mapper
einen Weg teilt, der zufällig zu einer Relation gehört, dann muss
er den Aufbau dieser Relation erlernen, um sie ggf. zu reparieren.
Würden wir festlegen, dass man die Elemente jeder Relation teilen
darf (dann hätte eine Abbiegerelation evtl. mehrere "from" und "to"
Elemente), wäre das eine echte Erleichterung für die Mapper.
Das hatten wir neulich schonmal - nur, weil anderswo etwas laestig ist,
ist das keine Lizenz, neue laestige Sachen einzufuehren.
Wenn der Editor für das Feld "Breite in m" nur Zahlen erlaubt,
macht der Mapper keine Fehler und alle Programme werten die
Angabe richtig aus. Wenn er "width=700cm" bei einem Fluss einträgt
und Osmarender einen 700m breiten See malt, ein anderes Tool
die Textausgabe "Flussbreite : 700cm m" macht oder der Editor beim
Zusammenfügen die Angabe "width=700cm; 7" erzeugt, ist der Mapper
verwirrt.
Es gibt bei OSM keine strenge Typisierung von Tags, und ich denke nicht,
dass es die jemals geben wird. Du musst Dich von dem Gedanken
verabschieden, dass das, was da in England auf dem Server ist, irgendwie
eine saubere, leicht auswertbare Datenbank ist oder jemals sein kann.
Kein Ausmass an Editorvorschriften und Bots wird dazu fuehren - diese
Datenbank wird immer das "Rohmaterial" sein, aus dem man brauchbare
Daten ableiten muss.
Nicht allen Mappern gelingt es, ein Gebiet exklusiv zu bearbeiten.
Sobald man mit anderen gemeinsam arbeitet, kann man seine bevorzugte
Einheit ohnehin nicht durchsetzten,
Ja, genau darum geht es, dass jeder seine bevorzugte Einheit verwenden
kann, ohne sie "durchsetzen" zu muessen.
Dann werden die Vorteile der einheitlichen Angabe noch deutlicher.
Besser ich zwinge einen Mapper, seine Angabe von Seemeile, yard,
Landmeile oder fathom in Meter umzurechnen (Wolfram Alpha:
"8 fathom in m" -> "14.63 meters"), als alle Mapper und alle
Anwender mit diesen Einheiten zu belasten.
Das ist etwas, was ganz gewiss nicht passieren wird. Erstens, weil wir
keine Seetiefen mappen ;) zweitens wegen (Wolfram Alpha) "14.63 meters
in fathoms" => "7.9998 fathoms" - der englische Mapper hat voellig zu
recht den Anspruch, dass aus seinen vom Verkehrsschild abgelesenen 20
mph nicht ploetzlich 19.9997 werden, weil irgendjemand das partout
intern in Meter pro Sekunde speichern wollte oder so.
Bei Osmarender muss eine angepasste Version an alle Teilnehmer
verteilt werden, bis eine neue Schreibweise zur korrekten
Kartendarstellung führt.
1. tiles@home ist eh tot, 2. die meisten Tile-Renderer machen eh
regelmaessig automatisch ein "svn up". Wenn Dein Argument stichhaltig
waere, koennte es ja in tiles@home nie irgendwelche Stil-Updates geben.
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.
Zu den Möglichkeiten des Validators oder zu anderen Vorteilen
wählbarer Einheiten?
Dazu, dass die mitgefuehrte Einheit keinen Vorteil bringt.
Jeder der drei Anwender würde von einer Zahlenangabe in MW profitieren.
Für den ersten vereinfacht sich das Umrechnungstool, der andere kann
die Zahl ohne Vorverarbeitung nutzen. Der Mapper spart drei Zeichen
und kann sich an der sinnvollen Nutzung seiner Daten erfreuen.
Die mitgelieferte Einheit gibt eine groessere Sicherheit bei der
Interpretation; die Freiheit des Mappers, die Zahl so eintragen zu
koennen, wie er sei in der freien Wildbahn antrifft, ist m.E. hoeher zu
bewerten als der Komfort des Programmierers.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
