Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limitations in capturing Geo-coordinate on ODK collect #375

Closed
imran3may opened this issue Feb 2, 2017 · 12 comments
Closed

Limitations in capturing Geo-coordinate on ODK collect #375

imran3may opened this issue Feb 2, 2017 · 12 comments

Comments

@imran3may
Copy link

imran3may commented Feb 2, 2017

Software and hardware versions

Collect v1.4.14, Android v5.1 device used...

Problem description

Feature is not available to hide button to capture Geo-Coordinates, which means there is no options are available to capture Geo-coordinate without the interaction of an user.

Steps to reproduce the problem

Expected behavior

For the need of a project, a funchtionality of auto capturing of Geo-coordinate is required. Which means, the location of the user should automatically captured withous having a button to capture Geo-coordinate.

Other information

Forms developer may have an option to hide the button while designing the xls form. For example, change some behaviours, constraints are used or a condition used under appearance. I would suggest, this feature may help resolving issues of may ODK users.

@yanokwa
Copy link
Member

yanokwa commented Feb 3, 2017

@imran3may Why do you need to capture GPS coordinates without user interaction? Is it a training issue of GPS being hard to capture? Is it because you don't trust that your enumerators to know GPS is being captured? The reasons why inform the design, so we should discuss them.

@chrislrobert
Copy link

FYI, in SurveyCTO we have a "background" appearance for geopoint fields. We also added a Collect option to pre-warm GPS for up to x seconds and/or y meters accuracy at the beginning of any form that contains a geopoint field.

Reason: smart enumerators, rather than filling out all forms at home, visit every actual household, capture the GPS position of each from the street, save, move on, capture, capture, then go home or sit in a tea shop and complete all of the tiresome surveys. This is how they adapt to GPS positions being captured and monitored. So okay, then the next adaptation is to scatter these invisible/background GPS positions between modules, throughout the form. Using distance-between(), can then calculate distance between the different points and flag cases where they seem to have moved a lot. Etc.

Also supports accuracy threshold.

screen shot 2017-02-03 at 6 43 39 am

@imran3may
Copy link
Author

@yanokwa I am currently working on a project for a country Government health agency and in one of their forms, they are looking for this hidden GPS-coordinates capturing feature. I assume they simply want to hide this feature in order to make this form more acceptable to their staffs. Though on the declaration it is clearly mentioned that their location will be recorded. Thanks

@lognaturel
Copy link
Member

Related to #24

@yanokwa
Copy link
Member

yanokwa commented Feb 6, 2017

@chrislrobert I have a few questions...

  1. Given the problem described, why not capture a trace of where the phone has been instead?
  2. Where is this background GPS saved (e.g. sidecar file, data model)?
  3. What do you do when the user swipes past the background location, but you haven't gotten lock?
  4. What happens when the user is indoors and there is no lock?

@yanokwa
Copy link
Member

yanokwa commented Feb 6, 2017

@imran3may Android does not let you hide the menu icon that shows GPS is being fetched. Is that acceptable?

@imran3may
Copy link
Author

imran3may commented Feb 6, 2017 via email

@nap2000
Copy link
Contributor

nap2000 commented Mar 7, 2017

I think this should be added as an option to the timer log issue #257 . If track GPS is set then for each question the GPS will be recorded and logged.

Because the coordinates captured at each question have to be the best available at that point in time then I suggest we record what we have including accuracy.

@jnordling
Copy link
Contributor

So whats the verdict on this? We doing it or no. @yanokwa

@lognaturel
Copy link
Member

lognaturel commented Mar 17, 2017

Yes! I believe @nap2000 is getting close to a timing-only implementation for #257. @nribeka is working on #508. Once those pieces are in place we can discuss the final design but it will likely be something like what @nap2000 describes.

@nap2000
Copy link
Contributor

nap2000 commented Mar 19, 2017

Yep a draft approach for the timing log is nearly done.

@steverichards
Copy link

I may be a bit late to the party on this one. Muy use case is recording observations from a helicopter where time to collect is an issue. I'm looking for a one tap solution.
Form is open
Select observation from radio button
GPS location is collected automatically
Record is saved
Ready for next observation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants