DE:Dokumentieren von ermittelten Punktpositionen

Problem

Für Wege gibt es in OSM die Möglichkeit, die vom GPS-Gerät aufgezeichneten Spuren (Tracks) auf den OSM-Server zu laden und sie so anderen Mappern für die Arbeit im Editor zur Verfügung zu stellen, die mit den so entstehenden Linienbündeln leicht eine gute mittlere Position des Weges festlegen können. Dabei kann jeder Mapper optisch kontrollieren, auf welche Tracks sich die Vorgänger bei der Positionsvergabe bezogen haben.

Alternativ gibt es Luftbilder, auf die man sich beim Mappen von Wegen beziehen kann — dies kann für nachfolgende Mapper mit dem Tag source=* vermerkt werden.

Für kleine, in OSM als Punkte (Nodes) dargestellte Objekte wie zum Beispiel Grenz- und Meilensteine funktionieren diese Methoden meist nicht, da sie nicht „abgelaufen" werden können und meist auf Luftbildern nicht erkennbar sind.

Hier ist die gängige Praxis, dass der Ersterfasser die Position mittels eines Waypoints eines geogetaggten Fotos oder freihändig vergibt. Nachfolgende Mapper korrigieren dann typischerweise die Position noch mehrmals auf Grundlage ihrer selbst erhobenen Daten, können aber kaum von den Daten der vorhergehenden profitieren, da sie weder die Methode der Erfassung noch deren Genauigkeit einschätzen können. So gehen möglicherweise wertvolle Informationen verloren.

Lösungsansatz

Manuelle Visualisierung für 3 Mittelungsergebnisse (rote Punkte) eines Grenzsteins (Position aus Mittelwerten) in JOSM. Orange Linie: Grenze aus dem Kreisgrenzen-Import. Rote Linie: Grenze aus offizieller online-Katasterkarte von [1] zum Vergleich exportiert.

Bei der Erfassung von Grenzsteinen und einzelnen anderen Objekten habe ich folgendes Vorgehen erprobt:

• mitteln eines Wegpunktes mit dem GPS-Gerät für mindestens 10 Minuten
• festhalten von Startzeitpunkt und Dauer der Positionsmittelung
• dokumentieren der Position als Tag nach folgendem Schema:

 position:averaging:Gerät:Startzeitpunkt:Dauer(s)=Breite,Länge,Höhe

Beispiel Grenzstein Grenzstein:

 position:averaging:vistahcx:2011-12-15-15-55-12:660=50.68805,7.03846,142

• mehrmaliges Wiederholen der Messung

Durch das Vorhandensein des Startzeitpunktes im Schlüssel des Tags können theoretisch beliebig viele Messungen gespeichert werden und in einer zukünftigen Auswertung könnte theoretisch die zu diesem Zeitpunkt vorhandene Satellitenkonstellation berücksichtigt werden.

Für eine Position, die aus einem „einfachen" Wegpunkt übernommen wurde, könnte dieses Schema angewendet werden:

position:waypoint:Gerät:Zeitpunkt=Breite,Länge,Höhe

Alternative Tagging-Schemata

• bitte Vorschläge ergänzen

Alternative 1: position:averaging:<nr>=<datum>;<gerät> <lat>;<lon>[;<ele>]

Das oben vorgeschlagene Schema hat den großen Nachteil, dass jede Messung einen neuen Schlüssel erzeugt und es zu jedem Schlüssel nur genau einen Wert gibt. Das ist sehr unschön und ineffizient. Außerdem kann man (z.B. mit der XAPI) nur sehr schlecht nach solchen Nodes suchen. Das Datum (auf jeden Fall) und das Gerät (da könnte man ggf. noch drüber reden) gehören also in den Wert und nicht in den Schlüssel.

Das Format des Datums und der Dauer der Messung ist auch sehr unglücklich gewählt, weil es keinem existierendem Standard entspricht und schwer zu lesen ist (Datum und Uhrzeit werden optisch nicht getrennt). Besser wäre es ISO 8601 zu benutzen. Das sieht fast genauso aus und bietet bereits einen Mechanismus die Messdauer anzugeben. Außerdem kann der Zeitpunkt der Messung mit Zeitzonen genau angegeben werden (falls irgend jemand im nachhinein die gemessenen atmosphärischen Störungen herausrechnen will).

Mehrere Messungen an einem Node sollten durch laufende Nummern unterschieden werden. Das entspricht üblichen Taggingkonventionen (siehe z. B. destination:1=* bis destination:19=*).

Das Leerzeichen habe ich als Trennzeichen zwischen den Metadaten und den Daten des Messung gewählt, weil es automatisch dafür sorgt, dass bei den Metadaten Disziplin bei der Wahl der Formate eingehalten wird (keine freien Formate mit Leerzeichen).

Das Semikolon als Trennzeichen hat den Vorteil, dass es weder in Angaben nach ISO 8601 noch in typischen Dezimalzahlen vorkommt. Egal was bei den Dezimalzahlen als Dezimaltrennzeichen oder Tausendertrennzeichen benutzt wird — die Trennung der drei Werte bleibt davon unberührt.

Der Algorithmus zur Auswertung des Tags sollte fest vorgeben werden:

1. Wert an allen Leerzeichen trennen
2. Die beiden ersten beiden sich ergebenen Teilstrings an Semikolons trennen
3. Die beiden ersten Strings aus dem ersten Teilstring und die drei ersten Strings des zweiten Teilstrings bilden das Ergebnis

Das obige Beispiel sieht damit dann so aus:

Beispiel Grenzstein Grenzstein:

 position:averaging:1=2011-12-15T15:55:12PT11M;vistahcx 50.68805;7.03846;142

Alternative 2: Metadaten in das Value verschieben

Freie Werte finde ich im Value besser aufgehoben:

 position:1           = time=2011-12-15T15:55Z; lat=50.68805; lon=7.03846; ele=142; device=vista; user=Alfonzo; …

oder

 position:1           = time: 2011-12-15T15:55Z; lat: 50.68805; lon: 7.03846; ele: 142; device: vista; user: Alfonzo; …

• wird atomar geschrieben
• ist menschenlesbar
• ist trivial maschinenlesbar
• ist auf und abwärtskompatibel bei Erweiterung der Tags

Netzwolf 23:36, 10 January 2012 (UTC)

mögliche Anwendungen

• Nachvollziehbarkeit der Quellen einer Objektposition
• Einschätzung der Positionsgenauigkeit eines Objekts (speziell auf Luftbildern verdeckte und kleine Objekte)
• ein Editor-Plugin, das aufgrund der Messungen eine gemittelte Position für Punkte vorschlägt
• Feststellung des Versatzes von Luftbildern anhand sichtbarer gemittelter Objekte
• ...