Allisyn,
Your configuration is very similar to the setup we are currently using for our operations. Our RTK is running on GCS NAD 1983(2011). We are using ESRI base maps for field work on the collector units which are WGS 1984 Web Mercator Auxiliary Sphere. The transformation we are using is WGS_1984_(ITRF00)_To_NAD_1983_2011. One item you do not note in your question is what coordinate system is your feature data service published to AGOL for collection. As our enterprise database is using NAD83(2011) Ohio State Plane North, this is what we publish our feature services to AGOL. AGOL and Collector handle the transformation from GCS NAD 1983(2011) to PCS Ohio State Plane North NAD 1983(2011). This has worked well for us.
We also have to provide our data to several other agencies in WGS84 and NAD83(1986) so we have projection scripts running to process this information on a nightly schedule and generate deliverable files. To insure there have not been issues introduced somewhere in the process, we have about 30 control points over a 35 square mile area that at least two control points are collected in the field on a daily basis for each device. We have a set of confirmed points, for each coordinate system, that the script looks for variance between the data and the controls outside the accuracy of the GPS.
These control points serve two functions:
1) used internally to pick up potential errors in the collection process or equipment
2) for transformation verification
A couple of examples how we used this approach.
One morning we came to find an email from our GIS server that the previous day’s data collected from one device was outside our acceptable limits (substantially). After reviewing the data and the device it was found that the user had selected the correct GPS but forgot to change the profile and wrong RTK was being utilized. The problem was quickly found and we only lost a day’s production data for that device. We now run a check on the data as it is posted to AGOL several times a day to catch this sooner.
Another example as when we first attempted to project our data to from NAD83(2011) to NAD83(86) it did not go well. No matter what we tried the data was always off after translation. After a little research, it turned out it was too big of a step to go from NAD83(2011) to NAD83(86). We need to add an intermediate step of converting to NAD83(HARN). However, because we had control points, available in the deliverable datum, this was blatantly obvious before we delivered the data.
In setting up our program, we chose to minimize the number of transformations while collecting and storing the field data and perform post collection transformations to get the data in the form needed. Each transformation in the field introduces a potential point of error that cannot be undone. We collect our field data in NAD83(2011) Ohio State Plane North, however, since we also collect our GPS metadata we have the raw GPS data (lat, long and altitude) from our RTK service in GCS NAD 1983(2011), height above elipsoid.
One other factor to consider, in comparing your data to control points and day to day repeatability, is the accuracy of your equipment and correction service. If you are collecting data to 1 foot accuracy, keep in mind that is typically a plus or minus or a 2 foot diameter circle. If one day you collect a point that is on the plus 1 side and the next day collect the same point on the minus 1 side. These two points will be 2 feet apart. Furthermore, that 1 foot accuracy is if the accuracy was 1 foot and not collected under a tree near a building reducing your accuracy to maybe 2 or 3 feet (a 4 or 6 foot diameter circle).
