Hello. Is this software useable for adjusting a point with GNSS baselines to known CORS stations?
I have the official WGS84 coordinates and also local CRS for the stations. I have 3 baselines calculated via postprocessing of GNSS observations at a new point versus each of the 3 CORS (with RTKLIB). So I have east,north,up baselines. Distances are up to 80km.

I have tried but is seems the up component, at least, is not correctly used. For example using only one baseline with an up component of 600m the new point is calculated with a z value about 600m above the CORS but the ellipsoidal height difference is really over 1200m.

Hello Marcel,

Is this software useable for adjusting a point with GNSS baselines to known CORS stations?

Yes, the application should adjust such kind of network.

I have tried but

... without providing data, it will be hard to answer your questions. So, please provide you data (e.g. just copy the coordinates and the baselines into you next posting).

/Micha

Hello. This is the government provided data for 3 CORS

ID Lat DMS Long DMS Ell Hgt Sigmas N E U
CIQE 10 19 21.31054 -84 25 51.21060 680.618 0.001 0.001 0.004
RIDC 9 55 10.86421 -84 25 6.66020 1212.147 0.001 0.001 0.002
PUNT 9 58 47.56247 -84 49 55.68815 23.646 0.001 0.001 0.002

There is a new point, named CASA, that we want to locate and its aproximate coordinates are
9°54'36.10"N 84° 2'5.86"W 1228m ell height

These are baselines from the new point to each CORS as exported from the JAG3D 3d Baseline table

CIQE CASA 43433.6100 -45613.9500 235.4680 0.0230 0.0260 0.0380
PUNT CASA 87443.7240 -7622.0070 600.5070 0.0320 0.0120 0.0790
RIDC CASA 1551.9860 -1068.2310 15.8030 0.0060 0.0050 0.0140

I am not sure how or where coordinates for the CORS should be entered into the software. We also have official CRTM05 (EPSG:5367) coordinates for each CORS.

Thanks for your consideration.

Hello.

This is the government provided data for 3 CORS
ID Lat DMS Long DMS Ell Hgt Sigmas N E U

JAG3D needs Cartesian coordinates. Do you have such Cartesian coordinates of the stations and the new point?

/Micha

We do have official coordinates in CRTM05

ID North East
CIQE 1141453.371 452808.934
PUNT 1103633.696 408765.664
RIDC 1096862.037 494618.968

The new point would be aproximately at 1095794 496168

We don't want to introduce errors because of particulars of CRTM05. Is it better to use UTM or other CRS?

CRTM05 info:
Proj4
+proj=tmerc +lat_0=0 +lon_0=-84 +k=0.9999 +x_0=500000 +y_0=0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

Hi,

for a first check, I transform lat/lon/height to X/Y/Z (WGS84). The corresponding coordinates read:

CIQE 609086.575860679 -6246622.90882520 1135491.70093521
PUNT 565870.301787418 -6256745.19933001 1098060.79280774
RIDC 611248.433670597 -6254807.29657424 1091707.74690573
CASA 653126.771933286 -6250773.77345104 1090658.12307496

The distances between the new point and the GNSS stations are given by

62982.6821515789
87773.2819741715
42085.2258472698 ***

The corresponding baseline lengths are

62985.4455998656
87777.3345821874
1884.15173177905 ***

There are large discrepancies between the distances derived from coordinates and the corresponding baseline lengths. Can you check your input quantities?

/Micha

I am sorry, this is the correct data:

RIDC 9 55 10.86421 -84 2 56.66020 1212.147 0.001 0.001 0.002

can you recommend a reliable conversion method to X Y Z. I used an online conversion and got a bit different results.

Hi,

okay, if I derive the baseline components from your coordinates (i.e., CORS - CASA), I got

 -44040.196072607          4150.86462583952          44833.5778602501
 -87256.470145868         -5971.42587897088          7402.66973277996
-1560.18983063602          37.8204587697983          1049.62383077014

Your baseline components read

CIQE CASA 43433.6100 -45613.9500 235.4680 0.0230 0.0260 0.0380 
PUNT CASA 87443.7240 -7622.0070 600.5070 0.0320 0.0120 0.0790 
RIDC CASA 1551.9860 -1068.2310 15.8030 0.0060 0.0050 0.0140

Usually, the baseline components are related to the WGS84 and should be close to the estimated baseline components derived from coordinates. What are the reason of such discrepancies here? Did you used the WGS84?

/Micha

Hi,

in JAG3D. In the main menu, click module --> Coordinate converter.

/Micha

I think there might be different definitions for what a baseline is. I do not know what JAG3D expects as a baseline. What I have a for baselines is obtained from RTKLIB postprocessing of raw GNSS observations at the CORS and the new point. I understand these are east north and up components in meters. There is no use of any local or other coordinate system or geoids in obtaining these baselines.
These baselines are similar to what I get from other GNSS raw processing like Topcon Tools.
So maybe some conversion is needed to get the numbers as JAG3D expects them.

It is unfortunate that there is no documentation to help new users. I see the Coordinate conversion modules but cannot understand how to use them, to make this kind of conversion.

Hi,

how to use them, to make this kind of conversion.

just copy your coordinates to the lat/lon/height text fields, select WGS84 (or your specific reference frame) and click Process....

/Micha

Hello,

I think there might be different definitions for what a baseline is.

Okay, that is possible. JAG3D does not expect baselines in WGS84. However, I expected the baselines in WGS84 because it is the reference frame of GNSS.

For further analysis, I used the transformation tool of JAG3D. The "source system" is defined by your provided baselines, i.e.,

CIQE 43433.6100 -45613.9500 235.4680
PUNT 87443.7240 -7622.0070 600.5070 
RIDC 1551.9860 -1068.2310 15.8030

and the "target system" is given by the baseline components derived by the coordinates, i.e.,

CIQE -44040.196072607          4150.86462583952          44833.5778602501
PUNT -87256.470145868         -5971.42587897088          7402.66973277996
RIDC -1560.18983063602          37.8204587697983          1049.62383077014

I imported the coordinate to the transformation tool, i.e.

Since the original baselines as well as the derived baselines (from coordinates) are related to the new point CASA (i.e., there is no translation), the network rotations are unknown, i.e.,

Both system should be congruent to each other. The next figure depicts the results. The rotation parameters are given in radian (RAD) and are significant.

However, this is not the problem but the baseline components in source system (the original baselines) didn't match the components in target system (derived from coordinates), i.e.,

The last column (labeled by Outlier) indicates "gross errors" and ∇ indicates the assumed "gross error". All values are given in meters. As you can see, the values are very large. So, it is impossible to transform the original baselines to the values derived by coordinate components, i.e., both systems are not congruent to each other. Why?

Please note, this is my fist check of your data. If such checks failed, further analysis in JAG3D are not meaningful.

regards Micha

Ok so what I understand is there might not be a direct path from the way I am producing the baselines to something usable in JAG3D.

So may I ask how do other people produce GNSS baselines that can be used?

Hi,

Ok so what I understand is there might not be a direct path from the way I am producing the baselines to something usable in JAG3D.

No, that's not right. I'm unable to understand your values. I'm unable to derive a relationship between your baselines and your provided coordinates. If I don't understand the problem, I'm unable to answer your question.

So may I ask how do other people produce GNSS baselines that can be used?

Let us take a look to an example, given in Hofmann-Wellenhof et al, p. 59ff.

The fixed reference point is given by

SB 4213857.480 1025292.070 4664733.470

the new points read

KK 4214436.777 1025493.730 4663835.190
KS 4213099.408 1022546.373 4665836.887
LK 4215184.630 1021692.539 4664261.604

and the observed baselines are given by

SB KK   579.297   201.660  -898.280 0.01 0.01 0.01
KK KS -1337.369 -2947.357  2001.697 0.01 0.01 0.01
KS LK  2085.222  -853.834 -1575.283 0.01 0.01 0.01
SB KS  -758.051 -2745.673  1103.395 0.01 0.01 0.01
LK KK  -747.852  3801.192  -426.417 0.01 0.01 0.01

The published results are

KK X 4214436.785 Y 1025493.739 Z 4663835.181
KS X 4213099.421 Y 1022546.388 Z 4665836.874
LK X 4215184.640 Y 1021692.551 Z 4664261.595

And the adjusted results given by JAG3D are

Thus, JAG3D was able to reproduce the results given in Hofmann-Wellenhof et al, p. 64.

The question is, why it is impossible to transform your original baselines to the baselines derived by coordinates?

/Micha

Are there any comments in the book you mention on the process to obtain the baselines?

Hello,

Are there any comments in the book you mention on the process to obtain the baselines?

No, but as you can see, the baselines are related to the frame of the coordinates.

Today, I realized the relation of your baselines and the coordinates given in local CRS. The resulting network plot looks like that

However, there are still large discrepancies between the baselines and the coordinates. I upload the current project. Please note, this is not a final analysis!

/Micha

It seems to me that the GNSS postprocess software gives baselines as if measuring by sight or a laser. So If a line is projected "east" level to the surface it will continue to elevate with respect to the earth because of its curvature. When it reaches the target point it will be above the original ellipsoidal height. This is why the baseline up value is 600 for PUNT-CASA baseline while the difference in ellipsoidal height is much larger.
Not sure if this is new info for you? How do the other type of baseline work?

Hi,

in an Earth-Fixed Frame, all values are Cartesian. There is no kind of projection.

/Micha

Hi,

if you don't need the height component and the horizontal components of the baseline are already projected, you can also adjust a horizontal network (instead of the spatial network).

/Micha

Do you mean that JAG3D expects baselines as differences in the ECEF system? I think the topography software is giving baselines in a NED o ENU system https://en.wikipedia.org/wiki/Local_tangent_plane_coordinates
Did you consider this in your previous conversions?

I still do not understand if the problem is mismatched concepts between software, a software bug, or bad data. I can produce new data to other goverment CORS or to private poins using a pair of GNSS receptors.

Thanks

The end result we are looking for are lat,long,CRTM05 and ellip height for the new points.

Hi,

I still do not understand if the problem is mismatched concepts between software

Baselines are nothing else the coordinate differences in a specific but known frame, i.e., $\Delta X = X_2 - X_1$. GNSS is refereed to WGS84. So, if you don't use any settings, the raw data are refereed to WGS84. For that reason, RTKLib must support WGS84 out of the box. Your baselines are not refereed to WGS84. You have select some settings to convert the raw WGS84 coordinates to something else.

a software bug

No, because I have tested several examples like this. It works fine. The problem is, that your coordinates are not congruent to your baselines. JAG3D needs congruent data (refereed to the same frame or an congruent frame).

I can produce new data to other goverment CORS or to private poins using a pair of GNSS receptors.

Please provide WGS84 coordinates and baselines (or use at least the same convention for both, the coordinates and the baselines).

/Micha

I have checked Topcon Tools and RTKLib and both use WGS84. There is an option to use a geoid instead of ellipsoid but I am not using that.

I think what we need to do is convert the local ENU baseline to a ECEF baseline.

https://gssc.esa.int/navipedia/index.php/Transformations_between_ECEF_and_ENU_coordinates

I don't see how a topographer would be able to directly produce a ECEF baseline unless they have some commercial software that has this feature and then they would just do the adjustment in the same software. Most open source users would like to enter the ENU baseline they get from RTKLib into JAG3D and have the software take care of the rest.

There seems to be a missing link between JAG3D and RTKLib, which could be fixed in either one and then we would have a complete post process and adjustment solution. Since I can't do this myself what I am trying to do is clarify the process and then see how we can create interest in programmers of either software to make the necessary changes.

Thanks

Hi,

I think what we need to do is convert the local ENU baseline to a ECEF baseline.

Due to the original baseline is referred to ECEF, you should disable the ENU conversion.

I don't see how a topographer would be able to directly produce a ECEF baseline

Each GNSS receiver provides the position in WGS84. Here an example output of my u-blox sensor

The coordinates are given in Lat / Lon / ell. Height and can be simple converted to WGS84 X/Y/Z coordinates. If you observed two points, the baseline is derived by the coordinate differences.

unless they have some commercial software that has this feature

No, that's not right, see the screenshot above.

There seems to be a missing link between JAG3D and RTKLib

No, see e.g. page 14 in the manual: X/Y/Z components in ECEF frame. RTKlib supports ECEF. Just use it.

regards
Micha

I am glad to inform that I finally figured it out.

Is it possible to convert XYZ sigmas to lat-long-ellipH ?

Why are the colums labeled y x z in the tables but one is supposed to enter the values x y z ?

Hej Marcel,

I am glad to inform that I finally figured it out.

Congratulation! Do you change the output format or what is/was the solution?

Is it possible to convert XYZ sigmas to lat-long-ellipH ?

Yes, of course. You can use the propagation of uncertainty or a Monte-Carlo simulation.

Why are the colums labeled y x z in the tables but one is supposed to enter the values x y z ?

In geodesy, usually the east, north and height components are refereed to y, x and z, respectively. In contrast to a mathematical system where the angle of incline is defined counterclockwise, in geodesy, the angle (i.e. the azimuth) is defined clockwise. Since JAG3D is a geodetic adjustment tool, the column heads are labelled by y, x and z.

/Micha