dpos report question

[Duane Frymire]

On the dpos report "# fixed amb:" it tells me "yes" I'm assuming this is similar to opus reports except automatically telling me if a certain percentage has been reached (opus recommends >50%). Is that the case, and what is your percentage cutoff when it would change to "no"?

On the dpos report there is a "Geometry factor:" What does that number represent and what number should I look for in a reliable solution? The one in front of me says 0.9

On my current comparison with an opus report the opus solution uses only 53% of observations, while dpos uses 99% of observations. opus uses 3 stations instead of dpos 5 stations (the same 3 plus 2 more), and dpos uses glonass as well as gps. There are 63% more observations looked at in the dpos solution. Horizontal solutions agree within 0.001, vertical within 0.010 (but opus 12b v. dpos 12a). I'm processing over 48 hours from time of session and opus is using rapid ephemeris, dpos still using broadcast. The end result are the peak to peak errors in the opus report barely meet recommended (0.05 horiz., 0.08 vert.) but are within total rms recommended (<0.03) at 0.024. The dpos results peak to peak 0.004 horiz. and vert., and total rms 0.007. It appears that opus is throwing out observations it deems questionable and including that in the error report, while dpos is using almost all observations and giving a less conservative error estimate. As with my first two questions, I'm just wondering how to explain the different rms estimates, why they might be different, and what threshold rms to look for in dpos. Would it be the same <0.03 recommended by opus? Or, given the differing results, would it be something less than that?

Thanks for any help with this.
Duane

 

[Matt Johnson]

The geometry factor is the dilution of precision (DOP), a value less that 2 is good. I would not trust a solution with a RMS greater than 3 cm. There will be some differences between the OPUS and DPOS solutions as different processing engines and possibly base stations are used. DPOS also processes with GLONNASS, OPUS is still GPS only.

I'm not sure why the number of fixed ambiguities isn't being reported. I will see if this can be fixed.

 

[Alexey Razumovsky]

DPOS engine uses so-called 'partial solution' for fixing ambiguities. It means engine try to fix about 15-20 'best' ambiguities first. Then on the base of 15-20 integer values engine recalculates all other float ambiguities and get final integer solution. In this case there no reason in quantity of fixed ambiguities because it depends mostly on internal engine settings and less of measurements quality. Yes/No on the DPOS report indicates fixed or float solution.
DPOS uses more CORS station than OPUS because DPOS knows less about CORS data quality. We've investigated that 5 station bring relable solution in all cases. New web DPOS inteface will offer a choice of CORS stations from a list (one or more stations).

 

[Matt Johnson]

Alexey are there plans to use rapid and precise ephemeris?

 

[Alexey Razumovsky]

Alexey are there plans to use rapid and precise ephemeris?

I have no these plans at the moment. I am still waiting for new web UI to expand our testing area. In the mean time rapid ephemeris looks attractive for the our service. I'd like to process compound rover/base jps file that deals instant solution. I am not going to develope OPUS similar product.

 

[Shawn Billings]

Alexey,
I have a customer that will be using the LS worldwide (I don't know what countries specifically). Is it possible to process positions in other countries using IGS stations? Thank you.

Edit: Using LS and Triumph1M as base

 

[Alexey Razumovsky]

Alexey,
I have a customer that will be using the LS worldwide (I don't know what countries specifically). Is it possible to process positions in other countries using IGS stations? Thank you.

Edit: Using LS and Triumph1M as base

Hi Shawn, the answer is clear. With free DPOS - no, with Justin - yes.

 

[Shawn Billings]

Is it planned to make DPOS worldwide?

 

[Alexey Razumovsky]

DPOS service runs under CORS. I know nothing about NGS plans. I'd like to emphasize once more that actual DPOS ability to post-process compound jps files solve most of problems of couple (TLS rover - T2 base , e.t.c.) JAVAD receivers users.

 

[Shawn Billings]

I'm specifically looking for the ability to resolve the reference station location to ITRF. We do this with DPOS and CORS. IGS collects data all over the world. I'm wondering if we can use this data to expand the usefulness of DPOS.

 

[Duane Frymire]

Thanks for all the replies.
All of NY rtn now glonass & gps. Based on the above explanation I should be able to get good reliable positions faster using dpos than opus. Will experiment.

 

[Matt Johnson]

DPOS engine uses so-called 'partial solution' for fixing ambiguities. It means engine try to fix about 15-20 'best' ambiguities first. Then on the base of 15-20 integer values engine recalculates all other float ambiguities and get final integer solution. In this case there no reason in quantity of fixed ambiguities because it depends mostly on internal engine settings and less of measurements quality. Yes/No on the DPOS report indicates fixed or float solution.
DPOS uses more CORS station than OPUS because DPOS knows less about CORS data quality. We've investigated that 5 station bring relable solution in all cases. New web DPOS inteface will offer a choice of CORS stations from a list (one or more stations).

Alexey, since we aren't reporting the number of fixed ambiguities maybe just change "# FIXED AMB" to "FIXED AMB" in the report. Also what do you think about automatically having DPOS reprocessing in float mode if the RMS exceeds some threshold?

 

[Alexey Razumovsky]

I'm specifically looking for the ability to resolve the reference station location to ITRF. We do this with DPOS and CORS. IGS collects data all over the world. I'm wondering if we can use this data to expand the usefulness of DPOS.

My opinion is DPOS with CORS deals coordinates othewise DPOS deals postprocessing solution.

 

[Alexey Razumovsky]

Alexey, since we aren't reporting the number of fixed ambiguities maybe just change "# FIXED AMB" to "FIXED AMB" in the report. Also what do you think about automatically having DPOS reprocessing in float mode if the RMS exceeds some threshold?

Agree to change to "FIXED AMB". RMS comes from network adjustment. It has no relation ambiguity searching. Discrepancy in reference point positions often affects to RMS more than solution accuracy. DPOS client should select CORS station himself. In this case one will appreciate RMS in advance.

 

[Matt Johnson]

RMS comes from network adjustment. It has no relation ambiguity searching. Discrepancy in reference point positions often affects to RMS more than solution accuracy. DPOS client should select CORS station himself. In this case one will appreciate RMS in advance.

My concern is that the reported RMS values always seem overly optimistic. How is it calculated? When I calculate it how I assume it would be calculated I get a much higher value:

Here I created a spreadsheet with reported DPOS solution in row 2 and the solutions from the CORS stations in rows 3 through 7. In column E,F and G I am showing the delta between the Solution and each CORS station. In column H I calculate the 3D delta and then in column I, I square that value. Row 9 shows the average 3D_Delta^2 and then I take the square root of that value in row 10 for what would be the RMS. The DPOS solution reports an OVERALL RMS of 0.147 where I come up with 0.447 meters.

I have attached my spreadsheet and DPOS report.

 

[Alexey Razumovsky]

My concern is that the reported RMS values always seem overly optimistic. How is it calculated? When I calculate it how I assume it would be calculated I get a much higher value:

View attachment 3405

Here I created a spreadsheet with reported DPOS solution in row 2 and the solutions from the CORS stations in rows 3 through 7. In column E,F and G I am showing the delta between the Solution and each CORS station. In column H I calculate the 3D delta and then in column I, I square that value. Row 9 shows the average 3D_Delta^2 and then I take the square root of that value in row 10 for what would be the RMS. The DPOS solution reports an OVERALL RMS of 0.147 where I come up with 0.447 meters.

I have attached my spreadsheet and DPOS report.

Matt, you are right! It is not RMS but integrated Sigma from adjustment. Strictly say it is not correct to calculate RMS of rover position based on 3-5 entries (reference CORS stations quantity in adjustment). So we put down on a report a value that equals : sqrt(sqr(SigmaX) + sqr(SigmaY) + sqr(SigmaZ)), where SigmaX, SigmaY, SigmaZ are diagonal elements of covariance matrix. To my mind we are right too. Isn't it?

 

[Matt Johnson]

Do you know if that is how OPUS calculates the Overall RMS too? Since the DPOS report is formatted similar to the OPUS reports I think we would want to be calculating the values in the same way.

To me knowing the "residuals of position determined by individual baselines from the final position" is much more useful. This is shown in OPUS RS extended reports:

Could this be added to the DPOS reports? If it is, I would also suggest displaying the average residuals for all the stations combined.

Also in the DPOS reports how are the accuracies reported to the right of the coordinates calculated? OPUS accuracies are reported as either peak-to-peak errors (static) or standard deviation estimates (rapid static).

 

[Alexey Razumovsky]

Do you know if that is how OPUS calculates the Overall RMS too? Since the DPOS report is formatted similar to the OPUS reports I think we would want to be calculating the values in the same way.

To me knowing the "residuals of position determined by individual baselines from the final position" is much more useful. This is shown in OPUS RS extended reports:

View attachment 3412

Could this be added to the DPOS reports? If it is, I would also suggest displaying the average residuals for all the stations combined.

Also in the DPOS reports how are the accuracies reported to the right of the coordinates calculated? OPUS accuracies are reported as either peak-to-peak errors (static) or standard deviation estimates (rapid static).

1. Unfortunately I do not know how OPUS calculates Overall RMS.
2. "residuals of position.. " are the most important statistics. I might to add above mentioned table to the report. Can't say the same about averaged residuals.
3. To right of the coordinates are sigmas (site covariance matrix from adjustment).
I do not see reasons to run competion with OPUS. If somebody wants more statistics he can submit data to OPUS.
There is "JAVAD TR_LS2-JAVAD TRIUMPH2" solution report at the end of your DPOS report. This part of DPOS report is available instantly in the field during survey session. I expect it prompts surveyor how much time to stay at the point.

 

[topoagrime]

olá, permita-me entrar no diálogo, também tenho interesse, sou do Brasil e aqui o relatório tem que ser emitido com sigma separado, isso já está em Javad Mobile Tools?