I am new to SparkFun products, but just received my SparkPNT X2. I just finished connecting to the GPS using SW Maps (iOS) and got the NTRIP server working (I am accessing MDOT CORS corrections).
This seems like fantastic setup for the work I need to do, but I noticed that all of my data is shifted about 1.3m to the southwest. I immediately assumed I had a coordinate system mismatch.
After a bunch of poking around I think I found the problem - the MDOT CORS system sends corrections in NAD 1983 (2011), but SW Maps operates exclusively in WGS 84. All of my exported data reflects this shift. It seems the Android version allows you to change the coordinate system within SW Maps but the iOS version does not? As a result, all of my exports reflect WGS 84 data ‘corrected’ with NAD 1983 (2011) that SW Maps incorrectly assumes is also WGS 84.
I’m a longtime user of GIS but not an expert. I am not sure I correctly identified the issues. But if I did, is there any workaround for this with an iOS device used as a collector for the SparkPNT? I love the hardware but, given an iOS mobile device, I seem to be out of options to use the RTK corrections unless there is an alternative to SW Maps?
Your RTK points will indeed inherit the NAD83(2011) reference frame. SW Maps (iOS) will save the coordinates correctly, but the metadata will be wrong (as you mentioned).
You can export your file and then manually edit the projection(.prj) file.
You would correct the reference frame declaration to:
Do that once and you can re-use that .prj file over and over as a workaround for exporting shapefiles from SW Maps(iOS). The RTK positions are correct, SW Maps (iOS) just labels the metadata wrong.
“Normally”, changing the Reference Frame or Coordinate System in a software package is just a data label… unless you ask it specifically to perform a transformation.
The next thing you will likely discover is the RTK points you collect now will be related to the earth’s crust as it was in 2010, since MDOT CORS uses the NAD83(2011) Reference Frame. It’s a fixed-plate frame. The 16 years of local tectonic plate motion are “removed” because the base stations in the MDOT network are sending their observation data based on their static position from the 2011 realization. The State’s CORS Network moves with the tectonic plate, so the coordinates stay the same even though the ground has moved ~half a meter since 2010.
Depending on what you are doing with your RTK points, this can be extremely valuable or frustrating. When is just as important as Where, in high accuracy GNSS.
After correcting the .prj file from the SW Maps export - If your RTK points still don’t show agreement with a 2’nd data source, you’ll want to identify the reference frame of the 2’nd data source.
That’s super helpful, thanks! The .prj edit definitely moved the points in th right direction, and look much closer to ‘correct’, though it does not look like the claimed ~8mm accuracy has been achieved…
…BUT I also realized this morning that a ‘perceived’ shift could very well be (at least partially) caused by inaccuracies in the base layers, if I am simply judging by eye. I’ll need to check my RTK data from the GPS unit against some known survey data corrected with MDOT CORS to be sure where I stand. So in the end, I think my first visual on the data revealed two separate issues - a CRS mismatch AND some shifting in the base map data which, together, made the data look way off where it ought to be.
Thanks so much for the tips!
At least this means I don’t have to buy an Android tablet and hotspot it to my iOS phone just to get RTK with my GPS…hopefully someday SW Maps includes the CRS switching feature in the iOS version. Because with SW Maps, the SParkFun GNSS units do a lot at a very low price.
Ryan.F’s diagnosis and fix are right, but one explanation is off, and there are a few things the thread should also have said. I read posts #1–#5 through the forum’s raw view.
What Ryan gets right (posts #2 and #4)
With RTK, the rover’s coordinates are in the frame of the corrections source. MDOT CORS broadcasts NAD83(2011) epoch 2010.00, so the points really are NAD83(2011). SW Maps on iOS just labels them WGS84. The coordinates are fine; the label is wrong.
Editing the exported .prj to say NAD83(2011) (EPSG:6318, or the matching State Plane or UTM code) is the correct fix. It changes what the file says, not the numbers.
Changing a CRS label doesn’t move data. Only a transformation does. That’s the key point, and he makes it.
Where post #4 is wrong
He puts the gap down to about half a meter of tectonic motion. In Michigan, NAD83(2011) and current ITRF/WGS84 differ by roughly 1.2–1.4 m horizontally. Most of that is a fixed offset between the two frames’ origins. Only about 0.3–0.4 m is plate motion since 2010.
The original poster’s 1.3 m shift therefore fits the datum difference almost exactly. It isn’t mainly basemap error.
What the thread is missing
Which transformation the GIS uses. After the .prj fix, ArcGIS or QGIS converts NAD83(2011) to WGS84 to draw the points over the basemap. If it picks a null or “ballpark” (zero-shift) transformation, the points won’t move at all. In ArcGIS, the right one is WGS_1984_(ITRF08)_To_NAD_1983_2011. In QGIS, check which transform it chose. Post #5 says the points moved, so a real transformation was probably applied.
Imagery can’t check 8 mm. Esri and Google imagery is usually only good to 1–3 m or worse. Also, the ~8 mm in the spec is RTK precision relative to the base station plus about 1 ppm of distance, not accuracy against the ground.
The right test. Set up over an NGS or MDOT control point published in NAD83(2011) epoch 2010.00 and compare the raw numbers, with no transformation and no basemap. Post #5’s plan to compare against MDOT-surveyed points is the right idea, as long as that data is also in NAD83(2011).
Heights are the next trap. SW Maps may record ellipsoid heights, while local survey data is usually NAVD88 heights from GEOID18. They differ by about 34–35 m in Michigan, so check that before comparing elevations.
Yes, I was quickly testing out my new toy when making the initial post, and forgot some of my fundamentals in the heat of my aggravation with the iOS version of SW Maps. The base imagery is of course helpful in making sure you’re in the vague ballpark, but when it comes to judging sub-meter accuracy it is useless. I am going to go gather some data over nearby NGS control points to get a real sense of what my data looks like.
When I altered the prj ArcGIS was showing the transformation you mention, so I am fairly certain Rysan F.'s solution did the trick as far as my CRS mismatch issue is concerned.
Vertical accuracy is not something I am especially concerned about for the moment, but thanks for the tip on the potential elevation discrepancies, I will keep that in mind as wall.
Appreciate all the help! I do plan to get a second SparkPNT so I can do a base/rover setup in remote locations, but getting this SW Maps / NTRIP to work with MDOT CORS was important.
After some digging in the documentation I did notice that my SparkPNT can supposedly serve as it’s own NTRIP client via wifi to my phone with the latter as a mobile hotspot, but the documentation does not seem to contain a step-by-step how-to. I wonder if that would allow me to get RTK corrections on an iOS version of Esri Field Maps without any other software (although would I run into the same CRS mismatch problem? What is the CRS used by the built-in NTRIP client? Probably WGS 84?)…I’ll have to investigate that further.
