User story: Uplift of RCS to geocore with CRUD interfaces

[bo-lu]

As a user, when accessing geocore metadata I would like to also see the viewer configurations (if they exist) so maps are rendered as per the contributor's wishes. Currently, the configuration of the viewer is hosted separately from the metadata and for years, this has caused issues with synchronization and headache to manage.

Therefore, in FY23-24, we need to uplift the RCS logic to geocore with CRUD interfaces to support GeoView and OSDP. A potential configuration name is the GeoView Configuration Service (GCS).

Work:

• RCS will be harvested from GeoNetwork when a record is published, changed or deleted using the change API. The RCS settings will be appended to the geocore geojson file.
• A listener to the existing RCS API to check if values have been changed (e.g., comparing two hash values).
• New CRUD APIs are need to access/modify the GCS settings manually
• New APIs to summarize the GCS (for example, how many records are viewable on a map?) Link to related ticket: Canadian-Geospatial-Platform/geo.ca#98
• New 'heartbeat' dashboard can be created to monitor the mapping services Link to related ticket: Canadian-Geospatial-Platform/geo.ca#87

[elatsis]

Hey team! Please add your planning poker estimate with Zenhub @bo-lu @johnweng001

[bo-lu]

Note: it is possible to query multiple RCS entries like so (with the comma or %2C):

https://gcgeo.gc.ca/geonetwork/srv/api/0.1/v2/docs/en/574c32db-aba7-4919-9c9f-c58398754173%2Ca4b190fe-e090-4e6d-881e-b87956c07977

First, sort the uuids by date harvested in ascending order. Then append ~250 UUIDs (32-character long) to a extremely long comma-separated string in a GET request (limited by the maximum of ~8000 characters supported by a default Apache LimitRequestLine config). This will reduce the number of GET requests which is slow due to IO overhead. For example, our 7000 records divided by 250 means 28 GET requests will be issued.

Compare the result to a hash value from a previous run. If it is different, iterate through the 250 records to find the RCS entry/entries that were changed and update them in the geocore geojson file. Can do some kind of recursion here, by breaking down the work into two equal halves, but might be too much effort.

Appending to geocore is easy, we will need a flag to disable the automatic harvesting.. say for customized configurations beyond what is in the RCS..

We will also need CRUD interfaces to the GCS.