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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
