AW: opengeodb Nachrichtensammlung, Band 27, Eintrag 7

Hallo zusammen,

do what you want with the formulas! Um ein Gefühl dafür zu bekommen, was
unter der Haube vor sich geht, sind sie vielleicht ganz nützlich. Ansonsten
würde ich sie an eurer Stelle ganz schnell wieder vergessen (man braucht sie
heutzutage wirklich nicht mehr). Oder wollt ihr ein halbes Jahr
rumprogrammieren, um dann festzustellen, dass ihr es besser und einfacher
mit vorhandenen open-source-Tools/Bibliotheken (viele davon von Frank
Warmerdam) hättet haben können? Abgesehen von java (hier wird eine eigene
Schiene verfolgt), c/c++, delphi... gibt es mittlerweile auch bindings für
alle gängigen interpretierenden Sprachen. Im Fall von php seht euch z. B.
an, was man alles mit den Extensions php_proj4 und php_ogr anstellen kann:
Beispielsweise Umwandlung mit gleichzeitiger Transformation (nahezu
beliebiger Koordinatensysteme) von in einer csv-Datei oder in einer
odbc-Datenquelle gespeicherten x,y-Punktkoordinaten nach postgis, oracle,
esri shapes oder GML. Mit der utility ogr2ogr.exe (ist u. a. ein Bestandteil
der sehr empfehlenswerten, freien fwtools) oder cs2cs.exe geht das Ganze
auch ohne Progammieren.

Um Geokoordinaten umzurechnen, habe ich ansonsten beste Erfahrungen mit der
transform()-Funktion von postgis gemacht (meist werden die Ausgangs- und
Ergebnisdaten ja eh in eine rdbms geschrieben). Mit postgis hatte/habe ich
auch die schnellste Lern- und Erfolgskurve. Die nötigen sql-Anweisungen
können natürlich auch aus einem Programm (wie php) heraus abgesetzt werden.
Dies gilt auch für Entfernungsberechnungen mit distance(). Seit Version 4.1
hat mysql auch eine spatiale Erweiterung (distance und transform sind bisher
aber wohl noch nicht implementiert). Auf jeden Fall wird es dringend Zeit,
dass ihr eine "Koordinaten"-Spalte vom Datentyp Geometry (im Format wkb/wkt)
in die opengeodb einfügt (wird auch durch mysql ab 4.1 untersützt), den nur
auf dem Datentyp Geometry lassen sich solche Berechnungen direkt
durchführen. Dabei ist es überhaupt kein Problem Punktkoordinaten aus einer
lat und einer lon-Spalte in eine Spalte vom Datentyp geometry zu überführen
bzw. diese von dort wieder herauszuholen. Für Multipoints, (Multi-)Linien
und (Multi-)Polygone ist der Datentyp geometry eh Voraussetzung.

Was Eure Fragen bezüglich "geographischen Koordinaten", UTM usw. betrifft:
wikipedia beantwortet sie ausgezeichnet. Startpunkt z. B.
http://de.wikipedia.org/wiki/Geographische_Koordinaten

Mit der Verwendung von geographischen Koordinaten im eigentlichen Sinn (also
latlon) bezogen auf den (weltweit gültigen) WGS84-Ellipsoid liegt ihr
GOLDRICHTIG (BLEIBT DABEI)!! WGS84 ist (zumindest für Zwecke der opengeodb)
praktisch identisch mit dem GRS80-Ellipsoid des europäischen ETRS89-Systems,
vgl. z. B. http://de.wikipedia.org/wiki/Referenzellipsoid.

Gerade ältere latlon-Angaben aus "ehemaliger" BRD beziehen sich aber häufig
(und meist ohne das es dabeisteht) auf den Bessel-Ellipsoid (ehemalige DDR:
Krassowski-Ellipsoid). Die Abweichungen, die sich daraus ergeben, dass ein
falscher Ellipsoid angenommen wird, können ein paar hundert Meter betragen
z. B. sind die Koordinaten-Unterschiede Bessel und ETRS89 bei Hannover:
Rechts: ca -70, Hoch: ca. +440 m. Ich möchte wetten, dass in die opengeodb
latlon-Angaben übernommen wurden, die als WGS84 laufen, sich in Wirklichkeit
aber auf Bessel beziehen (wenn sie z. B. unverändert aus Software der Firma
killet entnommen wurden).

Weiteres Beispiel (bzw. Masterfrage): Auf welchen Ellipsoid beziehen sich
die latlon-Koordinaten des "digital chart of the world" (DCW), das wenn ich
mich nicht täusche z. B. als Grundlage für eure Deutschland-Übersichtskarte
Verwendung fand. Antwort: CLARKE 1866. Weil entsprechende Angaben bei den
heruntergeladenen Daten fehlten, hatte ich jahrelang WGS84 angenommen und
mich immer gewundert, warum z. B. der Verlauf der Autobahnen so stark von
dem aus anderem Kartenquellen abwich (ein weiterer Grund ist natürlich der
große Maßstab der Vorlagen des DCW).

WICHTIGES FAZIT: Um sicherzugehen, dass latlon-Koordinaten wirklich genau
sind, muss man den verwendeten Ellipsoid kennen (bzw. durch Ausprobieren in
Erfahrung bringen)!

Ein weitaus komplexeres (und mit jede Menge Fallstricken behaftetes) Thema
sind Koordinatenangaben, die sich auf bestimmte (oft landesspezifische)
Projektionen beziehen. SOLANGE MAN ALLE PARAMETER (Ellipsoid, Projektion,
Zone, Meridiane, false easting etc. etc. etc.) kennt, ist es mit den
heutigen (open-source) gis-Programmen/Tools prinzipiell kein Problem, diese
ineinander und nach latlon (auch auf einen anderen Ellipsoid) umzurechnen
(Stichwort EPSG-Codes). Bei "nackten" Koordinatenangaben hilft aber oft nur
Tüffteln und eine gewisse Erfahrung bis man diese Parameter richtig
zusammengetragen hat. Wenn euch einige der obengenannten Begriffe bisher
nicht viel sagen und ihr auch mit UTM-Projektion im WGS84-Ellipsoid bezogen
auf die Zone 32 wenig anfangen könnt oder wenn ihr nicht wisst, dass
Gauß-Krüger-Koordinaten (Bessel, Datum Potsdam, DHDN) bezogen auf den
dritten Streifen auf einer Transverse Mercator Projektion beruhen, die u. a.
durch einen bestimten Zentralmeridian gekennzeichnet ist, möchte ich
dringendst davor abraten, dass ihr eine NICHT spatial-erweiterte-rdbms (wie
sie opengeodb momentan darstellt) auch mit projektierten Koordinaten
füttert.

Deshalb würde ich in einer online-Eingabe-Maske auch lediglich die Eingabe
von latlons (wgs84) zulassen. Für Leute, die Koordinaten per gps oder mit
digitalen Daten auf PC ermitteln (dies dürfte die Mehrzahl sein), stellt
dies kein Problem dar. Bei Leuten, die projektierte Koordinaten von auf
Papier vorliegendem (historischem) Kartenmaterial ablesen, dürfte es sich in
der Regel um "Profis" handeln, die tendenziell große Datenmengen sammeln und
für die eine anschließende Umrechnung nach latlon in der Regel auch kein
Problem darstellt. Bleibt nur noch der Fall, dass man größere Mengen
projektierter Koordinatenangaben aufgetan/bekommen hat und nicht weiß, worum
es sich dabei genau handelt bzw. wie man sie nach latlon (wgs84) bekommt. In
solchen Fällen kann ich ja mal unterstützend auf die Daten sehen.

Zur Kartendarstellung sind latlon-Koordinaten natürlich in eine Projektion
zu bringen. Dies ist völlig unproblematisch. Weil es den größeren Teil
abdeckt, verwende ich für Deutschland persönlich bevorzugt "utm Zone32" bzw.
"gkk 3. Streifen", Brandenburger oder Sachsen werden hingegen vielleicht
eher auf "utm33" bzw "gkk4"-Koordinaten stehen (tatsächlich hat sich
Brandenburg zumindest im webgis-Bereich ein ganz eigenes Projektionssystem
zurechtgebastelt).

So, zu den Formeln habe ich nur dre Sätze verloren :)

Tschüß

Andreas



-----Ursprüngliche Nachricht-----
Von: opengeodb-bounces-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx 
[mailto:opengeodb-bounces-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx]Im
Auftrag von opengeodb-request-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx
Gesendet: Donnerstag, 13. Oktober 2005 12:00
An: opengeodb-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx
Betreff: opengeodb Nachrichtensammlung, Band 27, Eintrag 7


Um e-Mails an die Liste opengeodb zu schicken, nutzen Sie bitte die
Adresse

        opengeodb-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx

Um sich via Web von der Liste zu entfernen oder draufzusetzen:

        http://lists.phpbar.de/mailman/listinfo/opengeodb

oder, via Email, schicken Sie eine Email mit dem Wort 'help' in
Subject/Betreff oder im Text an

        opengeodb-request-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx

Sie koennen den Listenverwalter dieser Lister unter der Adresse

        opengeodb-owner-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx

erreichen

Wenn Sie antworten, bitte editieren Sie die Subject/Betreff auf einen
sinnvollen Inhalt der spezifischer ist als "Re: Contents of opengeodb
digest..."

-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)