GPS accuracy is determined by the device hardware. There’s nothing we can do in Collect to increase accuracy.
@yanokwa is correct that the accuracy is based on the hardware. Factors that influence the accuracy as well are the number of GPS satellites, etc.
However, that is not the end of the story, ODK can help you to require higher accuracy. If you want to require your form to have more accurate GPS coordinates then you can set the accuracyThreshold higher. For example in an XLSform you can do it this way: http://xlsform.org/#gps-accuracy-threshold
WARNING: increasing the accuracy requirements might be beyond the ability of the smart device hardware in the terrain/ground cover you are operating in. You should test the accuracy requirements as if you increase the accuracyThreshold enumerators might have a harder time obtaining GPS coorindates.
@yanokwa, I feel the point I was trying to explain is not.clear.
I am not trying to improve the accuracy of GPS, I Know it's dependent on the device and many other factors, I am trying to suggest an offline/indirect GPS capturing method by using plus codes.(https://plus.codes) as we don't need to depend anymore on location service to know the lat and long of our place if we are familiar to.plus codes
Is there a way we can use plus codes in Google map sdk or open street map sdk in ODK Collect
@mistcrrgpsa If I understand correctly, you would like data collectors to provide location information by filling out plus codes instead of capturing GPS coordinates, is that right? Is there any reason you can't do that today with a text field?
Alternately, could the data collectors use an offline basemap (https://github.com/opendatakit/docs/issues/3) and select coordinates from there?
There was another request for plus codes recently at https://github.com/opendatakit/collect/issues/1850 so there is interest.
If you could say a little bit more about how you imagine this working and why the two approaches I suggested above might not work, it would be very helpful.
My Intention behind the suggestion was to have an accurate offline GPS
capturing mechanism, but i have my own doubts in the possibilities of
getting the exact coordinates at the ground level using Plus Codes /
Offline base maps, as for both the above ways, the accuracy of the location
depends on the ability of the user in accurately identifying the Placemark
in the offline map. Hence i feel further explorations in terms of ideology
and future data capture perspectives need to be envisaged before planning
for the same.
Is there a provision to have an offline satellite map SDK for ODK Collect
to capture GPS Cordinates?
Thanks & Regards,Anup Krishna P,Specialist MIS,State Program Management
Unit(SPMU),Rasthriya Gram Swaraj Abhiyan (RGSA),Local Self Government
Department,Govt. of KeralaPh: 94960 46910
Yes, you can use an offline base with the steps described here: https://github.com/opendatakit/docs/issues/3
GPS doesn't need data connectivity to work so you can capture coordinates even when you are offline. What you can't do is capture GPS location when the sky is obstructed (indoors, in thick forest, etc).
It seems to me that plus codes are useful as an alternative to addresses in a location where not all structures have existing identifiers.
I actually dropped by to post about Plus Codes. I think they may end up being useful, but not 100% sure yet. We currently identify buildings like churches, health clinics, etc via satellite in more inaccessible areas to collect data on and I think having a global address that's a little bit more sensible than lat,lng for places that have no addresses would be great. My larger concern with Plus Codes are, will they actually be helpful.
I just wanted to hear some feedback from others in this community on the whole Plus Codes implementation and if it should be implemented into the larger system.
Hi, I wanted to clarify for readers that plus codes (previously named open location code, published by google) are not dependent on an external API. It is an open source calculation library available in multiple coding languages and can be integrated as a library into another application like ODK Collect. I have also come across another such computation, geohash that looks just as good and is open source too.
IMHO Instead of a geo-point, pluscodes / geohash can be used to capture geo-area as a predefined square on the map. User can choose smaller or bigger squares, choose neighboring ones, but cannot move the square around.
How I foresee it being implemented: check out this geohash implemented map: http://geohash.gofreerange.com/
Thanks for that extra information, @Nikhil_VJ!
Can you describe the use case for this in more detail? I can see the value of selecting features like buildings or roads but I'm less clear on the value of selecting a predefined bounding box. Are there systems that you might want to cross-reference that are indexed by plus code?
If really the desired output is a plus code, it seems to me that the enumerator could still select a specific point and the conversion to plus code could be done on the backend.
Sample use case: "It was somewhere here, within this 200 metre wide area".
- The user doesn't have to take extra efforts to draw the bounding box each time just to show the area.
- Set the grid size (aka the degree of precision, corresponding to number of letters in the code), tap a box on the grid (which we can hopefully overlay on the map) and carry on.
- Makes room for approximations and ends the eternal "but you said it would be exactly here!" quagmire.
- Makes room for ground movements like earthquakes, subsiding bedrock, tectonic shifts.
- Simplifies finding repeat-records or clustering of data. Just search the column for duplicates (or where first 4 chars match, for example), no gis expert needed.
- Suitable for low-resolution cases where anyways one needed approximate and not precise location to be recorded. Lookup 'pixellating' of images. So we pixellate the map and choose a pixel.
Update: Plus codes has released grid overlay in a tile layers url that can show the plus code on the map.
Hi - I just joined the community to raise pretty much this feature request. My name is Doug Rinckes and I'm the founder and lead of the plus code project within Google.
My suggested feature, is very simple:
Display the plus code, in addition to the lat/lng/altitude/accuracy, after location steps (GPS/Manual) in ODK Collect.
This has come from groups who are doing voter registration. They would like to see the plus code in ODK Collect, because it means they can inform people of their plus code immediately.
This conversion will depend on adding in the plus code library. It won't make network calls, and this means it will work offline. (Offline support is really important!)
This will not change the data that the form will send - it is only a UI change, because I don't want to break the existing flow or add complexity to the processing, or add a whole new set of location type questions.
If a group wants to convert lat/lngs to plus codes after the forms have been submitted, there are a variety of tools to enable that in our GitHub project including a Google Sheets plug in.
I think we can find people to help with the coding, but looking for some discussion first!
Hi @doug, welcome to the community. I've got a couple of questions for you!
- How big are these voter registration projects (enumerators, forms filled, etc)?
- Do you have a sense of how much larger ODK Collect will be with the library added?
- You've described just a UI change, and that is indeed a lightweight way to go, but we don't want to be too short sighted. Would it be more beneficial to persist the plus code (this would likely require a new question)?
- What about for other geo data types (e.g., geo shape, geo trace). Do you see plus codes are necessary there as well?
We know of two projects right now, that would be targeting in the order of 3-5000 forms (one form per voter) (based on the current counties they are doing, but they expect to expand to a lot more). One project knows of ODK and is considering it's use, the other isn't yet but I'm talking to them next week. Both were thinking of developing their own app but don't have a lot of app development skills. ODK would mean they can skip all of that and get started with their actual jobs. (I can also think of multiple other country scale projects where this would be useful - we'd be talking about potentially millions of enumerators for example.)
Size impact should be very small, like a few kb. It doesn't need the full library since it won't have to support decoding. It might make more sense to just add the required function to ODK Collect's source, rather than link the (larger) library from the open-location-code repo.
I don't think it's necessary, and maybe not even a good thing to add a new question type for this. Since plus codes are computed from the lat/lng, once I get the form into my backend system I can do the computation there, or call an API to get the address form (like "9G8F+6W Zürich"). I don't see that there's a big advantage to doing this in ODK Collect, and the disadvantage is that we end up adding a dependency on a functioning data network. We are working towards having a high quality open-source locality set in which case we could add this into the app (size depending) without requiring a network, but that's six months or more away.
I don't think so. Plus codes are useful when you want to communicate a location to a person, and I don't know if this is something enumerators would do with those other types. Maybe it makes sense to display the plus code for the center point, but I am happy to punt this to the future.
Rather than having to persist an actual overlay map on the device, if Plus Codes have a well defined algorithm, could this be accomplished - with relatively little impact - via the addition of a suitable XPath function, to translate a GPS coordinate to its respective Plus Code? From what I can see wrt Plus Code Specification, this is a well defined algorithmic function from WGS84 GPS coordinates. If so, then you could add an additional output (to a geopoint) that would display the Plus Code from a geopoint capture, or alternatively display the 'central' GPS coords from a (text) Plus Code input.
Or do you need to display an actual Plus Code map for users to enter a value from (which is different from their current physical location)?
I see, courtesy @Nikhil_VJ, there's already some JS code that we could probably translate over to Java, without a lot of effort, to implement a suitable (?)
pluscode-to-geopoint() XPath function for ODK Collect.
Would this suffice?
Arguably, with these functions available in code, with a few smarts you could even conceivably use them to draw an overlay over any map shown of your present location; geopoint-to-pluscode() can give you the pluscode associated with the center of the shown map, pluscode-to-geopoint() will give you the actual GPS center for that pluscode, and with well-defined grid sizes (20°, 1°, 0.05°, ...) you can then determine the GPS corners of all the surrounding cells with which to draw (and label) your grid.
I think programmatically generating this grid - if needed for display purposes - would be preferable to having to (pre)load a potentially large overlay image with all the pluscode tiles, or require a live network connection with which to fetch the relevant tiles whilst out in the field.
(Note that the code in the link earlier is a geohash implementation, not plus code.)
I'm not sure what I think about displaying the grid - it would be fairly easy to work out the viewport coordinates, pick the grid resolution to draw and draw it, but it wouldn't solve the original issue which was "after I pick a location I want to know the plus code".
I'm open to it, and am happy to provide existing algorithms, but I really like the idea of @Xiphware's suggestion of a
geopoint-to-pluscode() function that can be used to display it.
So the proposal is to add in the existing Java library from github and call it from the
geopoint-to-pluscode() XPath function?
Opps - showing my geo-ignorance... So yes it looks like the github open-location-code has existing Java routines for both encoding (lat+long -> code) and decoding (code -> lat+long) plus codes, which could probably be pulled in as a lib and write a simple wrapper to expose as respective XPath functions.
Since the code is readily available anyway, I'd suggest implementing both
pluscode-to-geopoint() for completeness, in one PR hit.