Hey Emlid team and community. I could use some insight as I am not a surveyor by any means but need some basic assistance: I will be surveying points and I need the result in WGS84.
I have an RS2+ base and rover and, based on the location of my surveys, will more often than not need to perform PPP to obtain my base coordinate and base my remaining points off of that point. When processing the data through OPUS I gain the data points back in NAD83, ITRF, UTM, and State Plane. When I was looking to process my data through CSRS, I noticed it doesn’t give the option for WGS84 coords either.
I have tried wrapping my head around coordinate transformations and I get lost looking at the various conversions online so I would like to find the easiest way possible so I do not cause error.
From the various threads here, the lackluster PPP guide, YouTube, and Google searches, I can’t seem to find the answer.
If the answer requires the need to download software, it will not be viable as I am unable to do so with my current system and when I go to the field I will not have access to my personal computer.
My initial plan revolved around utilizing NAD83 but this WGS84 use has really got me at a standstill and needing assistance.
Thanks to Plate Tectonics, WGS84 isn’t really your answer. Its a bit like Magnetic North, it wanders over time.
You would be best to stick to your local state datum (NAD83 as you’ve found), and have your base and rover set up accordingly. You will then have a much better time between surveys. Use the result of your data from OPUS for your base in NAD83 and the rest will fall into place.
If you then must have a point in WGS84, you can then convert it with a datum transfer program (one you could use in the US is WVDEP), but you will need to know the Epoch between the datum and basically todays month.
Again, strongly recommend using your local datum and not WGS84.
Could you explain a bit about what you are surveying, the purpose for the survey, and if there is anything in particular that is driving the need to have the coordinates in WGS84?
Like Joel said, there is a really good chance that what you need is a tectonically fixed coordinate system NAD83 (2011). But if you need the survey in WGS84, then you can use the ITRF2014 coordinates from the OPUS survey (and be sure to list the points as ITRF2014 2024.X where X is the fraction of the year in decimal form on the date you did the survey). Your OPUS report will include the decimal date for ITRF2014. The ITRF2014 coordinates are closely aligned to WGS84 coordinates (within approximately 10mm).
Recording and maintaining the date of survey with the coordinates is essential when you use a coordinate system that is not tectonically fixed.
You should be aware that ITRF (2014 or 2020) and WGS84 are cm-level the same.
What you get from OPUS (ITRF2014) or CSRS-PPP (ITRF2020) are equivalent to WGS84 at the cm-level. mm-level is another matter, but then we are getting into things like needing an individual antenna calibration. It gets esoteric pretty fast.
Want to test this out yourself? Look at the HTDP software from NGS (US National Geodetic Survey) and convert some coordinates from ITRF2014 to ITRF2020 to WGS84 (G2139). See how they differ.
Joel,
Thank you for the response. Due to the nature of my work I am stuck with needing to use WGS84, believe me, I would much rather work in NAD83. I will look into WVDEP and see if I can figure it out. Thank you very much for the quick response.
-Tony
The points I am surveying are essentially targets, fixed points in an area and the driving force is the organization that will be utilizing this data. They only work in WGS84 and do not have the ability to utilize other datums.
I remember reading about ITRF coords being very close to WGS so that may be my only option here. As far as recording and maintaining the date of the survey goes, is there anything special within Emlid Flow or the hardware I can do to verify the date? I just ran a quick check on Emlid Flow and started a new project which projected the correct date and time but when I go to survey it will be in another part of the country and I want to ensure that I do not have to actively adjust for the time zone difference or anything. I appreciate the quick response here.
@jbonde002 cm level accuracy isn’t just good, it’s good enough haha.
Based on ITRF data being within that distance then I would assume that it will suffice for the level of accuracy I am looking for.
I am not sure if I have the ability to download the HTDP software on my work computer to test it but I will look into it as well as WVDEP, which Joel recommended above.
Thank you for the quick response as well, this community is great and I greatly appreciate the prompt and thorough responses here.
It sounds like the organisation is more interested in mapping than surveying, so perhaps what they are really after is their results in Web Mercator (EPSG:3857)? Its what most online mapping programs like Google Maps, ESRI, etc. use and is Psudo WGS84 for this purpose.
Perhaps then you stick to your local surveying datum (NAD83) and translate into 3857 to the client?
A program on the computer I’d use to translate this is QGIS. It can handle a CSV input, which you assign an input datum, and you can then export it to any (mostly) other datum/s you’d need and vice versa.
Because most surveying datums were equivalent to WGS84 at the time of their adoption, this translation between datums pretty much gets handled through transformation parameters known between each EPSG, which QGIS handles quite well.
The added benefit is you can then have a base map, cadastre, other points, etc. in the project and can see it all on a map at once.
They have recently created a new WGS84 system (G2296) to allign with ITRF2020 and it’s been in effect for a couple of months. Note that the older system WGS84(G2139) is still cm-level consistent with the new one. Much like ITRF2014 is with ITRF2020.
If you really want WGS84 coordinates you can get the precise nav and clock data in this system from a link at the above site and do your own PPP processing, but realize that what you get from OPUS/AUSPOS/CSRS-PPP is going to be cm-level equivalent. You can try it for yourself.
The guys have provided great solutions. I’m sure one of them will suit your workflow. I just wanted to answer your question here.
The time setting works a bit differently on the hardware and on the software side.
On Reach devices
The Reach units use GPST (GPS time) in sync with satellites, so there is now a way to modify that. They keep track of time and save their logs in this format. You can learn about the difference between GPST and UTC in this post.
In Emlid Flow
The Emlid Flow app is constantly adapting to the time settings of the mobile device. So, if you change the time on your phone, the app’s timestamps will reflect the new time setting. You can test it by selecting a different time and creating a new project in Emlid Flow.
I had the same challenge at my previous job that I just left. I was working at an arboretum and WGS84 made the most sense because drone photo coordinates for photogrammetry are in WGS84, the web GIS systems are WGS84 based, etc.
You can convert but there is something to consider. Emlid Studio only accepts base station coordinates in WGS84. If you give it NAD83 2011 coordinates, it assumes those are WGS84. Everything still seems to work, as long as you assume your output is NAD83 2011 and not WGS84 as the output files say.
This isn’t really how things should work. Differential correction depends on the base station coordinates being accurate. Contrary to popular belief, there is no offset in differential correction.
If the software assumes the wrong coordinate system AND no tectonic shift, and it’s off by 2 meters, that doesn’t mean you can just assume the other coordinate system to offset 2 meters the other way. But in practice that does seem to work, presumably because the algorithm assumes your “offset” is a delay/increase of the speed of signals from the satellites.
I appreciate the feedback @daygeckoart I too am working with UAS photogrammetry. I think my current plan is to conduct 2 surveys for the data collects. One of which in NAD83 and the other in ITRF2014. As previously mentioned, the difference in ITRF2014 and WGS84 is negligible so I should be safe having that be my main data. I will collect in NAD83 as a CYA type survey and let the customer determine which set of grids they intend on utilizing.
