Hi-Accuracy Storage of Coordinates with Web mercator basemaps and NAD83(2011) augmentation Not Possible

[JoelCusick1]

Currently, when using a hi-precision bluetooth receiver (Trimble R1/R12i and Leica GG04 Basic Plus) on Android OS 13 with Mock Location ON and a real-time stream based on (NAD83(2011) - EPSG:6318) GCS, it is not possible to store features accurately online when the QuickCapture project map is based on Web Mercator (EPSG 3857). Since both QuickCapture and Survey123 are identical in handling integrated providers, this issue persists with Survey 123.

A description of a series of tests on survey control conducted recently are attached which I hope provide the level of detail so your team can best figure a way forward to allow hi-accuracy storage of solutions meeting manufacturer specifications.

FieldMaps when setup properly on Android (Mock location off) both Trimble Mobile Manager and Leica Zeno Connect pass through the NAD83(2011) augmentation stream allowing a user with hi-accuracy receivers to store data in AGOL meeting specifications.   My tests reveal the same workflow with Quick Capture (mock location off on Android), induces an error on stored positions.

Eliminating this datum shift would allow the user community to use QuickCapture to store high accuracy positions, which are not possible on phones/tablets today and allow users to leverage the large market of hi-precision bluetooth receivers on the market today.  QuickCapture is an incredible app but we think it should offer the same capacity as Field Maps - use for hi-accuracy receivers based on a GNSS output other than "WGS84"

Here is the screenshot of Test results (Figure 4 in attachment) using the Trimble R1, Trimble R12i and Leica GG04 Basic Plus.

Hi-Accuracy Storage of Coordinates with Web mercator basemaps and NAD83(2011) augmentation Not Possi...  

@Mapping and GIS Solutions Community (trimble.com) Android Device S123 not using mock locations from Trimble Mobile Manager 

[MichaelLohr]

We see the issue of unknowingly storing inaccurate coordinate values in Field Maps/Collector using the Trimble R1 and R2 units. The myriad of profiles, custom local corrections in Trimble Mobile Manager (TMM) and Field Maps make it time and consuming and challenging for office and field staff to record accurate and reliable positions. If the hardware is capable of centimeter level accuracy, the various software apps should all behave in a similar fashion for configuration set ups and warn the user of non-optimum set ups prior to storing lower accuracy results. Field staffs have to navigate between multiple Web Maps with different coordinate systems, sometimes RTK, sometimes WAAS, sometimes uncorrected. The ESRI/Trimble Team should prioritize streamlining the config process to help store best possible coordinate values.

My response to a similar topic in Trimble Community is below:

Joel, thanks for reposting this in this forum. We have used The R1 and R2 along with Collector, and now Field Maps on both iOS and Android devices using the companion apps of GNSS Status, the Trimble Mobile Manager. Our objective is to always achieve the best accuracy possible with the available equipment and software. We see the same challenges that you do regarding multiple changing settings requirements, software app updates and the general complexity of the processes happening in the background. Too little effort, we think, has been taken by the software/hardware developers and the sales support community to ensure this process to achieve high accuracy is streamlined and understandable. 

It is great that ESRI and Trimble has, or once did have, a team that worked jointly on the development of this field data collection process. But, this type of system problem seems to continue over the years. 

We try to always include check in points to known monumentation as a part of the field operations, but that is not easy to accomplish on the fly, in the field where it needs to happen, because of datum transformation issues, incorrect profiles in use, or incompatible map GCS occurences. Field staff cannot spend an hour at a check in point trying to figure out an inaccuracy problem.  And we have documented where the accuracy bar in FM displays acceptable accuracy but then is not matched in the recorded GNSS metadata, causing more uncertainty. Ten years ago, maybe we could say that this was an evolving technology and not everything is worked out yet, but I'm not sure that still works after years of software and hardware improvements. 

We don't have any magic solutions but would offer that if you need high accuracy results, plan on a lot of high-level support for that operation and have a strong tech support program to rely upon. Then be prepared to test their suggestions in the field, as they sometimes will not have the firsthand field experience that enables them to really understand your issue, nor the time to really listen.  We welcome the opportunity to expose these topics in a wider forum of the mobile mapping data collection community.