Randy Rhodes
Member
Discovered to my dismay that when you do a resection or intersection and AFTERWARDS adjust with dpos the resection or intersection points are not adjusted. What am I doing wrong ?
Dpos
- Thread starter Randy Rhodes
- Start date
Design points are currently not adjusted with DPOS. Currently you would need to use CoGo Shift or Move to translate the design points. I think we are planning to support shifting design points in the the future with DPOS.
Randy Rhodes
Member
I like that plan.
Nate The Surveyor
Well-Known Member
I propose a possible solution would be to ALLOW an option that would make FIELD CALC. DESIGN POINTS, to be SURVEY POINTS. Last time I checked, when you do a CLUSTER AVERAGE, they come in as SURVEY POINTS. As survey points, they are also in the group that is uploaded, into ACAD/Carlson. So, you could have an option, to make these cogo points, go into the same pile, as the ones that get shifted with dpos. Am I right, or mistaken, that CLUSTER AVERAGE points DO get shifted with DPOS? That's how I have it in my mind... correct me if I'm wrong.
Thanks.
N
Thanks.
N
Survey points are measured from a base. They are, in essence, the endpoints of vectors. A design point is a coordinate with no genealogy. Cluster Average points are survey points, provided that all of the points that created the cluster are survey points. Add a design point and the average loses its lineage. Cluster Average points create a vector from the base of the first point in the average. Because of this, when the base moves (due to DPOS, shift or manually editing the base position), then all rover points from that base will move with it, because the vector is preserved. A design point has no tie to the base, so when its moved, there is no automated approach to knowing which design points should move and which should not.
We're looking at several different solutions for this. One solution is to make the user perform a CoGo>Shift after DPOS, where the user selects which design points to shift, and populating for him the shift amounts in dN, dE and dU.
The other solution we're looking at is to add a base point to certain design points. For instance, if you do a bearing-bearing intersection from two survey points (P1 and P2), then the design point would inherit the base point of P1. If the base point of P1 is ever shifted, then the design point would also shift. I believe this will be the most elegant solution, but it may take some time to implement.
We're looking at several different solutions for this. One solution is to make the user perform a CoGo>Shift after DPOS, where the user selects which design points to shift, and populating for him the shift amounts in dN, dE and dU.
The other solution we're looking at is to add a base point to certain design points. For instance, if you do a bearing-bearing intersection from two survey points (P1 and P2), then the design point would inherit the base point of P1. If the base point of P1 is ever shifted, then the design point would also shift. I believe this will be the most elegant solution, but it may take some time to implement.
Cody Jones
New Member
I second the notion of being able to make design points, act like survey points and be shifted with the other surveyed points.
Nate The Surveyor
Well-Known Member
Thank you Shawn, for your calm, and well reasoned response.
I do not know the final answer to this dilemma.
In my imaginary software, all points created by any means, have a one or 2 letter code code attached to them. TS came from a Total Station. LS came from the LS. PP came from a post processed, DPOS. CO, came from COgo. BB came from bb intersection. dd came from Distance Distance int. BD came from Brng Dist int. 9
In the dashboard, you set up how each of these behave. The USER selects weather or not the given points SHIFT with DPOS, or not. It is a check box system.
Fundamentally, they are in 2 categories: Points that SHIFT, with dpos, and those that do not.
This is an area of my imaginary software, that I am working on.
N
I do not know the final answer to this dilemma.
In my imaginary software, all points created by any means, have a one or 2 letter code code attached to them. TS came from a Total Station. LS came from the LS. PP came from a post processed, DPOS. CO, came from COgo. BB came from bb intersection. dd came from Distance Distance int. BD came from Brng Dist int. 9
In the dashboard, you set up how each of these behave. The USER selects weather or not the given points SHIFT with DPOS, or not. It is a check box system.
Fundamentally, they are in 2 categories: Points that SHIFT, with dpos, and those that do not.
This is an area of my imaginary software, that I am working on.
N
Nate The Surveyor
Well-Known Member
Addendum to my above post, what my imaginary software does, is run line by line through the coords, and finds the code, and uses the 2 letter code, to decide what to do with that point. So, when you authorize an adjust points with DPOS, it also runs over, and checks the database of coords, for points with the code that is attached to the DPOS shift, and they simply move with it. This way, you can have other rules, (set in the dashboard) so that you can manually manipulate certain coords, and not others. Such as rotate, translate etc. Dashboard also allows groups.
N
N
Randy Rhodes
Member
Wouldn't it be simpler to store resected or intersected points as survey points ?