Discussions in progress (nothing in this document is fully scoped, scheduled, or contracted yet)
fyi Matt Berg Nathan Mceachen Justin Lewis Craig Appl
Any Reveal-CGR integration will have to be phased. We anticipate the following phases.
Phase 1: Get a hierarchy defined in the CGR into Reveal.
GOALS
Build process of preparing shapefiles into neat and nested geojson format, into CGR. Currently this is happening manually by Akros GIS team.
Requires Akros and Tf teams to document the process that Akros is currently and build it into CGR
Test would be that an output is the identical geojson that Akros sends to Ona/Pierre
Build a Reveal output in CGR for hierarchy to be sent to Reveal.
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)
Build a connector from CGR restAPI to Reveal Nifi to connect and transform CGR output and put in Reveal
Deal with/change json properties as needed
Other transformations
Build connector, format, transformation, and hierarchy structure being compatible
Mostly Akros + Terraframe: Documenting what Akros has had to do to prep files for Reveal. Identify the process and how to get into CGR.
End goal/expectation: Client would be uploading their files into CGR and that would ‘port’ over to Reveal
Input to CGR could be all the inputs that CGR supports
*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)
Jira tickets/user stories this would cover
Phase 2: Operationalizing integration, dealing with change management and in-field edits.
Work done already (proof of concept only):
Feature 1: CGR adapter
Feature 2: Geowidget download of hierarchy
Did not put these two together
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).
Phase 3: 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.
In discussion:
Need to know what the LOE would be broadly on the Ona side to do this.
Need to know LOE for phase 2 and 3
Need to further define phase 2 and 3
Need to define if there is implementation $ to support CGR and servers in pilot country (e.g. Thailand?)
In Reveal architecture is there a facade interface where all the architecture is abstracted?
Yes in WebUI
Unknown Android Client and Server
Annie’s notes
Client-desired capabilities
Importing coordinates, vector shapes, enumeration/hierarchy data
Updates made in field get into system
What are the nodes of integration that make most sense technically and strategically?
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?
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 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?
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?