Pull GPS points taken in real-time into a mapped geoshape

Hi there,

I have a form where I am taking 4 GPS points around a centre point. I have used a measurement between points to ensure the user takes a point that is 100-m away from a centre point.

I would then like to pull these GPS points to visualize the polygon on a map, all on the same form.

I suppose that I use something like this in the calculation field to capture the geoshape (where locations are each of the 4 GPS points surrounding a centre point):
“{location 2} 0 0; {location 3} 0 0; {location 4} 0 0; {location 5} 0 0; {location 2} 0 0”

Where I am stuck is on how to immediately visualize the geoshape. So far I have put this in the calculation field to create the geosahpe (but it doesn’t seem to push the coordinates to the form):
geoshape($"{location 2} 0 0; {location 3} 0 0; {location 4} 0 0; {location 5} 0 0; {location 2} 0 0")

Any tips would be greatly appreciated.

Thank you!

Ruwan

Hello @rratnaya ,
Could you share the related part of your form, please, to facilitate support.

Did you check if the calculation itself is working well? (set type to text instead calculate)

Thanks Wroos, here is the form that I am using. polygon test.xls (49 KB)

Hello @rratnaya ,
Would you mind, please, to correct all errors given by Online validator https://getodk.org/xlsform/, before further community support, e.g.
image
You also have other duplicate names, like location1, … location5.
Reuse the Online validator, please, until all is cleaned.
Thanks.

I would propose, also to check a strange syntax/spelling (several places):
geoshape($"{location 2} 0 0; {location 3} 0 0; {location 4} 0 0; {location 5} 0 0; {location 2} 0 0")
Probably this should be concat(${location2}, "; " ${location3}, "; ", …) - See position of ", ${…} and spaces, no geoshape in calculation etc… geoshape is a type not a function (like area).
image

If you still have problems after fixing the errors, I would like to suggest changing all calculate types temporarily to text. So, you can review what happens exactly.

2 Likes

This is very helpful – I will take some time to validate and check these errors and come back with the right question.

Thank you.

1 Like

Here a reduced example. You can see if it does what you are looking for
polygon test 03.xlsx (19.2 KB)

There is a Enketo problem, see below.
I only found this workaround, see example. In Preview only this seems working
concat(${location2}, "; ", ${location3}, "; ", ${location4}, "; ", ${location5}). You get an open polygon, which can be closed.

At the end, I added an example, to illustrate the KoBo/ODK syntax of geopoint, geotrace and geoshape.

Maybe you could explain what you exactly want to do? You don’t get a circle, just a rectangle area.
If you want to make sure that a selected household is in a given area there might be another approach, previously discussed in the forum.

I am not an GPS expert. But I think you could also calculate a validate area with moving latitude or longitude for a 100 m distance from the center point, for the 4 points entered now manually.

Here the pending Enketo problem (also visible in ODK Validation Preview!):
https://community.kobotoolbox.org/t/problem-with-gps-shape-and-line-modification-in-enketo/16028/26.

@Xiphware @Kal_Lam @martijnr ? Can you help more, please? What is the status? Is there a github ticket?

Geofence:
https://forum.getodk.org/t/odk-geofence-v1/18656

I’m also a bit confused as to exactly what, or which, problem you are trying to solve…

  • If you want to take a bunch of samples in a form, each with a geolocation, and then plot the path you took to all of them on a single map, then I might recommend using a repeat group (containing your geopoint question among others…) and then construct a suitable geotrace from (as @wroos has described) which you can them plot in a geotrace question at the end of your form. You’ll probably want to exploit the join() function to pull out each geopoint from your repeat group.

  • or if you want to check that all samples are taken within a certain circular region around some center, then you can do this with a simple constraint with an appropriate distance() calculation. See Calculate distance between geopoints - Support - ODK Forum for example.

  • or if you want a more sophisticated check that each sample is within an arbitrary polygon area, then perhaps looks at my geofence solution (above).

2 Likes

Hello @Xiphware ,
Thanks a lot for coming in.
My issue was more the Enketo problem with the trailing ; You can reproduce/see it with my example attached, please…
Kind regards

If there might be a trailing ‘;’ on your geotrace/geoshape - depending on whether you used Enketo vs Collect to acquire it… - then you can workaround it with a correction calculation:

if(ends-with(${mygeotrace}, ';'), substring(${mygeotrace},0,string-length(${mygeotrace})), ${mygeotrace})

workaround.xlsx (6.0 KB)

(if there’s no trailing ‘;’ then nothing changes)

BTW the root of the problem has already been fixed upstream in ODK Collect: See Remove trailing semicolon from geotrace and geoshape serialized value · Issue #4451 · getodk/collect · GitHub. Once this shows up in KoboCollect no such workaround should be necessary anymore.

1 Like

Hello @Xiphware ,
Thanks.
Would you mind to try the sent short XLSForm with Enketo or Online validator Preview, please.
Maybe, I didn’t explain well:
Either the polygon shows up closed, but you will get an error on validate (and manually have to move the closing point and close the polygon) OR
The polygon shows up but not yet closed and you need to “close polygon” manually.

So, I couldn’t find a way to calculate a closed polygon, which validates ok, without manual workaround. Do you have a working solution, please?

I seems that the problem from the previous thread mentioned with you and martijnr is still pending.
Kind regards

[looked at your form but still trying to decipher exactly what the problem with it is… :slight_smile: ]

So is your issue that Validate is throwing an error on your manually constructed ${catchment} closed geoshape?

If so, that’s probably because the validation logic is strictly checking that the last geopoint in your geoshape precisely matches the first. However I note that your concat is using a '; ' delimiter [IMPORTANT: there is the space after the semicolon!] and validation is performing a strict string compare of everything before the first semicolon (aka first geopoint) against everything after the last semicolon (last geopoint), which dont quite match because the last geopoint has a leading space!

Try changing your ${catchment} calculation, removing the delimiter space, to:

concat(${location2}, ";", ${location3}, ";", ${location4}, ";", ${location5}, ";", ${location2})

and seeing if that solves your issue [again, sorry, but I couldn’t quite tell from running the form what the intention is… :thinking:]

2 Likes

Thanks @Xiphware,
It was the space really!

But concat(" ", ${location2}, “;”, ${location3}, “;”, ${location4}, “;”, ${location5}, “;”, ${location2}) would not work. As probably the leading blank is cut-off by the parsing.

So, here the corrected version. @rratnaya
polygon test 04.xlsx (18.6 KB)

I only could test it with Online validator Preview, as the “detect current location” didn’t work in KoBo Preview. But this is another issue.
Have a nice week-end

2 Likes

Hello @Xiphware and @wroos, just to say a huge thanks for wading in here.

I had not set myself up to get pinged when I received a reply, so my apologies for not following up on this excellent advice that I’m seeing now.

I will go through step by step right now and write a cohesive message on what I’m looking for and how this has helped.

thanks again, Ruwan

2 Likes

@wroos, I tried the updated version (polygon text 04.xlsx) and it worked perfectly in terms of visualizing the polygon. Thank you for clarifying the workaround with Enteko, and for correcting the grammar :grimacing:

The problem I am trying to solve is defining a ring-radius around a household that is 100 metres in four directions around this household, visualizing the ring (or polygon, to start with), and then populating the ring/polygon with households that fall within that polygon. This is to support a containment intervention for an infectious disease which is applied around the first identified household affected.

Here are the proposed steps I am taking to operationalize this within Kobo:

  1. Mark the primary household (which is the centre point of the ring/polygon).
  2. Mark 4 points (upper, right, lower, left) around the household, each 100 metres distance from the household.
  3. Display the polygon (and potentially the single household point in the middle).

- Wroos’ clarifications takes care of 1-3 (many thanks). A radius/ring would be optimal for our purposes, but I think that’s simply a case of adding four more intermediary points to approximate a ring to have 8 points total. Then again, it’s a balance between this accuracy and feasibility/speed for the data collector in the field.

  1. Then, mark all the other households within the polygon (we think around 100 households).

- Combining your solutions 1 and 3 @Xiphware , a repeat group containing the geofence solution could work well here, to make sure each of 1 to N households falls within the arbritary polygon boundaries. Then, I could use the join() function to pull out each geopoint and paste it back on a single map and also export the geolocations to a list.

I will work on step 4. Many thanks for your expertise so far.

Ruwan

Hello,
I would suggest to discuss also with a GIS expert. Probably, there is an algorithmus to calculate a circle and geofence values based on centre co-ordinates and radius.

Maybe have a look here: https://www.google.com/search?q=how+calculate+a+circle+from+center+gps.

I think, also your 4 “circle” points with 100 m distance can be calculated, based on a centre GPS latitude / longitude.

If you use ODK / KoBo Collect, there is also a general form feature to see all entered households on the map. This might also be helpful. But I am afraid we cannot ad circle/polygon here dynamically.

1 Like

Thanks! Yes, I definitely think the simplest way forward would be to automatically calculate the radius based on the centre co-ordinates. The idea of using 4 points is for the data collector to actually go to those points to see if the radius is feasible for our purposes.

I want to stick with ODK/KoBo Collect for this, The general feature to see all entered households on the map will be essential.

As @wroos has pointed out, with a little math and trigonometry, you can readily generate an arbitrary number of points around some center GPS coordinate. Simplest would be 4: North/South/East/West points, since that’s just adding/subtracting an offset from your center’s latitude/longitude value. eg 100m is approx 0.001deg lat, so adding/subtracting 0.001 to your center lat value with give you the North and South points. It’ll be similar for East and West, however what fraction of a deg-longitude that 100m corresponds to will vary according to latitude (but again there’s a well-know formula for this…).

Or if you want to get fancy, you can generate more points around your circle perimeter with a few well-placed sine and cosines… Start dusting off your high-school trig textbook! :slight_smile:

3 Likes

I think it’s that time @Xiphware – I’ll make my high school algebra teacher proud.

3 Likes