Hallo Andi

Aus aktuellem Anlass (fehlerhafte Konfiguration) habe ich noch eine ganz wichtige Sache, die man ergänzen sollte. Es geht um die Verifikation des Swipos Korrektursignals, das es in verschiedenen Auspägungen gibt, je nach Bezugsrahmen. Es muss unbedingt sichergestellt sein, dass

1. Das Koordinatensystem mit dem Swipos Mount Point übereinstimmt
2. Stets der richtige Höhen Bezugsrahmen verwendet wird.

Die entsprechenden Information findet man im Header, am Anfang (und manchmal zwischen) den Messungen:

Relevante Datenrecords:

--User Defined: SWITZERLAND/LV03-3P/CH1903+
--RTK Method: RTCM V3.0, Device: Internal GSM, Network: NTRIP MSM_GISGEO_LV95LN02

• wenn "CH1903+", dann "GISGEO_LV95LN02" und 7-stellige Koordinaten (1nnnnnn,2nnnnnn)
• wenn "CH1903", dann "GISGEO_LV03LN02" und 6-stellige Koordinaten (nnnnnn,nnnnnn)

Dieser Test muss auf alle "-- RTK Method" Records angewandt werden, nicht nur auf den ersten!

Falls der Test misslingt, riesengrosse Fehlermeldung ins CSV und ins TXT, sodass ein fehlerfreier Import keinesfalls möglich ist.

Until now we claimed that all measurements belonging to the same GCP are continuous, that's not always true, as it turns out.

Example: GCP5 can only be measured once and maybe with a a signifficant HSDV/VSDV, hence we continue with other GCPs and come back later.

• GCP4: PM03,PM04,PM05 // continuous
• GCP5: PM06, PM22, PM23, PM33 // not continuous
• GCP6: PM07, PM10, PM11 // not continuous

In order to recognize these cases, we can no longer process the measurement one by one. Instead, we have to temporary store them in an array (or so) . Upon identifying all the measurements for a given GCP, we then can consider every sinle measurement, not only the next one.

program version
git revision (git rev-parse --short HEAD)

In case of an error (constraint violation), we substitute the fractional digits by "***" to illustrate the uncertainty. In this case, the values before the fraction digit (Vorkommastellen) shall not be rounded.

Example:

• raw values: 1234567.854 / 1234567.724 / 1234567.999
• drift too big, cut off/replace fractional digits by "***"
• result: 1234567.*** (not 1234568.***) -- cut off, do not round

Hallo Andi

Ich habe mir den letzten Stand nochmals angeschaut, ich glaube, jetzt passt's :-)

Noch etwas Kosmetik, falls du grad Langeweile hast, ist aber wirklich nicht dringend:

• GCP Nummer immer 2-stellig, also GCP01 anstatt GCP1
• PDOP (von bis) durch SATS (von..bis) ersetzen -- habe beim Beispielstudium bemerkt, dass PDOP wenig ausssagekräftig ist
• Error HSDV/VSDV: Nur HSDV oder nur VSDV oder beides, je nach Fehler und auch hier "exceeds limits" verwenden, z.B. "ERROR: HSDV exceeds limits"
• Error Drift X/Y/Z exceeds limits: Auch hier spezifisch ausweisen, was verletzt wird, X und/oder Y und/oder Z, z.B: "ERROR: Drift X,Y exceeds limits"
• Referenz auf Messungen möglichst kompakt in [], immer am Schluss
• Zeilenformat / Reihenfolge leicht anpassen, möglichst kompakt, siehe unten

Zeile neu:
GCPnn: XXXXXXX.XXX,YYYYYYY.YYY,ZZZ.ZZZ H.HHH,V.VVV / Date Time / #N / SATS: XX-YY / ERROR (if applicable) / [PN1,PN2,PN3,...]
oder als Beispiel
GCP04: 2600727.123,1202030.566,492.007 / 0.024,0.044 / 12-05-2017 10:08:50 / #3 / SATS: 8..10 / ERROR : VSDV exceeds limits / [PN10,PN11,PN12]

Erkennen der Messungen und der Tatsache, dass sie zu ein und demselben GCP gehören. Bisher waren alle Messungen je GCP exakt in Folge, neu kann es jetzt sein, dass es z.B. zwei Messungen gibt ganz am Anfang, z.B. PN02 un dPN03 und dann eine Stunde später nochmals 3 Messungen, z.B: PN41,PN42 und PN43 am gleichen Ort/GCP. All diese Messungen müssen zusammengefasst und als Messungen eines einzigen GCP erkannt werden.

Hallo Andi

Ich habe noch ein weiteres Problem gefunden, nicht im Code sondern in meiner Spezifikation:

Schau mal die folgenden 3 Samples (Messungen ) an:

--GS,PN28,N 1202089.0499,E 2600706.0025,EL492.1325,HSDV:0.024, VSDV:0.043, STATUS:FIXED, SATS:10, AGE:0.8, PDOP:2.623, HDOP:1.300, VDOP:2.278, TDOP:0.588, GDOP:2.688, NSDV
--GS,PN29,N 1202089.0533,E 2600706.0109,EL492.1502,HSDV:0.025, VSDV:0.045, STATUS:FIXED, SATS:10, AGE:4.6, PDOP:2.623, HDOP:1.300, VDOP:2.278, TDOP:0.588, GDOP:2.688, NSDV
--GS,PN30,N 1202088.8512,E 2600706.1007,EL491.7214,HSDV:0.018, VSDV:0.026, STATUS:FIXED, SATS:9, AGE:1.0, PDOP:3.833, HDOP:2.400, VDOP:2.988, TDOP:0.205, GDOP:3.838, NSDV:

Die ersten zwei schauen vernünftig aus, der Dritte (PN30) passt gar nicht. Ein solches Tripel dürfen wir keinesfalls mitteln!

Die Differenzen:

• deltaN ~= 20 cm
• deltaE ~= 10 cm
• deltaZ ~= 42 cm

Hier müssen wir einen neuen, zusätzlichen Constraint definieren, der den resulierenden GCP als *** drift exceeds limits *** markiert,
so etwas wie

if deltaN > 0.04 or deltaE > 0.04 or delta Z > 0.06 {
mark with Warning

Es sind immer die Minimum/Maximum aller Messungen (pro GCP) miteinzubeziehen.

Gruss
Reto

Beispiel:

GCP06,2603712.***,1197100.***,510.***,0.029,0.045  -  #4 / SATS: 12-14 / 01-25-2019 09:34:14 ERROR [PN11,PN12,PN67(Drift Y Exceeds Limits),PN68]
  --GS,PN11,N 1197100.8850,E 2603712.5510,EL510.2499,--
  --GS,PN12,N 1197100.8829,E 2603712.5481,EL510.2518,--
  --GS,PN67,N 1197100.8215,E 2603712.5566,EL510.2656,--
  --GS,PN68,N 1197100.8214,E 2603712.5566,EL510.2661,--
     >> dXmax = 6.36 / dYmax = 0.85 

Hallo Andi

Ich habe mir soeben das angehängte File angeschaut und dabei zwei "Probleme" entdeckt:

Bei GCP8 werden #4 Messungen ausgewiesen, ich sehe im Raw File aber nur 3 (PN16..PN18).
Nach PN18 kommt im RW5-File aber ziemlich "Noise", vermutlich habe ich das GPS aus- und wieder eingeschaltet. Diesen Noise müsste man überlesen.

Die PDOP Min..Max stimmen irgendwie nicht, soweit ich sehe.

• PN1: PDOP: 1.966
• PN2: PDOP: 1.965
• GCP1: PDOP: 1.747-1.748 ???

Die Mittelwerte habe ich in etwa 5-10 Stichproben überprüft, das sieht sehr gut aus.P301-3_AARE.txt
P301-3_AARE.rw5.txt
P301-3_AARE.csv.txt

E Gruess
Reto

Den folgenden Fall aus "P301-12_AARE.rw5" sollten wir untersuchen:

--GS,PN10,N 1202029.9775,E 2600727.0208,EL491.8784,HSDV:0.024, VSDV:0.044, STATUS:FIXED, SATS:10, AGE:0.4, PDOP:2.140, HDOP:1.100, VDOP:1.836, 
--GS,PN11,N 1202029.9854,E 2600727.0404,EL491.8836,HSDV:0.021, VSDV:0.040, STATUS:FIXED, SATS:11, AGE:1.0, PDOP:3.001, HDOP:1.200, VDOP:2.751, 
--GS,PN12,N 1202029.9878,E 2600727.0466,EL491.8201,HSDV:0.068, VSDV:0.161, STATUS:FIXED, SATS:10, AGE:1.0, PDOP:2.971, HDOP:1.100, VDOP:2.760,**

Das Resultat (.txt):

GCP4,2600727.021,1202029.978,491.878,0.024,0.044  -  #1 / PDOP: 2.140-2.140 / 12-05-2017 10:08:50 from: PN10
GCP5,2600727.047,1202029.988,491.820,0.068,0.161  -  #1 / PDOP: 2.971-2.971 / 12-05-2017 10:09:20  HSDV or VSDV not in Range from: PN12

Bemerkungen:

1. Alle 3 Punkte liegen innerhalb von 50cm, gehören also zusammen zu einem GCP
2. PN12 weist eine zu hohen VSDV auf und fliegt deshalb raus
3. Aus den restlichen Punkten (PN10 und PN11) sollte ein GCP erzeugt werden, durch Mittelwertbildung

Habe ich etwas übersehen?

Der Zusatz "from: ..." ist sehr nützlich, Danke.

Ein anderer Fall, ebenfalls aus P301-12_AARE

--GS,PN46,N 1202188.9306,E 2601355.0732,EL493.3889,HSDV:0.030, VSDV:0.033, STATUS:FIXED, SATS:8, AGE:0.8, PDOP:6.215, HDOP:3.300, VDOP:5.267, 
--GS,PN47,N 1202188.8913,E 2601355.0960,EL493.4051,HSDV:0.024, VSDV:0.032, STATUS:FIXED, SATS:10, AGE:0.4, PDOP:2.361, HDOP:1.200, VDOP:2.033, 
--GS,PN48,N 1202188.8879,E 2601355.0854,EL493.3998,HSDV:0.022, VSDV:0.026, STATUS:FIXED, SATS:9, AGE:1.0, PDOP:2.120, HDOP:1.200, VDOP:1.748, 

Resultat:

GCP19,2601355.085,1202188.911,493.397,0.030,0.033  -  #2 / PDOP: 2.361-6.215 / 12-05-2017 12:14:30 from: PN46,PN47
GCP20,2601355.085,1202188.888,493.400,0.022,0.026  -  #1 / PDOP: 2.120-2.120 / 12-05-2017 12:14:59  Drift Exceeds Limits from: PN48

Bemerkungen:

1. Trotz der Drift liegen liegen alle 3 Messungen innerhalb von 50 cm und werden demnach zu einem GCP zugeordnet.
2. Jetzt wird's schwieriger ... Von "Hand" sieht man, dass PN46 der Ausreisser ist, wie aber soll der Algorithmus das detektieren? Ich muss etwas nachdenken oder nachlesen, hast du eine gute Idee?

For example here: double --DT --TM lines

GPS,PN1,LA46.560420942696,LN7.334150123920,EL638.194000,--
--GS,PN1,N 1198163.9833,E 2609358.4122,EL587.0773,--
--GSRD,TXD0.240,TYD-0.240,THD,TDTStonex_S9i
--GSRL,TXL0.015,TYL-0.015,T2D0.021,TTL0.030
--GT,PN1,SW1978,ST201565000,EW1978,ET201575600
--Valid Readings: 10 of 10
--Fixed Readings: 10 of 10
--Nor Min: 1198163.9785 Max: 1198163.9879
--Eas Min: 2609358.4068 Max: 2609358.4150
--Elv Min: 587.0693 Max: 587.0863
--Nor Avg: 1198163.9833 SD: 0.0031
--Eas Avg: 2609358.4122 SD: 0.0022
--Elv Avg: 587.0773 SD: 0.0048
--NRMS Avg: 0.0060 SD: 0.0000 Min: 0.0060 Max: 0.0060
--ERMS Avg: 0.0050 SD: 0.0000 Min: 0.0050 Max: 0.0050
--HSDV Avg: 0.0078 SD: 0.0000 Min: 0.0078 Max: 0.0078
--VSDV Avg: 0.0130 SD: 0.0000 Min: 0.0130 Max: 0.0130
--HDOP Avg: 1.0000 Min: 1.0000 Max: 1.0000
--VDOP Avg: 1.6930 Min: 1.6930 Max: 1.6930
--PDOP Avg: 1.9663 Min: 1.9663 Max: 1.9663
--Number of Satellites Avg: 12 Min: 12 Max: 12
--HSDV:0.008, VSDV:0.013, STATUS:FIXED, SATS:12, AGE:0.6, PDOP:1.966, HDOP:1.000, VDOP:1.693, TDOP:0.521, GDOP:1.896, NSDV
--DT12-05-2017
--TM09:00:17
--DT12-05-2017
--TM09:57:50
--User Defined: SWITZERLAND/LV03-3P/CH1903+
--Equipment: Stonex, S9i, SN:S940111600733, FW:0.18.161114(STONEX)
--Antenna Type: [STXS9I NONE],RA0.0795m,SHMP0.0598m,L10.0968m,L20.0773m,--Stonex L1/L2 Antenna
--Localization File: None
--Geoid Separation File: \Program Files\SurvCE\Data\Geoids\swiss04.gsf N45�45'00.0" E005�50'59.0" N47�51'00.0" E010�30'00.
--Grid Adjustment File: None
--GPS Scale: 1.00000000
--Scale Point not used
--RTK Method: RTCM V3.0, Device: Internal GSM, Network: NTRIP MSM_GISGEO_LV95LN02
BP,PN324,LA46.580868801584,LN7.265338429548,EL485.8308,AG0.0000,PA0.0000,ATARP,SRROVER,--
--Entered Rover HR: 2.0000 m, Vertical
LS,HR2.0968

"Ein hab' ich noch..."

Weisst du eine gute Möglichkeit, den java Aufruf so zu scripten, dass ich auf einfache Art und Weise ein x-beliebiges RW5-File (in irgendeinem Directory) verarbeiten kann und das Resultat (.txt und csv Files) möglichst ins gleiche Directory zu liegen kommen.

Es muss nicht gleich eine File Explorer Action sein, ein einigermassen flexibles Commandfile würde wohl schon genügen... Hast du eine gute bzw. bessere Idee?

Noch etwas: Nebst LV95 gibt es auch noch das alte Format LV03, wie du sicher weisst. Ab und zu zeichne ich Punkte auch in diesem alten Koordinatenformat auf.

Man muss also beim Parsen damit rechnen, dass 7-stellige oder 6-stellige Koordinaten (X,Y) auftauchen.
Sonst bleibt alles gleich, glaube ich.