(This item is moved here from the ODK Geo roadmap document.)
Currently, the user of ODK Collect can set a GPS accuracy threshold when collecting points for a GeoTrace or GeoShape (e.g. only record points with an accuracy value < 5 m). They can also set a collection interval (e.g. collect a point every 10 seconds).
We're considering letting the form designer configure both of these things in the form definition, for all the geo widgets, so that the enumerator doesn't have to choose them. With such a capability, the form designer could set a consistent accuracy threshold and collection interval for a survey project involving many items of geographic data and many surveyors, and surveyor training could be simplified.
The names of the configuration parameters are yet to be determined.
Most likely, if both parameters are set, then the "Input Method" dialog is skipped and data collection goes straight to "Automatic" mode with the accuracy threshold and collection interval set by the form definition. If only one parameter (accuracy or interval) is set in the form, then we'd presumably provide the user with the opportunity to set the other one.
Your feedback and thoughts on this are welcome!
Is it set once for all geo-widgets? Or set per question?
What column(s) would this be set with in the form definition?
Per question. The names of the attributes aren't chosen yet, but they'd be attributes on the question.
All this seems fine to me.
Just to add a bit more meat to these bones, what about a parameter on geo all the geo widgets called
Note that we already have an accuracyThreshold attribute and as part of this effort, maybe we could start deprecating that.
interval makes sense; possibly
interval-seconds if measured in seconds. (What do other parameter names do with their units?)
min-accuracy is confusing because this isn't a minimum bound on the accuracy value, it's a maximum — but that's because a more accurate reading has a lower accuracy value.
max-accuracy would be equally confusing. (This is why I want to rename "accuracy" to "standard deviation" or "standard error", but that's a bit of a diversion here.)
Given that we already have
accuracyThreshold, why wouldn't we want to continue to use that as the name of the parameter, and use it across all the geo widgets?
We haven't used units in the parameters in the past because typing
interval-seconds is more annoying that just
interval. I'd rather not change that, but I'm open to being convinced.
I'm not sure
std dev are that clarifying. I like to think what I'd write in the docs and then pick based on that. Based on that metric, max-accuracy isn't too bad...
max-accuracy - The maximum accuracy allowed in meters. For example, if set to 5.0, only points with accuracy between 0.0 and 5.0 meters will be recorded.
This is exactly what we're looking for in Indonesian Red Cross, we want to extract the WKT form every simplified geotrace widget record for our further vehicle movement product report. In addition, the current widget required us to keep the screen on in order for the geotrace widget to record properly within the set interval otherwise the trace will only resume if the device screen returned on.
About the WKT extraction, you could take a look at this post : ODK geoshape/geotrace/geopoint to WKT
The suggestions for a (form designer set) GPS accuracy requirement and collection interval setting in GeoTrace or GeoShape is a real great idea! The proposed interval-seconds attribute makes a lot of sense, and perhaps accuracy-req is similarly close to current use in the Input Method dialog box of Geoshape/Geotrace. Or have these already been implemented?
Yes, it would be great to have the ability to require geopoints within a certain accuracy. i.e in the placement-map appearance, once the max-accuracy is achieved, it exits the map view and returns to the form.
Additionally, requiring a 'Pin-Drop' only geopoint selection would be very useful. For example, when viewing Google Maps satellite view, it is possible to find your exact location from the image displayed (i.e. what side of the street you are on). In this case, a Pin Drop may actually be faster, especially if you are in a built up area with tall buildings.
Hi @J_D1, have you looked at the Geopoint widget with user-selected location? I think it provides the pin-drop functionality you describe.
Yes, we use it regularly. However, at the moment, the user can decide whether to rely on the phone GPS accuracy or use the Pin Drop. Having a parameter to only allow one or the other would be useful, as the phone GPS is sometimes not accurate enough, but the Pin Drop is very accurate if you know your bearings.