Höhe über Geoid <-> Höhe über Ellipsoid

[cr2_gps]

Zusammengefasst finde ich es halt schade, dass SAPOS HEPS Transformationsinformationen liefert, ich diese in RTKLib aber nicht nutzen kann, obwohl dieses für einen mit dem Programm vertrauten Prgrammierer IMHO leicht implementierbar wäre.

Kann jemand, der Zugang zu den SAPOS HEPS hat, einen Ausschnitt aus den Datenstrom machen und ihm zur Verfügung zu stellen?
Der Mountpoint muss natürlich die RTCM3.1 Messages 1021, 1023 und 1025 beinhalten, z.B. aus
http://www.sapos.geonord.de:2101/sourcetable.htm
5 Minuten mit dem Log von STR2STR reichen meiner Meinung nach vollkommen aus,
um den RTCM3 Parser zu ergänzen.

[ssquare_de]

Hallo ,


ja, kann ich machen...aber leider erst nächste Woche.

Um was geht es? (für die Mitleser)
Darum:

..."Neue Message 1025 in der RTCM3-Transformationsnachricht

Ab 01. August 2014 wird die RTCM3-Transformationsnachricht in das amtliche CRS
DHDN90 (GK) durch die Projektionsmessage 1025 ergänzt. Die im SAPOS® HEPS
ausgestrahlte RTCM3-Transformationsnachricht enthält dann folgende Informationen:

Message 1021:
Ellipsoid-Parameter des Start- und Zielsystems (GRS80- und Bessel-
Ellipsoid), sowie Transformationsparameter einer bayernweiten 7PVortransformation
(ETRS89 → DHDN90)

Message 1023:
16 Punkte des Transformationsgitters (4x4), welche die Lage-Residuen
nach der 7P-Vortransformation enthalten. Für jeden Gitterpunkt wird
außerdem die NN-Undulation zur Berechnung von NN-Höhen im
Höhenstatus 100 angegeben. Nach Verarbeitung der Message 1023 im
RTK-Rover liegen im Feld ellipsoidische Koordinaten (Breite und Länge)
im DHDN90 (Bessel-Ellipsoid) und NN-Höhen vor.

Message 1025:
Parameter der GK-Abbildung für die Zone 4 (12° Mit telmeridian). Mit der
Message 1025 ist der Rover im Feld nunmehr ohne Zusatzinformationen
in der Lage die ellipsoidischen Koordinaten (Breite und Länge) im
DHDN90 automatisch in die amtliche GK4-Abbildung zu verebnen.
Damit steht am Rover-Gerät bei jeder Einwahl in SAPOS® HEPS ein vollständig definierter
Datumsübergang zwischen ETRS89 (DREF91) und DHDN90 (GK) / DHHN12 (Höhe über
NN) zur Verfügung.
Die Nutzung der RTCM3-Transformationsnachricht ist ohne Aufpreis und zu den geltenden HEPS-Nutzungsbedingungen möglich."...

aus den "SAPOS® - Bayern - Nachrichten 1 / 2014" entnommen



Stefan

[cr2_gps]

ja, kann ich machen...aber leider erst nächste Woche.

Das wäre prima.

[cr2_gps]

Wenn es ums Geld geht, versteht der Freistaat Bayern wohl kein Spaß:

Code: Alles auswählen

Nutzungsbedingungen für die SAPOS®-Dienste in Bayern

Der Lizenznehmer hat dafür zu sorgen und dem
Landesamt für Digitalisierung, Breitband und Vermessung (LDBV)
auf Verlangen nachzuweisen, dass Dritte keinen Zugriff auf die Daten
nehmen können und dass seine Mitarbeiter die Daten weder zu persönlichen Zwecken
nutzen noch Dritten zugänglich machen. 

Mir geht es in diesem Fall nur um die Datenstruktur, die landeseigenen Daten werde ich bewusst ignorieren

[oekoplaner]

Zusammengefasst finde ich es halt schade, dass SAPOS HEPS Transformationsinformationen liefert, ich diese in RTKLib aber nicht nutzen kann, obwohl dieses für einen mit dem Programm vertrauten Prgrammierer IMHO leicht implementierbar wäre.

Kann jemand, der Zugang zu den SAPOS HEPS hat, einen Ausschnitt aus den Datenstrom machen und ihm zur Verfügung zu stellen?
Der Mountpoint muss natürlich die RTCM3.1 Messages 1021, 1023 und 1025 beinhalten, z.B. aus
http://www.sapos.geonord.de:2101/sourcetable.htm
5 Minuten mit dem Log von STR2STR reichen meiner Meinung nach vollkommen aus,
um den RTCM3 Parser zu ergänzen.

Habe hier länger nicht mehr reingeschaut - deshalb späte Antwort.
Ich nutze das SAPOS HEPS in NRW. Dort sind anscheinend nur die Messages 1021 und 1023 integriert ( http://www.bezreg-koeln.nrw.de/brk_inte ... ps_faq.pdf ).
Würde dir das trotzdem weiterhelfen?
Wenn ja, was müsste ich dir schicken? Ich habe hier mehrere von RTKNavi aufgezeichnete "Base Station" Log Streams. Ist das, was du suchst?

Grüße

Holger

[ssquare_de]

Hallo Holger,


ich hoffe, cr2_gps schaut auch bald hier wieder vorbei.
Irgendwie ist der Kontakt mit ihm abgebrochen, trotz PM meinerseits.
Ja, soweit ich das sehe, würden ihm 5min-Logs eines RTCM-Stream genügen, der die Transformationsmessages beinnhaltet.


Stefan

[oekoplaner]

Ich hole meinen eigenen Thread nochmal aus der Versenkung.

Ich will mit dem NVS NV08C-CSM + Novatel 701GG Punkte im Gelände mit Höhe aufnehmen. RTKNavi errechnet mit SAPOS HEPS Korrekturdaten eine RTK-Lösung und stellt sie via gpsd lokal (Port 127.0.0.1) als NMEA0183-Stream zur Verfügung. Der gpsd Stream wird dann von QGIS empfangen und dort erfasse ich die gewünschten Punkte.
Da QGIS per se nur die x- + y-Koordinaten erfasst ( vgl. meine Anfrage im Thread viewtopic.php?f=4&t=3509 ) habe ich mir ein eigenes Python-Script + Eingabeformular erstellt. Das Script liest die "Elevation" aus dem NMEA Datenstrom und reicht sie an das Eingabeformular weiter, wo ich dann einen Korrekturwert eingeben kann, um die Umrechnung in das gewünschte Höhen-Bezugssystem ( DHHN92 ) zu erreichen.
So weit so gut. Da GPS mit dem WGS84 Ellipsoid arbeitet, erwartete ich, dass QGIS auch Höhen im WGS84- / ETRS89-Bezugssystem erhält. Zu meiner Überraschung musste ich feststellen, dass dem nicht so ist!
Um das Ganze genauer zu untersuchen habe ich eine Testmessung an einem Höhenfestpunkt vorgenommen.

Code: Alles auswählen

Höhen des HFPs laut AFIS-Festpunktauskunft NRW der Bezirksregierung Köln:
Höhe (GRS80)                                                           68,301
Höhe (DHHN92)                                                          23,890

Von mir gemessene Höhen:
WGS84 (aus dem Positions-Log entnommen und über 9 Minuten gemittelt)   68,289
Mittelwert aus 9 in QGIS erfassten Werten                              23,522

Während der gesamten ausgewerteten Zeit zeigte RTKNavi eine Fix-Lösung an und die Höhenwerte waren stabil (Spannweite 2,7 cm)

Der Wert der WGS84-Höhe aus dem Logfile stimmt ja sehr schön mit dem erwarteten Wert überein.
Aber warum enthält der NMEA-Stream keine WGS84 Höhen und in welchem Höhenbezugsystem liegen diese Werte?

Habe ich in meinen RTKNavi-Settings irgendetwas versteckt, das das Programm anweist, die Höhen für den NMEA Output umzurechen?

RTKNavi_Settings.jpg (425 KiB) 33663 mal betrachtet

Bin für jeden Hinweis dankbar.

Viele Grüße

Holger

[Hagen.Felix]

Moin Holger,

liegt vielleicht hier der Lösungsansatz?

http://www.bkg.bund.de/DE/Bundesamt/Geo ... __nnn=true

Viele Grüße,
Hagen

[oekoplaner]

Moin Holger,

liegt vielleicht hier der Lösungsansatz?

http://www.bkg.bund.de/DE/Bundesamt/Geo ... __nnn=true

Viele Grüße,
Hagen

Nee, glaube ich nicht.
Wenn ich unter http://www.bkg.bund.de/DE/Bundesamt/Geo ... __nnn=true einen Wert für Quasigeoidhöhe für den Standort berechnen lasse, erhalte ich 44,442 m. Die beiden Werte aus der AFIS-Festpunktauskunft differieren um 44,411 m. Naja, 3,1 cm Differenz kann ich noch mit leben.
Aber zwischen meinem Messwert im WGS84-System ( 68,289 m) und dem anderen Wert im unbekannten Bezugssytsem liegt eine Differenz von 44,767 m.

[oekoplaner]

Habe gestern noch einen Versuch dazu durchgeführt, mich in das Thema NMEA-Sentences eingelesen und nochmal eine Nacht drüber geschlafen. Danach glaube (!!) ich, dass ich das Problem jetzt einigermaßen durchschaue.

In meinen Optionen für RTKNavi habe ich unter "Output -> Datum / Height" den Wert "Ellipsoidal" ausgewählt, um ellipsoidische Höhen ausgegeben zu bekommen. Diese Einstellung wirkt sich aber nicht auf den NMEA-Stream aus!
Die Positionsdaten im NMEA-Stream stecken in der "GGA" Message und dort werden - gemäß dem NMEA Standard - eine Höhe über Geoid und die Geoidhöhe (also die Höhe des Geoids über dem Ellipsoid) angegeben. Damit lässt sich natürlich auch die Höhe über Ellipsoid berechnen - QGIS stellt mir aber IMHO die Geoidhöhe nicht zur Verfügung!
In der QGIS API gibt es eine Klasse "QgsGPSInformation" die die folgenden Attribute besitzt (s. http://qgis.org/api/structQgsGPSInformation.html ):

Code: Alles auswählen

Public Attributes:
double 	direction
double 	elevation
QChar 	fixMode
int 	fixType
double 	hacc
double 	hdop
double 	latitude
double 	longitude
double 	pdop
int 	quality
QList< QgsSatelliteInfo > 	satellitesInView
int 	satellitesUsed
bool 	satInfoComplete
QList< int > 	satPrn
double 	speed
QChar 	status
QDateTime 	utcDateTime
double 	vacc
double 	vdop

Das Attribut "elevation" enthält dabei offensichtlich den Wert für die Höhe über Geoid. Der Wert für die Geoidhöhe scheint nicht verfügbar.

Ich habe schon auf der QGIS Homepage ein Feature Request formuliert, mit der Bitte, die Geoidhöhe als zusätzliches Attribut der Klasse hinzu zu fügen ( https://hub.qgis.org/issues/12999 ). Wenn jemand meine Ausführungen hier für logisch hält, würde ich mich über unterstützende Meldungen zu diesem Feature Request freuen, um so dieser Bitte mehr Gewicht zu verleihen.

Viele Grüße

Holger