Versatility with the Kind of BASE to HOLD, and the kind of BASE ROVER to hold.

Nate The Surveyor

Well-Known Member
I want to be able to Change up the BASE SOURCE COORD, any way I please. At any time I please.

I want to be able to set the selection RTK FIXED, or RTPK FIXED, at any time, independent of what I chose to hold for the base coordinate.

WHY do sideshots, contain 1-Local, or 2 Local, when only the BASE needs to address this?

SIDESHOTS can contain the the kind of base they were derived from. BUT they do not need a separate column. Just a little note in the box is sufficient.

Auto
Cors Fix
M-Local
I'm having a bear of a time getting it to do what I want.
20210621-16.06.52_00435_Processed_Point_Info.png

Here we have a screenshot. I cannot select RTK, or PPK, at this screen. I should be able to.
HOW we derive the base coord, in no manner should BLOCK or prevent us from choosing RTK or RTPK (Called PPK above) or CORS column.
Why does it block us?
I think it is a good idea to put a little code, or notification of HOW that base coord was derived, but we don't need to be locked out of the RTK/RTPK Choice, IF one local is used for the base.
IF I go to a job, that HAS an old base station, with SPC already on it, and I use AUTO, and work for a couple of days, then go look up the old coord, and wish to USE M-Local to HOLD the old base coord value, it should NOT penalize me, by excluding me from being able to choose RTK or RTPK.
Thank you,
Nate
 

Nate The Surveyor

Well-Known Member
As an additional concept, what happens, if I save a coord, BEFORE RTPK has finished, (so that there is no RTPK coord), does that shot get DPOS'd? Or, if I store after one iteration of DPOS, but while it's processing the second iteration, (@2 min and a few seconds) the first iteration generated a float, does this allow DPOS to generate a coord?
As an end user, I would like to know what is going on. Possibly an additional collum, for the DPOS value? I've stopped using DPOS, except as a check of my base, if I've got a good SPC. In some situations, (base to rover) with UHF, and very intermittent signal, RTPK is not going to do as well as DPOS.
The trouble with me is:
I will be pushing the edges of what's possible, and I don't know how to stop!
Thank you,
Nate
 

Matt Johnson

Well-Known Member
5PLS
Nate, this screen has been my nemesis for a long time and I have complained a lot about it. There was suppose to be a button added at the bottom of the M-Local column to indicate the solution type.

Option A

upload_2017-8-18_13-42-12.png


My opinion has always been that it should be implemented like this:

Option B

PROCESSED-POINT-INFO-SCREEN_Proposed.png
PROCESSED-POINT-INFO-SCREEN_Proposed2.png


So that all base coordinate possibilities are shown in one screen and then RTK vectors are shown in another.

If anyone has opinions about which option, Option A or Option B, you prefer more please voice your comments.
 

Nate The Surveyor

Well-Known Member
What set me off, was I had a bunch of field work, that I had carefully analyzed, and picked the rtk, or RTPK coord. There was a "beyond good" difference between these. I had multiple shots on these points.
I DPOS'd it. And it messed up all my selection, or RTK vs RTPK. On my acad screen, I had a bunch of outliers.
I think it selected RTPK for all of it.

There are 5 different kinds of rover coords.

Rtk
RTPK
DPOS
Rtn
Cors-rover

While working in the field, we would like have a checkbox, "needs attention".
And, the ability to review only those with the checkbox checked. This could be significant, where signals are weak. I can see using a Rtn coord in the field, but later wanting to see what RTPK does. This checkbox should be on the collect, and stake collect screen. And, it should be able to turn off, in the rover review screen, after resolving.

There are 4 kinds of base points.
1.) Known, (previous work)
2.) Rtn, (probably gets copied and put into one above)
3.) Reverse shift, off a known point.
4.) Standalone
5.) DPOS

I don't know of any others. But if we are going to revise this portion of the software, we should try to get it all included.

I think 2 above is better, @Matt Johnson.
But I don't want to later find I needed another collum, or data field.
I'm a grunt, a field hand. Not a developer. I don't know how much work my ideas/requests are. That's not my area of knowledge.
Again, thank all of you for your input, all the team javad people. You are doing a good job.
Nate
 

Nate The Surveyor

Well-Known Member
@ A.Lacey
I think
Its if you have started your job with autonomous on base, and the point is based off autonomous base.
RTPK in the field could be similar now though, so essentially, the software is out of date.
I think
Nate
 

Matt Johnson

Well-Known Member
5PLS
In B why is the rtk in standalone and not shifted with the base?
This label is the same that exists now and indicates if the RTK solution is a fixed, float or autonomous solution. It can be autonomous when the river does not receive corrections.
 

Matt Johnson

Well-Known Member
5PLS
There are 5 different kinds of rover coords.

Rtk
RTPK
DPOS
Rtn
Cors-rover
RTN is a type of RTK solution so it falls under this column.

DPOS and RTPK are basically the same as they both use Justin post-processing engine. I believe that both coordinates do not currently coexist in the database.

There are 4 kinds of base points.
1.) Known, (previous work)
2.) Rtn, (probably gets copied and put into one above)
3.) Reverse shift, off a known point.
4.) Standalone
5.) DPOS

For the base point selection there are only options needed:
  1. The base coordinate the base broadcasts when it is started. This can be known or unknown. With a RTN it is always known.
  2. The DPOS adjusted base coordinate.
  3. The M-Local/Reverse Shift coordinate

 

Nate The Surveyor

Well-Known Member
If you decide to change the "Known value", (a few hundredths away), then it looks like the first screen shot in this thread. And the user cannot select rtk/ppk.
 

Matt Johnson

Well-Known Member
5PLS
If you decide to change the "Known value", (a few hundredths away), then it looks like the first screen shot in this thread. And the user cannot select rtk/ppk.

Yes the issue is understood. The developers proposed what I labeled Option A a long time ago but somehow this was never implemented. My preference is what I came up with in Option B.
 

Nate The Surveyor

Well-Known Member
Nate, this screen has been my nemesis for a long time and I have complained a lot about it. There was suppose to be a button added at the bottom of the M-Local column to indicate the solution type.

Option A



My opinion has always been that it should be implemented like this:

Option B



So that all base coordinate possibilities are shown in one screen and then RTK vectors are shown in another.

If anyone has opinions about which option, Option A or Option B, you prefer more please voice your comments.

This needs further attention.
Go with option b.
It's a handicap to stay with a.
Thank you,
Nate
 

Nate The Surveyor

Well-Known Member
I pretty well think ALL surveyors agree, "b" is best.
I've talked with some surveyors who avoid using "assign value", for this very reason.
Question: how much work is it, to change to "b"?
Thank you,
Nate
 

Nate The Surveyor

Well-Known Member
Just curious. Is this change difficult?
Does it require a change in the database?
We really need this ability to select coord source, to be available. Regardless of how the base is derived.
What are we talking about, time and labor wise?
Thanks,
Nate
 
Top