Explore possible relationship between geopoint question type and geoJSON representation

[latin-panda]

Useful links

• GeoJSON specs
• ODK Collect specs

Description

The default Geopoint question type was added as part of this work.

Evaluate the codec and see how to fit GeoJSON; maybe external secondary serialization to use the same encoding logic.

[lognaturel]

I believe there's already support for geojson external secondary instances! There are two aspects to that:

• properties are made available like they would be for a CSV attachment or internal choice list
• geometry is made available through a special well-known geometry property

You can validate that the former is working by doing a select_one_from_file on a geojson file like cities.geojson.zip. You should see a list of all options.

For the second, let's say you have that select_one_from_file cities.geojson and the field name is city. You should be able to do something like have a calculate on a geopoint question with calculation instance('cities')/root/item[name = ${city}]/geometry and the geopoint question should show the location of the selected city. It's possible this second part doesn't work yet, I'm not sure.

[latin-panda]

@lognaturel This ticket was created because it was expected to have GeoJSON represented in the codec as an input value . When I first implemented Geopoint, that part was left out to reduce the scope to just the minimum to get Geopoint working.
I'd need time to dig and see if we still need it in the codec, and verify how that affects the processing in xforms-engine.
Is it okay to look at it after the select with image work? We can move it up in the backlog.

[lognaturel]

Aha, thanks for that additional context. It's not high priority at all, I just thought it could be closeable. I'll try renaming it to reflect what you just wrote and you can update it as needed.

[lognaturel]

Here's a form to validate that geoJSON secondary instance support works as intended: select_city.zip