Support map appearance in select/select_one_from_file

[seadowg]

As discussed on the forum (along with design details), we want to add support for .geojson files in Select questions. This means adding a map appearance for select_one/select_one_from_file (it's opaque to Collect which "select one" is actually being used in the form) that allows the enumerator to select an item from a map. Each item in the map is positioned using data from the select choice's geometery column.

Backlog

• Extract generic "select item from map" implementation from FormMapActivity #4947
• Add support for map and quick appearance in select_one/select_one_from_file #4949
• Add support for select_one/select_one_from_file with map appearance and without quick appearance #4948
• Make sure button text size uses dynamic font size (answerSize)

Cleanup

• Investigate moving shared map behaviour from SelectionMapFragment into MapFragment implementations (maintaining map zoom on recreate for instance)
• Remove individual implementations of zoom behaviour
• Investigate extracting maps module to house MapFragment, MapPoint and MapFragmentFactory and creating modules for each implementation (classic Depenednecy Inversion Principle setup)
• Organize geo package structure
• Add loading state/progress dialog to maps - currently DB operations are all happening on the UI thread (existing problem)
• Add tests to cover bottom sheet behaviour (currently untestable due to animations always running)

[lognaturel]

Exposing standard GeoJSON Feature attributes (type and coordinates) for select choices

In the forum writeup, I proposed exposing geometry in ODK format. That means the type isn't needed. A first split on ";" could be used to figure out how many points there are. If there are more than one, it's a shape if the first and last points are identical. Does that seem ok, @seadowg or do you see an issue with it?

Because we're using the map appearance to determine that a map should be drawn, there's nothing special about the source file being geojson and I think work on this can start right away. By the time JavaRosa does its parsing, we won't be able to tell what the source was anyway. Any select with geometry, name and id fields should work.

[lognaturel]

Any select with geometry, name and id fields should work.

I think it's even better than that -- only geometry is needed. The XForm configures which fields to use as name and label. It will be id and title by default for geojson as it is now name and label by default for other selects but will soon be configurable.

Here is a form that should work.

All this makes me wonder a bit whether the geometry field should be configurable as well. Will ponder what that might look like but we can start assuming its name is geometry.

[seadowg]

Here is a form that should work.

Ace! Could you add examples of how the different GeoJSON features will look (like LineString, MultiLineString etc). I want to make sure I have that all correctly understood in my head.

[lognaturel]

Consider requesting no markers on the basemap if it's possible. It's very tempting to tap on them and it's hard to see the form-specified markers in certain locations where there are many many markers on the basemap.

Wild idea: string field with map appearance that lets users select markers on the base map. Presumably GMaps and Mapbox make that possible and would return an OSM id. Not sure about osmdroid and its raster tiles.

[lognaturel]

I've filed a separate issue for invalid geometries: #5075. After thinking through it more I don't think it has to be part of the initial feature and I would tend to take it out of this meta issue.