Display features on the map based on a diameter

hello everyone, I would like to know if it is possible to display the entities on the map according to a radius around the collector.

example display all entities that are 10 meters from the collector.

If it is possible how to do it?

Hello @steeve_kevin ,

not in an easy way. I tried something that woks on grids but it is really not clean nor efficient :

  • It requires to create a geopoint to filter the place to print on the screen
  • It isn't based on the real distance between the enumerator and the places to show on the map but on the precision of the coordinates (considering that close places share the sames coordinates at a certain decimal level. The distance in meters that correspond to 0,0001 degree vary from one place one the earth to another...

So I calculate the longitude and latitude of the geopoint and I filter the places to show on their own long / lat values...

In a secondary version I compare the actual position and the boundings coordinates of the select objects.

Tell me if it is not that clear...

We agree that such a capability, to filter features with the actual location, in a transparent (no geopoint needed), efficient (indexed) way would be great :wink:

Thanks @mathieubossaert please I can see your solution I would like to test it and if possible make an improvement

of course !

Here it is, compliant with the extraordinary xlsform tamplate :star_struck:

  • The form ask you for a tolerance in meter (here I consider one meter correspond to 0.00001 degree)
  • We use a ten meters square grid (geojson attached)
  • The map shows you all the cells close to you that were not selected earlier in the form
  • If you do not find the cell you want close to your location, the form shows you the whole layer...

filter_on_location.zip (366,6 Ko)

Please share any trick or improvement :slight_smile:

This is likely not performant enough for your needs, especially given @steeve_kevin's 180,000 points (!), but have either of you tried a choice filter of distance(geometry, ${current_location}) < 10 where current_location would be a geopoint question?

1 Like

Thanks @ln!

No... And I don't know why :face_with_raised_eyebrow:
I''ll try it in a few jours !

I just tried but I can't make it run @LN.

Distance asks for one parameter.
I tried to concatenate both points as shown in the documentation : https://docs.getodk.org/form-operators-functions/#id22

distance(concat(geometry,’ ; ‘,${point})) < ${tolerance}

But now get an error saying the function distance requires a field as a parameter.

Now I remember I fried before I used coordinates calculation.
But your optimism with the distance function make me think it is possible :slight_smile: and I am misusing the function.

Sadly my optimism was misplaced. I did not realize that the geo functions only accept nodeset arguments. I've filed an issue to explore changing that: https://github.com/getodk/javarosa/issues/740

1 Like

Is there no possibility to "cast" a string to a node-set? (Something like a make_instance function :innocent:). This could help in other contexts too.

That's an intriguing concept. What are some examples of how you might use this functionality? We don't currently have a concept of a "virtual" nodeset that doesn't directly represent something in the form.

I have a more formal spec proposal available at https://github.com/getodk/xforms-spec/pull/311 and an implementation for Collect at https://github.com/getodk/javarosa/pull/761.

This sample form shows an example of a basic geofence: only points a certain distance from the current location are available to select.

2 Likes

Hi @LN I tried your solution and I got this error

It should also be noted that this solution needs a lot memory space for calculation so it crashes the application Odk collection

It's crashing because the code isn't in Collect yet. You'll need to wait until the xforms-spec and javarosa pull requests are merged and we ship a beta.

1 Like

Waouh ! That's so promising !
Thanks a lot for that.

It makes me think about this...

You should now be able to verify the form I shared above in the latest Collect beta using its XML: Filter select by distance.xml (1.4 KB). Central/pyxform will need to be updated before you can use the XLSForm.

I've also put together a form that describes basic reverse geocoding (going from a position to a place name), basic geofencing, and location filtering by distance (what we've been discussing previously in this thread): Distance examples.xml (7.5 KB) (XLSForm for future use)

Let me know whether you find the examples form helpful and whether there are other uses of the distance function that might be helpful to document.

Relatedly, the next Collect beta will include a geofence(point, shape) function that @Xiphware described at ODK geofence (v1) and contributed to Collect. It will let you verify whether a point is inside of a shape. Example form. This XLSForm will work in Central/pyxform today because of the if. I'll update once the next Collect beta is available.

4 Likes

I read this a few days ago thinking that I only had overly complicated ways to utilise this, but have just realised I have a great use case for the function. :confetti_ball:

A question - you say It will let you verify whether a point is inside of a shape, will it also verify if a series of points (i.e. geotrace, geoshape) is wholly (or partially) within a shape? If not, I think I could make my use case work by extracting a single point from a line/shape and then checking if that single vertice is inside a shape.

Thanks @LN, I was quite busy those days so I just tried to test it. Could you share the eiffel.geojson file for the "Filter select by distance.xml" form ?

I understand the word geofence as a fence that allow a user to do something or not regarding his location compared to the fence.

To use it to test to check if a point is inside a ploygon (for example to lookup in a geojson and pull the name of the study site) I would prefer a maybe more explicit synonym like inside or within.

1 Like

Nope. Its basically a point in convex or concave polygon algorithm. Whereas the intersection - or not - of two arbitrary polygons is a quite different geometry problem [note, checking whether the vertices of one polygon are all inside or all oustide of the other is not suffficient to determine if they overlap, nor if one is wholly contained within the other]

Thanks for the clarification!

looking forward to testing this in the next beta.

Ah yes, sorry! You can find it here.

I hear you, I wasn't very comfortable with the name at first either because it does sound like it sets up a fence that will be enforced. I think any other alternatives we include will need to include something about geo, though, because something like within feels like it could apply to different types.

Some alternatives: point-in-polygon, in-polygon, in-geofence.

@Xiphware mentioned in the Github discussion that there isn't precedent for a prefix like in and that geofence may be a term someone searches for.

Although this is in the latest Collect release, it's not yet supported by pyxform and we haven't announced it so if someone feels strongly about a name change, please do say so now!