Derzeit werden viele TAGs ohne Einheit angegeben (z.B. ele, maxspeed, maxheight, …)
manchmal ist jedoch auch eine Einheit zu finden, leider jedoch nicht sehr einheitlich:
height=3m, height=3 m, height=3meters, …
Mein Vorschlag wäre, die Einheit in ein eigenes Feld zu schreiben.
height=3 mit height_unit=m oder height:unit=m (in letzter Zeit setzt sich der Doppelpunkt eher mehr durch)
Das würde die Auswertung dieser Angaben enorm erleichern.
Bei taginfo habe ich derzeit nur distance_unit=mi, length_unit=km und width:units=meters dazu gefunden.
Also wenn ich z.B. vom Tag “height” bzw. “maxspeed” ausgehe, so ist das in der Beschreibung eigentlich so geregelt, dass Meter bzw. Kilometer/Stunde die Grundeinheiten bilden, welche nicht näher bezeichnet werden müssen.
Nur abweichende Maßeinheiten wie z.B. “feet” oder “miles/hour” müssen der Angabe nachgestellt werden.
beim gewicht (maxweight) ist es genau so.
allgemein: eine einheit ist definiert und abweichende einheiten werden halt im tag mit angegeben.
allerdings wird es da etwas “schwammig”. in welcher form die einheit dann angegeben werden soll, ist nicht mehr so klar definiert. (ft - feet, uz - unze? ’ - zoll?)
wir europäer können bestimmt gut damit leben (was ist mit den engländern? sind die schon “metrisch”?)
gruss
walter
wäre bestimmt zielführender wenn jemand mit einem Bot diese Angaben mal vereinheitlicht. Das betrifft auch das unterschiedliche Nutzen von Komma und Punkt bei der Angabe von Nachkommastellen, da Deutsche immer verleitet werden das Komma zu nutzen, es offiziell aber Punkte sein sollen. Die Konventionen für die Inselbewohner scheinen so auszusehen: http://wiki.openstreetmap.org/wiki/Road_Signs#Size.2FWeight_restrictions
sollte doch nicht so schwer sein:
wert besteht auf ziffern, “.” und leider auch “,”. der rest ist “einheit”. ist in 2-3 zeilen code zu machen.
wichtiger erscheint es mir, das format der “einheiten” klarer zu definieren. in dem wiki fehlen auch Flächen, Volumen und Gewichte.
dann könnte ein bot die einheiten bereinigen.
somit ist es nicht notwendig, neue tags oder sub-tags zu definieren.
So wird das aber nciht sinnvoll auswertbar. Entweder konsequent immer die Einheit oder mit zu der Zahl. Ansonsten darf man als Auswerter darauf vertrauen, dass jeder bewusst das x:unit weggelassen hat und es nicht nur nicht gewusst hat bzw. einfach vergessen hat.
eigentlich dachte ich daran, die Auswertung damit zu vereinfachen.
Mir ist klar, dass ich mit ein paar Zeilen Code die Einheit wieder vom Wert trennen kann.
Grundsätzlich ist es aber besser, in einer Datenbank Zahl und Einheit getrennt zu speichern und erst bei Bedarf zusammenzusetzen.
Wenn ich mit mkgmap oder dem Composer eine Abfrage auf < oder > einbauen will, dann geht das mit getrennten Einheiten wesentlich einfacher.
Vorab erst einmal: Ich bin gegen eine Auftrennung von Werten, die aus Zahl und Einheit bestehen, in zwei Tags.
Aus semantischer Sicht handelt es sich hier um einen einzigen Wert. Es macht absolut keinen Sinn, die beiden Informationen unabhängig zu betrachten: Ein x:unit ohne x ist Quatsch. Und auch das x ist ohne die Information aus :unit wertlos, weil es eben nun mal einen Unterschied macht, ob ich 42 Kilometer oder Meilen vor mir habe.
Ich finde es auch gerade aus Sicht des Mappers wesentlich natürlicher und komfortabler, wenn er den Wert nicht in Einheit und Zahl aufspalten muss. Und das Auswerten ist ja nicht mal so ein Problem, wie du es hier darstellst.
Wenn man für ein gegebenes Objekt die entsprechenden Werte verstehen will, dann ist das auch dann ziemlich simpel. Zumindest konnte ich es meiner Software ohne Probleme beibringen: ValueStringParser.java Die Klasse darf übrigens jeder gerne ohne weitere Auflagen verwenden, wenn er sich die paar Minuten fürs Selberschreiben sparen möchte…
Nicht ganz so einfach ist natürlich ein Vergleich über die Attributswerte verschiedener Objekte, aber ich sehe nicht, was die Trennung da für entscheidende Vorteile bringen sollte.
Deine Abfrage findet dann aber eben gerade nicht solche Objekte, die unter 3 m hoch sind, sondern nur diejenigen, die unter 3 m hoch sind und deren Höhe in Metern angegeben ist.
Ich habe zwar keine Ahnung von den Interna dieser konkreten Programme, aber es scheint mir ziemlich offensichtlich, dass eine Menge von Höhenwerten, auf denen man eine Bereichsabfrage z.B. per < durchführen möchte, vorher in einen rein numerischen Wert umzurechnen ist. Zum Zeitpunkt des Vergleiches sollte die Einheit, in der der Wert ursprünglich angegeben war, doch schon längst keine Rolle mehr spielen.
Hallo Walter,
hab eben im Zug nochmal ein wenig drüber nach gedacht. Am sinnvollsten wäre es, wenn man den Editoren die Umrechnung beibringt. Man gibt also an Maß und Einheit in einem Eingabefenster an und der Editor rechnet diese dann in SI-Einheiten um und speichert diese in der Datenbank. Noch besser wäre es natürlich, wenn man das Einheitensystem im Editor einstellen könnte, dann können diese Werte auch in der Gewünschten Einheit angegeben werden.
Ein extra unit-Tag oder auch Einheit mit beim Maß ist nicht sinnvoll auszuwerten, weil man für jede Längeneinheit bspw. eine eigene Auswertung machen müsste.
Das ist nicht unbedingt sinnvoll, denn dann wäre die Information, in welcher Einheit der Wert gegeben war, ja nicht mehr für zukünftige Bearbeiter verfügbar.
Außerdem ist dann außerhalb von Editoren, z.B. in der History, der Änderungsansicht oder auch Taginfo, ebenfalls wesentlich nützlicher, ein “55 mph” angezeigt zu bekommen, als ein “88.51392”.
Die gewünschte Einheit ist aber oft diejenige, in welcher z.B. das Schild in der Realität nun mal gehalten ist, und daher nicht global anzugeben.
Ich finde eine Einheit mit im Wert problemlos auswertbar, solange sich die Mapper auf einige Einheiten (z.B. die auf Map Features/Units definierten) beschränken. Da bei vielen der Tags ohnehin Beschilderung die Grundlage ist und dort nicht gar so viele unterschiedliche Einheiten zum Einsatz kommen, ist das in der Praxis auch üblicherweise der Fall.
Hallo Henning, du hast Recht, für ft müsste eine eigene Zeile geschrieben werden.
Hallo Tordanik, height:unit!=* führt dazu, dass Zahlen ohne Einheit als Meter betrachtet werden.
Es ist wohl beim Mappen aufwändiger, wenn 2 Felder bestückt werden müssen.
Ich hoffe daher, dass die Umrechnung irgendwann einmal bei mkgmap implemetiert wird.
Also eine Umrechnung im Editor halte ich jetzt auch nicht für so sinnvoll. Dann müsste ja jedes Routingprogramm seinerseits auch wieder alles Umrechnen um es korrekt an zu zeigen wenn man in dem jeweiligen Land ist. Zudem gibt es evtl. auch irgendwo in irgendwelchen Bereichen exotischere Maßeinheiten für irgendwas, die der Editor nicht kennt und dann auch nicht umrechnen kann.
Es wäre also wirklich sinnvoll die Maßeinheiten mit dazu zu schreiben, in welcher Form auch immer. Im selben Tag ist natürlich einfacher für die Mapper, was allerdings wenig bringt wenn es Softwareseitig schlecht aus zu werten ist. Wobei das ja eigtl. kein Problem sein dürfte wenn man sich an gewisse Regeln hält (z.B. die Einheit getrennt durch ein Leerzeichen, so dass das Programm die Buchstaben nach dem Leerzeichen automatisch als Einheit werten kann). Aber da muss ein Programmierer was zu sagen.