In the survey form, the “Record location” question allows me to capture latitude, longitude, altitude, and precision data for a specific point. However, my questionnaire includes a question requiring the number of satellite signals available at that location. While this information is visible during data collection in the app, it is not stored in the data table. I would like to store this information for both app and browser-based data collection.
Specific details regarding the GPS location acquisition - such as number of satellites, their individual signal strength, etc - is not presently acquired or persisted in geopoint form data. Which, as you are probably aware, only includes latitude, longitude, accuracy and altitude. Although you can probably infer some of this from the provided accuracy value (eg you are not going to get 1m accuracy with only 2 satellites…)
However, this desire has been raised before; you may want to follow (and contribute to?) the discussion here: Record time elapsed and satellites of a geopoint - Ideas - ODK Forum
A new feature like this will require a change to the core ODK Collect app, upon which KoboCollect is based. So the above is the appropriate Forum to propose such a change.
1 Like
Thanks.
I’ve few more questions regarding this.
What is the source of the captured coordinates in KoBo? Does it collect location data using the GNSS receiver of a device, or does it rely on Wi-Fi or other external signals?
After capturing location data in the app, the coordinates are displayed in degrees, minutes, and seconds . Is there a way to set this to decimal degrees instead? > this is only when the app display the data before finalization.
KoboCollect/ODK Collect now use the so-called ‘Fused Location Provider’ services on Android, which (and if enabled by the user) will also take in public data about nearby WiFi hotspots, cell towers, etc to help acquire a location faster/less power. This API is now used by the mobile app for all geo* questions since about 2020; see Use fused location provider everywhere by lognaturel · Pull Request #3772 · getodk/collect · GitHub
Typically, however, your device settings allow you to enable/disable these other signals and just uses the raw GPS sensor [AFAIK this isn’t settable via the app itself however]. eg
Again, KoboCollect app will use whatever sources of location data are available (and enabled) on your specific device via the Fused Location Provider. Precisely what sources were used is not, however, exposed to your form.
Short answer no (or not yet). All GPS locations are always stored in decimal form, but they are displayed in the GUI in DMS (Degrees, Minutes, Seconds).
This is mostly a historical artifact, but you are not the first person to desire the option of displaying decimal degrees. If you are interested there is renewed discussion about it here (so you may see this feature being made available in the nearer term). Please feel free to contribute your input too.
By and large people seem to have worked around this limitation by adding a followup note that re-displays the location in decimal degrees latitude and longitude.
1 Like
Is the location data character the same for browser-based data collection as well?
And thank you so much for the responses.
For Enketo browser-based form filling, it will depend on the underlying browser being used, the device operating system (Android, iOS, macOS, Windows, Linux, …), the specific OS version, and the hardware it is running on. At lot of non-mobile based hardware, especially, do not have any GPS hardware, so in a lot of cases it may be based simply off the device’s current IP address (!) as mapped to your ISP (and assuming your ISP has a well known central geographic location…).
Which is to say, typically you should probably expect a somewhat lower precision when using Enketo vs KoboCollect, because the latter - by nature of being a native app (as opposed to a web app) - has unfettered access to the actual device hardware via native APIs.
FWIW, you might try pointing your browser at this: https://mylocation.org/. It may give you a sense of what accuracy to expect from Enketo.
1 Like
I need to set the automatic threshold 15m which is by default set as 5m for geographic coordinates accuracy during data collection using app. **Is there any way to adjust the accuracy level , which is set to 5 meters by default ?
Yes, you can use capture-accuracy to increase/decrease the default target acquisition accuracy:
capture-accuracy: when the device accuracy reaches this value or better, the point will be automatically captured and the dialog will close. If you always want data collectors to make an explicit decision about accepting a point, set this value to 0. Defaults to 5 (meters), a target that can usually be reached by modern devices given enough time. We generally do not recommend setting this value to below 3 (meters) unless you are using an external GPS device. You can also set an accuracy constraint.
But it is also worth being cognizant of what this so-called ‘accuracy’ measurement really means:
The accuracy radius is an estimate of what Android calls the radius of 68% confidence: there is a 68% chance that the true location falls within this radius. This is an estimate reported by the Android system based on the available sensors (GPS, network, etc). The accuracy radius itself may be more or less reliable depending on the sensor(s) used and current conditions.
To get an accurate location quickly, ensure devices have a clear view of the sky. For even faster points, consider “warming” the GPS with a start-geopoint question. See improving location performance for more.
1 Like
It works. Thank you so much
1 Like
It works perfectly in app.
But during data collection using browser it shows error (red mark in question) when the accuracy is 12 (below 15m). But the accuracy can be vary 1 to 15m; not more than 15m.
How to change the calculation so that it can capture the data when the accuracy ranges from 1-15m?
I believe accuracyThreshold - which is what capture-accuracy gets translated to in an XForm - is not yet supported in Enketo, hence it is probably being ignored.
FWIW this is the (longstanding) issue: add support for accuracyThreshold · Issue #397 · enketo/enketo · GitHub
1 Like
