Hallo,
ich bin gerade darüber gestolpert, dass die Koordinaten, die mir die OKAPI unter caches/geocache zu einem Cache liefert scheinbar anders gerundet sind als jene, die auf der Webseite oder in einer GPX von der Webseite enthalten sind. Das ist kein Weltuntergang, aber schon irgendwie komisch, wenn man annimmt, dass beiden Ausgaben der gleiche Datensatz zu Grunde liegt.
Webseite: N 51.35153° E 007.49052°
GPX: <wpt lat="51.35153" lon="7.49052">
OKAPI: <string key="location">51.351533|7.490517</string>
Viele Grüße!
Edit: Hier am Beispiel von OC1158E .
OKAPI vs GPX : Uneinheitlich gerundete Koordinaten?
Ich sehe in Deinem Beispiel keine Abweichung.
Sind doch ganz normale Rundungen, die da vorgenommen wurden.
Also aus 51.351533 (OKAPI) wird 51.35153 (GPX) <-- weil ...33 zu ...30 abgerundet wird.
Und aus 7.490517 (OKAPI) wird 7.49052 (GPX) <--- weil ...17 zu ...20 aufgerundet wird.
Sind doch ganz normale Rundungen, die da vorgenommen wurden.
Also aus 51.351533 (OKAPI) wird 51.35153 (GPX) <-- weil ...33 zu ...30 abgerundet wird.
Und aus 7.490517 (OKAPI) wird 7.49052 (GPX) <--- weil ...17 zu ...20 aufgerundet wird.
Ich habe ja auch nichts von Abweichung geschrieben, sondern nur von Runden . Ich finde es halt komisch, dass die Schnittstellen nicht einheiltich sind.
Hinzu kommt, dass im OKAPI-GPX-Format auch sechs Nachkommastellen ausgegeben werden. In den Original-GPX-Dateien von Groundspeak sind es allerdings nur fünf Stellen.
Sechs Stellen dürften beim Hin- und Herkonvertieren zwischen verschiedenen Koordinatenformaten zuverlässiger sein, bei fünf Stellen kann sich leichter mal ein Rundungsfehler an der letzen Stelle einschleichen. Allerdings ist auch eine Übereinstimmung mit den Groundspeak-Koordinaten sinnvoll.
Was tun?
Sechs Stellen dürften beim Hin- und Herkonvertieren zwischen verschiedenen Koordinatenformaten zuverlässiger sein, bei fünf Stellen kann sich leichter mal ein Rundungsfehler an der letzen Stelle einschleichen. Allerdings ist auch eine Übereinstimmung mit den Groundspeak-Koordinaten sinnvoll.
Was tun?
Oh, ich wusste nicht, dass die "Standards" das so definieren. Habe inzwischen auch mal nachgerechnet: Die Abweichungen sind unter 40cm. Vielleicht besteht da auch absolut kein Handlungsbedarf. Ich war nur drüber gestolpert
Der Standard (das GPX-Schema von topografix) definiert hier lediglich den Typ (decimal), der wiederum eine Fließkommazahl von maximal 18 Stellen darstellt. Insofern ist die Zahl der Nachkommastellen 'lediglich' eine Konvention und eine gewisse Variabilität meiner Ansicht nach durchaus vertretbar.
Bleibt die Unschönheit, dass für einen Cache mit identischen GC- und OC-Koordinaten verschiedene GPX-Koordinaten ausgegeben werden, wenn die Zahl der Nachkommastellen abweicht. Da man Koordinaten aber ohnehin unscharf vergleichen muss (z.B. weil GC-Koordinaten manchmal wegen Abstandskonflikt ein paar Meter verschoben werden) sollte das kein Problem sein.