Troubleshooting a Coordinate Mismatch

Emlid Flow & Emlid Flow 360 Coordinate Systems
1

We have been using the Emlid REACH RX and Emlid Flow 360 to collect ground data for our projects, but have been running into an issue where our GPS points collected differ from our survey control points by about 3.5’. Fortunately, each of the points are off by about the same distance, so we can batch correct them, but we would like to understand where the issue is stemming from (and hopefully not have to make the extra step in processing corrections in the future). I’ve already visited the page for “Reasons for a coordinate mismatch and how to fix it” and followed the helpful steps to try and correct it, but am having no luck.

Some more information about the issue with a project file attached for reference:
We export our survey points from Emlid Flow 360 as a .csv file in PENZD format, clean them up and reformat them to PNEZD point file format, and import them to AutoCAD Civil 3D as COGO points (“Insert” Tab, “Import” panel, select “Points from File” and navigate to the .csv file). I’ve tried doing this both with and without “Do elevation adjustment if possible” and “Do coordinate transformation if possible”, but the points turn out the same regardless. When loaded to CAD, the points are slightly off from our three control points (provided by our project survey):

  • The first control point has a -3.5’ difference in elevation and a 5.5’ difference in distance (-5.30’ in the x direction [west] and +1.44’ in the y direction [north]).
  • The second control point has a -2.26 difference in elevation and a 5.4’ difference in distance (-5.19’ in the x direction [west] and +1.63’ in the y direction [north]).
    *The third control point has a -3.53 difference in elevation and a 5.38’ difference in distance (-5.17’ in the x direction [west] and +1.48’ in the y direction [north]).
    All three control points had a FIX. We were receiving corrections from UNAVCO NTRIP host station P230, which is within 5 miles of our project site.
    When we manually move the points to match the control point locations, the elevations adjust to the surface and are corrected to within tenths of a foot.

The coordinate system used in the GPS/base: NAD83(2011) / California zone 3 + NAVD88(GEOID18) height
Units: US survey feet
Datum: GRS 1980
Projection: Lambert Conic Conformal, 2SP (Mercator)

Coordinate system used in CAD: NAD83 CA State Plane Zone 3
Units: US foot
Datum: NAD83
Projection: LM (Lambers Conformal Conic Projection)

We have noticed this ~3’ discrepancy on at least one other project we have used the GPS for, so I don’t think it’s an issue with our survey, rather some fix we need to make in our GPS settings, with our NTRIP, or a transformation that needs to happen after collecting the data. The points appear differently in CAD, but also are different from the control points before exporting from Emlid, which leads me to believe it is not an issue with how I am importing them to CAD. We checked with our surveyor and the only advice they could offer was that it may be an issue with our units (e.g., we may have used meters instead of US survey feet), but we verified that the GPS, Emlid project, our NTRIP host, and CAD have the same units and coordinate system.

We would appreciate any insight on this issue. Thank you for your time!

1 Like
2

Can you try another NTRIP station to rule it out? Or measure a KNOWN BENCHMARK POINT from a public record to make sure NTRIP station isn’t at fault?

1 Like
3

Where did the original coordinates come from? Sounds like a localization or a US vs International Feet to me but a whole different issue vertically being that far off and the relativity of the “known” data being more than a foot off from each other. I know you mentioned CAD but that means nothing in the real world. CRS’s can be set to whatever you want in the software and points can easily be moved.

1 Like
5

I have a similar issue with the Texas state plane and when I checked the False Northing and Easting they are different in Emlid compared to ArcGIS projection data.
Check if the False Northing and Easting are different from the CA state plane.
To avoid that I switched to UTM coordinates

1 Like
6

Hi @erik,

I agree with Tim’s suggestion to do a test on a benchmark. Do you have them nearby? Can you please collect one and share a CSV file and its coordinates with me?

2 Likes
7

Hi Raed,

Hmm, what are the false Northing and Easting you need to work with?

9

Hi @timd1971 AND @julia.shestakova, thanks for your tips. I work with Erik and am troubleshooting this issue with him. I’ve tried to locate a few different NGS benchmarks nearby to use our REACH RX to test on them, but have not had any luck recovering them. I’ve been using the NOAA/NGS map online to find these points, but unfortunately it looks like a lot of them are out of date (the few I’ve looked at were last recorded in the 90s and I wasn’t able to find them myself). If you have tips on where I could find known benchmarks, I’d appreciate it. It looks like I’m not able to share .csv files in this forum, but I can share this .pdf that includes the GPS coordinates we recorded using the REACH RX and the control points from our surveyor to show the difference/discrepancy. In the file, points 1 and 8, points 6 and 9, and points 7 and 10, should all be lining up (respectively), but you can see that they are each offset from each other in distance and elevation. I hope this helps and thanks for any time and insight you can offer on this.
EMLID REACH RX Survey GPS Issue 2023.10.16.pdf (39.3 KB)

12

Hi @Hannah and @erik,

Just want to let you know that I am investigating this now. I checked the pdf file you uploaded and noticed that the Northing, Easting, and Latitude coordinates are truncated. Could you please send the CSV file to support@emlid.com?

I couldn’t find anything definite about the datum UNAVCO broadcasts its corrections. A quick check says it’s ITRF2014, so this could be the reason for the mismatch. I suggest reaching out to UNAVCO to determine their broadcast datum.

Meanwhile, try converting the ITRF2014 geographic coordinates to NAD83 using the NGS Horizontal Time Dependent Positioning tool, and then the NCAT to transform them to a different NAD83 realization in State Plane. Compare it with your benchmark and see if the consistent mismatch checks out.

If you have tips on where I could find known benchmarks, I’d appreciate it

As you have checked the NGS Data Explorer already, I suggest contacting your County or City’s Survey division. I saw that the survey area is somewhere in Alameda County, and I found this website where you can access survey data. Have you checked them out already?

4 Likes
13

Erik,

AutoCAD always works in flat, rectangular planes. In Civil 3D however, there are additional features that help convert the flat world into data that is useful for GPS. Without using these “conversion” features, you will always get your points in the same place. Where I am, if I do not take this into account, it could be as much as 400mm out of position over 1km (using a local scale of 0.9996)

In Civil 3D, you will need to set your drawing up to do these conversions for you, but what is often overlooked is the difference between Easting/Northing and Grid Easting/Northing. Civil 3D needs to know the difference as part of the import/export of the points.

In “Drawing Settings”, under the “Units and Zone” Tab, set up your coordinate system (make sure your drawing is in feet if your EPSG is in feet), then under the “Transformation” Tab, tick the box for “Apply Transform Settings” and set the appropriate reference point in the drawing. This reference point could be a local benchmark, just make sure to match the Local Easting/Northing with the Grid Easting/Northing from your observation. Make sure to also set the “Grid Scale Factor” to either “Reference Point” (software calculated from EPSG) or “User-Defined” (if you know the correct scale factor for this point).

When that has been done, when you then go to import your points from file, you will need to modify/copy the “PENZD” format (or whichever one you’re using) and change the “Easting” and “Northing” columns to “Grid Easting” and “Grid Northing”. Zone Transform can stay unset.

When you save this and go back into the Import Points window, select your file and leave all of the Advanced Options unset.

You should then find your points are imported and are located on different coordinates. When you select your Reference Point (will have a sort of red circle over it indicating its the reference location in the drawing) and open up the properties, you will see the Easting/Northing and the Grid Easting/Northing are the same. If you then select another point much, much further away, you will see these two values no longer match. The Grid Easting/Northing should be the expected coordinate you are chasing, but the normal Easting/Northing will be a completely different value. This is normal and the accuracy of which comes down to your observations and the Grid Scale used for the drawing.

You will find now that when you measure between points, the normal Easting/Northing should basically give you the true ground distance (assuming same elevation). Just remember that Civil 3D normally snaps to objects in the Z direction, so perhaps manually change your 3dpoly or polylines to 0 for all nodes if you want a ground distance. This distance should more or less match any terrestrial survey between points, such as what’s done by Total Station.

In reverse, make sure you then export Grid Easting/Northing for points to then stake out.

Remember too, this does not take into account Localisation that may have been performed through Flow. If you have localised through Flow, most of what is said above will more or less be useless depending on the specific scenario. I have a completely different method I use if I use Localisation.

Hopefully this helps you out, or get you to the next step?

Joel

1 Like
14

Hi Ruth,

Thanks for your help. I emailed Emlid with the .csv file. I also reached out to UNAVCO to confirm the datum they use to broadcast corrections. They responded that all of their positions are in ITRF2008. I am having a hard time understanding how to convert from ITRF2014 to NAD83 using the first link you provided; it states at the top of the web page that “HTDP should NOT be used to transform between NAD 83 realizations (2011, NSRS2007, HARN, etc.). It will not give correct results”

Thank you for the tip from the Alameda County website. I checked it out, but unfortunately wasn’t able to find any survey benchmarks using their GIS search tool.

We are continuing to check known survey benchmarks each time we go out to use the GPS, and while we are still finding that our values are consistently displaced from the known benchmarks (regardless of the base we use / station we are receiving corrections from). Each time, we make sure that the datum and coordinate system we use to set the project up are the same as the base. At least our errors are systematically off so that we are able to make the corrections afterwards.

Thanks,
Hannah

15

If you found a known benchmark, you need to get the recorded data on that known benchmark, then set your base on it and ENTER that known benchmark data MANUALLY (using the SAME coordinate system horizontally and vertically as the data on record). Then everything after will be measured cm level based on that known benchmark point. Best to locate another known benchmark nearby also to check/compare to.

Your post says you couldn’t locate any known benchmarks but also says you did? ???

1 Like
17

I understand that, thanks. When I mentioned “known benchmark” in my last message, I was referring to a control we are referencing from a private survey for the project, not publicly available benchmarks, which I have been having trouble finding the monuments for. Sorry for the confusion.

1 Like
18

Why not contact the surveyor who provided the control ? That would at least give you correct datum for his data.

He may be on some localized system other than the NSRS

2 Likes
19

Thank you for the tip, but we actually contacted the surveyor first thing to troubleshoot this issue. I think that at this point, there is a disconnect between the feedback we are getting in this forum and the problem we are having. To clarify, our problem is that when we receive a survey that is in CA state plane and NAVD88 datum and we use our GPS to re-occupy the site, including local control points, we are always off by a few feet horizontally and vertically. The expected function is that our GPS will take us to the exact spot within the error of the GPS solution, which should be centimeters, not meters. I don’t think that finding a known benchmark is an issue; we essentially have known benchmarks with all of our surveys that are georeferenced. Perhaps a GPS is typically off by feet compared to a survey, but we assumed that if it is CA state plane, that it should like up exactly. Is that assumption correct? Should be expected that - when we receive a CA state plane survey with control points and our GPS get a fix - that it should be within inches (not feet) of the control points? And if it should (and our assumption is correct), but our results are not within inches, but rather feet (as is the case for us now), what should we do to troubleshoot it?

1 Like
20

Yes, you should be getting cm accuracy (less than an inch at that) if everything is locked in correctly.

Sounds like u need to post some screen shots of your base settings? Probably provide data for at least 1 known benchmark from surveyor to look at along with their coordinate system used.

I am not familiar with the RX… but sure someone can help with that.

2 Likes
21

@Hannah , I have had success in using a custom CS when working between “Improved” Datums and CORS propagating either New or Old corrections (depending on which way I need to “convert” my coordinates). For me, I found the relevant 7 Parameter Transforms which defined the difference between one Datum to the other (about 1.8m NNE), then the corrections work for me.

Something to consider though, you’d need to be certain of what this method does with your data. Depending on the Datums (and how they are defined in relation to each other), there may, or may not be differing Geoids, which affects what could be the change in Z.

For clarity (for those interested in my case), Australia recently shifted to a new Datum. This moved us (pun intended) 1.8m NNE to match WGS at the time (1 Jan 2020). The old Datum was GDA94 (1 Jan 1994) and was more recently on ITRF2008, the new Datum is GDA2020 and is on ITRF2014. ICSM has published a Technical Manual describing in detail this change, including 7 Parameter Transforms between GDA94 and GDA2020.

For me to then utilise GDA2020 Corrections from CORS with GDA94 data in Flow, I have a custom CS with the 7 Parameter Transforms with opposite signs (multiplied by -1). Further, because we also had a Geoid change, this Custom CS then utilises the previous 2009 Geoid. This allows me to effectively work between new and old data as I need to.

@Hannah , perhaps there is a similar document which has a similar specification to be able to work between Datums and not be the same number of freedom units out?

Hope this helps you find the information you’re looking for.

Joel

2 Likes
22

There’s something seriously wrong … either the provided control is not what it is claimed to be or it’s user error either using the equipment/software or inputting the data into your cad program. Is the “surveyor” that provided the data licensed and knowledgeable in the GNSS field ? Are you a professional land surveyor/geodesists that has knowledge in geodetic methods/computations, is there a person on staff that has knowledge in this field ?

Also, I find it difficult to believe that there’s no NGS passive markers to find and locate near your project site. If there are passive marks found to verify your use of the equipment, the control marks should be in the same datum as your project coordinates. You can actually “stake out” to control marks using RTK by setting up your project in the receiver software using your states coordinate system and inputting the NGS passive control marks coordinates. Even in desolate areas, NGS OPUS or PPP use can verify the sites coordinates.

2 Likes
23

:bulb:

NGS Survey Map | National Geodetic Survey (noaa.gov)

ngs
ngs1920×1190 304 KB

2 Likes
25

Hi guys,

Hannah, thank you for sharing the CSV file. I checked it and looked through all the comments here once again. I second Ruth’s assumption that the mismatch seems to be coming from the difference in the datums.

When you choose the NAD83(2011) / California zone 3 coordinate system for your project, Emlid Flow asks you to make sure that your corrections are in NAD83(2011). However, UNAVCO base stations provide data in ITRF2008. This causes a mismatch: Emlid Flow applies the state projection to the data as if it were in NAD83(2011) when it’s not.

I see 2 possible ways to solve it:

  • The first one was suggested by Joel. You can create a custom coordinate system in Emlid Flow and specify the parameters of transformation from ITRF2008 to NAD83(2011) and California zone 3 projection.
  • The second is to use Localization. You’ll need to measure about 5 points with known coordinates in the target CRS. After that, pair the measured and known coordinates, and the app will calculate the transformation parameters for you. Here is a guide about working with it.
3 Likes
26

I found this converter. You can try to use it for the already collected data. You’ll need to convert the geographic coordinates from ITRF2008 to NAD83(2011) and then apply the state projection.