I’m not successful just trying to establish a single point. Any help with what I’m doing wrong would be great.
I let the Reach sit for an hour logging and then downloaded the .ubx
I used RTKCONV to turn the log into RINEX files. Then I downloaded the CORS logs by specifying a VRS at my location, specified the time range starting a little before and running a little after. Used RTKPOST to reconcile my data with the logs.
Using the viewer in RTKPOST it shows no coordinate (s) at all.
One thing is that the elevation shown by Reach in status is a lot different than anything else I have for reference as if it is a different scale than everything else I am using. It reports about 70m where all my other regular gps, maps, google earth, etc. show ~90m. Is there an explanation for this?
That’s correct. Saving a point in project and logging are separate. Saving a point in “single” usually wouldn’t be of much value. I recently went through the learning process of post processing a single point to calculate my base station position. From RTK plot you can export a file that can be opened in excel. I used average function in excel to average the fixed position readings of lat long and height and get one set of coordinates from many close ones. You need to research geoid height vs ellipsoid height to understand the reason for the height difference. I can’t explain it but you’ll find quite a bit of information on it on the forum.
Did a quick search and my head hurts. From a practical standpoint, is the z value from Reach going to be usable for uas mapping and volumetrics or does a transformation need to take place. It looks very complicated to convert one to the other.
1 Like
Yes, I also am learning about transforming points from one coordinate system to another but, to be honest, I don’t know the ins and outs of datums, ellipsoids, and geoids. Are datums and coordinate systems bound to each other?
Or can you use any datum on any coordinate system? Unfortunately, I can’t help you much on this… But I can help by adding my voice to your message! Someone, help make it simple! 
- How do we handle height information (especially when post processing!)?
- What happens if the CORS station uses a different datum and you post process your reach logs with wgs84?
- When do we care? and when do we not need to worry about datums?
I don’t want to detract attention from dpitman’s post but rather draw attention to it.
The reach log was over an hour and I didn’t get anything. Perhaps my data was not sufficient but I don’t know how to determine that. I did not get any errors.
Here’s what I use to calculate my ellipsoid difference.
Example:
Say your Reach gives you…
Lat: 40.xxxxxx
Lon:-82.xxxxxx
Elev: 215.xxx
You enter those Reach coordinates into that website below and lets say it kicks back an adjustment of -33.15.
I would then take my original Reach Elevation(215.xxx), and then add the 33.15, so now my Elevation is 248.xxx.
https://www.ngs.noaa.gov/cgi-bin/GEOID_STUFF/geoid12B_prompt1.prl
Hopefully this helps.
1 Like
That gives me an adjustment of -21.21 meters. If I add that to what Reach is telling me I get approx. 90 meters which is what I would expect.
Thanks for that link! I wonder if Maps Made Easy, or Agisoft does the conversions on the fly when generating orthos?
If you are using a DJI and using those images in MME, they aren’t really doing a conversion because the drone itself is already reading the “correct” Elevation. It’s not that Reach isn’t correct, it’s just they are both reading the elevations but just using two different systems. If that makes sense. So it’s not that they are converting it, they are just reading that system to begin with.
When I create my “notepad/txt/csv” document with all my coordinates from the Reach that can be loaded into QGIS, I first copy and paste into excel and use a quick formula to convert all my elevations at once using that number from the website for my correction.
…deleted
Is there no coordinates in your converted raw file?
…deleted
I think that perhaps I had selected the wrong time period when requesting CORS logs because it is asking for GPS time and I put in local. This time I did indeed receive coordinates…yay!
What is the best way to get the coordinates out of the .pos file into excel to average?
Dane, how do you create your .csv? Also, in case you haven’t seen it, I found you can specify GEODETIC for height in the OUTPUT tab in RTKPOST. Maybe can save you a step.
Alarm Bells!
When you export using Ellipsoidal Height you know exactly what the reference is. It is the WGS84 ellipsoid.
Normally the relationship between WGS84 and the local datum is well defined.
If you select Geodetic you have to know the model you are using and its relationship to your local datum.
This is less easy to find.
As for import into excel, it doesn;'t need to be .csv it can bbe the pos file (same for QGIS)
if you have processing options and headers turned on in rtkpost …
In excel . Open file (.) start import at line 26, my data has headers, delimited text (space as delimiter) . and in it comes
1 Like
The Geodetic height seems more user friendly to a non surveyor. Looking at monuments I can find in my area, GEOID12B always comes up. Is that the model that needs to be used? For your script that edits the exif of the images, is the height of the uas defined in ellipsoidal terms? And if so, is it converted to geodetic in SFM software? I know the guys on the construction site would be totally lost if the map elevations were in ellipsoidal terms.
I have headers on so I’ll import into Excel and see how it goes. Is it best practice to just do a straight average of the coordinates and heights? And the longer the logging time the better?
@dpitman
Really depends on how local your work is.
For a small area you can assume that the offset between the spheroid and a local datum is constant (within RTK measurable amounts) and therefore you can apply a fixed offset. For any of my local reference marks I have a height relative to Australian Height Datum (AHD). If I set up on one of those spots and enter my base position relative to that point and am working within a few km of the mark I am effectively working to that datum. further afield I have to know the rate of change of the relationship between the local datum (effectively a geiod with a local height offset) and the ellipsoid. That information is normally readily available through state survey depts.
BUT more importantly HOWTO skip excel and do your averaging in QGIS.
I will use a base that I set using SINGLE point positioning as it has a bit more spread and looks prettier.
I collected a load of data at a point and I want to ‘average it’ to get a final point position.
Remember GPS data is a point cloud in 3 dimensions.
We tend to look at it like this (the lighter the colour the more points overlap) in 2D.
But we should think of it like this, in 3D
QGIS has the tools to do what we want: Namely Mean coordinates and basic statistics for numeric fields (height being a numeric field)
Example of my height statistics for the cloud of points shown.
Why do it in QGIS?
Because it is easy to see it!
And
I can filter the data based on any of the fields in the .POS file.
If this was PPK data rather than single I could use the Q flag to filter only for fixed positions, and the SD fields to filter poor records, or the number of satellites to reduce the observations to only the good ones.
Hope this helps
3 Likes
@Simon_Allen
Yes, your approach makes perfect sense. I will probably send you an email with some questions. Thanks for your help!
Hi Dave, I have gone thru many of your questions with using the reach and post processing, coordinate conversion, etc.
Here are a few things I have learned.
1.Reach RS logs data in UTC, or Zulu or Greenwich Mean Time. All the same. You need to know your time zone offset from UTC. On the west coast of the USA(pacific std time) the offset is -8hrs. When you collect data and download to you desktop, consider putting the files in a folder with the date… Ex. Raw GPS 2017-10-12.
Then when you go to download your CORS Data (if in US try UFCORS) download each UTC date (24 hours) that your data was collected in. Sometimes in the late afternoon I “bridge” from one UTC date to the next.
-
The Reach RS collects data in Geographic Coordinates using WGS84. Elevation is ellipsoid height in meters (Not Orthographic or Mean Sea Level). DO NOT CHANGE This until you are done post processing.
-
Most of us will need to project the data and convert the vertical Datum. In my case I need to output horizontal coords to California State Plane coordinates in NAD83, units feet, and Vertical coords (Elevation) to NAVD88 (MSL) in feet or meters.
A nice tool to do this is NOAA’s vDATUM app. It handles batch conversions from one coord system to another. You can find info and download it here: NOAA/NOS's VDatum: About VDatum Project
I hope this helps a bit. I have been able to usually get sub centimeter accuracy and good control for my Drone Mapping.
Andrew
3 Likes