A Javad dream place.

[Nate The Surveyor]

Post your dreams here. Keep them honestly related to what you see as possible.
ie, no mechanical impossibilities.

Here, I'll start.

1.) My dream for the Javad LS is:
That it has a visible red laser line, to simply put line on the for forest floor.
Something like this, built in:
http://www.tjsolution.com/products/Laser guidelight/Main laser guidelight_LD series.html
This would be super handy for setting a corner. Set the LS up in the clear, aim it back in the woods, at the correct angle, and it tells you "ahead 8.22'" Set the GPS up carefully, measure with the box tape, with visible line of the forest floor. Set temporary dimple, and move the LS up, to the dimple, and press START.
This would get you very close, for the FIRST observation.
-------------------------------------------------------------------------------------------------------
2.) Distance Distance intersection, in stake out.
I actually did this yesterday, in the field. I needed a D/D intersection, to HUNT for a corner.
I used Stake Point, in conjunction with "Dist to last" to perform a D/D int. It got me within a few tenths, and the Shonstedt revealed the buried corner. Which, I then dug up, and observed.

So, we could add a white button, that takes you to a screen that says Double Point Stake.

Enter the two points to be staked, and it now gives you a up to date:
Azimuth, Bearing, and dist to 2 points at the same time.
This would allow a quasi B/B int to be used too.
It would just be a handy search tool.
Of course, we could do this sequentially, ie, Stake one, then the other... but, hey doing them together is faster!
--------------------------------------------------------------------------------------------------
3.) I'd like the Dist to Last button to display the Bearing and distance to the hundredth, to the last 5 shots, (If there is room, make that 10 shots) when pressed.

So, if you were collecting a couple of shots on the SAME point, it would look like this, AFTER pushing that button:

89 to 90 N 14°28'13" W 0.025' UP 0.05'
90 to 91 S 86°15' 24" E 0.085' UP 0.08'
91 to 92 N 16°12' 02" E 0.042' Dn 0.02'
92 to 93 S 61°48' 49" W 0.13' UP 0.22'
93 to 94 N 49°23' 26" E 0.086' UP 0.16'

THEN, at this screen, one more button allows us to LOOK AT CLUSTER graphically, and to scale. This way, we can quickly observe shot spread, in the field.
THEN one more button, that allows you to MAKE CLUSTER AVERAGE of just that cluster.
ALSO, if you press LOOK AT CLUSTER, then it will include previous shots, that are within the cluster limits. And, there is a button to UPDATE CLUSTER AVERAGE. So, now you can modify the previous cluster point.

Now, you can write that point number down, on your field cheat sheet, and use it for further computations.
ALSO the above would allow you to REVIEW a series of TOPO shots through the woods, to see that things looked right, before moving on.
------------------------------------------------------------------------------------------------------------
OK, maybe I have kicked off this "Javad Dreams" thread. Hopefully it will generate fodder, for the programming team.

Thank you!

Nate

 

[David M. Simolo]

Good stuff Nate.

 

[Matthew D. Sibole]

Nate, distance distance intersect can already be done in the collect screen or stake screen in real time.

I shoot one of the corners that I know that connects to the one that you don't know where it it yet. Then use the PDelta white box to enter the shot or point number of the other point that you know. You can then see the real time distance to both points and move to the required distances to both. I do this all the time and it works really well.

 

[Nate The Surveyor]

Matthew, I'll have to figure that out.

N

 

[Nate The Surveyor]

Item 3 above would serve to let the user know when he had reached the confidence and accuracy level he really needed. WHILE in the field, on the point.
N

 

[Vladimir Prasolov]

Item 3 above would serve to let the user know when he had reached the confidence and accuracy level he really needed. WHILE in the field, on the point.
N

Hi Nate,
We are discussing the implementation of that "real-time" clustering feature.

 

[Vladimir Prasolov]

Hi Nate,
We would suggest the following UI logic for new Interactive Clustering screen.
a) Clicking on white box "Distance to Last" will call new COGO Cluster screen. It synergies Michael's Cluster screen and COGO Average screen.
b) On that screen user has to select first point of the clustering sequence. Last point will be selected automatically as last surveyed point.
c) Also clustering threshold could be changed. Default value will be 0.1m.
d) All point from first to last are processed chronologically. The table shows point pairs with relative bearing, distance and vertical shifts. The pairs with rejected points are colored in red.
e) Rejection is based on distance from median point is bigger than threshold value.
f) Average point is reset when first point is changed. So it will be updated when last point is changed.
g) The description contains list of accepted points.
h) Map point allows review cluster graphically.

 

[Nate The Surveyor]

I will be thinking it through. Thanks for your response. Reply later.

 

[Matt Johnson]

-------------------------------------------------------------------------------------------------------
2.) Distance Distance intersection, in stake out.
I actually did this yesterday, in the field. I needed a D/D intersection, to HUNT for a corner.
I used Stake Point, in conjunction with "Dist to last" to perform a D/D int. It got me within a few tenths, and the Shonstedt revealed the buried corner. Which, I then dug up, and observed.

So, we could add a white button, that takes you to a screen that says Double Point Stake.

Enter the two points to be staked, and it now gives you a up to date:
Azimuth, Bearing, and dist to 2 points at the same time.
This would allow a quasi B/B int to be used too.
It would just be a handy search tool.
Of course, we could do this sequentially, ie, Stake one, then the other... but, hey doing them together is faster!

Regarding this issue, have you tried using the Distance-Distance CoGo function to create the intersection point? Next you would just need to stake this point. Is there some reason you don't like it.

 

[Adam]

Hi Nate,
We would suggest the following UI logic for new Interactive Clustering screen.
a) Clicking on white box "Distance to Last" will call new COGO Cluster screen. It synergies Michael's Cluster screen and COGO Average screen.
b) On that screen user has to select first point of the clustering sequence. Last point will be selected automatically as last surveyed point.
c) Also clustering threshold could be changed. Default value will be 0.1m.
d) All point from first to last are processed chronologically. The table shows point pairs with relative bearing, distance and vertical shifts. The pairs with rejected points are colored in red.
e) Rejection is based on distance from median point is bigger than threshold value.
f) Average point is reset when first point is changed. So it will be updated when last point is changed.
g) The description contains list of accepted points.
h) Map point allows review cluster graphically.

Hi Vladimir, I think this goes hand in hand with the suggestion I posted in the Repeat observation post from a couple days ago.

"I suggest that when auto restart is checked that the LS would observe the first point and hold that point in memory but not store it, then the same with each repeated observation until the set # of restarts has been met. At this point a screen will pop up displaying the data for each sub point and the average details. Then the user would be prompted to save average point or save each point. The static file would be recorded for the entire time. A lot of surveyors work flow is to stay on point and shoot it several times. This would basically automate cluster average for repeat consecutive points but you would have the added static time too. Cluster average would still be used for points repeated where there is a gap in point numbers and observations."

I tend to think this should happen when the auto store and restart is checked. One advantage to this is the user will not have to remember what the first number is. The main advantage to trying it this way would be to be able to have one long static file. Distance to Last seems an odd place to compute averaged points to me. I think the user needs to know that his plan is to average so many points and address this under what to store.

 

[Adam]

Regarding this issue, have you tried using the Distance-Distance CoGo function to create the intersection point? Next you would just need to stake this point. Is there some reason you don't like it.

View attachment 5346

Matt, I do it just like Matt S. mentioned.Its much quicker and real time. In stake out or collect select a point, in PDelta select a point, and have DTL as a white box. Work toward where you are going collecting as you go. Works great.

 

[Matt Johnson]

Matt, I do it just like Matt S. mentioned.Its much quicker and real time. In stake out or collect select a point, in PDelta select a point, and have DTL as a white box. Work toward where you are going collecting as you go. Works great.

You can certainly do it this way but I would argue that against it being a lot quicker. I just timed how long it took to me to create a Distance-Distance intersection point with the CoGo function and then select it to be staked, it was less than a minute. This was without using the Offsets whitebox. I tried it too and it would reduce the time but I noticed a few bugs with it that need to be fixed.

 

[Adam]

You can certainly do it this way but I would argue that against it being a lot quicker. I just timed how long it took to me to create a Distance-Distance intersection point with the CoGo function and then select it to be staked, it was less than a minute. This was without using the Offsets whitebox. I tried it too and it would reduce the time but I noticed a few bugs with it that need to be fixed.

The main reason I use pdelta and dtt is for a real time stake out while collecting points. You're probably right that COGO is faster if thats the only goal.

 

[Vladimir Prasolov]

Hi Vladimir, I think this goes hand in hand with the suggestion I posted in the Repeat observation post from a couple days ago.

"I suggest that when auto restart is checked that the LS would observe the first point and hold that point in memory but not store it, then the same with each repeated observation until the set # of restarts has been met. At this point a screen will pop up displaying the data for each sub point and the average details. Then the user would be prompted to save average point or save each point. The static file would be recorded for the entire time. A lot of surveyors work flow is to stay on point and shoot it several times. This would basically automate cluster average for repeat consecutive points but you would have the added static time too. Cluster average would still be used for points repeated where there is a gap in point numbers and observations."

I tend to think this should happen when the auto store and restart is checked. One advantage to this is the user will not have to remember what the first number is. The main advantage to trying it this way would be to be able to have one long static file. Distance to Last seems an odd place to compute averaged points to me. I think the user needs to know that his plan is to average so many points and address this under what to store.

Hi Adam,
We could store all point (it is more safe and more compatible with current application architecture). When clustering session is started, user can go into Clustering screen and select current point as first. We will try simplify that. At the end, when clustering is successful we could check "Delete Collected Points" checkbox, to keep only result.

 

[Matt Johnson]

Hi Adam,
We could store all point (it is more safe and more compatible with current application architecture). When clustering session is started, user can go into Clustering screen and select current point as first. We will try simplify that. At the end, when clustering is successful we could check "Delete Collected Points" checkbox, to keep only result.

You might consider merging all the raw data files into one file that would be stored and associated with the averaged point. There would have to be some limitation on when this is done I think to prevent problems for Alexey when post-processing with DPOS. These limitations include:

• The rover antenna (internal or external) and its height must be the same for all files
• All files would need to have the same base station session

I think this would be the simplest method to create one long static file.

 

[Matt Johnson]

You might consider merging all the raw data files into one file that would be stored and associated with the averaged point. There would have to be some limitation on when this is done I think to prevent problems for Alexey when post-processing with DPOS. These limitations include:

• The rover antenna (internal or external) and its height must be the same for all files
• All files would need to have the same base station session

I think this would be the simplest method to create one long static file.

Or maybe the data files could be copied and associated with the averaged point but given the same "Marker Name" for each file so that the DPOS/Justin engine would treat them as a single site. This would eliminate the need for these restrictions.

 

[Cody Jones]

What about a option to disassociate the static data from the points. So you could basically tell the LS when to start and stop the static recording regardless of what is going on. Maybe if you uncheck the record GNSS data it would allow you to start and stop a static file while taking multiple RTK shots.

 

[Nate The Surveyor]

Cody, I have thought about that... To do it "right" It'd have to be associated to SOME kind of point name, and description. And, it'd have to have an ALARM for when you took off, and LEFT raw data recording... I can see where this could have advantages... a single PPK file is preferable to 5 shorter ones. Loss of continuity makes it weaker. A single larger file would make it stronger. To make it fit well into the LS, it'd have to be well thought through. Perhaps the association could be with the FIRST PPK shot, like the _AVG point is named after the first point in a cluster. But, it'd have a name add on, to differentiate it from all the RTK. I think alot, and I confess, I don't have my mind wrapped around the "Best" way to have accomplished this. I will admit, I am seeing some sort of changes from when this first was released... it seems stronger now, and maybe they are getting PPK going so good, that short files are ok.... The whole schmere has to work as a whole, with everything.... I wish my brain were bigger!

 

[Matt Johnson]

What about a option to disassociate the static data from the points. So you could basically tell the LS when to start and stop the static recording regardless of what is going on. Maybe if you uncheck the record GNSS data it would allow you to start and stop a static file while taking multiple RTK shots.

There currently is an option to record data that won't be associated with a point using the "Start Continuous Recording" option found after clicking the GNSS Data Recording white box option.

This data won't be processed with DPOS since it's not associated with a point.

 

[Cody Jones]

It would have to have a point number, but my point was that it not be associated with the RTK point number. When you record just static it stores the data in a logxxxx. To me it seems to give more freedom in the process of how you collect data.