Survey123 is truncating auto-filled geopoints. The form is opened with the url parameters -
However the coordinates end up as
The survey was made with Connect. Is there a field that needs filled out to expand the number of decimal places that the survey will allow?
I am having this problem in the field app. The screenshot below is for the same point added into Pro. They are almost 800 feet apart. I copied the link coming out of the webmap popup and it looks fine: ¢er=34.54978344800003,-112.46260085999995
The web app only stores 5 decimal places of precision for coordinates. This translates to about ~1m of accuracy. Do you have a need for greater accuracy in collection?
I am seeing a shift of over 13ft, so yes, I need better accuracy than this...well in my case it isn't accuracy really, it is simply saving the point that I pass to Survey123. I am using Survey123 for field inspections, and am passing on the latlng of the field asset to the survey. This way I do not have to add another step where I join the field assets to the survey as the asset location would be exactly the same as the survey point location. With this not being the case...not sure what I will do. Most likely eliminate collecting a geopoint altogether and simply pass the latlng as strings and manually create a point from there.
Are you aware of any plans to change this setting or make this adjustable in the future? I get the idea of not wanting to collect a point from a phone or tablet with more decimal places than the actual GPS accuracy, but it would be great if this setting could adjusted by the user.
I see a accuracyThreshold in my excel template, is that related to this at all?
Thanks for the feedback. We have had a few other comments regarding the level of precision available in the web app and will be considering revising that in the future. The accuracyThreshold setting is designed for use in the field application when receiving the location via a GPS or other location-determining methodology (as opposed to passing in values via URL) and doesn't sound applicable in this case.