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

Mi Feb 16 14:13:58 UTC 2011

Ich habe mich grad letzthin ziemlich abmühen müssen, so etwas
Einfaches wie "elevation" von peaks oder viewpoints zu parsen. Das "m"
nach der Höhenangabe ginge ja noch...

Mit der Eingangsfrage "Werte mit/ohne Einheit" haben sich andere ja
auch schon befasst, z.B. XML wo das einfach wäre aber hier nicht so
Sinn macht. Meine Erkenntnisse aus diesen Erfahrungen sind:

* Dem Mapper überlassen, ob er eine Einheit hintendran hängt und dass
diese halt so ist, wie er es nach bestem Wissen meint.

* Die Mapper aber immer wieder freundlich ermuntern, "nach bestem
Wissen und Gewissen" zu handeln, bzw. editieren.

* Grundsätzlich die ISO-Basiseinheiten verwenden
(http://de.wikipedia.org/wiki/Internationales_Einheitensystem#SI-Basiseinheiten
) und Abweichungen davon selbstverständlich dokumentieren (:->).

* Die - zugegebenermassen nicht-hinreichende - Voraussetzung zur
Ermunterung und zur Dokumentation ist eine gute OSM-Wiki-Seite (:->).

* Die an sich schon guten OSM-Editoren könnten einem (in Zukunft) bei
der Auswahl der Masseinheiten helfen.

* Ein Kompromiss wäre, Einheiten in eckigen Klammern (o.ä.) zu setzen
(bzw. vom Editor das so setzen zu lassen). Beispielsweise
"generator:output:electricity=0.1 [MW]".

Letztere Notation wäre menschen- *und* maschinen-lesbar und löste auch
das (noch schlumernde) Problem, dass in Zahlen ja auch Zeichen und
Buchstaben vorkommen könnten (z.B. Exponential- oder Potenzangaben),
was das "Entziffern" der Codierung endgültig zum Rätselraten verkommen
lässt.

LG, S.

P.S. Als Programmiersprache zur OSM-Datenverarbeitung würde ich in
diesem Fall Python anschauen und einen passenden Editor
(Entwicklungsumgebung) dazu auslesen: vgl.
http://www.gis.hsr.ch/wiki/Python

Am 15. Februar 2011 03:20 schrieb Stephan Wolff <s.wolff at web.de>:
> Moin!
>
> Am 14.02.2011 19:42, schrieb Frederik Ramm:
>>
>> 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.
>
> Die Umrechnung zwischen metrischen Einheiten ist nicht lästig. Der
> Mapper spart die dafür verwendete Sekunde wieder ein, da er keine
> Einheit tippen muss. Die Einarbeitung in unbekannte Relationen
> kostet dagegen viel Zeit.
>
>>> 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.
>
> Die OSM-Datenbank wird immer Daten in seltsamen Formaten enthalten. In
> den meisten Fällen werden diese Daten keinen Nutzen haben und keinen
> Schaden machen. In wenigen Fällen wird es Fehlinterpretationen geben
> und ein Freiwilliger muss die problematischen Daten ändern.
> Falls Osmarender einen Fluss mit "width=700cm" als 700m breiten See
> malt (ich habe das nicht getestet), würde ich die Angabe in "width=7"
> ändern. Dadurch habe ich Arbeit, das Kartenbild ist zeitweise defekt
> und der ursprüngliche Mapper verliert seine Einheit.
>
>>> 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 ;)
>
> Der Wittensee (http://osm.org/go/0Hm7TLEs-) und einige hundert Punkte
> mit waterway=depth beweisen das Gegenteil :-)
>
>> zweitens wegen (Wolfram Alpha) "14.63 meters in fathoms" => "7.9998
>> fathoms" -
>
> Der Mapper meinte wahrscheinlich (8+-1)fathom, so dass alle Angaben
> zwischen 14 und 15 Meter gleichbedeutend sind. Anderenfalls dürften wir
> auch einen Kreis nicht durch ein Polygon mit endlich vielen Punkten
> beschreiben.
>
>> 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.
>
> Für gesetzliche Einschränkungen, insbesondere Verkehrsschilder sollte
> man sicherlich die offizielle Angabe nutzen. Bei geschätzten/gemessenen
> Größen hat ein einheitlich metrisches System viele Vorteile.
> Die Googlesuche nach "osm ist metrisch" lieferte mir gerade das Zitat:
> "...
> Und Wassertiefen immer in Faden angeben, ist ja klar, oder :-)
> Bye
> Frederik
> (PS: War Spass - OSM ist metrisch.)"
>
>>> 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.
>
> Eine Datenbank hat nur einen Nutzen, wenn die Daten sinnvoll auswertbar
> sind. Wenn ein Mapper "highway=Autobahn" eingibt (wie es im Gesetz und
> auf Schildern steht), ist das komfortabel, aber der Weg wird vom
> Renderer nicht dargestellt und von Router nicht ausgewertet. Die
> Umsetzung in "highway=motorway" ist beim ersten Mal lästig, aber der
> Weg wird dann gezeichnet und für das Routing benutzt.
>
> Jemand, der Regeln für Osmarender, Mapnik, Kosmos oder Maperative
> erstellt, kann Längen- und Breitenangaben mit beliebigen Einheiten
> in der Regel nicht korrekt auswerten. Jemand, der alle Straßen
> schmaler als x Meter aus einer bestehenden OSM-Datenbank ziehen will,
> wird scheitern oder sehr viel Zeit brauchen.
>
> Für den Komfort des Mappers, einen Wert im von ihm bevorzugten
> Textformat zu kodieren, möchtest du die Freiheit der Datennutzung
> auf die wenigen Programmierer beschränken, die Zeit und die Fähigkeit haben,
> einen korrekten Parser für die Texte zu schreiben. Dann wäre
> die Nutzung der OSM-Daten auf einen kleinen, elitären Kreis beschränkt.
>
> Viele Grüße, Stephan
>
>
>
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>