Select to view content in your preferred language

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

445
3
04-14-2024 12:44 PM
Status: Open
Labels (2)
JoelCusick1
New Contributor III

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).

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.

JoelCusick1_0-1713120704806.png

@Hi-Accuracy Storage of Coordinates with Web mercat... - Survey123 Ideas Esri Community

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

3 Comments
MarikaVertzonis

This is really great research Joel, and the QuickCapture/Survey123 team appreciates you sharing this detail. In short, we know we are stuck in the current releases of the two apps, to not being able to support projected maps. But we are enthused that with the next generation of the apps we will have the full use of the Maps SDK, and will be able to do so, just like in Field Maps. 

Your testing environment and setup is outstanding so I am keen to follow up with you directly to see if you would be willing to test both possible workarounds, and of course prototype implementations when they are ready.

MichaelLohr

Repeating my comments made to this post i Trimble Community forum ....

*********************************

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.

FrancesBiles1

Thanks to Joel and Michael for highlighting this issue.  Well put Michael, agree 100% with every point you made.