Like this: You work in a JAVAD data collector. BUT you have a TDS DC in your backpack. They are hot linked together. So long as they are close to each other, they stay syncronised. If you take the TDS too far, it looses sync. You go and do cogo in it, and bring it back, it re-syncs. So, your new coords are synced and available to stake in the LS. (You have to set up perimeters, and, scale factors, and projections to do this)
Now, back in Carlson, you just hover over any point, and it will give you a complete breakdown. Lat Lon. And how long the point was observed in the field. How many engines. What RMS it had. All the basic data. And, then it was RE Shot, one hour later. And, here is that data. And, here is the average. And the CSF is:____________(combined scale factor) and rotation etc. So that everything is always available. Complete data flow. 5 yrs later, you re-shoot the point, and it has MOVED! yes, the whole Continent is drifting... So, you can actually look at the move due to continent velocities. And, enter a DATE, and it puts it all back were it was. So, it now has a drift factor.
Well, maybe in my lifetime, and maybe in the next generation. But we do need to move along.
Is anybody working on this?
N
There are two ways for manufacturers to push their products.
One is to make interchangeable brand A pieces (gun, GPS, data collector, office software, etc.) and try to convince people who like brand X GPS to use Brand A data collectors because they are better, and convince people who like brand Z data collectors to use Brand A guns because they are better, etc.
The other way is to make nothing interchangeable, so once you capture a customer who likes your gun, he has to buy everything else from you, too.
I think it is unfortunate that manufacturers have moved toward the second direction.
Hi Nate,
This is something I have been pushing for 15 years - integration of data flow. I want full integration, just not field to CAD, but incorporate GIS and asset management - field to board room! I have actually applied to a doctoral program and want to work on something like this for my research. I'm looking at either researching 1) full integration methods, or 2) model analysis tools for geospatial professionals to use in evaluating the best model for 'fitness for use' using risk assessment - the cheapest survey is not always the one that has the highest value to the client but how do you quantify it.
So I think it is feasible in our lifetime. I love your ideas!
What we have right now, is plane coords are generated from lat lon in our data collectors. Eventually the plane coords make it to cad, and a drawing is generated. Yet, the perimeters of this projection and all the details are hidden from our minds. (it's happening, but we often don't deal with it) .
Also, much more data should come to our home office desktop computers. Such as the whole equation. I think one of the routes to help us all get there is good educational material. Good understanding of projections, etc. Most surveyors using RTK set them up, (true north at the base) and then PLAY flat earth. Bill the client, and go home. Everything is flat earth living. We are going to have to become proficient in projections. And the whole integration process. Remember converting polar to rectangular coords? well, now we have alot more to think about.
N
But for property surveys, the finished product is the information that reaches the homeowner who wants to know just where to dig up the lawn and plant a garden. The finished product goes from the CAD system of the surveyor a mylar, which goes to a lawyer, who hands it to a paralegal, who types a legal description as an inpenetrable block of text. That gets sent to a title company, which scans it because there IT systems are not well-enough integrated to accept readable text from the lawyer. Then it gets emailed around the country a few times and winds up in front of the seller and notary. But electronic signatures and electronic notarizations are in their infancy as far as purchases are concerned, so the seller and notary do their things with ball-point pens and rubber stamps. The deed makes it's way to the recording office, where it gets scanned again. The property gets sold three times; each time the measurements get retyped from a scanned image. Finally a 12th generation text description of the measurements ends up in the hands of the gardener.
Ashton, that will always be part in the equation along with paper bookkeeping but for the larger arena you need the total package.
Nate, you can do a lot of this now using attributes and software versions built to integrate with GIS.
GIS is where it's headed, but GIS software is not ready for surveying. GIS software is barely ready for the "G" in GIS. The geodesy of GIS software is very puny. Furthermore, GIS vector data (linework) does not support the needs of design professionals - read circular curves. GIS DOES excel at providing rich data attributes which are much more useful to surveyors than the current single descriptor field most are using. The solution is, in my mind, a combined GIS database linked to DXF/DWG (or similar) linework.
One drawback to "integration" is that you are stuck with whatever the standard is. No room for improvement. Consider what integration has done to many manufacturers with "end to end" solutions. A database format can't be changed because it's THE format, so over time, the database grows to absorb new changes becoming bulky, but seldom is the database revamped (made more efficient). Furthermore, if brand X does a better job than brand Y, you're out of luck because the end to end solution made by brand X doesn't include brand Y.
Having said that, there are some industry standards that have been very helpful - ASCII coordinate files, RINEX raw GPS files, LandXML files, DXF, all come to mind. But there are reasons that no one uses these generic file formats for proprietary data. They are not efficient. Take for instance, the new tilt sensor data from GNSS receivers. If we waited for a standard solution to be resolved, we'd be waiting for the standards committee to hash out how that new data would be integrated into the data file. Standardization would likely stifle innovation in many respects.
Shawn, that is a very powerful argument against integrated software. For a glimpse at how significant the drawbacks can be, Google "electronic health record implementations."
If the software does it the way you do it, great. Otherwise, ....
Nate The Surveyor, post: 326245, member: 291 wrote: Like this: You work in a JAVAD data collector. BUT you have a TDS DC in your backpack. They are hot linked together. So long as they are close to each other, they stay syncronised. If you take the TDS too far, it looses sync. You go and do cogo in it, and bring it back, it re-syncs. So, your new coords are synced and available to stake in the LS. (You have to set up perimeters, and, scale factors, and projections to do this)
Now, back in Carlson, you just hover over any point, and it will give you a complete breakdown. Lat Lon. And how long the point was observed in the field. How many engines. What RMS it had. All the basic data. And, then it was RE Shot, one hour later. And, here is that data. And, here is the average. And the CSF is:____________(combined scale factor) and rotation etc. So that everything is always available. Complete data flow. 5 yrs later, you re-shoot the point, and it has MOVED! yes, the whole Continent is drifting... So, you can actually look at the move due to continent velocities. And, enter a DATE, and it puts it all back were it was. So, it now has a drift factor.
Well, maybe in my lifetime, and maybe in the next generation. But we do need to move along.
Is anybody working on this?
N
Nate,
I do most of that now using a windows tablet with Topcon Magnet. I use Google drive via 4g modem to sync files from my tablet, laptop, and desktop with the cloud in real time. Can walk to a known point and check it using nearest point stakeout. Can ipmort and work with true 3d cad files and surfaces. Can render and contour surfaces. Can compute volumes in the field.
MathTeacher, post: 326374, member: 7674 wrote: Shawn, that is a very powerful argument against integrated software. For a glimpse at how significant the drawbacks can be, Google "electronic health record implementations."
If the software does it the way you do it, great. Otherwise, ....
That's why I'm an Android guy and not an iOS guy. I know the plug and play "it just works" is nice, but you are limited to "it just works" how it works.