I've had a go at the connector and here's some feedback:
- Love the coding style, well documented and readable
- I used the code as is and did not fork or alter it.
- Got stuck at Using... step 3: The "path" meant the "ODK Central API URL". The example ending in
/v1
finally was the winning hint. The mention of "Using your form ID" threw me, as that only comes three dialogues later. - Was able to log in fine once "path" was correct.
- Consider using a form's OData Service URL as single parameter, replacing "path" in the first screen (login to ODK Central) and in the second screen (form config) replacing "dataset ID" and "form ID". You can parse all these elements out of the OData service URL.
- Was able to view ("explore") the data.
- Was not able to create any map from either WKT or GeoJSON. If you figured that one out, your users would love having these instructions in your README (or wherever they might be looking when using the connector). That's GDS's omission.
- Was not able to view images, but that's the current implementation of ODK Central: Can we hotlink ODK Central media files?
See what ruODK does to retrieve images: code and docs.
If you'd ask me what else to add to the roadmap, here are some ideas:
- Show a map of geopoints with popups showing custom HTML including images from ODK Central submissions (that's an extra authenticated HTML request per image, maybe trigger async on popup open).
- Show some useful example visualisations in GDS of the standard fields you could expect from an ODK form - metadata, submission dates, start/end times of forms, geolocation/start_time.
- View and left join repeats (any other table than "Submissions") to main data.
- A step by step tutorial of the above.
Overall, great work, wonderful code, and shaping up to become another valuable "low-code" avenue to visualize the OData feed.