Is anyone here actually using their Reach (RS+/M+) for surveying and/or drones to provide data related to the surveyed ground. I feel like an outcast when I bring this up because - it seems that many people are fine with ellipsoid and geoid elevations?
We use local_HREF and not geoid, so we need to convert height anyways, but single and multiple points is converted in batch easy with the right tool.
.
1 Like
We use the GPS localization of our site benchmarks and control points which are surveyed in using a robotic total station and auto-level. I guess this is so new to many that people may not have gotten to use drone data in an existing design data workflow. We have to relate to existing site datum and design files to accomplish what I want us to be able to do.
1 Like
Michael,
What is your workflow for translating to local ground coordinates?
I found a convoluted process to convert to state plane coords from lat/long that allows me to retain field codes, but it takes a good 20 minutes and requires a lot of manual formatting.
@RyanJMcGowan It is all done in the Topcon Magnet software. Other softwares that are better compatible with the Reach receivers also have a similar workflow. We start with YXZ points generated from a CAD file or that have been calculated from a paper document. We then make a “dummy” point somewhere in the vicinity of where we want to set our base station. It doesn’t matter where it is except for when zooming extents on the screen. We setup the base and let it acquire a LLH coordinates and everything from there is angle/distance from the base. The base coordinate can also be a known point with existing coordinates, but the only difference that makes is a faster acquisition of triangulation so that you can “stakeout” the other points. You go to each of the other preloaded points and “measure” them to give them a LLH coordinate and the program allows you to choose which points you want to use in the localization and which aspect of horizontal, vertical or both. It then provides the standard deviation of each attribute of each point and you can determine what your base network consists of. Basic requirements would be to “box in” the site as best as possible with at least 4 horizontal points and 3 vertical. They do not have to be the same points.
Another scenario is something like I just did this afternoon for a quick drone map. I only had one vertical benchmark so it was the only one of the 5 I located that I accepted the elevation for. The problem here is that I am putting all my trust in one point that may or may not have been cross-checked or level-looped. In this case I know the engineer well and am pretty confident that his information is trustworthy.
I hope this makes sense in theory.
2 Likes
Oh definitely don’t feel like a outcast, you very much ADD to all of this in the survey world. Most here will be learning a LOT from you as you are applying all of this is REAL WORLD conditions that most probably still do not understand.
1 Like
Michael,
Sounds like you must be using a data collector and the field version of Magnet?
I’m in the Civil3D ecosystem. I have three Sokkia non-RTK heads that can only work in Magnet and RTKLib. Sokkia dropped the post processing support for them, and I wasn’t interested in shelling out another $3k on Magnet just to post process when I can get a vectors in RTKLib for free. Most my work is on a total station anyway.
I was able to do a topographic survey with Reach on the native app, but as it is now, I see it’s not practical for staking out to anything that you don’t already have tied down with LLH data on. Still worth every penny of course. It’s really nice to be able to survey solo again. I’m even thinking of getting another head and using it as an NTRIP caster so I’ll have at least a third-order tie to datum without benchmark runs on every survey.
1 Like
Have you tried QGIS? Very easy to transform coordinates there. You can bring in a CSV of the points, transform the map and save them out in another coordinate system.
1 Like
I haven’t tested exporting to a csv from QGIS yet, but I am using QGIS.
I’m going to make myself a console app that will take the GeoJSON or csv file and spit out the data to a PENZD-formatted csv file transformed to project-specific coords.
1 Like
Nice.
QGIS is basically export the survey file from Reachview, load it in on WGS84, change the project to your desired projection and save as.
I still have to add point numbers, and translate to the basis or bearing and a known point coordinate. I could make a python plug in for qgis that could automate that, but it would be easier to just run a command prompt wizard.
1 Like
Point numbers and descriptions can be added as attributes during the import, but it sounds like you need different data collector software. Way to manual and probably not repeatable by others at this point. I guess unless you are the only one that will ever be processing the data…
I was under the impression that data collection could be handled by Reachview. I am somewhat able to, but it’s definitely lacking in surveyor’s needs. I’d love to do data collection and cogo on an android through wifi or bluetooth to the receiver. Before I bought it, I saw ReachView on github and thought I could add those features and contribute to it, but it’s not the mobile app that’s open source.
Here’s a question for you folks…
I have a CORS network that gives me reference coordinates in NAD83 (2011). All of Emlid/RTKLIB info says WGS84. My photogrammetry software interprets both as exactly the same locations. Would you care to explain from a survey perspective? According to the NGS, a transformation is needed, but what should be used where and when? Are they interchangeable at times?
I think MicroSurvey is developing a Android app (maybe iOS too, I don’t know) of FieldGenius. (probably subscription model) : (
Right now I use an old Trimble Nomad 900G data collector and a older Microsoft Surface Pro 1 (so I don’t have to worry about breaking it and crying over it). I use ReachView for the settings to connect (2) Reach RS receivers to either of them.
FieldGenius has it all. ReachView Survey have a LONG way to go to compete with FG. Good enough for basic stuff though.
2 Likes
From what I understand NAD83 and WGS84 are almost very much the same, not exactly, but quite close.
Edit: to clarify, NAD83 is based on Geodetic Reference System (GRS80) ellipsoid and the World Geodetic System of 1984 is based on WGS84 ellipsoid.
GRS80 best fit to Earth’s geoid. WGS84 is the GRS80 ellipsoid shifted to Earth’s center of mass.
My current understanding is that NAD83 is basically WGS84, but tied down to the North American tectonic plate so that Lat/Long of benchmarks don’t change over time. The question is if I need to be converting these coordinates prior to feeding RTKPOST, or if there’s effectively no difference so it won’t matter.
No, they are different. You will introduce a shift in the magnitude of the difference between the two datums upwards of a meter or more depending on your location on earth. Your CORS network in the U.S. in the .coord file will give you both NAD83 and ITRF08. It is my understanding that ITRF08 is latest realization of WGS84. Just use the ITRF08 coordinates for base position. Else, you need to convert NAD83 to WGS84. If you want to get technical you should then apply a velcoity transformation on the NAD83 coordinate to take into account the movement of tectonic plates with a tool such as this: HTDP - Horizontal Time-Dependent Positioning
Try converting from WGS84 to NAD83. Then convert from WGS84 to IRTF08 and see the converted coordinates. Keep everything WGS84 until the last step of processing, then transform data to your desired coordinate system to reduce introducing a shift/offset to your dataset.
3 Likes
Nathan,
Generally speaking network are adjusted to certain datum, but they all broadcast WGS84 (Lat, Lon, Ellipsoidal Height.In other words, the network receivers track the same information from the satellites than your Emlid Reach does. It is the software that takes care of transformations. In RTKLib (and Reachview on the RTK side) the options are limited to WGS84 and a couple of vertical datums (ERMS96 and something else I can’t seem to remember(maybe ellipsoidal height?). So, after you get your coordinates processed in RTKlib, then you will need one of the methods others in this thread have highlighted to be able to fit the coordinate system you are intended to use or your final deliverable coordinate system is.
1 Like
Nathan,
NAD 83 is based off of locations only on the North American tectonic plate. WGS is based off the entire planet. They differ by a few cm per year.
From a surveyor’s perspective, it doesn’t matter so much what datum you’re on because GPS standalone is somewhat meaningless on the ground. 1 arc second east-west is not the same distance as 1 arc second north-south. From a survey perspective, physical distances in feet or meters is what matters.
Also, if you’re dealing with property lines, you need to work from monuments in the ground. If you’re working with buildings, streets and sewers, you need to work off vertical control benchmarks. If you’re working on highways and large projects, you need to tie to horizontal control for the local state plane coordinates.
A surveyor will never define a location by WGS lat/long.
CORS is helpful, but only in that you have a receiver that is perfectly fixed over long time periods so you can reference to it again and again.
I wouldn’t worry about transformations between the two datums because the one that matters is the transformation from a datum to physical coordinates.
2 Likes