Notifications
Clear all

Trimble Business Center - PPK processing against multiple stations

5 Posts
3 Users
0 Reactions
4 Views
(@rover83)
Posts: 2346
Registered
Topic starter
 

I posted this in the Trimble forums as well, but I know there are a lot of power users here.

Our crews drove a couple of routes last week with a vehicle-mounted receiver in PP kinematic mode, logging continuous points at 1Hz.

I usually process PPK against a single station because in the past I was always working in remote areas and brought my own base to set up close to the project area. However, sometimes it helped to use a weighted mean of multiple solutions if I did have a second receiver to use as another base, and site conditions were not ideal.

We did not have any of our own bases running for these route surveys (not my project nor my decision), but there are three or four state reference stations within acceptable distance for PPK processing.

Processing results from each base station range from good to mediocre. We had some tough canyon areas and foliage to deal with. I would like to merge the processed route data from multiple stations into a weighted solution to get better final coordinates.

 

The problem is that "continuous topo" points are not handled in the same way as a "measured topo" point in TBC - once the first trajectory is processed, the points that came in with the .job or .jxl file are updated to match. Processing against another reference station for the same time window only adds another trajectory to the project, without incorporating that data into a weighted mean for the corresponding points. Project settings are to "compute weighted averages for all sideshots", but my suspicion is that continuous topo points are not treated as sideshots and thus cannot be weighted.

I could certainly process my trajectories as vectors and combine them manually...but there are a few thousand points throughout the project. So that's not happening.

I can run with a single-base solution if I have to, but for a few areas the results will be less than ideal. Not a deal-breaker for this project, but I would like to know if there is a way to combine continuous topo trajectories into a weighted solution for future reference.

Anyone ever done this before? Or if is this even possible?

 

Thanks in advance,

Eric

 

 

 

 
Posted : 05/05/2020 3:37 pm
(@stlsurveyor)
Posts: 2490
Registered
 

Hum, interesting...Not sure, first idea I come up with... Import the job and process holding one CORS station and export points. Re-import and process using another base, export; repeat one more time. You could then average the three values. Not weighted but would help identify really bad points.?ÿ

 
Posted : 05/05/2020 5:26 pm
(@rover83)
Posts: 2346
Registered
Topic starter
 

@stlsurveyor

I really liked this idea. I did start to go that route, until I realized that the autonomous point numbering would not necessarily match up between base stations. For one base station, some epochs would not meet positional tolerances (i.e. no AUTO0001 point generated at that epoch), while another base station session would get a decent position and generate a point.

So, no way to ensure the IDs would match on subsequent import.

I could crank up the positional tolerances for baseline processing but that kind of defeats the purpose of obtaining better values for the points...

This one has me stumped. I was expecting TBC to use all processed data to derive coordinates, like it does for measured topo points. The only difference between the trajectory-derived points and the measured topo points is the number of epochs - and not even that if "measured topo" is set to collect a rapid, single-epoch observation for a point. Functionally, the data are the same, but it does not treat them that way.

 
Posted : 06/05/2020 5:50 am
(@mightymoe)
Posts: 9920
Registered
 

I will process PPK to more than one base, it's a static file so it will adjust it just like any processed static point.

The caveat to the OP is that I don't do it for continuous topo PPK.

I reserve continuous PPK topo for areas where continuous topo PPK is appropriate, open country without any canopy.

Where there are possible obstructions then it's an RTK topo not PPK.?ÿ

Not sure how it will help to reprocess bad PPK points to another base, once lock is lost during a PPK session it needs a new PPK session with a new fix.?ÿ

If the topo is critical, I would re-run it.

 
Posted : 06/05/2020 6:04 am
(@rover83)
Posts: 2346
Registered
Topic starter
 

@mightymoe

I am 100% in agreement that PPK is best used in wide open areas, especially for continuous topo runs. In this case, I inherited this project / data and am looking to extract as much usable information out of it as I can. The idea was to get as much data as we could in the limited time we had available. So, it's not super critical. I am mainly wanting to know if there is something I am missing in TBC.

Obviously, PPK sessions can drift in precision throughout the session. From a processing perspective, continuous topo is just measured topo at a consistent time interval - if measured topo points can be improved by processing against multiple stations, then improving continuous points using the same methodology should not be out of the realm of possibility. (Or even considered poor practice, depending on the situation and goals of the project.)

This is admittedly unorthodox, but for a typical PPK project I wouldn't send crews back to the field when I could bring in another base station or two and tighten up the final positions of points, at least to see if I could meet project specs, before making that decision.

I was hoping that there is a workflow I could use to make that happen with continuous points/trajectories, considering that all of the information to do that is in the project...

 
Posted : 06/05/2020 6:58 am