NaviUser - Das GPS Forum für Einsteiger und Experten

Zurück   NaviUser > Technik > Berechnungsgrundlagen

Hinweise

Antwort
 
Themen-Optionen Ansicht
  #1  
Alt 10.08.2009, 14:38
mordillo ist offline mordillo
NaviUser
 
Registriert seit: 10.08.2009
Beiträge: 21
GPS Koordinaten Kartesisch abbilden[VB.NET]

Hallo zusammen,
zu allererst mal: schönes Forum habe lange suchen müssen um dieses Nette Plätzchen zu finden :-)

Meine Frage / Problem / Anliegen:

Was möchte ich machen:
Aus Längen- und Breitengradangaben, kartesische Koordinaten errechnen.
Das funktioniert auch schon und ist ja auch nicht so schwer.

Diese kartesischen Koordinaten dann in eine Picturebox eintragen und per DrawLine verbinden.
Das funktioniert auch, allerdings ist das visuelle Ergebnis != dem erwarteten, will sagen, Koordinatenpunkte falsch.

Um mir einen Referenzverlauf anzuzeigen, habe ich bei GoogleEarth 4Punkte über die Pfad-Funktion markiert. Aus diesen 4 Punkten dann die LON und LAT entnommen und 2D-kartesisch transformiert (Auf Basis einer Kugel da der Streckenausschnitt <100m war)

Wenn ich mir jetzt meine Berechnungen anschaue, sind diese korrekt (gibt ja einige Webseiten in denen man das umrechnen lassen kann), doch sieht meine Abbildung derer GoogleEarths nicht ähnlich, In GE wird eine "Treppe" als Pfad ausgegeben, in meinem Programm ein "U" mehr oder weniger symmetrisch :-(

Verwertet habe ich nur die errecheten X und Y Werte, wobei ich mir nicht sicher bin ob Z in irgendeiner Weise da mit eingerechnet werden muss.

Hat da jemand eventuell eine Idee zu?

Rohdatenumrechnung:
Code:
 x = Erdradius * Math.Cos(lat) * Math.Cos(lon) 
            y = Erdradius * Math.Cos(lat) * Math.Sin(lon)
            z = Erdradius * Math.Sin(lat)
Wobei LON und LAT im Bogenmaß gegeben sind. Obige Rechnung befindet sich innerhalb einer Schleife, wobei x, y, z dann an mccord(schleifenzähler).x / y / z übergeben wird

Ortsvektoren mit Bezugspunkt 0,0:
Code:
 
mvect(0).x = 0
mvect(0).y = 0

For i As Integer = 1 To LastEntry
            mvect(i).x = (mcoord(i - 1).x - mcoord(i).x) 
            mvect(i).y = (mcoord(i - 1).y - mcoord(i).y) 
        Next
Sinn des ganzen besteht darin, eine Wegstrecke mit dem Motorrad auf einer Strecke in 2D darzustellen. Später dann mit Sektorzeit, Geschwindigkeit, Rundenzeit usw.
Hierbei besteht keine Notwendigkeit das an eine Karte zu knüpfen, es soll einfach nur der gefahrene Kurs, ohne Höhenangaben angezeigt werden.


Gruß
m.

Geändert von mordillo (10.08.2009 um 15:02 Uhr)
Mit Zitat antworten
  #2  
Alt 10.08.2009, 18:44
mordillo ist offline mordillo
NaviUser
 
Registriert seit: 10.08.2009
Beiträge: 21
Hmm, da hab ich einige unregelmäßigkeiten in Google Earth, respektive Google Maps gefunden.

Bei Übertrag von LON und LAT aus Google Earth zu -Maps, komme ich nicht an den Koordinaten raus die GEarth anzeigt.
Sollte das mein Problem sein ? Inkonsistente GoogleEarth Daten ? Kann ich mir gar nicht vorstellen ...
Mit Zitat antworten
  #3  
Alt 10.08.2009, 20:58
macnetz ist offline macnetz
NaviUser
 
Registriert seit: 28.11.2008
Beiträge: 668
hallo mordillo,

du musst immer auf die Koordinaten-Schreibweise achten:
- hddd.ddddddd
- hdddmm.mmmmm
- hdddmmss.sss

Grüsse - Anton
Mit Zitat antworten
  #4  
Alt 10.08.2009, 22:41
Bunav ist offline Bunav
in memoriam
† 31. Januar 2013
 
Registriert seit: 20.11.2008
Ort: N51,30° E6,59°
Beiträge: 1.198
Hallo mordillo,

die Berechnungsformeln (1. Coderahmen) für die kartesischen Koordinaten sind OK.
Im zweiten Codefeld (mvect(i).x und mvect(i).y) kann ich aber keine Ortsvektoren erkennen.

Die Koordinaten der Ortsvektoren stehen im Feld mccord, die Differenzen zwischen zwei aufeinanderfolgenden Ortsvektoren lassen sich als Wege zwischen zwei Messpunkten deuten. Mir erscheint die zitierte Schleife insofern verdächtig, als fortlaufend Ortsvektoren subtrahiert werden.
Möglicherweise erklärt das den anfänglichen Misserfolg

Meine Vorstellung:
Verbindet man die einzelnen Punkte des Feldes mccord fortlaufend, erhält man den zurückgelegten Weg („Trackdarstellung“).

Weglassen der Z-Komponenten bedeutet die Projektion des Tracks in die Äquatorebene. Das kann zu sehr starken Verzerrungen führen. Insofern sollten die Vektoren korrekt dreidimensional behandelt werden. Bei dem geringen Rechenaufwand des vorliegenden Problems werden die Rechenzeiten ohnehin äußerst gering sein.
Ich hoffe zwar, dass ich die Aufgabenstellung prinzipiell verstanden habe. Allerdings habe ich mich noch nicht damit beschäftigt, mit Hilfe von Ortsvektoren einen Track in der Ebene darzustellen. Solange die Entfernungen klein sind –nicht mehr als einige hundert Kilometer- ergeben sich keine nennenswerten Fehlerprobleme.

Grüße Bunav
** nüvi 860TFM, GPSMAP 76Cx, eTrex Legend HCx **
Mit Zitat antworten
  #5  
Alt 11.08.2009, 14:29
mordillo ist offline mordillo
NaviUser
 
Registriert seit: 10.08.2009
Beiträge: 21
Ja, das mit den Ortsvektoren war natürlich eine Eselei, da diese ja das Abstandsverhältnis X zu Y versauen - Hab es eben selbst gemerkt und wollte noch posten das ich den Fehler gefunden hab ...

Nun sind in GoogleEarth gemalte Pfade mit meiner Zeichnung auch Deckungsgleich.


Wie kann ich Z in die Projektion mit einfliessen lassen ?

Vielen Dank für eure Antworten

Geändert von mordillo (11.08.2009 um 14:34 Uhr)
Mit Zitat antworten
  #6  
Alt 11.08.2009, 15:55
mordillo ist offline mordillo
NaviUser
 
Registriert seit: 10.08.2009
Beiträge: 21
Verzerrungen gleiche ich nun mit Rotationskorrekturen aus, hat auch den Vorteil das ich die Grafik nun in 3D umorientieren kann.
Mit Zitat antworten
  #7  
Alt 11.08.2009, 16:05
stefan_s ist offline stefan_s
NaviUser
 
Registriert seit: 08.12.2008
Beiträge: 69
Hallo mordillo,


ich störe mal kurz...

Wie willst du später die Sektorzeit, Geschwindigkeit, Rundenzeit... genau berechnen, wenn du die Höhenanteile unterschlägst?

Die Trackdaten sollen doch mit einem GPSystem aufgezeichnet werden ?!?

Normalerweise beherrschen die dafür in Frage kommenden Empfänger in einer ihrer
Protokollmessages die Ausgabe der Position im ECEF-Format.
Also 3D-Koordinaten XYZ mitsamt den gemittelten Momentangeschwindigkeiten in jeder der 3 Achsen.
Gemittelt über die Zeiten zwischen den Positionsupdates.

--> Empfänger mit 5-10Hz Updateraten sind gefragt.

Und wenn du deine Software gleich mit diesen Daten fütterst...?!?
Spart alles wertvolle Rechenzeit.


Stefan
Mit Zitat antworten
  #8  
Alt 11.08.2009, 16:15
mordillo ist offline mordillo
NaviUser
 
Registriert seit: 10.08.2009
Beiträge: 21
Also den Z Anteil unterschlage ich natürlich nicht in der Wegstreckenberechnung, es ging hier nur um das aufmalen des Tracks in eine Picturebox.

Das die Empfänger schon ECEF ausgeben hatte ich zwar gehofft, allerdings wollte ich das mal für mich selber durchrechnen...

Kann mir jemand einen geeigneten Empfänger empfehlen? Da die Soft nun das macht was ich will, brauch ich nun auch eine reale Eingabequelle :-)

Danke
Mit Zitat antworten
  #9  
Alt 11.08.2009, 16:40
stefan_s ist offline stefan_s
NaviUser
 
Registriert seit: 08.12.2008
Beiträge: 69
Hallo,


"fertig" gibts die schnellen Empfänger natürlich auch, sind aber teuer.
Da muss gebastelt werden.

Ich kenne derzeit 2 Lösungen, einmal die ANTARIS4 von u-blox , und dann den Venus634Lpx von SkyTraq.
Ersterer ( die Modelle LEA-4H, LEA-4T, TIM-4H... ) unterstützt offiziell nur Updateraten < 4Hz, inoffiziell gehen die aber auch bis 10 Hz.
Hier liegt die Protokolldoku frei zugänglich auf der u-blox-Website.

Beim SkyTraq müsstest du dich beim Hersteller nach einer genauen und vollständigen Protokolldoku erkundigen. ( wegen der ECEF-Ausgabe )
Der wiederum kann offiziell 10 Hz.


(Im Board aus der Nachbarschaft gabs kürzlich einen ähnlich gelagerten Fred:
http://www.kowoma.de/gpsforum/viewtopic.php?f=1&t=2089



Stefan
Mit Zitat antworten
  #10  
Alt 11.08.2009, 21:15
mordillo ist offline mordillo
NaviUser
 
Registriert seit: 10.08.2009
Beiträge: 21
Danke sehr !!

Mit Zitat antworten
Antwort

Themen-Optionen
Ansicht

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.



Alle Zeitangaben in GMT +2. Es ist jetzt 02:42 Uhr.


Powered by vBulletin® Version 3.8.4 (Deutsch)
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Template-Modifikationen durch TMS
© 2010 NaviUser KL