Datumstrafo am PDA

@all

Ich hab wieder an dem Prog. gearbeitet. Es sollte jetzt um einiges genauer arbeiten als vorher. Desweiteren ist die Eingabe von Dezimalgrad, Dezimalminuten und Dezimalsekunden möglich. Fugawi-User kennen das Prinzip. Hab ich Koordinaten der Form dd.ddddd° so werden diese genau so in das Feld "Grad" eingetragen.
Hab ich Koordinaten der Form dd°mm,mmm' trägt man die Grad ins Feld "Grad" ein und die Minuten (inkls. Komma" ins Feld "Min" ein.
Koordinaten der Form dd°mm'ss,sss'' werden analog dazu eingetragen.

danti
Für den östl. Teil Österreichs sollte die Umrechnung nach GK M34 brauchbar funktionieren. Die Transformation hat mich heute ziemlich gestresst. Denn:

"Damit ergeben sich für die drei in Österreich verwendeten Meridianstreifen folgende Parameter: Zone Verwendung Längenursprung Skalenfaktor false easting [km] false northing [km]
M28 Vorarlberg, Tirol E10° 20' 1 150 -5000
M31 Osttirol, Kärnten, Salzburg,
Oberösterreich, Weststeiermark E13° 20' 1 450 -5000
M34 Niederösterreich, Wien, Burgenland E16° 20' 1 750 -5000 "

---war mir neu!!!!

-----------------------------------------------------------------------

Bevor ich weitermach würde ich mich um Feedback von eurer Seite freuen. Wie heißt es so schön? "Manchmal sieht man den Wald vor lauter Bäumen nicht"
Also sagt mir bescheid, was schief läuft oder ob es brauchbar für ist.

Danke und Gruß

Anderl

P.S Inzwischen ist der Code schon auf einen beträchtlichen Umfang angewachsen. Aus diesem Grund ist euer Feedback wichtig für mich, damit ich weiß, ob es sich lohnt weiter zu machen.

NavTransCE 1.0 gibts auf www.eNavTools.de.vu

Zitat

Original von Anderl
Also sagt mir bescheid, was schief läuft oder ob es brauchbar für ist.

habe mal eine Position bei mir in der Nähe 'beackert':

WGS84: 50° 50,966 / 7° 4,731
UTM: 32U 364763 / 5634839
(Daten aus Ozi)

ergibt nach Bearbeitung mit dem Trafo:
UTM: 364764 / 5634848 (Fettes stimmt nicht, der Ostwert ist Lappalie, aber der Nordwert!?)
Potsdam: 50° 51,041 / 7° 4,778 (scheint bis auf Abweichung von ~2m auf der letzten Stelle zu stimmen.)

EDIT: Hier noch ein anderes Beispiel, diesmal bis auf die letzte Ziffer.

Ozi:
WGS84: 50° 51,1094 / 7° 4,3531
UTM: 32U 5635117 / 364326

Potsdam: 50° 51,1862 / 7° 4,3971

Trafo:
UTM: 32U 5635125 / 364328
Potsdam: 50° 51,185 / 7° 4,400

Wastl

androx

So wie mir scheint hast Du bei der Eingabe Länge und Breite vertauscht. Siehe das Bild unten.

Wastl
Komischerweise habe ich weniger Problem mit den Datumsübergängen als mit der Berechnung der ebenen Koordinaten wie GK oder UTM.
Im Nordwert bei deinem Beispiel sind es aber auch "nur" 9m. Ich habe das für den Anfang mal als "noch tragbar" eingestuft.
Wenn ich die Koordinaten mit Fuwagi oder Transdat umrechne sinds sogar nur 8m Differenz.
Problem ist, dass ich mit einer Reihenentwicklung arbeite und der Author dieser Literatur anscheinend der Auffassung war, daß diese Genauigkeit ausreichend ist und deshalb die Reihe vorzeitig abricht.
Andere Frage, ist die Abweichung zu groß für Dich? Wenn ja, welche Toleranzen würdest Du noch dulden?

Gruß

Anderl

Zitat

Original von Anderl
Wastl
Im Nordwert bei deinem Beispiel sind es aber auch "nur" 9m. Ich habe das für den Anfang mal als "noch tragbar" eingestuft.
Andere Frage, ist die Abweichung zu groß für Dich? Wenn ja, welche Toleranzen würdest Du noch dulden?

OK, für den Anfang. Mein problem: Ich habe hier haufenweise Karten in Potsdam vorliegen, die ich aber vielleicht mal zum geocachen brauchen werde. Problem dabei ist: in OziCE kann man kein anderes als das vorhandene Datum einstellen. Also muß ich die beim Cachen anfallenden WGS84-Daten nach Potsdam umrechnen. Und da kann (und sollte ...) es auf jeden Meter Genauigkeit ankommen

Naja, mir persönlich würde so was um die drei Meter reichen, denke ich. Müsste ich draussen in Aktion ausprobieren, hier am Monitor sieht das ja schon anders aus.

Wastl

Hallo Wastl,

Ich vermute mal ganz stark, dass du Topographische Karten vom Vermessungsamt verwendest.
Also so lange Du bei ellipsoidischen Koordinaten bleibst beträgt die Abweichung unter 1m. Probleme treten erst auf, wenn Du mit GK arbeiten möchtest. Da kann ich momentan nichts ändern.
Sollt die Differenz dennoch mehr als 1m in Deiner Gegend betragen, so empfehle ich Dir mal die Helmertparameter ganz konkret für Deine nähere Umgebung zu ermitteln. Wie das geht und vor allem ein Applet mit dem Du die Berechnung vornehmen kannst gibts unter www.ottmarlabonde.de
Wenn Du mir dann Deine Parameter durchfunkst baue ich sie Dir ein.

Also wie gesagt, bleib bei ellipsoidischen, die passen.
Wie man ellipsoidische Koordinaten auf die Karte überträgt schätze ich weißt Du, oder?

Gruß

Anderl

P.S. der Shift von Potsdam nach WGS84 ist schon in Vorbereitung.

Hallo,

Das Tool ist weitergewachsen. Die Umrechnung von Potsdam nach WGS84 ist jetzt möglich.

Gruß

Anderl

Hallo mfs,

Standard ist eigentlich bei ellip. Koordinaten zuerst Breite und Länge anzugeben. Bei ebenen Koordinaten gibt man erst Rechtswert und dann Hochwert an.

Problem bei der Genauigkeit habe nicht mit dem Datumsübergang sondern mit der Umrechnung von ellip. nach ebenen Koordinaten.
Ich werde dazu aber nochmal in der Literatur suchen.

Die anderen Wünsche werde ich bei Gelegenheit noch einbauen, versprochen.

Gruß

Anderl

Wastl,

Die Genauuigkeit kriegen wir auch noch in den Griff!!!

Nenn mir doch mal das von dir benötigte Gebiet (linke obere und rechte untere Ecke). Dann versuch mal ne Korrektur zu erarbeiten.

Gruß

Anderl

Zitat

Original von Anderl
Wastl,

Die Genauuigkeit kriegen wir auch noch in den Griff!!!

Nenn mir doch mal das von dir benötigte Gebiet (linke obere und rechte untere Ecke). Dann versuch mal ne Korrektur zu erarbeiten.

Das wäre -- grob -- N 51° 30' / E 6° 30' -- N 50° 30' E 7° 30'

Wastl

Hallo Wastl,

Hier ist mal ein Version speziell für Dein Gebiet. Siehs Dir einfach mal an.

Gruß

Anderl

Anhang entfernt!

Sorry Leute,

Ich hab grad keinen Bock mehr irgendwas hier zu machen.

http://www.pocketnavigation.de…?postid=386520#post386520

Gruß

Anderl