Wie viele Dezimal stellen sind sinnvoll?

[DunkleAura]

Ich möchte einen ganzen Stapel Koordinaten in einer DB Speichern, jetzt stellt sich mir die Frage, wie viele Dezimal stellen sind da sinnvoll?

Und Nord/Süd Ost/West, wie Löse ich das am besten?
N/S als 47.123/-47.123
E/W als 007.123/-007.123

oder doch je noch ein char Feld für N/S und E/W?

Mittlerweile hab ich auch herausgefunden, wie hoch die "Maximal" Werte sind, 90 resp. 180.

Bin dankbar für eure Meinungen.

Gruss DunkleAura

 

[TMC]

Ich möchte einen ganzen Stapel Koordinaten in einer DB Speichern, jetzt stellt sich mir die Frage, wie viele Dezimal stellen sind da sinnvoll?

Perspektivisch vielleicht mehr Stellen »eindenken«, als heute sinnvoll erscheint, weil irgendwann, wie auch immer, wird's genauer werden, als 10-5m.

Und Nord/Süd Ost/West, wie Löse ich das am besten?
N/S als 47.123/-47.123
E/W als 007.123/-007.123
oder doch je noch ein char Feld für N/S und E/W?

Das kommt stark darauf an, wie Du die DB nutzen wirst. Wenn Du 'nen eigenen Output schreibst ist's eher egal, weil Du dann so oder so korrekt anzeigen, sortieren oder selektieren kannst. - Wenn nur Du selbst die DB vorrangig über das DB-Interface nutzen wirst (myadmin o.ä.) dann kann es Sinn machen, wenig Tabellen-Felder zu belegen, weil dann z.B. die Sortierung leichter fällt.

 

[moenk]

Ich nehm doch mal Du wirst die Werte in Dezimal umrechnen und als Double speichern, jeweils für Länge und Breite.

 

[DunkleAura]

Ich möchte einen ganzen Stapel Koordinaten in einer DB Speichern, jetzt stellt sich mir die Frage, wie viele Dezimal stellen sind da sinnvoll?

Perspektivisch vielleicht mehr Stellen »eindenken«, als heute sinnvoll erscheint, weil irgendwann, wie auch immer, wird's genauer werden, als 10-5m.

Und Nord/Süd Ost/West, wie Löse ich das am besten?
N/S als 47.123/-47.123
E/W als 007.123/-007.123
oder doch je noch ein char Feld für N/S und E/W?

Das kommt stark darauf an, wie Du die DB nutzen wirst. Wenn Du 'nen eigenen Output schreibst ist's eher egal, weil Du dann so oder so korrekt anzeigen, sortieren oder selektieren kannst. - Wenn nur Du selbst die DB vorrangig über das DB-Interface nutzen wirst (myadmin o.ä.) dann kann es Sinn machen, wenig Tabellen-Felder zu belegen, weil dann z.B. die Sortierung leichter fällt.

Sowohl als auch.
Prioritär, werde ich es mit CocoaMySQL verwenden, auf Windows mit MySQL-Front oder Unterwegs mit myadmin als idee hätte ich da noch ein self made "lite admin" das handy tauglich ist.
MySQL finde ich da universeller ist als z.B. Access und gegenüber einer csv Datei auch sortiert und gefiltert werden kann.

Es kann auch sein, dass ich irgendwann "meine Favoriten" oder eben die privaten POIs auch meinen Kollegen per einer Homepage Zeige.

Ich nehm doch mal Du wirst die Werte in Dezimal umrechnen und als Double speichern, jeweils für Länge und Breite.

Genau, so habe ich es mir gedacht, in MySQL würde sich der Datentyp float dafür anbieten.

 

[Wallraff]

Hallo,

ich gedenke nicht, mich in DB-Fragen einzumischen ... aber was ist mit der Speicherart "double" gemeint, doch nicht doppelt-genau ?

Die gängigen GPS liefern siebenstellige NMEA-Formate mit tausendstel Minuten (z.B. 4813.123 N) entsprechend etwa 1,8 m .

Sollen daraus z.B. Koordinaten erzeugt oder gespeichert werden, wie ich sie zu meinem gelinden Entsetzen schon vorfand

5854333,445687189
d.h. auf Nanometer ???


Grüße Wallraff

 

[greiol]

nimm auf alle fälle mal alles mit an stellen was du hast, denn es ist immer einfach ab stelle x zu runden als später etwas "anzulängen". sofern du eine hinreichende laufzeit des projektes annimmst, kann es auch nicht schaden noch ein paar stellen "auf vorrat" zu haben, falls sich die messtechnik noch weiter verbessert.

 

[KoenigDickBauch]

Hallo,

Zum Speichern kann man das auf Integer (32bit) reduzieren.

einfach 180/2^31 als kleinste mögliche Zahl nehmen und das ist dann schon sehr genau.

Besser wäre es aber die kleinste Zahl mit 1°/10^6=0,00006' dann kann man im einem Datenbankbrowser sogar die richtigen Zahlen sehen und suchen und sortieren ist schneller.

KDB

 

[DunkleAura]

Also, ich Danke euch allen für Eure Antworten und sage euch jetzt mein Ergebnis. Ich habe mich entschlossen das ganze mit 6 Nach Komma stellen zu speichern, N/S vorne 2, E/W vorne 3.

Jetzt ist nur noch die Frage wegen der "Himmelsrichtung"
2 char Felder mit: N/S - E/W
oder
die Zahlen signed:
N = + | S = -
E = + | W = -

Wobei die 2 char Felder Human besser lesbar wären.

Gruss DunkleAura

 

[KoenigDickBauch]

Also, ich Danke euch allen für Eure Antworten und sage euch jetzt mein Ergebnis. Ich habe mich entschlossen das ganze mit 6 Nach Komma stellen zu speichern, N/S vorne 2, E/W vorne 3.

Jetzt ist nur noch die Frage wegen der "Himmelsrichtung"
2 char Felder mit: N/S - E/W
oder
die Zahlen signed:
N = + | S = -
E = + | W = -

Wobei die 2 char Felder Human besser lesbar wären.

Gruss DunkleAura

Warum so umständlich, + - reicht doch und warum soll man bei jeder Berechnung erst die Zahl aus Wert und Charfeld zusammen setzten hierbei sehe ich keine Vorteile nur Performensnachteile.

KDB

 

[DunkleAura]

Warum so umständlich, + - reicht doch und warum soll man bei jeder Berechnung erst die Zahl aus Wert und Charfeld zusammen setzten hierbei sehe ich keine Vorteile nur Performensnachteile.

Stimmt, überredet. Fall klar.
Danke.
Und da ich mit den "komischen" wahrscheinlich sowieso nicht in Berührung komme, ist es sowie überflüssig eigentlich nur halte ich mir gerne alle Optionen offen.

Gruss DunkleAura