Improvement ideas for select from map

Hi,
we use a form with select_one_from_file with geojson file and users give us feedback. Maybe it's just not possible but it's a good idea for future releases. I give you these requests or ideas (or response) :

  • plus (+) and minus (-) buttons to zoom in addition to the fingers, which are not always easy to use, especially on small screens

  • to be able to define the initial zoom level of the map and above all to have the possibility of keeping the previous zoom level, in particular in selection loops. (we select trees quite close to each other and it is painful to resize each time)

  • Have the possibility to display data in the form of a label visible at certain zoom levels and possibly maskable by the operator

  • The color of the symbols is defined at the level of each element of the geojson file and is no longer modifiable thereafter. We manage to hide elements that have already been selected (in a repeat loop) but ideally it would be desirable to change their color.

Some features may be possible but I don't know how to implement them, others may already be expressed with more or less complex or even impossible implementations, but at least we will have expressed what would be ideal for our use and probably interesting for others.

Thanks for advance for your response

Hello @Alain_Benard and thank you for your thoughts.

I was just preparing my own comments on this great select_one from map function. I hope you don't mind if I complete your thoughts with my comments...

Loading large external csv or geojson files (hundreds of objects) to feed the selection from the map may be painfull for collect regarding the terminal you use or the size of the file.

A trick I tested successfully is to ask for a geopoint before the selection and compare (choice_filter) the rounded lat and long values of the geopoint to the rounded lat/long values of each centroid object. This works fast and is efficient but it requires an extra question and screen each time the user wants to select on the map and also to fill 2 columns in the external file.

This makes me think of different things:

  • automatically filtering objects that intersect the screen extent (at a zoom level to be defined) or that are within a defined distance of the GPS signal would be really cool (this would certainly require indexing the geometries in the external file)
  • Another approach would be to be able to retrieve the latitude and longitude of the current position without creating a question and the to compare it with lat/long attributes of each object (as in my trick).
  • or to be able to load a hidden geopoint where we want to use it in the form.
  • Displaying vertices on a polygon seems to be expensive, I'm not sure if they are still needed, since we can now tap anywhere on a polygon to select it. Maybe showing only edges would help Collect.

Hello Mathieu, no problem for completing. Any idea are welcome and can interest other person.
It's sure, this 'select_one from map' is very great and a young possibility.
Have a nice day.

1 Like

Piling on after using this in anger for a bit

  • Overlapping / clustering / selecting
    • I now have an issue where I want to show field collected shapes to users, I am applying a filter (location, elevation, which 'side' it's on, plus what category it is,) however there are still shapes that overlap, and a large shape over a small shape means the small shape cannot be selected to get its details. The old way of rendering shapes with vertices did allow you to select the underlying shape by tapping its vertice.
      • Edit: In case anyone else is faced with this - I'm spilling out a few fields from my submissions to create a CSV containing the items to show. As I am calculating area in the form, if include this field and sort the items by area (small to large), then the smallest are drawn on top, so for almost all cases, each shape is selectable and no longer obscured by a larger one.
    • I already had an issue where two points with very similar geometry would overlap and one would prevent the other from being selected. If they're very close you cannot even tell there is one there that requires attention
      • Likewise, in this case I would sort by point styling to put incomplete ones on top
  • Styling - I use the styling of points to indicate a status/category to the users, changing the character and colour after completion. Similar styling for lines and shapes would be super - colour of line or fill / label of some kind
  • Images - Bit of a dream, but: being able to have a filename in the choice list (really, it'd be to use image in the choice list) and when selecting an item that image is rendered when you bring up the item tray with the other fields (name, label etc). This would be so helpful. Currently the only option is to select a feature, then show it as a dynamic image :wink: in a note - not as quick as tapping on a series of features on a map to find the one you want.
  • Could geometry in WKT be parsed as is in a CSV or will ODK format only ever be accepted?
  • I suppose it's down to the mapping SDK but +/- buttons would be nice, as when using gloves 'pinch to zoom' is difficult (can double tap with a stylus to zoom in steps, and hit the extents button to zoom out)

A couple more comments.

Documentation

The docs are slightly out of date for line/polygon as the vertices aren't shown currently (at least for polygon, I haven't tested lines recently)

Line and polygon choices are represented by red lines connecting small white circles at each vertex.

+/- zoom buttons

I know @seewhy wants +/- buttons to zoom when you can't two finger pinch, as did @Alain_Benard. They would be handy in cold/wet/dirty environments when gloves are worn. These were removed from OSM early this year though (due to OSM bug creating points when using them?) so I'm not sure they're coming back.

Indicate selected polygon/line

A selected geopoint enlarges to indicate the selected item, but a selected polygon doesn't change in appearance at all apart from a slight map zoom and a pan to centre it. If there are multiple polygons in the area it's not clear to the user which one has been selected. I don't have a great suggestion as to what to change to indicate this - show vertices / invert colouring / remove fill / change outline weight or style / flash element? Show vertices might be the simplest as a fixed colour change may clash with styling colour. Changing the stroke might not be feasible, especially as Mapbox doesn't obey it currently.

1 Like

I didn't spot the removal of the buttons (because I have not used OSM basemaps, so didn't know they were there!). It's always been a low-level 'desire' to have zoom in / out.

Buttons would be an extremely useful feature (and in keeping with most spatial apps). Dynamic maps on the web have +/- buttons at the top right by default, so it shouldn't be too much of a leap for enumerators.

The 'double-tap' zoom has been my work-around, but zooming from full extent just to get an overview is a bit tedious...

I'd agree that show vertices would be a good option when selecting. Filling polygons might work, but that doesn't solve the issue for lines, so it would at least be consistent between different geometries...

thanks for the tip Andrew !

Another one spurred by a github issue...

What high-level problem are you trying to solve?
With a select from map, there are often many columns associated with the choice list used for filtering/lookup etc, but I only want to show some of them to the enumerator.

Any ideas on how ODK could help you solve it?

Let’s filter out all properties with the double underscore prefix since they are not useful to users.

If this issue is resolved as described, can user created fields in a choice list / CSV / entity list also be prefixed with __ and they will be accessible for lookups/filtering etc but be hidden on the map bottom sheet?

1 Like