Three Things that we need

Nate The Surveyor

Well-Known Member
1.) This is the first one: Versatility with points to hold.
Although I would add that RTPK should have a column, and DPOS should have a different column. This would allow DPOS to be done, without messing up RTPK.
As a related item, if points are averaged, we could also include multiple sources of coordinates, if desired. Allow it to do a weighted average of each point, such as RTK, RTPK, and DPOS, as 3 coords to use to weight the average. This setting should be under AVERAGE points.

2.) Acreage program. It should be in spreadsheet format. So that we could enter the coordinate names, in an organized way. AND, it should allow EDITING of this sequence. SIMPLE Curves should be supported. Both tangent and non tangent curves. AFTER entering this point sequence, it should be STORABLE. Under a specific name. And, re callable.
Maybe like this:
Area Sequences, with a popup screen:
With (Enter Sequence)
Save Sequence
Recall Sequence
And, STAKE SEQUENCE
and, another button on Stake screen 1, that ALLOWS us to STAKE CURRENT acreage sequence. Which came from this group of sequences. While in this stake sequence, we should be able to "Go to Closest line of Current sequence". then, we should be able to STAKE lines, and POINTS with a one button toggle. This way, you can toggle between STAKE line, and STAKE points. This way you will walk around the parcel, toggling between lines, and points.
You could key into the LS the acreage sequences at the office. Name them whatever name you like. Then hand the LS to a field hand, and have him stake that sequence.

3.) Saving lines to stake.
I often enter 2 point names, to STAKE the line between them. I wish it would SAVE the LAST 10 lines. (After 10 lines, it just falls off, and dissappears) This way, I can go BACK to a previous line (Defined by 2 point names) and stake that previous line.
It also would help me to keep up with what lines were staked.

I'm suggesting things that we want, need, and will use. These things I'd use.

Thanks,

Nate
 

David M. Simolo

Active Member
I don't know the difficulty in implementation but these seem like worthwhile features. I would rank the priority as 1, 3 then 2.
 

Nate The Surveyor

Well-Known Member
I spoke with another surveyor. He said he should probably just get a laptop, (pretty nice ones are available) and put his favourite cogo into it. (Carlson) and when he needs Acreages in the field, just transfer the files. But, I think that this illustrates the need even more. Javad can't (practically) run solo. It has to borrow cogo from another source.
I had a laptop, but lightning got it recently.
I'm probably going that way too. Replace it.
I know of a number of other Javad users that have done this too.
Item 1 is pretty important.
And item 3 probably is not that hard.
Number 2 can be done with a laptop.
Nate
 

Matt Johnson

Well-Known Member
5PLS
2.) Acreage program.

This already exists. It supports curves when you select a polyline with a curve.

COGO-AREA-PERIMETER_20210723-10.28.00.png

Cogo_20210723-10.27.54.png


By creating polylines this handles your other requests of being able to save it, stake it and modify it.
 

Shawn Billings

Shawn Billings
5PLS
Matt has a good point regarding 3. Name the alignment and save it to a particular page if you wanted to make selecting it from a short list easier.

Regarding 2, Matt's point is good, however the CAD tools aren't mature enough to make this viable with a curve, in my opinion. Also, point selection in the Area routine is not good. It is impossible to select points from the Map, only from a list. If the point name is extremely long (as in the case of imported polylines from a dwg file) then it is impossible to know what points to even select from the list. The idea of a spreadsheet approach is that the user could select points from the list, recall by name, or picked from the map and also identify curve points and the radius of those curves. This would then create the polyline. It would also populate the rest of the spreadsheet with the direction and distance between the points, along with a preview of the polyline.

Regarding 1, I think the better approach is to more intelligently select the correct position and not rely on the user to select from multiple versions of the same point.
 

Matt Johnson

Well-Known Member
5PLS
The idea of a spreadsheet approach is that the user could select points from the list, recall by name, or picked from the map and also identify curve points and the radius of those curves. This would then create the polyline.

I think this already exists. It is the Polyline tool found in the Points screen (Line tab > + button).

EXPLORER-OBJECTS_20210723-13.32.29.png


POLYLINE-INFO_20210723-13.36.18.png


There may be improvements that need to be made to it but this is a different topic than the CoGo Area function. I find it is easiest to create polylines in the map screen (again this still needs improvements but is a different topic).
 

Nate The Surveyor

Well-Known Member
@Matt Johnson , I'm trying to:
Simplify jfield, without loosing power.
Make it more intuitive.
Need less technical support.
And increase its available power, without sacrificing simplicity.
I could write ALL my own CoGo, but then I could not find time to survey, as I'd be spending 10 years on it. And, who'd pay the bills during this time?
In short, CoGo should be written so that I don't need a blackboard and chalk to explain the CoGo. In fact, it should be written so as to be able to teach surveying WITH the CoGo.
Imho
I will add, thank you for your explanations. Now I have to find time to explore the utilitarian side of these expressions of surveying solutions.
(In short, make those expressions make more money, than the time to learn and apply them).
Nate
 
Top