Hi Shawn, I will simplify that step. So no unknown systems any more. Manually created Local system will ask for underlying system (e.g. State Plane) and name for created system.
Dpos still messes up localize.
- Thread starter Nate The Surveyor
- Start date
That looks really nice.
@Vladimir Prasolov I've found one weakness in this strategy. If the coordinates of the imported points exceed the range of acceptable coordinate values for the underlying system (such as before any associations are made), then it is not possible to use CoGo functions such as inverse of the inverse points. Perhaps we could remove this restriction for local systems?
I would try to remove such a restriction for local system for GRID bearings and distances. For other values types (GROUND, GEO...) it has no meaning. It would add complexity to behavior of toggle buttons too. With new local system paradigm (it is in development version already), I'm trying to create working initial local system as much as possible. In any case I would suggest to localize system before usage in COGO.
Nate The Surveyor
Well-Known Member
Vladimir, I respectively have a few comments. I'm a Land Surveyor, and an end user.
IF I have an old file, that is based on some small local system, that has values, such as 5000N/5000E, and I wish to find some of the old traverse nails, I often wish to use inverse, to locate a control station, to set the base up on. So, the OLD file, has a tie to a fence corner. And, I wish to USE this fence corner, to locate a traverse point, in a field. So, I inverse, between the fence corner, and the traverse nail, in the field. And, it tells me that the direction and distance is N 10°14'39" E 435.26', I now can take my compass, and tape, to measure this off, and search with my metal detector. I know my bearing is weak, but My distance should be close. I find my traverse nail, and set my base up on it, and set an autonomous lat lon on it. I now, use LOCALIZE to "Connect" the old and new points. Now, I have a mechanism to search for more control stations, to bring in more points, into the localize.
Use of inverse, without any defining elevation, or grid, is an acceptable fiction, for practical field use, in this case. There are other cases, but we have as surveyors, without GNSS equipment, but with a transit, and tape, or Total Station and prism, have been working this way for years...
Thank you
Nate
IF I have an old file, that is based on some small local system, that has values, such as 5000N/5000E, and I wish to find some of the old traverse nails, I often wish to use inverse, to locate a control station, to set the base up on. So, the OLD file, has a tie to a fence corner. And, I wish to USE this fence corner, to locate a traverse point, in a field. So, I inverse, between the fence corner, and the traverse nail, in the field. And, it tells me that the direction and distance is N 10°14'39" E 435.26', I now can take my compass, and tape, to measure this off, and search with my metal detector. I know my bearing is weak, but My distance should be close. I find my traverse nail, and set my base up on it, and set an autonomous lat lon on it. I now, use LOCALIZE to "Connect" the old and new points. Now, I have a mechanism to search for more control stations, to bring in more points, into the localize.
Use of inverse, without any defining elevation, or grid, is an acceptable fiction, for practical field use, in this case. There are other cases, but we have as surveyors, without GNSS equipment, but with a transit, and tape, or Total Station and prism, have been working this way for years...
Thank you
Nate
Nate, I checked and Arkansas appears to have statewide imagery for every county in .sid format (compatable with AutoCAD) that can be downloaded from http://gis.arkansas.gov/repository/repository.php?rep=geostor-imagery. I would suggest you use this imagery to move and rotate deeds to approximate state plane coordinates before importing into the LS. You will save a lot of time and not have to do what you describe above. This is what I do in Ohio. I believe Darren also does something similar in Kentucky.
A list of GIS data available for all states can be found at http://guides.lib.purdue.edu/c.php?g=353290&p=2378621
Nate The Surveyor
Well-Known Member
I've never done this... I know generally how to get lat lon from USGS, but if I know I will be shifting it, then how much it shifts is not relevant. So long as the software can handle it. I have a copy of Mr sid, Arkansas state wide. It crashed my older computer! So, I have not yet tried it in this one...
N
N
Do you have AutoCAD? See https://knowledge.autodesk.com/supp...les/sfdcarticles/Support-for-MrSID-files.html
The .sid files should already be referenced in the SPCS. No need to worry about lat and lon coordinates.
Hi Nate,
Your experience is very important for us and especially for me. I'm just mathematician and programmer, so I'm very appreciate to you for exact workflow information.
1. We do not prevent to use that workflow. The issue could be when the coordinates of the imported points exceed the range of acceptable coordinate values for the underlying system. It rarely happens. Even in that case you can go into localization and add one approximate matching pair of surveyed (or manually input) point in the underlying system and design/known point. Do not worry about accuracy of this step. After that all COGO functions will work fine. In future I would try to remove such a restriction for poorly defined local system for GRID bearings and distances.
2. Regarding using LOCALIZE feature to "Connect" the old and new points. Why do not use M-Local. Javad providently called it "M-Local". Initially it was M-Shift. In future, if you found shift is not enough to do that "Connect", we will add rotation and scale too. So it will be just regular network adjustment on device. It is feasible with current J-Field architecture.
Best regards,
Vladimir
Nate The Surveyor
Well-Known Member
In my way of thinking, my old 5kN/5kE system is wrong. I know it is wrong. I can deal with it as wrong. Moving to an intermediate, "Close but no cigar" system, seems like a round a bout approach. I'd druther just go from a purely wrong system, to a real system. One more intermediate step, is one more chance for me to mess it up...
But, as I sit and think... IF I can abandon the desire to set the base up on the old nail, and set the base up on a NEW random point, then I can shoot the fence corner, "Localize on the Fence corner" and now an inverse will work. OR, stake the old trav nail.
The advantage is one less measurement. With my older Topcon Legacy E gear, (Which was not as accurate) as this is, such things mattered more.
N
But, as I sit and think... IF I can abandon the desire to set the base up on the old nail, and set the base up on a NEW random point, then I can shoot the fence corner, "Localize on the Fence corner" and now an inverse will work. OR, stake the old trav nail.
The advantage is one less measurement. With my older Topcon Legacy E gear, (Which was not as accurate) as this is, such things mattered more.
N
Hi Nate, I think our goal is support ALL working scenarios. Why not? I do not see anything wrong in your approach. Everybody is looking for a way to do work easier and more convenient. Regarding Localization and M-Local. One is moving system, another is moving points. If we enforce our M-Local to real adjustment with rotation and scale, then we could use localization only for creating engineering systems with origin nearby. For all other corrections in well known systems we could use M-Local.
Nate The Surveyor
Well-Known Member
I really DO want my underlying coords to be REAL SPC. This was a VERY big (for me) part of the attraction, to the Javad LS. M-Local, shifts the actual coord, for the base. In my thinking, this shift (If it shifts the SPC) should NOT be large. Maybe in the range of less that 20 feet. Typically, more like 5 feet.
But, the freedom, to work in local coords, is very nice.
So, I have Page ZERO set to SPC, and Page 1 set to some local system. We now retain our SPC. And, can dpos it, and update the spc at the base. AFTER the job is completed, we can EXPORT PURE SPC. Now, we do another job, 4 miles down the road, and we can BRING our SPC coords into the second job, and scale them to that local system, and we have long and usable dimensions. Around here, we have TOWNSHIPS, that are roughly 6 miles square.
I AM working in pure SPC, BUT my scale factor is being taken care of in the LS. Until the job is done. THEN we want those SPC.
Thank you for your time.
Nate
But, the freedom, to work in local coords, is very nice.
So, I have Page ZERO set to SPC, and Page 1 set to some local system. We now retain our SPC. And, can dpos it, and update the spc at the base. AFTER the job is completed, we can EXPORT PURE SPC. Now, we do another job, 4 miles down the road, and we can BRING our SPC coords into the second job, and scale them to that local system, and we have long and usable dimensions. Around here, we have TOWNSHIPS, that are roughly 6 miles square.
I AM working in pure SPC, BUT my scale factor is being taken care of in the LS. Until the job is done. THEN we want those SPC.
Thank you for your time.
Nate
Nate The Surveyor
Well-Known Member
OK, I just got off the tele, with a colleague. We discussed this matter.
Here is what we want:
And, Page 0 is set to SPC, (Either autonomous, or shifted to real, a small shift) then we can inverse between ANY point on page 0, to any point on page 0.
IF page 1 is set to a local system, and named, we can inverse any point, to any point, ON THAT PAGE.
IF we inverse between a point on page 0, to a point on page 1 AT THIS POINT in sequence, it flashes a red warning, that "Warning, Pages are NOT associated Localize to associate". This would ALLOW an inverse, but with a warning. This would be useful, IF we have quasi spc, on page 1, and "Real spc" on page 0.
IF you inversed from a point on page 0, to a point on page 1, AFTER localize, then all is fine. No warning. (Even if the quality of this localization is only approximate) such as a hwy intersection, or a loose survey marker.
This would potentially allow an inverse, (BEFORE localize) that is some miles away, and not relevant. HOWEVER, it would still allow an inverse. Just with a warning. Some times, we actually want to rotate, translate, and scale a point group, to be on our datum.
This serves ALL known purposes.
IF you set page 1, to HAVE the same coord system as page 0, Then you do not get the warning. Even if they are many miles apart. (The extreme distance serves as a warning)
IF you have scaled some coords, off of the mr. Sid files, or off a USGS, or some other means, you can still use them, before associating them (Localize), as long as they are set to the same coord system, but on a different page. If you find that there is a difference, between the coords, on Page 0, and Page 1, you would then SET the coord system on page 1 to either UNKNOWN, or to a meaningful name, and now, it can be rotated, translated, or a localization to it performed. IF we rotated, or translated, then we would select the coords, by PAGE.
This keeps the group intact. Of course, design points are modifiable.
If you go to the field, and there are points, in the field, with real spc on them, you would use M-Local, to back the base coord in.
I am open to other ways to do all the above, however, this makes "Field Sense" to me. This is a very fun project, and fulfilling.
Thank you,
Nate
Here is what we want:
And, Page 0 is set to SPC, (Either autonomous, or shifted to real, a small shift) then we can inverse between ANY point on page 0, to any point on page 0.
IF page 1 is set to a local system, and named, we can inverse any point, to any point, ON THAT PAGE.
IF we inverse between a point on page 0, to a point on page 1 AT THIS POINT in sequence, it flashes a red warning, that "Warning, Pages are NOT associated Localize to associate". This would ALLOW an inverse, but with a warning. This would be useful, IF we have quasi spc, on page 1, and "Real spc" on page 0.
IF you inversed from a point on page 0, to a point on page 1, AFTER localize, then all is fine. No warning. (Even if the quality of this localization is only approximate) such as a hwy intersection, or a loose survey marker.
This would potentially allow an inverse, (BEFORE localize) that is some miles away, and not relevant. HOWEVER, it would still allow an inverse. Just with a warning. Some times, we actually want to rotate, translate, and scale a point group, to be on our datum.
This serves ALL known purposes.
IF you set page 1, to HAVE the same coord system as page 0, Then you do not get the warning. Even if they are many miles apart. (The extreme distance serves as a warning)
IF you have scaled some coords, off of the mr. Sid files, or off a USGS, or some other means, you can still use them, before associating them (Localize), as long as they are set to the same coord system, but on a different page. If you find that there is a difference, between the coords, on Page 0, and Page 1, you would then SET the coord system on page 1 to either UNKNOWN, or to a meaningful name, and now, it can be rotated, translated, or a localization to it performed. IF we rotated, or translated, then we would select the coords, by PAGE.
This keeps the group intact. Of course, design points are modifiable.
If you go to the field, and there are points, in the field, with real spc on them, you would use M-Local, to back the base coord in.
I am open to other ways to do all the above, however, this makes "Field Sense" to me. This is a very fun project, and fulfilling.
Thank you,
Nate
Nate The Surveyor
Well-Known Member
I guess part of that last statement, is not needed:
" you would then SET the coord system on page 1 to either UNKNOWN, or to a meaningful name, and now, it can be rotated, translated, or a localization to it performed."
Is not needed. they are DESIGN points, and as such, are modifiable.
N
" you would then SET the coord system on page 1 to either UNKNOWN, or to a meaningful name, and now, it can be rotated, translated, or a localization to it performed."
Is not needed. they are DESIGN points, and as such, are modifiable.
N
Darren Clemons
Well-Known Member
Yes Matt is correct Nate.
I also do what he describes using move/rotate. I never even bother with creating an "unknown" coordinate system. My jobs are started in Ky. Single zone (then a grid/ground and rename for the survey points) and the maps are in Ky. Single zone. We take old jobs such as this and only use our line work. Usually there's no need for the "old" coordinate file. I use Carlson Survey 2013 and it even has a "attach image by world file" option in it. I have a basemap of approx. 6 counties that I regularly work in with the grids of the mapping overlaid on them. I just open whichever county the job is in, find the location on a highway map to see which grid map i need, then download it to my job folder. After unzipping the file there will be a .twf (world file) in it. Then using the command in Carlson it automatically places that image on State Plane. I then just move my line work in CAD and calculate approx new points on our corners and then take those points to the field. With the mapping we have today it's remarkable how close we can get, using fence lines, even fence posts, c/l of the road, etc. to "line up" the old drawing to grid. Most times, as soon as we set up the base and get an autonomous position, we can stake to any point on the job with 5-10' (most of that is from the autonomous "get" which is typically 2-6' off). There will be very, very little rotation to the "new" points since it's aligned to grid via the mapping. Bonus - If it's one of our jobs in the last several years that was started with GPS and has geodetic bearings there will be virtually no rotation.
Once we get the first point then do a "move", or if you prefer, localization, on all the design points and then we go right to the rest around the entire job.
Once a second point is found I then rotate and, depending on the accuracy of the survey I'm following, may re-adjust as necessary around the rest of the job.
You may have seen it in the other threads, but Shawn has a great tutorial on doing this, using localization which is his preferred method.
https://support.javad.com/index.php?threads/how-about-using-the-new-pop-ups-feature-for-this.1863/
Garrett Dendy
Member
When you talk about localization, are you talking about shifting from grid to ground or are you shifting to an even more accurate "local system"? Speaking of grid to ground, how is that done with the LS?
Nate The Surveyor
Well-Known Member
Do you use acad/Carlson?
Have you used the ALIGN command?
It's a point number based cogo form of ALIGN.
If you know what that means.
Have you used the ALIGN command?
It's a point number based cogo form of ALIGN.
If you know what that means.
Nate The Surveyor
Well-Known Member
DPOS still messed up localize.
It still shifts the local coords, the same amount that spc shifts, from the autonomous, to spc.
Are you saying that if I resave the localize, It will put the local coords back where they belong?
I have gotten in the habit of:
Setting layer 0 current.
Set layer 1 as spc.
Deleting all design pnts.
Deleting all prev. Localize.
Set layer 1 current.
Set layer 1 to "unknown"
Re-import design points.
Re-Localize. Save the localize.
Now it all looks right.
Takes 10 mins. In the office.
N
It still shifts the local coords, the same amount that spc shifts, from the autonomous, to spc.
Are you saying that if I resave the localize, It will put the local coords back where they belong?
I have gotten in the habit of:
Setting layer 0 current.
Set layer 1 as spc.
Deleting all design pnts.
Deleting all prev. Localize.
Set layer 1 current.
Set layer 1 to "unknown"
Re-import design points.
Re-Localize. Save the localize.
Now it all looks right.
Takes 10 mins. In the office.
N