SEL-Columbia / formhub

Mobile Data Collection made easy.
http://formhub.org
BSD 2-Clause "Simplified" License
259 stars 163 forks source link

Geo vector feature selection field type? #1348

Open edrex opened 9 years ago

edrex commented 9 years ago

Our surveys have a question type we call "planning unit". The way it works is that we create a GeoJSON FeatureCollection[1] where each feature is a grid rectangle (but they could really be any shape), and then the respondent selects a particular unit (or group of units for a multivalued question type) by pointing to the feature on the map[2].

We would like to explore the effort needed to extend Formhub and Enketo to support this question type (actually 2, a single and multiple selection version). I'm interested in doing this right, in such a way that it can be adopted out later, but I'm also very new to the ecosystem so don't have a good idea of whether an implementation would require changing more than just Formhub and enketo-legacy code. Reading through the ODK Developers thread discussing geotrace and geoshape for background.

Guidance?

Sketch of an implementation spec:

Any major issues with this sketch? Suggestions to improve?

[1] Such as with geojson.io [2] Our current implementation uses Open Layers 2

MartijnR commented 9 years ago

Cool stuff. Not sure if this requires any changes on the formhub side. On the enketo side:

edrex commented 9 years ago

Thanks for the guidance, this is enormously helpful.

  • enketo-express will support external data but it will be different from the 2 ODK implementations. No plans to implement this in enketo-legacy (but most of the work is in enketo-core which is used by both enketo-legacy and enketo-express).

Assuming the initial implementation targets enketo-legacy, would it be feasible to use the media upload support in Formhub to store a GeoJSON feature file? My understanding is that media files are included in the application cache manifest (but will be stored in IndexedDB in enketo-express).

I guess you have 2 options for datatypes and appearances:

  • use geoshape, and add new datatype multigeoshape or something with a new appearance (note: adding datatypes is a big undertaking as it requires changes in ODK Validate (and Collect) as well) .

In our current implementation we just capture the ID(s) of the selected Feature(s), which are in the Feature properties (example) rather than storing the actual geometry, so it seems like we could just use one of the existing datatypes.

  • use the select and select1 datatypes with a new appearance. In this case, most of the implementation could be done by adding a new widget to enketo-core.

This seems like a pretty expedient approach, thanks so much for suggesting it! I wonder if it would be straightforward (and not require changes on the Formhub side) to load select values from an uploaded GeoJSON file rather than CSV. This isn't a hard requirement, but would make creating/working with geometry nicer. Does Formhub server-side validate selected values against the CSV file? If so, it seems like changes would be needed on the server to support loading values from GeoJSON.

MartijnR commented 9 years ago

Assuming the initial implementation targets enketo-legacy, would it be feasible to use the media upload support in Formhub to store a GeoJSON feature file? My understanding is that media files are included in the application cache manifest (but will be stored in IndexedDB in enketo-express).

Yes, but currently this file won't be automatically added to the ApplicationCache. Actually, if feasible, I would consider adding the geo shapes to the XForm itself (not as external data).

I also wonder if it makes sense to use the existing geoshape format instead of GeoJSON. It make the widget simpler as you could use the current geowidget as a basis (as this will already be able to display geoshapes in this format).

With the above, and using select and select-one with appearance="geoshape", your project could perhaps be reduced to simply creating a new enketo-core widget and nothing else (I would then be very interested in a pull request). I may be overlooking something though and you may need to use a handcrafted XPath expression in your form to obtain the id from the selected geoshape.

I wonder if it would be straightforward (and not require changes on the Formhub side) to load select values from an uploaded GeoJSON file rather than CSV. This isn't a hard requirement, but would make creating/working with geometry nicer. Does Formhub server-side validate selected values against the CSV file? If so, it seems like changes would be needed on the server to support loading values from GeoJSON.

If external data is required, it would be nice to use a format that can easily be converted to XML (XML itself would be best), in order to be able to use plain XPath (or some custom XPath function) to obtain the required values from it.