Discussions in progress. Next steps:
Akros is working with VW and Tf to explore how CGR functionality for importing and managing location files works (mid-Feb). Once that is evaluated, we will share what it looks like and how it works, so we can decide if we use one of options 1a, 1b, 2 OR option 3 for phase 1.In March we will start scoping both phases in detail.worked to vet the CGR for key pieces in the hierarchy upload and management process. The feedback on that review is here:
https://docs.google.com/spreadsheets/d/1KRtgnIYW95yr_MqJArgwfYwIRD5KHpM0CbpttpcmoNs/edit#gid=0
Remaining risk in delays of CGR development and added integration.
Decision point:
Pursue TOR to deliver phase 1 option 4 (wrapper and rebuild for scripts)
Ona team to work towards phase 2 option 2 (Android build)
fyi Matt Berg Nathan Mceachen Justin Lewis Craig Appl
...
Phase 1 Option (all would need to support client-based sync changes) | Pros | Cons | Est. LOE |
|---|---|---|---|
Akros would run one instance of CGR to minimize server costs. Requires a one way sync to Reveal from CGR. | One server, one set of costs Production environment for managing location data (see CGR vs OSM table) UI for file prep UI for management Relatively easy “upload”/”download” Open doors to other use of CGR Less GIS experience needed | Additional platform to support, train on, maintain, host (server implications). CGR current limitations - can only visualize one layer at a time, file types for imports are not unrestricted. Manual fixes to hierarchy may take longer in CGR than if someone with GIS experience is doing in QGIS or ArcGIS. | ~2 weeks of exploration, scoping, spec writing (Akros). ~1 week Tf time to customize export format for CGR to fit Reveal. ~1 week Ona time to support and do lite dev as needed Server-set up and monthly support cost (one server - could be shared across implementations) |
As clients have requirements to host own CGR instance, could set up own server and solution. Can do both 1a and 1b depending on client need. | Above, plus full country ownership of hierarchy. | Added cost to own servers. | Same as above but server-set up and monthly support cost, per implementation (could be offset if country self manages) |
2. CGR as a master list. Cloud service | Above, plus benefits of cloud hosting (less downtime, security, streamlined support) | Policy restrictions on this option. | Same as 1.a. |
3. Reveal as master list. UI to load, view, edit, manage locations | Streamlined platform for users. | Rebuilding towards what is already in CGR. May be more than what is really needed. | Significant development effort. We will not pursue this option. |
4. Reveal as master list. Import/Export tool in OpenSRP | Streamlined platform for users. Scripts for start of this already exist. Bulk fix of errors is easier. | No UI for management. Requires skillset to do upfront GIS work to get into correct format for Reveal. Relies on OSM for ‘production’ environment | ~3 weeks Ona time |
...
We need to definitely capitalize on geowidget-CGR work already done, but what else?
Use CGR locations for reporting.
Use CGR locations for reporting on activities over time (time support is being implemented now).
Master list curation
Use CGR WMS/WMTS services for visualization or operations.
Use CGR interface to build out the authoritative data.
OTher Other possibilities?
improve ability to support front end tools in the geowidget (like drawing new polygons, editing existing) through CGR storage and maintenance strategies and functions
Data structure and storage - any opportunities here?
User-team-plan-location linkages: would bringing the CGR and FHIR models together offer any opportunity for more flexibility?
...