David Held
New Member
When creating a direct offset point with a compass bearing and distance, will the offset shot be appropriately adjusted if DPOS is utilized for the "anchor" point?
offset shots with PPK
- Thread starter David Held
- Start date
No. It is not. The offset shot only translates relative to the Base translation for the CORS solution. It does not yet translate based on the anchor point translation. Very good question.
Nate The Surveyor
Well-Known Member
Wait a minute...
I was told it DID update, if you go through offset, but NOT if you go through cogo.
I can find a source for that latet, at my desktop.
I was told it DID update, if you go through offset, but NOT if you go through cogo.
I can find a source for that latet, at my desktop.
The position of the offset point will change if the base point changes (Autonomous to CORS). It will not change between RTK and PPK for the anchor point.
David Held
New Member
So in simple terms, the only way to have a good offset point is to have a good verified RTK shot for the anchor point?
Yes. I have in the past used the RTK position to inverse to my offset point, then recompute the offset point holding the PPK position. It's cumbersome, but works. If you think you need to use the PPK solution, probably better to book it and enter it in after processing.
Nate The Surveyor
Well-Known Member
Ok, so were talking rtk vs ppk position.
Got it.
Offset shots, from gps shots, are strictly based on rtk solutions, and, they do NOT update to be FROM ppk solutions. If and when ppk is held, instead of ppk.
(ppk = static) this could amount to significant difference.
Thanks
N
Got it.
Offset shots, from gps shots, are strictly based on rtk solutions, and, they do NOT update to be FROM ppk solutions. If and when ppk is held, instead of ppk.
(ppk = static) this could amount to significant difference.
Thanks
N
Steve Douty
Well-Known Member
WOW! This is a horrable and dangerous way to process the data. Warnings should be posted in bold print everywhere.
Danger Will Robenson!!!
Here is one user that calls this a programing flaw and request a software update/fix.
Danger Will Robenson!!!
Here is one user that calls this a programing flaw and request a software update/fix.
Darren Clemons
Well-Known Member
Agree completely Steve! I’ve complained about this process since it’s inception. The offset function, and as Nate mentions above, when used by selecting the offset whitebox and not by using COGO, is a wonderful feature but is extremely dangerous.
The problem, in my opinion, is how the LS handles the offset point. For a very, very long time it 100% stored that point in design points NOT survey points. I believe that it now puts it in survey points IF you are in the collect screen, then select offset by clicking the whitebox and collecting that way. It seems though, I’ve seen it put in in design sometimes and survey other times, I am probably mistaken there. The basic is though, keep a very close check on these, write down your bearing and distance and check in computer after all processing has been done.
There were two sides arguing that that stored point created from the anchor points was a design point instead of a survey point. If it’s my intent to store it in the field while I’m surveying, it’s a survey point! On that note, I’ve always wished and wanted to be able to simply “select” an option when I creat ANY point in the field to store it in survey points in order to eliminate most all of the problems we have with Dpos and moving them.
If I shoot two pins, then calculate a new pin to set online between those two, it’s a design point. If I go back to office, apply Dpos and translate survey points, that point, and any/all others created like it do NOT move.
Those calculated points, stored as a design points, CAN be shifted correctly after Dpos by using the move function, selecting them from design points list, selecting the base number they were shot from and applying....way, way too much trouble to move points that should 100% be translated automatically in correlation with the Dpos translation.
I understand that in the Javad equipment world, a “design” point is not the same as a “survey” point and it seems to several to be sinful to make one the other, but exactly what, if any, would be the issue if I could delineate those created points as survey points? Would they have any geodetic data? No. Would they have correct elevations? No. I am not concerned about any of that on these certain kinds of points, all I want and am concerned about is the coordinate.
Would they have the correct northing, easting, bearing and distance in relation to all other shots on my survey? Yes.
Would they automatically be translated when I ran Dpos? Yes. Would they be a correct coordinate to connect to in Cad when I import my text file? Yes.
Of course, on points like this, we always collect a final RTK, fully verified session after setting the calculated corner for a check and store shot, which will be a few hundredths from the design point, but in cad, the design point is the one I want......if the line is say, N-22-30-45-E and I calculate and set pins in that line and use the “shot” points my bearings will all be a tad bit different - just a few seconds, but different. In most every good sized job we’ll have 5 or 10 points like this that, as of now, always have to be remembered to be selected in the move function and translated using the Dpos session and point number. Just not sure I see why we, as the user, couldn’t decide ourselves where we want those points to go. It would certainly eliminate a lot of potential errors and confusion.
Darren those are good thoughts but a bit off topic.
1. All offset point observed from the collect screen should produce Survey Points, never design points.
2. If you want your calculated CoGo points to move with DPOS automatically, I recommend using Offset in Collect instead of CoGo. This way the resulting points are Survey points and not Design points. As far as I know every CoGo method for creating a point is also available in the Offset options as well.
1. All offset point observed from the collect screen should produce Survey Points, never design points.
2. If you want your calculated CoGo points to move with DPOS automatically, I recommend using Offset in Collect instead of CoGo. This way the resulting points are Survey points and not Design points. As far as I know every CoGo method for creating a point is also available in the Offset options as well.
Darren Clemons
Well-Known Member
Hmmm....didn’t know that. So, I “could” go into offset through the collect screen, create my calculated point between two recently collected pins in COGO and it will store it in survey points?
Sorry for getting off topic....my thoughts rarely stay on a topic very long....discussion was about moving/shifting and well, I just took off on a tangent
I may have missed your train of thought, but CoGo is a different part of the software from Offsets. So you would not create the point in CoGo you would create it in Offset and then it will be a survey point. You can use Brg-Brg, Dist-Dist, and Direct in Offset just like you can in CoGo, so you don't give up anything. The only complication is that you can't select your anchor points from a list or from Map, you'll need to know the point name. Use the long press for the anchor point which allows you to key in the name. Hopefully we can get that changed so that long press gives the point recall screen where you have the option for Map, List, Manual and Survey, but until then, you'll need to know the point name.
No worries about getting off tangent, you've brought up a good topic. I just don't want to see your points and points made above get lost in translation.
No worries about getting off tangent, you've brought up a good topic. I just don't want to see your points and points made above get lost in translation.
Darren Clemons
Well-Known Member
Gotcha. I see where you’re at now. I would’ve never thought of that! There a so many different ways to skin every cat in Jfield, it really is amazing!!
I’ll give that a try next time the situation presents itself and see how it works.
Thanks for the tip.
I’ll give that a try next time the situation presents itself and see how it works.
Thanks for the tip.
Nate The Surveyor
Well-Known Member
Ya know. We asked to be able to do STATIC along with RTK. They named it "wrong" (PPK) but, they did it.
We asked for the ability to do offset shots. They did it.
Fact is, we did not think of the fact that some subroutines would have to be written, to store offset data, and then attach it to BOTH the RTK and the PPK data sets. Yes, some of us did not see it coming. But, hey, AT LEAST THEY ARE LISTENING, and writing stuff we ask for.
Try that with any other company.
Thanks Mr. Ashjaee.
I pretty well agree that this should be fixed, but, HEY, when I see that think clicking away, in IMPOSSIBLE-VILLE, I just grin all over.
If Javad quits making and maintaining GPS... maybe I'll become a plumber, or drive the county road grader.
Happy weekend to all.
Nate
We asked for the ability to do offset shots. They did it.
Fact is, we did not think of the fact that some subroutines would have to be written, to store offset data, and then attach it to BOTH the RTK and the PPK data sets. Yes, some of us did not see it coming. But, hey, AT LEAST THEY ARE LISTENING, and writing stuff we ask for.
Try that with any other company.
Thanks Mr. Ashjaee.
I pretty well agree that this should be fixed, but, HEY, when I see that think clicking away, in IMPOSSIBLE-VILLE, I just grin all over.
If Javad quits making and maintaining GPS... maybe I'll become a plumber, or drive the county road grader.
Happy weekend to all.
Nate
Nate The Surveyor
Well-Known Member
While we are discussing offset shots, is there a way to enter all the offset shots, WHILE it's shooting the "anchor point"?
Since it's obvious that OFFSET shots from PPK will need to be done, can we include the ability to ENTER the offset shots, while observing the anchor point?
And, MULTIPLE offset shots from the same anchor point would be appropriate too. Sitting on a point for 20 mins, doing nothing, then having to enter the shots is not field efficient.
thanks.
N
Since it's obvious that OFFSET shots from PPK will need to be done, can we include the ability to ENTER the offset shots, while observing the anchor point?
And, MULTIPLE offset shots from the same anchor point would be appropriate too. Sitting on a point for 20 mins, doing nothing, then having to enter the shots is not field efficient.
thanks.
N
Steve Douty
Well-Known Member
Well said Nate.
If you select from list button in the top right corner of the screen you can select points from the list:
That's good, of course you still need to know the point name (number). I'm more familiar with Direct Offset. It doesn't have any option other than long press for keyboard or by survey.
David Held
New Member
I mostly use the direct offset routine to shoot trees, utility poles and things of that nature. I'll also use direct offset for building corners if they don't have to be super precise locations. The resection offset routine can give a very precise location and would be suitable for boundary monuments if you can directly occupy them for whatever reason.