Reveal Location

Akros 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)

Phase 1: Get a hierarchy defined in the CGR into Reveal. Cover this Jira story:

https://smartregister.atlassian.net/browse/RVL-410

Phase 1 Option (all would need to support client-based sync changes)	Pros	Cons	Est. LOE

Phase 1 Option (all would need to support client-based sync changes)	Pros	Cons	Est. LOE
a. CGR as the master list. “Bare metal” instance of CGR 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)
b. CGR as the master list. “Bare metal” instance of CGR 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

Options 1, 2, and 3
1. GOALS
  1. Build process of preparing shapefiles into neat and nested geojson format, into CGR. Currently this is happening manually by Akros GIS team.
    1. Requires Akros and Tf teams to document the process that Akros is currently and build it into CGR
    2. Test would be that an output is the identical geojson that Akros sends to Ona/Pierre
  2. Build a Reveal output in CGR for hierarchy to be sent to Reveal.
    1. Spec for what a json going into Reveal will look like → This is in a Github issue → geojspec, georegistry spec, FHIR spec to build this spec (Tf to build spec, should have this budget already in new grant)
  3. Build a connector from CGR restAPI to Reveal Nifi to connect and transform CGR output and put in Reveal
    1. Deal with/change json properties as needed
    2. Other transformations
  4. Build connector, format, transformation, and hierarchy structure being compatible
    1. Mostly Akros + Terraframe: Documenting what Akros has had to do to prep files for Reveal. Identify the process and how to get into CGR.
  5. End goal/expectation: Client would be uploading their files into CGR and that would ‘port’ over to Reveal
    1. Input to CGR could be all the inputs that CGR supports
    2. *How to we expose the issues in hierarchy alignment (i.e. issues in transformation from CGR to Reveal) to user. This needs to be a part of phase 1 (error capture)

Phase 2: Operationalizing integration, dealing with change management and in-field edits. Cover these Jira stories:

Phase 2 Option	Pros	Cons	Est. LOE

Phase 2 Option

Pros

Cons

Est. LOE

Editing in client using geowidget; update OpenSRP/OpenMRS locations in server and data warehouse

Support field-based updates with less effort than other options.

No UI for managing changes to locations → no admin workflow to “approve” locations

Potential significant data issues without way to manage/approve field updates.

M to L t-shirt size.

~1 month dev work

2. Editing in client using geowidget; update OpenSRP/OpenMRS and sync to CGR

Web-based manage of locations; use of admin approval workflows

Audit functionality for change management

Complexity of master list syncing

3, Editing in client using geowidget; sync directly to CGR

CGR becomes part of Reveal stack!

CGR becomes a requirement in Reveal stack - unknown how complex this would be for implementation

We will not support the ability to create new operational areas (this includes drawing a new OA or splitting an existing OA).

Geowidget work done already
1. Feature 1: CGR adapter
2. Feature 2: Geowidget download of hierarchy
3. Did not put these two together
  1. Would need to implement geowideget into Reveal - work for edit process and SAVE as event, sync locations down and up (and someway to undo this in an admin/dev way) in field and sending to server, updating data warehouse
4. End goal/expectation: Client would be able to make specific changes to the hierarchy either through web UI of CGR or through Reveal mobile client (geowidget).

Phasing considerations

If we use the CGR in phase 1 (options 1 -3), we need to have two way syncing to be able to support Phase 2.

Phase 3 (future): Tighter coupling of CGR and Reveal so that CGR is the system of record

These are already both Java applications so we have these written to work together. Would this tighter coupling make life easier.

CGR vs OSM as production environment

Depending on the strategies chosen for each phase, there are two options for the ‘production’ environment for Reveal. This is the place where edits will be made on the Web side. Below we list the pros and cons to each.

	Pros	Cons

Pros

Cons

OSM

Optimised for enumeration and boundary management

Widely available for crowd-sourced enumeration

Very mature tools for editing and creating polygons

Cloud hosted and free

Easy download of locations with Overpass

Open-source nature makes bulk editing difficult

Other actors are able to modify information

Not a good place to store any non-public data

CGR

Data is protected from external modification and use

Bulk updates possible

Storage of program specific objects possible (OSM community may not want Reveal specific layers added to OSM)

Change over time functionality

Change management functionality

Support available

Lack of layers in navigator

Not optimised for drawing boundaries

Untested for large country deployments with many k geoobjects and many users

Platform less mature

Workflow for Master List Updates

Master list - Reveal
- Log in to master list application (CGR or OSM)
- Make a change or add an object
- This action get logged as a change request (this could be manual in the case of OSM, or automatic in CGR)
- When the change request is approved, the change is synced to Reveal
- Todo: ensure there are rules to prevent the destruction of any information in Reveal
Reveal – Master list
- Drop a point in Reveal when a new structure is found
- Upload this to the master list
- Approve addition in master list
- Sync the master list unique id for that location back down to Reveal

_____________

Annie’s notes (old)

Client-desired capabilities
1. https://smartregister.atlassian.net/issues/?jql=project%20%3D%20RVL%20AND%20labels%20%3D%20Geoprism%20ORDER%20BY%20priority%20DESC
  1. Importing coordinates, vector shapes, enumeration/hierarchy data
  2. Updates made in field get into system
What are the nodes of integration that make most sense technically and strategically?
1. Location hierarchies for Reveal

Initial load
MaintenanceIntegration of front end changes
Field edits that are sent from geowidget and maintained

We need to definitely capitalize on geowidget-CGR work already done, but what else?
1. Use CGR locations for reporting.
2. Use CGR locations for reporting on activities over time (time support is being implemented now).
3. Master list curation
4. Use CGR WMS/WMTS services for visualization or operations.
5. Use CGR interface to build out the authoritative data.
Other possibilities?
1. improve ability to support front end tools in the geowidget (like drawing new polygons, editing existing) through CGR storage and maintenance strategies and functions
2. Data structure and storage - any opportunities here?
3. User-team-plan-location linkages: would bringing the CGR and FHIR models together offer any opportunity for more flexibility?

B. Technical readiness of each tool for integration - how far are we from this and what would it take to get us there ($ and time wise)? And what has already happened/is already underway?