Dear all,
Is it possible that geofence() is not workig as expected and as descibed in the docs?
I am gettig this error when opening a form in Enketo that contains geofence() as described in the docs:
To make sure, my form is not the issue, I tried it with the form linked in the docs about geofence(). With the same result.
This was the case in Enketo. The error did not appear in Collect. But the relevant funstion did not work.
Does anybody implemented geofence() with success yet?
Thank you all
The new geofence() function is not yet supported (or recognized) in the Enketo web client.
FWIW here’s the ticket to add it: https://github.com/enketo/enketo/issues/1326
Thanks for pointing to the ticket, @Xiphware!
The form we most test with is this one which by default makes a fence around the US state of Nevada and lets you change the fence. I've just tried it again and confirms it works as I would expect in Collect.
You probably can't share the exact shape you're using as a fence but could you tell us about it? Is it really close to the equator or the poles for example? Is it really small? Maybe you can also share the way that you're using the function without sharing the values you're using? Does Collect always show that values are outside the fence? Inside?
I also just verified that it works in Web Forms as I expect so you could consider opting into Web Forms for that form if you need data entry from the web and other functionality you need is supported. You can preview a form in Web Forms while in the draft state by pressing and holding W+F and clicking the preview button or you can first publish the form and then opt in from form settings. We're going to make this whole process much smoother in the next Central release.
I case you are wondering why this might matter, its worth mentioning that the ODK javarosa geofence() function implements a point-in-polygon algorithm, to basically determine whether the your (geo)point is inside (or outside) the prescribed geoshape polygon. And in doing so, it basically has to turn our spherical planet Earth into a flat surface instead; much like a regular wall map.
But, as mentioned in the original github ticket, there’s a few gotchas where this difference becomes important:
Specific mention should be made to situations where the algorithm becomes degenerate. Specifically it cannot be used on areas that surround either pole. Also, if the target geoshape crossed the prime meridian then the coordinates specified for the geoshape should be adjusted to ensure they correctly map to corresponding Cartesian coordinates (ie you dont try to go from long 358deg to 2deg, but instead 358deg to 362deg) . And geoshapes with very long edges should probably be broken into shorter ones, due to fact great circles in spherical coordinates don't precisely map to straight lines in Cartesian coordinates. Failure to do so will result in points actually inside the geoshape - on a spherical surface - being incorrectly identified as outside the polygon - of a flat surface.
The point-in-polygon algorithm works great in most cases, but please do be cognizant if your area crosses the prime meridian (aka longitude 0deg), don’t try to use it on an region that happens to encompass either the North Pole or South Pole. And if you have a geoshape spanning hundreds of km along a side, you probably want to break these up into shorter segments; this is because a straight line on a flat map projection corresponds to an actual curve on the surface of the earth, and vise versa [which is why if you fly direct from San Francisco to London, you actually pass over most of Canada and even a tad of Greenland!]. The longer the side the greater the disparity, especially the further towards the poles/away from the equator you go.
Also please note that presently the geofence function (in Collect) doesn’t support fixed constant/literal geoshapes; there’s another ticket to add this: https://github.com/getodk/javarosa/issues/769
