Am in a rather tricky situation. I need to collect multiple points to map an area, but the personnel that are filling in the forms need to be able to do so COMPLETELY OFFLINE (they only get less than bite sized data bundles to download the form with and later send the results). I tried geotrace and geoshape with this, but i can't get around the blank map area displayed AND i need the points to be specifically collected by the app, and not selected by the client. So i resorted to using a repeat_group and GeoPoint, then doing the map drawing and calculations waaaaay later. This has worked well*-ish* since August.
Now the problem: i need to calculate and display the acreage of the mapped area while the form is still being filled. I've been beating around concatenating the geopoints saved and then passing them onto area().
Is there an inbuilt way to use area() with geopoint? is there a workaround someone has figured that could make this work? I would gladly appreciate any input.
Can't you for example use Geoshape with Manual location recording? You won't see the map if you don't have offline tiles but still the location will be recorded. So it should be ok if the real location of your enumerators matter.
It looks like the documentation is incomplete! I've filed an issue to update that.
You have two options for computing area without a geoshape:
Concatenate several points together with semicolons in between. In XLSForm, that would look like introducing a calculate with calculation contact(${point1}, ';', ${point2}...} and then calling area on that.
Use points in a repeat. In XLSForm, that would look like calling area(${my-point-in-repeat}) outside of the repeat.
Just done the introduction, thanks for the reminder!
Also, the manual location recording allows for the client to tap the screen and save a point far from where they are, which is a possibility i cannot have. Thanks though, I appreciate the thought.
thank you so much, this worked like a charm setting it up. unfortunately, the values i get at the end are not what i was expecting. where i was supposed to be getting approximately 1000 square metres, i got approx 445 m2 (accuracy 3m). I am doing this from Uganda, quite close to the Equator. Are there any known bugs that might be causing this, or is it more possible that i am mistaken about the size of the land am using to test this?
There are no known bugs but certainly there could be unknown ones. How are you producing your estimate? Could you try entering in your test case to https://www.mapdevelopers.com/area_finder.php and see what area you get from there? You can enter a point in lat, lon format in the search bar to set a point.
I did something similar to your idea of a test case, and got one of those typical "find area of land" apps just to see who it would side with in this experiment (odk calculations vs my knowledge of the land). And through its map, i realized that my phone was picking up coordinates from somewhere else far from where i actually was (which is odd, but not uncommon). So even if odk and my land-know-what are good, my phone doesn't want us to agree. I have put this on a self (temporarily), and my form will have to do with out it since it is being deployed in an hour. I will definitely pick this up again in a while, since it is a feature on high demand, but am glad i know how to work out the odk side of this equation. Thank you so much for your assistance.
edit: i got my estimate from the land surveyors that inspected it before owner purchased it.
Sorry to hear about that. GPS performance varies quite a bit device by device. Collect currently uses raw GPS values but we're planning to change this in the next release and use other device sensors as well. This may address these kinds of bad points and so I'll tag you when a beta is ready so that you can try it out and see if it would work for you for future data collection.
we actually find the raw gps an advantage, that way we can have the same experience within urban areas and remote areas (really remote, where cell service is a luxury and wifi is a fantasy). as the extras are added, please include an option to keep it raw. the raw gps performance has been good enough for us to maintain it as a service, with the added advantage of having consistent results everywhere.
nonetheless, i am looking forward to that beta. i love testing odk limits
Unfortunately, Google doesn't exactly document how their advanced location capabilities work. From our testing, it's clear that it does some kind of smoothing on raw GPS and uses other available sensors even in absence of wifi signal (e.g. accelerometer). I believe that it should entirely avoid big jumps in locations that are physically impossible.
