RTK & RTPK

briarcutter

Member
once back at the office and analyzing the collected data and I have multiple RTK/RTPK shots taken on a single point. Is there a way to store the RTPK coordinate without overwriting the RTK ?
say ... 1001=rtk and 1001-A=rtpk
 

Shawn Billings - Javad

Active Member
JAVAD GNSS
Not directly. Probably the only way to do it would be to select the RTK solution, export as ASCII, then switch to the RTPK solution and export as ASCII. I know that's not as clean as what you'd like to do, but that's the only way I can think of to do it.
 

briarcutter

Member
can an option be added at the screen that ask "do you want to overwrite the rtk value" and instead ask "do you want to STORE the rtpk value to another number" ?
 

Clay Davidson

Active Member
It would be nice to have the option to store them separately.

The work around I use, once I have a point stored with rtk and rtk. I go into the collect screen and offest points. Then offset the point N 0 deg. E, 0 ft. Then store. Then go to points and switch the point over to rtpk.

I wish it just stored the different solutions separately. Using the next point number. Or had an option in rtpk setup to do so.

It would make our cluster average points more accurate.
 

Shawn Billings - Javad

Active Member
JAVAD GNSS
It would be nice to have the option to store them separately.

The work around I use, once I have a point stored with rtk and rtk. I go into the collect screen and offest points. Then offset the point N 0 deg. E, 0 ft. Then store. Then go to points and switch the point over to rtpk.

I wish it just stored the different solutions separately. Using the next point number. Or had an option in rtpk setup to do so.

It would make our cluster average points more accurate.
That's an even better workable solution than what I suggested, Clay. The offset point should keep the statistics of the anchor point... Good idea. Still not as elegant as your requested feature, but a good workaround.
 

Clay Davidson

Active Member
That's an even better workable solution than what I suggested, Clay. The offset point should keep the statistics of the anchor point... Good idea. Still not as elegant as your requested feature, but a good workaround.
I can't take credit for the work around. Mathew Sibole told me about it.

It works well for those points that take a lot of time. However I wouldn't want to do that procedure on all points collected, LOL.
 

Sean Joyce

Well-Known Member
Some ideas about a few things I would like to see;

1. I just finished a job on which I had 3 sessions on the same base point totalling 14 hours on the same base.
After DPOS processing the first base point I hold that point for the subsequent sideshots for the rest of the job.
I would like to be able to process just the base points through DPOS THROUGH THE LS without shifting the sideshots and EASILY wrap them into an average base point to store with the project.

2. I would like to be able to store the RTK value and the RTPK value for a point and possibly average them together without going through the procedures discussed above.
(In the past I have hand entered the RTPK value in manually to create a new point to average)
In order to make a separate point of the RTPK could we make a setting in the points screen that would apply a prefix to the RTPK to distinguish and store that point separately?Maybe have a third designation for the points "Survey" "Design" "RTPK" or some other way to organize the points so they can be averaged together.
 

Wes Hand

Active Member
Sean you can do that in the LS but after the Dpos processing of the 3 sessions you would need to cluster average those 3 base sessions. Be careful not to average them as the same name of any of the base session names. Once you get that cluster average you should be able to use mlocal to shift each base session and their associated points to the averaged value. You would have to select each base session and shift to the averaged value. Personally I get lost and sometimes confused using the shift and don’t like having to do this because I lose my ability to see the rtk and rtpk comparisons. Of course I could be doing this wrong.

You could also download each base session file to your desktop and go to app.javad.com and submit it for processing there. Do your average manually and key that value back into the LS as a design point and you can then do the shifts to this value. Regardless I do not like doing a shift. I prefer to get my base position nailed down via an RTN. Again I may be making this more difficult than it should be but this is how I have done it.
 

Shawn Billings - Javad

Active Member
JAVAD GNSS
I think you explained it well, Wes. It would be handy if this could be somehow automated. But the processes exist to use multiple DPOS solutions in a highly refined sort of way (weighted averages).
 

Sean Joyce

Well-Known Member
Wes;
Thanks, that clever procedure will get the job done but we need a much simpler way. I don't want to get into mlocal and shifts (unless there is a good reason for it).
Currently manually entering coordinates to create an additional point which I do is another step where an error can be made.
I use the DPOS app but my point is we need to do this from the L.S. for a base point only and get the results in feet without a shift being performed.
Would have to be able to pick the raw data for the base point only (minus the attached sideshots)
Most times my base coords only vary by a hundreths so using the first processed base is not a big problem, but 16 hours i.e over various times and days makes for sound base position to be able to archive or to have for subsequent longer term large construction projects after the initial surveys.


My second point on the wish list; there is a coordinate field in the L.S. that contains the RTPK value.
We need an easy way to be able to distinguish, store and use that as a separate point. i.e (point # 1 PREFIX "RTPK1 COORD COORD HEIGHT)
I am not a programmer but it seems that this should be able to be done.
 

Clay Davidson

Active Member
Wes;
Thanks, that clever procedure will get the job done but we need a much simpler way. I don't want to get into mlocal and shifts (unless there is a good reason for it).
Currently manually entering coordinates to create an additional point which I do is another step where an error can be made.
I use the DPOS app but my point is we need to do this from the L.S. for a base point only and get the results in feet without a shift being performed.
Would have to be able to pick the raw data for the base point only (minus the attached sideshots)
Most times my base coords only vary by a hundreths so using the first processed base is not a big problem, but 16 hours i.e over various times and days makes for sound base position to be able to archive or to have for subsequent longer term large construction projects after the initial surveys.


My second point on the wish list; there is a coordinate field in the L.S. that contains the RTPK value.
We need an easy way to be able to distinguish, store and use that as a separate point. i.e (point # 1 PREFIX "RTPK1 COORD COORD HEIGHT)
I am not a programmer but it seems that this should be able to be done.
I agree. Would nice to have the option to store the points separately. RTK prefix and RTPK prefix in the descriptions or option to store in separate pages. Something would be nice. There's just valuable data setting there not being used.
 

Shawn Billings - Javad

Active Member
JAVAD GNSS
Before this becomes a feature request, I'd like to know why you want to have both solutions stored as separate points. If I understand the need correctly, it seems like it would be better to have the option to combine the solutions for the point's final coordinate (a weighted average). Maybe I'm missing some benefit to having two coordinate points for the same point from the same observation, but I think you may as well look at what you're planning to do with those two points and get the software to do that instead of getting you half-way there.
 

nusouthsc

Active Member
Before this becomes a feature request, I'd like to know why you want to have both solutions stored as separate points. If I understand the need correctly, it seems like it would be better to have the option to combine the solutions for the point's final coordinate (a weighted average). Maybe I'm missing some benefit to having two coordinate points for the same point from the same observation, but I think you may as well look at what you're planning to do with those two points and get the software to do that instead of getting you half-way there.
I’m with you Shawn. It seems an average between the 2 would be most useful. But I would love to hear a workflow that utilizes independent solutions.
 

Clay Davidson

Active Member
Before this becomes a feature request, I'd like to know why you want to have both solutions stored as separate points. If I understand the need correctly, it seems like it would be better to have the option to combine the solutions for the point's final coordinate (a weighted average). Maybe I'm missing some benefit to having two coordinate points for the same point from the same observation, but I think you may as well look at what you're planning to do with those two points and get the software to do that instead of getting you half-way there.
For me its helps my cluster average on hard shots in the woods. Sometimes my entire project. Then that helps my relative accuracy that my state board requires. +/- .05 + 100 ppm.

I have my rtpk set to 15 min because if it is set to 5 min and it does more than one that don't agree it doesn't store a rtpk. Sometimes I have to use several rtpk shot to get my tolerance down.

I usually do a quick check via the map screen and that gives me an idea of my accuracies but when points are tied together I can't see the closest average. I can see rtk or rtpk but not both or how they relate to other points rtk or rtpk. There are to many combinations that the LS simply does not show because the two different solutions are not separated.

My point is they are two different solutions. Why does the LS treat them as 1 point. I see them as two different solutions that are currently ties together and you're not getting the full benefit of them.

I hope I have explained toughly. Please respond if I haven't.

Thanks,

Clay
 

Sean Joyce

Well-Known Member
Before this becomes a feature request, I'd like to know why you want to have both solutions stored as separate points. If I understand the need correctly, it seems like it would be better to have the option to combine the solutions for the point's final coordinate (a weighted average). Maybe I'm missing some benefit to having two coordinate points for the same point from the same observation, but I think you may as well look at what you're planning to do with those two points and get the software to do that instead of getting you half-way there.
If there are 2 solutions available why not have them to use for the reasons I stated (averaging or using the RTPK solution because it works better for the task at hand) or others.
Also would like to see the base station only processing through DPOS from the L.S.
 

Shawn Billings - Javad

Active Member
JAVAD GNSS
If there are 2 solutions available why not have them to use for the reasons I stated (averaging or using the RTPK solution because it works better for the task at hand) or others.
My point is, if you know what you ultimately want to do with the two solutions (average them), then why not just make the application perform the average instead of creating two points out of one. If you only want to use RTPK, you can select that solution with the current software interface.

Also would like to see the base station only processing through DPOS from the L.S.
Can you explain this a little more? I don't understand what you're asking for.
 

Sean Joyce

Well-Known Member
My point is, if you know what you ultimately want to do with the two solutions (average them), then why not just make the application perform the average instead of creating two points out of one. If you only want to use RTPK, you can select that solution with the current software interface.


Can you explain this a little more? I don't understand what you're asking for.
send in base only raw files through the L.S. without having to download the file and use the DPOS app on a computer.
There is currently no choice under DPOS settings on the L.S. to process just the base session without sideshots
AND not automatically shift the points after processing.
The RTK vs RTPK is all about keystrokes and the procedure we have to go through now to create a separate point for RTPK.
It is not just about averaging. The solution is in a data field now why not just be able to separate it out.
Switching back and forth in the points screen between RTPK and RTK takes too many keystrokes.
 
Top