Falsche Werte bei GPS-Höhe WM5.0 C#

Hallo ich programmiere mit GPS unter WM5.0 mit C#.
Ich verwende die MS Beispiel-Klassen für die Positionsbestimmung.

Jetzt habe ich festgestellt, dass zwar die Position(Lat, Lon) stets korrekt ist, aber
die ellipsoidische Höhe nicht. Diese hat stets den Wert 47,9 unabhängig vom Ort.
(Eigenschaft: GpsPosition.flAltitudeWRTEllipsoid)
Korrekt wäre hier bei meinem Haus eine ellips. Höhe von etwa 500 m.


Hatte jmd von euch das gleiche Problem ???
Ich freue mich um einen guten Rat !!!!!!

 

Wie viele Satelliten hast Du denn für die Positionsbestimmung zur Verfügung? Du benötigst für die Höhenbestimmung mindestens 4 Stück. Ich könnte mir vorstellen, dass Du evtl. nur drei hattest, die für die Position ausreichen, aber nicht die Höhenbestimmung.

 

Hatte mehr als vier Satelliten. Es kommt als ellips.Höhe immer 47.9 und einmal 48.0 rein, bzw 0.0, was unmöglich stimmen kann.
Habs auch während einer Fahrt auf der Autobahn getestet, da ändert sich nix.
Anfangs glaubte ich an einen KOnvertierungsfehler zwischen Float und Double, aber das wäre zu schön gewesen......;-)

Gibt es Eigenschaften, die man falsch einstellen kann? Das meiste steht auf "Objekt.Unknown" und sollte daher die Höhe wohl zulassen.

GIbt es sonst noch Tipps für mich?

 

Ich kenne das Programm nicht... aber wie ist diese Eigenschaft definiert ?
Es könnte die Differenzhöhe Ellipsoid<>Geoid sein. Diese ändert sich auf kurze Strecken nur ganz wenig und der Wert +49m liegt im Bereich der Werte für Europa.
Der Wert 0.0 wäre dann ein Rohdaten- oder Auslesefehler...

>>> http://de.wikipedia.org/wiki/Geoid


Das GPS-Ellipsoid WGS84 ist eine theoretische Form. Es entspricht der Wulst am Aequator (infolge Zentrifugalkraft).
Die Null-Höhe (die Meereshöhe) wird aber lokal durch die jeweilige Gravitation mitbestimmt... und diese hängt von den Massen im Erdinnern unter dem jeweiligen Ort ab, egal ob Kontinent oder Ozean.
Das Erd-Geoid selbst hat deshalb Dellen und Beulen (bis plus/minus 100m) - eine Art Orange...

Um die wahre Höhe über Meer ausgeben zu können, braucht das Gerät deshalb eine "Geoid-Karte" mit diesen Korrekturen, wo es den Wert am errechneten Standort auslesen kann.

Es könnte sein, dass die Eigenschaft eben diesen Korrekturwert ausliest...

Gruss Urs

 

@Urs2:
thx, stimmt, das wäre gut möglich.
Diese Korrekturhöhe nennt sich Geoid-Undulation (N = Hell - Hgeoid).
Allerdings wäre dann der GPS-Intermediate-Driver von MS, den ich verwende, katastrophal falsch konfiguriert.

Ich bräuchte in diesem Fall tatsächlich ein Geoid-Grid oder Ellipsoid-Grid, von dem ich die Höhen quasi interpolieren kann. Die meisten Datenbanken enthalten ein Undulations-Grid......was leider ja nix bringt, die dies ja meine Ausgangswerte sind.

Evt sollte ich mal Micr*soft anschreiben, was die dazu meinen.
Ich werde es dann hier berichten.

 

Ich habe zwar immer noch keine Erfahrung, wie die GPS-Daten weiterverarbeitet werden sollen, aber...
...wenn ich Google mit "GpsPosition.flAltitudeWRTEllipsoid" füttere, stosse ich unter anderem auf die Eigenschaft >
flAltitudeWRTSeaLevel

Was gibt Dir diese Eigenschaft zurück ?
Eine auf das Geoid-Null bezogene Höhe, oder auf das Ellipsoid und dann noch zu korrigieren ?

Für den EndUser sind die auf das Ellipsoid bezogene Werte so oder so unbrauchbar.
Wie der GPS-Chip intern verdrahtet ist, weiss ich natürlich nicht, es könnte aber sein, dass er einen Algorithmus enthält, der die Höhenkorrektur selbständig berechnen kann.

Dein Gerät zeigt doch normalerweise die Höhe an?
Es gibt ja viele GPS-Verwendungen, wo diese überhaupt nicht angezeigt wird (zB Hochseenavigation) und dort wohl auch nicht berechnet werden muss. Ob dann eine Höhe fest vorgegeben ist ?

Gruss Urs

 

.....Problem gel&#246;st!!!!!

Ich habe eben die Sealevel Eigenschaft nochmals getestet, sie ergab korrekte Werte.
Zusammen mit der Undulation N kann ich nun die ellips.H&#246;he berechnen.
Formel: H(Ellipsoid) = H(SeaLevel) + N

Beim ersten Testen, bevor ich diesen thread &#252;berhaupt gestartet hatte, habe ich die Sealevel-Eigenschaft schon vergeblich ausprobiert, sie gab falsche Werte zur&#252;ck.
Das lag dann wohl daran, dass ich nur Sicht auf 3 Satelliten hatte.


Ich danke dir vielmals, urs2, ich war schon fast am Verzweifeln!

PS: Es bleibt jedoch trotzdem etwas fragw&#252;rdig, dass Micros*ft beide Eigenschaften homogen benannt hat, obwohl unterschiedliche Dinge gemeint sind. Was solls.
Um deine Frage wegen der Relevanz der ellips.H&#246;he zu beantworten: Es handelt sich um ein Programm, in denen mit mehren Koordinatenreferenzsystemen gearbeitet wird, sprich, man hat mit Datumshift zu tun. F&#252;r die Umformung in geozentrische Koordinaten brauchst du die ellips.H&#246;he.

Gr&#252;&#223;e

 

Aha... dann ist das SeaLevel-Ding also die schon korrigierte Höhe auf dem Geoid... für den EndUser.

Deine Formel: H(Ellipsoid) = H(SeaLevel) + N .................. Ist das nicht umgekehrt, H(SeaLevel) minus N ?
Wir sitzen hier ja auf einer Beule von +48m, die ellipsoide Höhe liegt unter uns...
Ich weiss, vorher hast Du geschrieben "N = Hell - Hgeoid", aber hier wird das Vorzeichen von N ja vom Gerät geliefert...
...zum Testen > auf Spesen mal in die USA fliegen, die sitzen dort in einer Delle...

Zwischen ...Ellipsoid... und ...SeaLevel... kann ich aber zumindest keine HomoSapiensGenität feststellen. Bei mir gingen jedenfalls beim Lesen Deines Alt...Ellipsoid immerhin gleich gelbe Blinklichter an...
Die Datumsverschiebung ist ja auch nicht gerade das, was der gewöhnliche EndUser normalerweise selbst machen will.

Ich hatte mich genauer mit GPS-Daten beschäftigt, nicht mit der Weiterverarbeitung der Rohdaten, sondern mit der theoretischen Genauigkeit und den entsprechenden Fehlerquellen. Die genauen Angaben mit X Kommastellen erschienen mir suspekt...

Besonders die Höhen scheinen da Probleme zu bereiten, sie sind so etwas wie... absolut genau, aber relativ ungenau !
Erst eine gleichzeitige Messung mit einem identischen Gerät, an einem bekannten Punkt in topographisch identischer, und geographisch und meteorologisch grosser Nähe, bringt relative Genauigkeit.
Die erforderliche Genauigkeit ist natürlich auch relativ. Bei den Cruise-Missiles, die in Bodennähe und fern von Referenzpunkten fliegen müssen, wird das wohl nur über einem ständigen Abgleich mit Geländemodellen und einer Radarhöhenmessung funktionieren.

Gruss Urs

 

Nein, die Formel ist korrekt......und bitte nicht verwechseln: Das WGS84-Ellipsoid liegt unter dem Geoid. --> Die ellips.Höhen sind größer als die Orthometrischen Höhen(= SeaLevelAlt).

Die Formel gilt übrigens ebenso bei der Berechnung von NHN-Höhen, die sich auf das Quasigeoid beziehen, falls dies von Interesse sein sollte.
(Dies sind die zukünftigen Höhen der Vermessungsämter, teilweise schon NHN und NN parallel aufgeführt in den Unterlagen)

Richtig, aber die EndUser in meinem Fall sind Vermesser.......;-)

Zum Thema Genauigkeit bei GPS:
Um das Genauigkeitsproblem zu umgehen, wird in der Vermessung mithilfe von SAPOS vermessen. U know? Das ist der deutsche Satellitenpositionierungsdienst, der ca alle 50 km GPS-Referenzstationen in D aufgestellt hat, die dir Korrekturdaten via Handyverbindung an deinen GPS-Rover schicken. Die Genauigkeit der Lage beträgt dann sage und schreibe ca 1 bis 3 cm. Jedoch ist dieser Service nicht kostenlos und du brauchst das entsprechende Equipment.

Ich freue mich im übrigen auf Galileo, wenn es endlich mal in Betrieb genommen wird. Galileo wird dann mit GPS gekoppelt und ich bin auf die Resultate gespannt.....

Greetz

 

....ja natürlich ...ich hatte dabei dummerweise in absoluten Distanzen vom Erdmittelpunkt aus "gedacht".

Kurz vor dem Posten hatte ich mich mit der örtlich sichtbaren Position des Mondes beschäftigt, dort ist für die Parallaxe ja eben diese Distanz Erdmittelpunkt<>Erdoberfläche zuständig... das hatte wohl für Verwirrung gesorgt...

Gruss Urs