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

[Frederik Ramm]

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