[OT] Alternatives, "einfacheres" Koordinatensystem?

Hallo NGs!

In einer MySQL-Datenbank möchte ich gerne Geo-Koordinaten speichern -
dummerweise hat das "Standardformat" von solchen Koordinaten
("50°10'20'' N, 10°30'40'' O") den Nachteil, daß es nur äußerst
"sperrig" in Datenbankfelder paßt. Ähnliches gilt für die
"Fließkommadarstellung" "50,17222° N, 10,51111° O", weil man auch hier
zusätzlich zu den beiden Zahlenwerten noch zwei Felder für die
Unterscheidung N/S bzw. W/O braucht.
Das muß doch auch effizienter gehen. :-)

OK, ich könnte "eigenmächtig" einfach negative Gradangaben z.B. für S
und W bzw. positive Werte für N und O definieren - aber vielleicht gibt
es ja bereits "offizielle" Systeme für sowas.
Es gibt ja schließlich auch keinen Grund, mutwillig potentielle
Inkompatibilitäten einzubauen. :-)

Lange Rede, kurzer Sinn: wie würdet Ihr Geo-Koordinaten in einer
MySQL-DB speichern?


TIA,

Sebastian

PS: Wegen Foreign-Key-Constraints in der DB kommt nur InnoDB als
Storage-Engine in Frage.

PPS: XP dcdm & datg, f'up2 dcdm

Re: [OT] Alternatives, "einfacheres" Koordinatensystem?

Sebastian Suchanek schrieb:
> Hallo NGs!
>
> In einer MySQL-Datenbank möchte ich gerne Geo-Koordinaten speichern -
> dummerweise hat das "Standardformat" von solchen Koordinaten
> ("50°10'20'' N, 10°30'40'' O") den Nachteil, daß es nur äußerst
> "sperrig" in Datenbankfelder paßt. Ähnliches gilt für die
> "Fließkommadarstellung" "50,17222° N, 10,51111° O", weil man auch hier
> zusätzlich zu den beiden Zahlenwerten noch zwei Felder für die
> Unterscheidung N/S bzw. W/O braucht.
> Das muß doch auch effizienter gehen. :-)
>

Gauss-Krüger.
UTM.

Re: [OT] Alternatives, "einfacheres" Koordinatensystem?

Christian Kirsch schrieb:
> Sebastian Suchanek schrieb:
>>
>> In einer MySQL-Datenbank möchte ich gerne Geo-Koordinaten speichern -
>> dummerweise hat das "Standardformat" von solchen Koordinaten
>> ("50°10'20'' N, 10°30'40'' O") den Nachteil, daß es nur äußerst
>> "sperrig" in Datenbankfelder paßt. Ähnliches gilt für die
>> "Fließkommadarstellung" "50,17222° N, 10,51111° O", weil man auch hier
>> zusätzlich zu den beiden Zahlenwerten noch zwei Felder für die
>> Unterscheidung N/S bzw. W/O braucht.
>> Das muß doch auch effizienter gehen. :-)
>
> Gauss-Krüger.
> UTM.

Wenn ich die Wikipedia-Einträge dazu richtig verstanden habe, benötige
ich für diese beiden Systeme immer noch jeweils drei DB-Felder:
Meridianstreifen/X/Y bei Gauß-Krüger und Zone/Rechtswert/Hochwert bei
UTM - zuzüglich zu vermutlich aufwendigen Umrechungsoperationen vom o.g.
Standardformat in die beiden anderen Formate und zurück.


Tschüs,

Sebastian

Re: [OT] Alternatives, "einfacheres" Koordinatensystem?

Sebastian Suchanek schrieb:

> In einer MySQL-Datenbank möchte ich gerne Geo-Koordinaten speichern -
> dummerweise hat das "Standardformat" von solchen Koordinaten
> ("50°10'20'' N, 10°30'40'' O") den Nachteil, daß es nur äußerst
> "sperrig" in Datenbankfelder paßt.

Naja, entweder als String (zB "N50°10.234 E007°30.123"), oder
als 2 Dezimalzahlen -180.00000 bis 180.00000

Grüße,
Christian

Re: [OT] Alternatives, "einfacheres" Koordinatensystem?

Sebastian Suchanek schrieb:
> Hallo NGs!
>
> OK, ich könnte "eigenmächtig" einfach negative Gradangaben z.B. für S
> und W bzw. positive Werte für N und O definieren - aber vielleicht gibt
> es ja bereits "offizielle" Systeme für sowas.
> Es gibt ja schließlich auch keinen Grund, mutwillig potentielle
> Inkompatibilitäten einzubauen. :-)
>
> Lange Rede, kurzer Sinn: wie würdet Ihr Geo-Koordinaten in einer
> MySQL-DB speichern?

Genau so würde ich es auch machen.

Ich denke das ist die beste Lösung und sie ist mir auch schon des
öfteren über den Weg gelaufen.

-Sven-

Re: [OT] Alternatives, "einfacheres" Koordinatensystem?

Christian Steins wrote:
> Naja, entweder als String (zB "N50°10.234 E007°30.123"), oder
> als 2 Dezimalzahlen -180.00000 bis 180.00000

Zeigst Du mir dann bitte mal den 150. Breitengrad auf einer Karte?!

Re: [OT] Alternatives, "einfacheres" Koordinatensystem?

Sebastian Suchanek wrote:

>> Gauss-Krüger.
>> UTM.
>
> Wenn ich die Wikipedia-Einträge dazu richtig verstanden habe, benötige
> ich für diese beiden Systeme immer noch jeweils drei DB-Felder:
> Meridianstreifen/X/Y bei Gauß-Krüger und Zone/Rechtswert/Hochwert bei
> UTM - zuzüglich zu vermutlich aufwendigen Umrechungsoperationen vom
> o.g. Standardformat in die beiden anderen Formate und zurück.

Vorteil von UTM ist doch, dass die MySQL-DB das direkt verwursten kann -
sprich du Polygone suchen, Flächen berechnen und einen SPATIAL-Index auf das
Feld legen kannst.

Du brauchst meines Wissen nur ein einziges Feld, indem du die Koordinate als
Punkt speicherst.

http://dev.mysql.com/tech-resources/articles/4.1/gis-with-my sql.html

Die "komplizierte" mathematische Umrechnung zwischen WGS84 und UTM kannst du
ergoogeln und nach Schema-F umsetzen.

Grüße
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Re: [OT] Alternatives, "einfacheres" Koordinatensystem?

Sebastian Suchanek schrieb:
> Christian Kirsch schrieb:
>> Sebastian Suchanek schrieb:
>>> In einer MySQL-Datenbank möchte ich gerne Geo-Koordinaten speichern -
>>> dummerweise hat das "Standardformat" von solchen Koordinaten
>>> ("50°10'20'' N, 10°30'40'' O") den Nachteil, daß es nur äußerst
>>> "sperrig" in Datenbankfelder paßt. Ähnliches gilt für die
>>> "Fließkommadarstellung" "50,17222° N, 10,51111° O", weil man auch hier
>>> zusätzlich zu den beiden Zahlenwerten noch zwei Felder für die
>>> Unterscheidung N/S bzw. W/O braucht.
>>> Das muß doch auch effizienter gehen. :-)
>> Gauss-Krüger.
>> UTM.
>
> Wenn ich die Wikipedia-Einträge dazu richtig verstanden habe, benötige
> ich für diese beiden Systeme immer noch jeweils drei DB-Felder:
> Meridianstreifen/X/Y bei Gauß-Krüger und Zone/Rechtswert/Hochwert bei
> UTM - zuzüglich zu vermutlich aufwendigen Umrechungsoperationen vom o.g.
> Standardformat in die beiden anderen Formate und zurück.

Ja, und was willst Du nun tun? Die Erde ist nun mal keine Kugel, also
musst Du, wenn die Ergebnisse denn benutzbar sein sollen, Dir ein paar
Mühen bei der Projektion aufladen. Oder eben in geographischen
Koordinaten rechnen. Ob das nun "effizient" ist oder nicht, könntest Du
ja erstmal ausprobieren. Alle relevanten Datenbanken haben heutzutage
eigene Geo-Datentypen (MySQL, PostgreSQL, Oracle, DB2 etc.) und die
passenden Funktionen dafür.

Re: [OT] Alternatives, "einfacheres" Koordinatensystem?

Sebastian Suchanek schrieb:

> OK, ich könnte "eigenmächtig" einfach negative Gradangaben z.B. für S
> und W bzw. positive Werte für N und O definieren - aber vielleicht gibt
> es ja bereits "offizielle" Systeme für sowas.

EPSG:4326 [1],[2] verwendet genau diese Vorzeichen: S und W sind negativ.

CU Christian
[1] http://en.wikipedia.org/wiki/EPSG:4326#EPSG:4326
[2] Streng genommen ist das Koordinatensystem EPSG:6422.
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA

Grundlagen Geo-Funktionen (was: [OT] Alternatives, "einfacheres" Koordinatensystem?)

Thus spoke Christian Zietz:
> Sebastian Suchanek schrieb:
>
>> OK, ich könnte "eigenmächtig" einfach negative Gradangaben
>> z.B. für S und W bzw. positive Werte für N und O
>> definieren - aber vielleicht gibt es ja bereits
>> "offizielle" Systeme für sowas.
>
> EPSG:4326 [1],[2] verwendet genau diese Vorzeichen: S und W
> sind negativ.
> [...]

Danke für den Hinweis, das klingt schon mal sehr
vielversprechend: Direkte Nutzung der Spatial-Funktionen von
MySQL und gleichzeitig triviale Umrechnung von und in
"normale" Koordinaten (das ist doch das, was hier mit "WGS84"
bezeichnet wurde, oder?).
Allerdings habe ich da noch einige Schwierigkeiten bei der
Umsetzung.

Ich habe mir erstmal eine Testdatenbank erstellt

CREATE TABLE geo (
id tinyint(3) unsigned NOT NULL auto_increment,
name varchar(50) default NULL,
coord point default NULL,
PRIMARY KEY (id)
)

und zwei Datensätze eingeworfen:

INSERT INTO geo (name, coord) VALUES ('Landungsbrücken', GeomFromText('POINT(53.54581 9.96659)', 6422))
INSERT INTO geo (name, coord) VALUES ('Marienplatz', GeomFromText('POINT(48.13724 11.57562)', 6422))

(Die Koordinaten habe ich aus Google-Earth entnommen - die
Landungsbrücken in Hamburg und der Marienplatz in München.)

Wenn ich jetzt die Distanz zwischen diesen beiden Punkten
berechnen lassen möchte, erhalte ich folgendes (die Methode
der Distanzberechnung habe ich dem Link in Johannes' Posting
entnommen):

SELECT a.name, b.name, GLength(LineStringFromWKB(LineString(AsBinary(a.coord), AsBinary(b.coord)))) AS distance FROM geo a, geo b

Ergebnis:

+-----------------+-----------------+------------------+
| name | name | distance |
+-----------------+-----------------+------------------+
| Landungsbrücken | Landungsbrücken | 0 |
| Marienplatz | Landungsbrücken | 5.6428367853235 |
| Landungsbrücken | Marienplatz | 5.6428367853235 |
| Marienplatz | Marienplatz | 0 |
+-----------------+-----------------+------------------+

Man könnte jetzt vermuten, daß das die Entfernung in 100km
sind - laut Google-Earth sind es aber ca. 611km. Für zwei
weitere Punkte in meiner näheren Umgebung spuckt Google-Earth
ca. 13km aus, MySQL dagegen 17km.

Auch wenn ich die Koordinaten mit SRID 4326 statt 6422
eintrage, ändert sich nichts.

Kann jemand diese Diskrepanzen erklären, bzw. mir erklären,
was ich falsch gemacht habe?


Tschüs,

Sebastian

--
http://www.baumaschinen-modelle.net
http://www.schwerlast-rhein-main.de

Re: Grundlagen Geo-Funktionen

Sebastian Suchanek schrieb:

> Ich habe mir erstmal eine Testdatenbank erstellt
>
> CREATE TABLE geo (
> id tinyint(3) unsigned NOT NULL auto_increment,
> name varchar(50) default NULL,
> coord point default NULL,
> PRIMARY KEY (id)
> )
>
> und zwei Datensätze eingeworfen:
>
> INSERT INTO geo (name, coord) VALUES ('Landungsbrücken', GeomFromText('POINT(53.54581 9.96659)', 6422))
> INSERT INTO geo (name, coord) VALUES ('Marienplatz', GeomFromText('POINT(48.13724 11.57562)', 6422))
>

Das sind geographische Koordinaten, gell? Also quasi Grad und in
Dezimalteile von Grad umgerechnete Minuten + Sekunden.

> (Die Koordinaten habe ich aus Google-Earth entnommen - die
> Landungsbrücken in Hamburg und der Marienplatz in München.)
>
> Wenn ich jetzt die Distanz zwischen diesen beiden Punkten
> berechnen lassen möchte, erhalte ich folgendes (die Methode
> der Distanzberechnung habe ich dem Link in Johannes' Posting
> entnommen):
>
> SELECT a.name, b.name, GLength(LineStringFromWKB(LineString(AsBinary(a.coord), AsBinary(b.coord)))) AS distance FROM geo a, geo b
>
> Ergebnis:
>
> +-----------------+-----------------+------------------+
> | name | name | distance |
> +-----------------+-----------------+------------------+
> | Landungsbrücken | Landungsbrücken | 0 |
> | Marienplatz | Landungsbrücken | 5.6428367853235 |
> | Landungsbrücken | Marienplatz | 5.6428367853235 |
> | Marienplatz | Marienplatz | 0 |
> +-----------------+-----------------+------------------+
>
> Man könnte jetzt vermuten, daß das die Entfernung in 100km

Könnte man. Man könnte auch irgendwas anderes vermuten, z.B. dass es
sich um Millierg pro Kilonewton handelt oder um die Schuhgröße von,
sagen wir mal, Ole von Beust, geteilt durch das Gewicht von Herrn Uhde.
Oder sonstwas.

> sind - laut Google-Earth sind es aber ca. 611km. Für zwei
> weitere Punkte in meiner näheren Umgebung spuckt Google-Earth
> ca. 13km aus, MySQL dagegen 17km.
>

Du könntest jetzt einen Taschenrechner Deiner Wahl nehmen (wie ich es
gemacht habe) und mal spaßeshalber den euklidischen Abstand von A und B
ausrechnen. Das ist *exakt* das, was MySQL dir hier zeigt.

Vermutlich wirfst Du geographische Koordinaten rein, MySQL hätte aber
gerne UTM oder Gauss-Krüger oder eben irgendwas anderes rechtwinkliges
(verständlicherweise).


Ich nehme das "vermutlich" zurück. Ein Blick in die Dokumentation
schafft (wie so oft) Klarheit:
http://dev.mysql.com/doc/refman/5.1/en/gis-class-geometry.ht ml

Aber wozu lesen, wenn man fragen kann ...

> Auch wenn ich die Koordinaten mit SRID 4326 statt 6422
> eintrage, ändert sich nichts.
>
> Kann jemand diese Diskrepanzen erklären, bzw. mir erklären,
> was ich falsch gemacht habe?

s.o. Es handelt sich um ein GiGo-Phänomen: Garbage in, Garbage out. Und
Du verschwendest Deine (und anderer Leute) Zeit mit diesem Spielkram.
Nimm UTM/Gauss-Krüger oder irgendwas anderes rechtwinkliges. Oder nimm
eine Datenbank, die besser mit Geodaten zurechtkommt als MySQL. Oder
gleich ein GIS.

Re: Grundlagen Geo-Funktionen (was: [OT] Alternatives, "einfacheres" Koordinatensystem?)

Sebastian Suchanek wrote:

> Ich habe mir erstmal eine Testdatenbank erstellt
>
> CREATE TABLE geo (
> id tinyint(3) unsigned NOT NULL auto_increment,
> name varchar(50) default NULL,
> coord point default NULL,
> PRIMARY KEY (id)
> )
>
> und zwei Datensätze eingeworfen:
>
> INSERT INTO geo (name, coord) VALUES ('Landungsbrücken',
> GeomFromText('POINT(53.54581 9.96659)', 6422))
> INSERT INTO geo (name, coord) VALUES ('Marienplatz',
> GeomFromText('POINT(48.13724 11.57562)', 6422))
>
> (Die Koordinaten habe ich aus Google-Earth entnommen - die
> Landungsbrücken in Hamburg und der Marienplatz in München.)
>
> Wenn ich jetzt die Distanz zwischen diesen beiden Punkten
> berechnen lassen möchte, erhalte ich folgendes (die Methode
> der Distanzberechnung habe ich dem Link in Johannes' Posting
> entnommen):
>
> SELECT a.name, b.name,
> GLength(LineStringFromWKB(LineString(AsBinary(a.coord),
> AsBinary(b.coord)))) AS distance FROM geo a, geo b
>
> Ergebnis:
>
> +-----------------+-----------------+------------------+
>> name | name | distance |
> +-----------------+-----------------+------------------+
>> Landungsbrücken | Landungsbrücken | 0 |
>> Marienplatz | Landungsbrücken | 5.6428367853235 |
>> Landungsbrücken | Marienplatz | 5.6428367853235 |
>> Marienplatz | Marienplatz | 0 |
> +-----------------+-----------------+------------------+
>
> Man könnte jetzt vermuten, daß das die Entfernung in 100km
> sind - laut Google-Earth sind es aber ca. 611km. Für zwei
> weitere Punkte in meiner näheren Umgebung spuckt Google-Earth
> ca. 13km aus, MySQL dagegen 17km.

Das ist genau gar nichts.
Google Earth zeigt dir die Position auf einer "Kugel" - in Grad, Minuten und
Sekunden. MySQL kann aber nicht mit Kugeln rechnen, jedenfalls nicht intern.
Deshalb musst du Kugel-Koordinaten umrechnen auf rechtwinklige Koordinaten.
Du musst Dir das vorstellen, als ob jemand die Kugel an den Längengraden
aufschneidet und anschliessend das ganze Flach hinlegt (wie bei einer
geschälten Apfelsine). Dabei entstehen aber hässliche Lücken zwischen der
Nahtstelle (Äquator) und den oberen/unteren Enden die spitz zulaufen. "In
echt" wären da natürlich keine Lücken, deshalb musst du diese Stellen
"aufweiten", so dass du am Ende eine total verzogene Karte hast, die aber
auf rein rechtwinkligen Größen beruht - dies ist die Idee von UTM.

Jetzt könntest Du tatsächlich so einfach wie oben Entfernungen berechnen.

an dieser Stelle ist es dann vielleicht doch wieder Schade, dass die Erde
keine Scheibe ist ;p

Grüße
Johannes

PS: Eine Formel zum umrechnen von Google-GeoDaten in UTM gibts hier
http://www.ottmarlabonde.de/L1/UTMBeispielRechnung.htm

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Re: Grundlagen Geo-Funktionen (was: [OT] Alternatives, "einfacheres" Koordinatensystem?)

Sebastian Suchanek wrote:

> INSERT INTO geo (name, coord) VALUES ('Landungsbrücken',
> GeomFromText('POINT(53.54581 9.96659)', 6422))
> INSERT INTO geo (name, coord) VALUES ('Marienplatz',
> GeomFromText('POINT(48.13724 11.57562)', 6422))
>
> (Die Koordinaten habe ich aus Google-Earth entnommen - die
> Landungsbrücken in Hamburg und der Marienplatz in München.)
>
> Wenn ich jetzt die Distanz zwischen diesen beiden Punkten
> berechnen lassen möchte, erhalte ich folgendes (die Methode
> der Distanzberechnung habe ich dem Link in Johannes' Posting
> entnommen):
>
> SELECT a.name, b.name,
> GLength(LineStringFromWKB(LineString(AsBinary(a.coord),
> AsBinary(b.coord)))) AS distance FROM geo a, geo b
>
> Ergebnis:
>
> +-----------------+-----------------+------------------+
>> name | name | distance |
> +-----------------+-----------------+------------------+
>> Landungsbrücken | Landungsbrücken | 0 |
>> Marienplatz | Landungsbrücken | 5.6428367853235 |
>> Landungsbrücken | Marienplatz | 5.6428367853235 |
>> Marienplatz | Marienplatz | 0 |
> +-----------------+-----------------+------------------+
>
> Man könnte jetzt vermuten, daß das die Entfernung in 100km
> sind - laut Google-Earth sind es aber ca. 611km. Für zwei
> weitere Punkte in meiner näheren Umgebung spuckt Google-Earth
> ca. 13km aus, MySQL dagegen 17km.
>
> Auch wenn ich die Koordinaten mit SRID 4326 statt 6422
> eintrage, ändert sich nichts.
>
> Kann jemand diese Diskrepanzen erklären, bzw. mir erklären,
> was ich falsch gemacht habe?

Du kannst mit Grad und Minuten nicht rechnen wie im Dezimalsystem (sprich du
kannst auf einer Kugel(die Erde ist ja nichtmal eine Kugel) nicht einfach
eine Linie zwischen zwei Punkten ziehen, da diese Linie ebenfalls gebogen
wäre, sofern du auf der Schale der Kugel wanderst).
Du musst erst die Kugelkoordinaten auf eine 2D Karte abbilden um dann damit
einfache Berechnungen durchführen zu können.

Wies geht? Hier ein Rechenbeispiel:
http://www.ottmarlabonde.de/L1/UTMBeispielRechnung.htm

So gehts:
Google-GIS-Daten in UTM umrechnen und als Punkt in der DB speichern, ebenso
musst du natürlich die originalen Google-Daten speichern (da die nicht zum
suchen benutzt werden ist das "wie" völlig schnuppe), da du sie sonst nicht
auf einer Google-Maps-Karte abbilden kannst. Anschliessend rechnest du bei
einer Suche in den Daten jweils Google-Punkte in UTM um und suchst dann in
deinem Datensatz.

Grüße
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Re: Grundlagen Geo-Funktionen

Thus spoke Christian Kirsch:
> Sebastian Suchanek schrieb:
>
>> [...]
> Ich nehme das "vermutlich" zurück. Ein Blick in die
> Dokumentation schafft (wie so oft) Klarheit:
> http://dev.mysql.com/doc/refman/5.1/en/gis-class-geometry.ht ml
> [...]

Jetzt habe ich drei Anläufe gebraucht, bis ich den
entscheidenden Satz "All calculations are done assuming
Euclidean (planar) geometry." gefunden habe. :-(
Das wirft aber auch gleich ein weiteres Verständnisproblem
auf: Bedeutet das, daß die Entfernungsberechnung in MySQL
komplett in die Hose geht, wenn es in die Größenordnung
"halbe Erdkugel" geht? Oder wird das durch die
Koordinatentransformation ausgeglichen?

>> Auch wenn ich die Koordinaten mit SRID 4326 statt 6422
>> eintrage, ändert sich nichts.
>>
>> Kann jemand diese Diskrepanzen erklären, bzw. mir
>> erklären, was ich falsch gemacht habe?
>
> s.o. Es handelt sich um ein GiGo-Phänomen: Garbage in,
> Garbage out. Und Du verschwendest Deine (und anderer Leute)
> Zeit mit diesem Spielkram.

Meine Zeit betrachte ich erst dann als verschwendet, wenn man
Ende *nicht* das Verständnis der Materie und eine funktionierende
Lösung stehen.

> Nimm UTM/Gauss-Krüger oder irgendwas anderes rechtwinkliges.

Was mir auch nach stundenlangem Googlen noch nicht (ganz)
klar ist:

1. Sowohl UTM als auch GK arbeiten mit diskreten Zonen als
"Grobeinteilungen" plus zwei Koordinaten - die
WKT-POINT-Angaben haben aber nur zwei Koordinaten. Heißt das,
ich muß mir eine (beliebige) Zone schnappen und Koordinaten
bezüglich dieser Zone transformieren, auch wenn dabei
eigentlich "ungültige" Koordinaten 'rauskommen?

2. Falls die o.g. Zonen doch erhalten bleiben (müssen): Muß
ich verschiedene UTM-/GK-Zonen in verschiedene SRID-Werte
umsetzen?
Den Satz in o.g. Link "In MySQL, the SRID value is just an
integer associated with the geometry value" interpretiere ich
so, daß ich das gar nicht darf, weil MySQL eh nichts damit
anfangen kann.

3. Falls doch - wie geht's? (Also SRID zur jeweiligen Zone
bestimmen.)


Tschüs,

Sebastian

--
http://www.baumaschinen-modelle.net
http://www.schwerlast-rhein-main.de

Re: Grundlagen Geo-Funktionen

Thus spoke Johannes Mueller:
> Sebastian Suchanek wrote:
>
>> [...]
>> Kann jemand diese Diskrepanzen erklären, bzw. mir
>> erklären, was ich falsch gemacht habe?
>
> Du kannst mit Grad und Minuten nicht rechnen wie im
> Dezimalsystem (sprich du kannst auf einer Kugel(die Erde
> ist ja nichtmal eine Kugel) nicht einfach eine Linie
> zwischen zwei Punkten ziehen, da diese Linie ebenfalls
> gebogen wäre, sofern du auf der Schale der Kugel wanderst).

Doch, *ich* kann (vor >10 Jahren gab's mal sphärische
Trigonometrie in der Schule...) :-)
Mir war nur bis gerade eben nicht klar, daß MySQL anscheinend zu
doof dafür ist und ausschließlich Projektionskoordinaten haben
möchte.

> Du musst erst die Kugelkoordinaten auf eine 2D Karte
> abbilden um dann damit einfache Berechnungen durchführen zu
> können.
>
> Wies geht? Hier ein Rechenbeispiel:
> http://www.ottmarlabonde.de/L1/UTMBeispielRechnung.htm
> [...]

Was mir an dieser Rechnung noch nicht so ganz klar ist: Werden
dabei auch die "Nichtlinearitäten"[1] in den UTM-Zonenfeldern
berücksichtigt? Oder ist das nicht relevant, wenn mit ganzen
Zonen hantiert wird?
(So wie ich die Wikipedia verstanden habe, kann man Koordinaten
mindestens mit Nord-/Süd-Zone und Zonenfeldern angeben.)


Tschüs,

Sebastian

_____
Anmerkungen:
[1] Zum Beispiel die verschobene Grenze zwischen 31V und 32V

--
http://www.baumaschinen-modelle.net
http://www.schwerlast-rhein-main.de

Re: Grundlagen Geo-Funktionen

Sebastian Suchanek wrote:

>> Du musst erst die Kugelkoordinaten auf eine 2D Karte
>> abbilden um dann damit einfache Berechnungen durchführen zu
>> können.
>>
>> Wies geht? Hier ein Rechenbeispiel:
>> http://www.ottmarlabonde.de/L1/UTMBeispielRechnung.htm
>> [...]
>
> Was mir an dieser Rechnung noch nicht so ganz klar ist: Werden
> dabei auch die "Nichtlinearitäten"[1] in den UTM-Zonenfeldern
> berücksichtigt? Oder ist das nicht relevant, wenn mit ganzen
> Zonen hantiert wird?
> (So wie ich die Wikipedia verstanden habe, kann man Koordinaten
> mindestens mit Nord-/Süd-Zone und Zonenfeldern angeben.)

Okay, dazu kann ich Dir jetzt auch nichts genaueres sagen, denn das
übersteigt jetzt meinen Horizont. Diese Zonenfelder - so ist mein Eindruck
(ACHTUNG, ab hier spekuliere ich nur) - werden benötigt um in den
nachfolgenden Rechnungen die Krümmung der Erde zu korrigieren. An
unterschiedlichen Stellen ist die Erde unterschiedlich gekrümmt und das soll
wohl durch diese Zonen zum Ausdruck kommen.

Wenn Du willst kann ich Dir eine 1zu1-Quick-And-Dirty-PHP-Umsetzung von
http://lists.phpbar.de/pipermail/opengeodb/2005-October/0024 93.html (das ist
in VB) schicken - schreib einfach eine Email, aber meine Signatur beachten.

Meine Tests haben ergeben, dass das zumindest für ausgewählte deutsche Orte
stimmen müsste. Allerdings kann ich das nur für UTM sagen, Gauss-Krüger habe
ich nicht getestet.

Grüße
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Re: [OT] Alternatives, "einfacheres" Koordinatensystem?

"Sebastian Suchanek" schreef in bericht
news:fkuk84$3po$1@suchanek.de...
> Hallo NGs!
>
> In einer MySQL-Datenbank möchte ich gerne Geo-Koordinaten speichern -
> dummerweise hat das "Standardformat" von solchen Koordinaten
> ("50°10'20'' N, 10°30'40'' O") den Nachteil, daß es nur äußerst
> "sperrig" in Datenbankfelder paßt. Ähnliches gilt für die
> "Fließkommadarstellung" "50,17222° N, 10,51111° O", weil man auch hier
> zusätzlich zu den beiden Zahlenwerten noch zwei Felder für die
> Unterscheidung N/S bzw. W/O braucht.
> Das muß doch auch effizienter gehen. :-)
>
> OK, ich könnte "eigenmächtig" einfach negative Gradangaben z.B. für S
> und W bzw. positive Werte für N und O definieren - aber vielleicht gibt
> es ja bereits "offizielle" Systeme für sowas.
> Es gibt ja schließlich auch keinen Grund, mutwillig potentielle
> Inkompatibilitäten einzubauen. :-)
>
> Lange Rede, kurzer Sinn: wie würdet Ihr Geo-Koordinaten in einer
> MySQL-DB speichern?
>

My German is not good enough to give the answer in German, but I'll try to
give an answer in English.

How to store data. Size offcourse is of importance but not the only
importance, size of an individual coordinate is of importance, but the size
of the total set is of importance as well. Second point is converting the
coordinates is not free, so we should avoid unneccesary conversions.

60 degrees, 60 minutes, 60 seconds.
GG.ggggg
GG.MM.mmm
GG.MM.SSs

All three formats use 7 digits for displaying. The last digit in each is :
10000 km / 90 /100000 = 1.111 meter
10000 km /90 / 60/1000 = 1.8585 meter
10000 km /90 / 60 /60 /10 = 3.086419 meter

The above is for N/S coordinates. (For E/W coordinates the distance is twice
on the equator, going to zero on the poles).
So with the same number of digit's we can store more information using
degrees only. There are GPS receivers which do display 7 digits in all three
formats. 7 decimal digits that is just under 24 bits of information. This is
nice because 24 bits is exactly 3 bytes. Introducing a sign or going
North/South and East/West we go over 24 bits. But say we use 1 bit for the
sign an 23 bits for the size. The minimum distance we can still express is
10000 km / (2^23) = 1.192 meter. (This is in the North/South direction).

On the equator this would become
20000 / (2^23) = 2.384

So with 48 bits (6 bytes) we could have a coordinate system which cover the
world and give the coordinate of any point of earth within 1.5 meters. (That
is on the equator and more accurate when we get removed from the equator.).

As said not only is size of the storage of large importance, so is the speed
of retrieval (and searching). To make 'local' searching faster the N/S
coordinate should become interwoven with the E/W coordinate. Suppose we have
the coordinastes as :

Nnnnnnnnnnnnnnnnnnnnnnnn (24 bits)
Eeeeeeeeeeeeeeeeeeeeeeee (24 bits)

The can be stored as
ENenenenenenenenenenenenenenenenenenenenenenenen

The bits of the N/S and E/W coordinates are used alternately in the storage.
The most imported bits from both are in the front, the least importand bit's
are in the 'rear' of the number.
If this is used as a key to search on in a database, it is resonable easy to
find near locations. For example you search everything within a km from a
certain location. For example on coordinates.

Nxxxxxxxxxxxxx xxxxxxxxxx
Eyyyyyyyyyyyyy yyyyyyyyyy

The last bit (N/E) is about 1.192 meters so for a km about 10 bits are
needed.
The last bit is about 2.384 meters (or less if not on the equator) so less
than 10 bits are needed.
Depending on the value of the point we are searching from the searching has
about to be done from
ENyxyxyxyxyxyxyxyxyxyxyxyxyx0 (Value 1)
To
ENyxyxyxyxyxyxyxyxyxyxyxyxyx1 (Value 2)

The value's of the first 28 bits is known and fixed. Everything with this
set of 28 bits is 'near' the actual location.

It is possible to more exactly determine the 'edges' of the search criteria.
Databases should be fast is finding all geocoordinates between the value 1
and value 2. The area searched is large than all point within one km from
the searching point, but a selection on the points can be made.
The search criteria above (value 1 and value 2) are not exact, and should be
determined a little bit different from the illustrated example above. But
the search is fairly optimal and fast.

It's easy to expand the system to a more precise system, just add more bits.
It's easy to also store less precise information, just use less bits. For
GPS systems 2 times 24 bits is pretty much optimal. If this can not be
stored as one field (48 bits), it can be split into a 32 bit field plus a 16
bit field or in two 32 bit fields.

Conversion can be done just before the values are displayed and imediatly
after they are entered. Searching and indexing can be done with the storage
format. For calculations the number ENenenen... has to be split into
Nnnnnn... and Eeeee...., which is fairly
simple for even smal CPU's. (Conversion can by done by byte, for byte sized
CPU's or by word for larger CPU's, if done by byte only a few cycles are
needed to do the conversion).

The advantages of the above system are
- Small storage size for coordinates.
- Coordinates can easely be made more preciese.
- Coordinates can easely be made less preciese.
- Searching can be done 'localy' easily and fast.
- The storage is scale independen, searching for near locations can with
meters, kilometers, miles or hundreds of kilometers. (One has to do a little
precalculation to determine the two searchlimits). After the search a more
detailed selection has to be done.
- Searching in area's with very little points (Sahara), can easely be
extended with a larger radius, because not many poits will be found.
- Segmenting of maps is not completely necessary, because everything is
stored near localy geocoordinates.
- If using disks local geocoordinates are stored locally together and this
aides diskaccess and caching.
- Finding routes, because it is all stored locally together it's easier to
go through the correct data.


(Assumed is that the storage in the database can be tuned to store values in
a 'sorted' way, all or most modern databases can do that, in SQL-server a
clustered index should be used on the coordinate. In Oracle the value should
be used for the storage organisation, I think this is called clustered
tables, allthough in this situation only one table is used, but the value
should be used to do the clustering. For My SQL I do not know what the most
suetable storage format is, but there must be an index mechanism to exploid
the above system).


Please inform me if the above was of any use to you.

(The alternation is not worked out into detail. Near the poles (South and
North) there are some anomalies and the system does not work very well. It
could be that the order of bits could be a bit more optimized. The searching
can be improved, because it is not a specific bit (the 29th) which is
changing but on has to add and substract a certain amount of the location
which is used as a search point. The searched area is not a circle but a
rectangle. The rectangle does not have the exact sizes of the search
criterium (instead of a circle with an R of 1 km a rectangle with larger
sides has to be searched. Maybe starting of with 2 EE bits is better.)

(If storage is done in Oracle, Oracle's numbers are not bit based, so here
the storage is not limited to a certain number of bits, but to a certain
number of 100 groups. (two digits are stored in one byte), this can be
exploited as wel).

Ben Brugman.


>
> TIA,
>
> Sebastian
>
> PS: Wegen Foreign-Key-Constraints in der DB kommt nur InnoDB als
> Storage-Engine in Frage.
>
> PPS: XP dcdm & datg, f'up2 dcdm

Re: Grundlagen Geo-Funktionen

Sebastian Suchanek schrieb:
> Thus spoke Christian Kirsch:
>
> [...]
> Das wirft aber auch gleich ein weiteres Verständnisproblem
> auf: Bedeutet das, daß die Entfernungsberechnung in MySQL
> komplett in die Hose geht, wenn es in die Größenordnung
> "halbe Erdkugel" geht? Oder wird das durch die
> Koordinatentransformation ausgeglichen?
>
> [...]
>> Nimm UTM/Gauss-Krüger oder irgendwas anderes rechtwinkliges.
>
> Was mir auch nach stundenlangem Googlen noch nicht (ganz)
> klar ist:
>
> 1. Sowohl UTM als auch GK arbeiten mit diskreten Zonen als
> "Grobeinteilungen" plus zwei Koordinaten - die
> WKT-POINT-Angaben haben aber nur zwei Koordinaten. Heißt das,
> ich muß mir eine (beliebige) Zone schnappen und Koordinaten
> bezüglich dieser Zone transformieren, auch wenn dabei
> eigentlich "ungültige" Koordinaten 'rauskommen?
>
> 2. Falls die o.g. Zonen doch erhalten bleiben (müssen): Muß
> ich verschiedene UTM-/GK-Zonen in verschiedene SRID-Werte
> umsetzen?
> Den Satz in o.g. Link "In MySQL, the SRID value is just an
> integer associated with the geometry value" interpretiere ich
> so, daß ich das gar nicht darf, weil MySQL eh nichts damit
> anfangen kann.
>
> 3. Falls doch - wie geht's? (Also SRID zur jeweiligen Zone
> bestimmen.)

Gibt's hier wirklich niemanden, der mir bei diesen Fragen weiterhelfen kann?


Tschüs,

Sebastian