How to take a forever GPS based survey (if there is such a thing)

GPS/GNSS
1

I have a Sparkfun Postcard that I purchased for purposes of mapping underground private utilities on our property in East Tennessee (Calhoun, TN). I’m finally ready to start that process and I want to make sure that I do this right so future generations (or me 10 years from now) can rely on the data points I record this year.

Assuming I have an RTK fix on my equipment, what should my settings look like in SW Maps to be as “standard” as possible for someone to use that data without confusion? For starters, what should I choose under Project settings/coordinate system? We border TVA land and they supplied me “NAD83 Tennessee State Plane Coordinates” for their monuments. Should I use the same for my work? If so, that seems to indicate I should use either EPSG code 2274: NAD83 / Tennessee (US Survey Feet) - The most common projection used for local engineering surveys, zoning, and state-level mapping (according to Google) or EPSF code 32136: NAD83 / Tennessee (Meters) – The federal and metric standard definition for Tennessee State Plane coordinates. Maybe I need to ask my TVA contact which one they use.

Are there other settings that I need to set in SW Maps to make sure my data is future proofed? I would hate to go through huge amounts of work to collect the data and then find I did it wrong.

Also, with tectonic plates shifting over time, will someone 100 years from now have to carry this data forward to new coordinates or is that factored in so that a given coordinate will always point to the same survey marker for example?

Thanks so much for your insight.

2

You are asking the right questions, for sure.

I think this is one of the best docs to get you started, if you haven’t already seen it :

It’s old, but still a great document.

What Correction Source will you use for RTk ?
->Your RTK positions will generally be in the same reference frame and epoch as the Base unless you transform them

Will you use iOS or Android version of SW Maps?

3

Short Answer:
Leave SW Maps in WGS84, because that’s native and what it expects GNSS positions to be.

Example:
The reference frame associated with the PointPerfect Flex correction service is ITRF2020, and the epoch updates are performed quarterly (currently). Modern realizations of WGS84 and ITRF2020 are coincident generally at the centimeter level. So you can setup your SW Maps project as WGS84 and log RTK points as the same. [Note: for mapping context in this discussion, not control] Keep the metadata with your work (reference frame, and epoch of the correction), and future users will always have what they need for a transformation later.

Naturally, the engineer in me would much prefer using State Plane Coordinates for a Civil Project - but that’s not your scope. This gets even more complicated since NAD83 is a is a geodetic reference system. It models the curved, three-dimensional surface of the Earth using an ellipsoid shape. However, The State Plane Coordinate System (such as the TVA control you mentioned) is a grid projection built on top of the NAD83 geodetic datum. It uses flat-surface map projections to flatten the Earth’s curve into a localized grid for higher accuracy on a particular site or project.

It’s not hard to get this right, but it’s also pretty easy to mess things up.

The Key is to always publish the metadata along with your positions (be clear on the Correction Source reference frame and epoch date), to future-proof your work :slight_smile:

If you ever swap correction sources (with a different reference frame or epoch), you’ll need to keep the work separate or perform a transformation to align all your points into one system.

When starting out- one thing you can do is establish a Control Point with an independent method. Use your PostCard to log a 24-hour static session, covert to RINEX, and submit it to CSRS-PPP. The report will give you the specific reference frame and epoch used in the analysis. You can always use that control point as a check-in point to confirm any RTK source. But you’re also confirming a lot more (your entire setup/system) if the converted RTK position doesn’t align with the accurate PPP 24-hour position. That’s a sure-fire way to be forced into understanding the reference frame/epoch situation and a great way to gain confidence :slight_smile:

4

I haven’t read through the linked document yet but, to answer your questions more timely, I’m using PointPerfect Flex on an Android device (Pixel 9 Pro).

5

Then the easiest is to stick with ITRF2020 reference frame (with the epoch year, and quarter, that you collected the data).

You are North of me, but let’s assume TN moves ~2cm per year…just for discussion/fun.
PointPerfect broadcasts raw positions in the global ITRF2020 reference frame, its coordinates are dynamic. When you store a point in 2026, your PointPerfect corrected RTK coordinates are relative to the Earth’s center of mass at that exact moment in time (currently Epoch 2026.5).

Over the next decade, the North American plate will physically slide ~ 20 centimeters at your location (that’s an assumption, I didn’t research your location). So a future user a decade from now will need to perform a time transformation to update the coordinates to 2036 to recover an underground utility, to account for the plate motion. But, professional data collection apps have this ability “built-in”. I would assume freeware apps will eventually. SW MAPS can import a layer and perform the transformation, but I think it will always assume the incoming real-time GNSS positions are always WGS84 (not certain), for now.

OR - you can choose a plate-fixed reference frame such as good-ole NAD83.
NATRF2022 will replace NAD83 as the new plate-fixed frame, and SPCS2022 will replace the old State Plane zones. But- the trick with using a plate-locked system is a future user will also need a correction source that’s broadcasting it’s position in that same reference frame, or apply the transformation on-the-fly with their data collector.

Since you plan to use PointPerfect as the correction source, just tag your positions with ITRF2020 (Epoch 2026.5). Since PP updates the reference frame quarterly, any points you collect this fall will be Epoch 2026.75, and so on. That’s overkill for underground utilities, but it’s the correct procedure to future-proof your RTK work.

Something else to consider is to commission your own base station with a 2’nd Postcard. If you used PP Flex to establish the Coordinates for the Base Antenna this quarter, all your future RTK work would be locked to ITRF2020 (Epoch 2026.5) when using your PostCard Base Station.

What commonly happens is this:
PointPerfect is used to collect very accurate RTK positions in the ITRF2020 frame. Another user assumes these positions are WGS84, and that still basically matches on the ground. 10 years later, the tectonic plate has moved 8" and they still appear “pretty close”, even when WGS84 was assumed incorrectly and the Epoch was ignored. This works fine for casual users, but is a disaster for Control Work or professionals. [For Control, we almost always use a fixed frame.]

6

Having just had a fiber line to my house replaced because the cable TV guy couldn’t be bothered to call 811, I definitely feel your pain.

If we were talking about miles of utilities, or state-wide information that we are tracking, then I think the idea of correcting for plate shift and data source references would be great. However, if this is just to map out stuff in your own (literal) backyard, then my suggestion is to locate them as thoroughly as possible, locate other points (like house corners and road edges) and then plot those out to a PDF document (or a piece of paper if you’re old school).

The relative locations of those things will be much more useful in the future, and much easier to reliably locate.

I manage locations on a 400 acre university campus, and we’ve already run into issues with WGS84 versus state plane coordinates showing things about 3 feet from where they actually are. We’re not using Sparkfun hardware for locations, but the equipment I’m using gets me within a foot or 2 every time. It really comes down to what we’re locating. If it is a buried pipe, as long as we’re within 3 feet, we can avoid hitting it, or find it when needed. It if is a surface feature (meter valve lid or manhole), then we just need to be in the general area and have a metal detector if it has been covered by mulch/dirt.

The hard one is the irrigation equipment. We locate valve boxes (plastic) but getting back to those needs more precision. The best tool I’ve found is attaching a photo to the point location and being able to figure out where to go from the photo. I haven’t tried that with SW maps though, so I’m not sure if that feature is available. (I’m using ESRI tools and ArcGIS Field Maps for our work.)

My original data is from 2014-2016 time frame, so I’m just coming up on the 10 year mark for locating things again. Now, I’m verifying locations with orthometric photos taken from a drone, so the technology keeps moving forward.

7

I’m sorry to say that I still don’t understand what that means I should choose in the SW Maps settings. When you say, “Leave SW Maps in WGS84, because that’s native and what it expects GNSS positions to be.”, is that to say that we don’t need to make any changes to the coordinate system settings (the UTM and EPSG Code settings)?

I’m guessing that the UTM zone will auto setting will get that right based on one’s location but that we still need to select an EPSG code the relates to WGS84. That gets more confusing as there is more than one choice. I read the following online:

The primary EPSG code for the unprojected WGS 84 coordinate system is EPSG:4326. [1]

Depending on your specific project requirements, you might need one of its closely related variants:

Common WGS 84 EPSG Codes

  • EPSG:4326 (Standard 2D): The standard unprojected geographic coordinate reference system (CRS) using latitude and longitude in decimal degrees. This is the most common format used by GPS devices and standard GeoJSON data. [1, 2, 3, 4, 5]
  • EPSG:3857 (Web Mercator): The projected coordinate system used for flat, 2D web map tiling. It is utilized by platforms like Google Maps, OpenStreetMap, and Bing Maps. [1, 2]
  • EPSG:4979 (Standard 3D): The three-dimensional version of WGS 84. It includes latitude, longitude, and ellipsoidal height. [1, 2, 3, 4]
  • EPSG:4978 (Geocentric 3D): A 3D Cartesian system using X, Y, and Z coordinates mapped directly from the Earth’s center of mass. [1, 2]

With the desire to view my underground utilities on Google Maps, it seems like EPSG code 3857 would be best. However, that is 2D instead of 3D so I suspect that it will not capture elevation data which I would like to use for marking the depth of the utilities.

Can you further help a layman know what the settings should be based on your advice?

Thank you so much @rftop for all the professional knowledge you share with this group. It is much appreciated.

8

@David_Jensen , a lot of things are getting scrambled up in your last post.

Let’s take it 1 step at a time… I like to begin at the actual work => the RTK position.
So we start with the Reference Frame. Any particular reference frame is a realization of the Reference System. A Reference Frame is “realized” on a particular date (the epoch). Since you plan to use PointPerfect Flex, all RTK positions will be ITRF2020 (Epoch 2026.5 currently). Any points you collect after October will be Epoch 2026.75, and so on.

Your RTK coordinates will always be in that ITRF2020 (current quarterly epoch) Reference Frame, unless you specifically perform a time dependent transformation.

You have other options if you don’t like ITRF2020 Quarterly Epochs. You can setup your own base and perform a 1-time transformation for it’s position into a Plate-Fixed System, or even the new Modernized System. Just remember everything starts at the Base, you inherit it’s Reference Frame.

Independent of the Reference Frame : Changing the EPSG Code in SW Maps is changing the Map Projection… Think of it as stretching/shrinking the Map’s Grids to fit on a flat sheet of paper. A completely different animal verses the Reference Frame.

For Your forever survey : A well-documented point preserves the reference frame and epoch, a clearly labeled Ellipsoid Height, the datum and geoid model for orthometric elevation (if used), the correction source, collection date, and basic quality indicators such as FIX status, PDOP, and observation time. With that metadata - you RTK points can live forever. How you (or anyone else) chooses to display those points on a Map do not change your work product.

Does that help any?

As far as Google Maps… here’s the bad news. Your positions are much more accurate than the Satellite Image registration (orthorectification) of Google. Accurate Positions don’t generally align well with free Aerial Imagery.

But the Good News is you can create extremely accurate imagery of your property with ultra resolution…and UAV’s are very cheap these days.