Remote sensing data derived from WFP’s Open Data Cube and SERVIR’s RHEAS platform are configurable and visualized within PRISM

For WMS and WCS layers, we need to get a list of available dates.

We can get inspiration from the code in https://github.com/wfp/PRISM/pull/190/files

Historical disaster and additional food security, nutrition, and poverty statistics are displayed within the table and chart views of PRISM

I just deployed the ground station date fix to https://prism-mongolia.org/. After deploying I noticed that if you load a ground station layer first (which as of now will use Sept-21 as the latest) and then try to load a WMS layer, it fails. The latest WMS layer is Sept-11.

The current implementation for nso layers was built around getting an API response as a json. More often, we're setting up these layers based on fairly static locally sourced datasets. Instead of requiring a json, allowing a CSV to provide the data and admin key would simplify steps to setup PRISM in new instances.

The ideal state is to have layer configuration work the same as current. The configuration in layers.json specifies the data field, admin key, and file location while the implementation detects if the file is a json or a CSV and renders the layer accordingly

Popup with data details
When a user chooses a layer and then clicks on a polygon (administrative area), they should see a popup with details for the layer and that area. There are two types of data and requirements for this interaction:

• Data already in the admin boundary GEOJSON, usually "baseline" data
• Raster data, such as climate data derived from the Mongolia Data Cube (MDC)

We can take inspiration from https://github.com/bayesimpact/encompass/tree/master/frontend/src/components/MapTooltip

More info is available here:
https://docs.google.com/document/d/1uD3S33TkKVUPRqkx2hQP65Nl6dOHBYenP1rroZHHbC4/edit

Through the PRISM interface, users are able to produce descriptive statistics interaction with administrative areas and indicator selection from drop-down menus

Right now JSON data files (e.g. admin boundaries, NSO files) are being directly imported into the code base (e.g. using an import statement in JS). This means that the full JSON data gets bundled into our javascript code, which is pretty seriously bloating the deployment.

These files should be hosted somewhere (e.g. S3 buckets) and fetched asynchronously instead.

Right now there's a slight vertical scroll for the main map container. This is because the map view is sized using 100vh, which doesn't account for the height of the navbar.

We should redo the structure of the page to make the the main wrapper a column-oriented flex container, with the navbar taking up its fixed height and the main container growing to fill the rest of the available space.

We would like to order layers to make sure that raster layers are at the bottom and that admin boundaries are at the top.

We could look at using the before option to order layers - alex3165/react-mapbox-gl#35

We would like the app to be available in multiple languages.

We can use i18next and have a similar approach as mapswipe/website#33

Currently, if dates fail to load from WMS, WCS or Point Data, an error is sent to the console. There used to be a notification, served through the error notification middleware, but this was removed because if an exception is thrown in serverUtils, all the other layers would not attempt loading dates.

To solve this, a notification could be dispatched instead of relying on the error middleware.
Not too much of a concern as date errors aren't likely to happen, but would be nice to solve eventually

https://github.com/WFP-VAM/prism-frontend/blob/5c68143ff2e15ac95127c8f5ceac673293d7096d/src/utils/server-utils.ts#L180

Relevant links for the implementation:

• https://docs.traefik.io/middlewares/ratelimit/

Or use slowApi?

Idea

Create a config generator to make it easier for new users to create or update their own configs.
We could also allow loading a file or using a remote config easily.

This is a continuation of the concerns raised by @bencpeters at the following PR disscussion.

In summary, the way BoundaryLayers will load after #81 merges is less than ideal since it is done in MapView. We ideally want a way to load it in BoundaryLayer. If you have a solution, let us know!

Also, after exploring issue #27, I noticed loadLayerData does not have any way to prevent loading things twice or loading while the promise is pending. The current measurements that ensure this doesn't happen are located within the dispatch itself (example).

There is an article on Redux Docs on how to achieve this.

I've already attempted to solve this here, but the implementation isn't done too well - we mutate an object that just lives alongside the thunk. If we can agree this is a worthwhile issue, I can continue on this branch and make a solution that instead works around redux states.

Idea

Allow users to share a link to a specific analysis / selection / view

The current date selection implementation is not ideal. Let's propose improvements from a UX and UI perspective.

Current implementation

Context
Layers can have data available daily, once per month or every 10 days. We can only select dated layer at a time.

PRISM should have support to display a choropleth map (from statistics data in JSON format) with time-series variable. For example is to show the poverty rate in district level from year to year, or to support rendering "old version" of impact layers (the data also in statistics and JSON format).

PRISM already have the "NSO" layer type which can display choropleth map and also "point_data" which render selected time-series data from given link. I think the approach that we can use is NSO layer with capabilities to get and render data from API just like "point_data".

IDCO would like to prioritize in this feature as we need it to display socio-economic layer (ideally in time series so people can compare the changes from year to year) and support for "legacy" impact layer data. But first I would like to clarify and ask some question to @ericboucher and @dubwalla:

• I would like to just confirm if the feature mentioned above is not already supported, or RBB team is currently developing a similar feature?

• Should we create new category, or should we just expand from NSO layer type with more parameters something like: "timeseries": true, "data": http://linktoapi, etc.

• Should we have more standardize API? Or should we make it more flexible, so user can setup the "GET" format in config file alongside with layer properties.

Thank you.

The current implementation of text legend class is to read the value properties. While now it can accommodate number and text, the way it implements somehow a bit confusing (I assume it will process integer/number first, then put all "value" including string for render the legend element.

What I would like to purpose is a dedicated "text" property for legend. Which can provide a more flexible and predictable way to generate text for legend, while separating the class for value classification.

"legend": [
{
"value": -40,
"color": "#7ab1c0",
"text": "-40° C"
},

First I would like to have input from @ericboucher about the idea. I would like to put the changes as part of understanding the ideal workflow of adding features into prism workflow.

Layer need statement for vector & raster.

While we get WMS images as layers, we would also like to get raw data to run browser side analysis.

One possibility would be to get WCS layers as geotiff that we can then process in the frontend to analyze and merge.

Is this a reasonable approach? What other methods could we explore for browser-side analysis?

--> Comment on PR#32

We shouldn't mix and match Immutable & regular JS objects. Since this is all Redux state with Immutable, we'd like DateRange (and MapState for that matter) to be strongly typed Maps instead of objects or weak (because of the any) types.

This SO post is useful for that - read the first answer.

You can do something like:

// The default Map interface accepts <K,V>: Key, Value.
// Build an interface that also accepts 'T': the shape of your data.
// You might want to add other methods, e.g. `update`? Probably can cut and paste more or less from
// https://github.com/immutable-js/immutable-js/blob/7f4e61601d92fc874c99ccf7734d6f33239cec8c/type-definitions/Immutable.d.ts#L2449
export interface IImmutableMap<T, K, V> extends Map<K, V> {
  toJS(): T;
  get<I extends keyof T>(key: I & K): T[I] & V;
  set<S extends keyof T>(key: S & K, value: T[S] & V): Map<K, V>;
}


export interface IMapState extends Map<string, any> {
  layers: LayersMap,
  // Do a similar typed definition for `DateRange`
  dateRange: DateRange,
};

export type MapState = IImmutableMap<IMapState, string, any>;

// Update the type definition on initial state to your type.
const initialState: MapState = Map({
  // Not sure if you'll have to cast these or if TS will just pick them up as a compatible type
  layers: Map(),
  dateRange: Map(),
});

(haven't tested this, but something like it should work)

Each type of layer can have a date attribute associated with it but currently only WMS layers have this implemented. We need to be able to display the appropriate data based on a point in time. For example, for ground station data in Mongolia, a new reading is collected every 10 days but the current implementation can only show the latest available data. And in Indonesia, some of the baseline / vulnerability / nso layers may have different values based on the month and year.

An MVP version of this could include the layer configuration to specify the date interval required and available dates with data. A more ideal solution would to have some service that determines the interval and available dates automatically but that would require something like WMS GetCapabilities on external sources that we may not have control over. @ericboucher - what do you think?

A solution for this in Mongolia for the ground station data needs prioritization. A solution for nso layers could come later, but it would be great if we can solve for both cases together.

As a user, I should only be able to select ONE layer with dates at a time.

In the NavBar, the GitHub link should point to https://github.com/oviohub/prism-frontend

The About should display a modal, similar to the one on https://encompass.bayes.org/

After #92 has been merged

It is the extension of the #86
This is in the continuation to New Analysis UI Footer
The new Analysis UI

TODO

• Add new footer UI
• Improve clear analysis functionality
• Improve Download functionality
• Refactor the analysis layer
• Improve the implementation of tooltip on the map

Currently the NSO data type expects the data attribute to be mapped for an admin area to be called 'DTVAL_CO'. This was specific to Mongolia. To make deployments more efficient, we should allow this to be configurable for each layer, the same way that the admin code is configurable.

We need to improve date utils. When we select the month of February, a layer available on 01/31 should not be the one selected.

The DatePicker is timezone aware, which makes it tricky to save string dates into date formats and then get matching string dates again.

Eg. 2020-02-10 becoming 2020-02-11 in #25

To mitigate that, we should make the app timezone independent, esp. the DatePicker component.

⚠️ The routing must be bugged

The new useDefaultDate hook introduced in #102 was not made to be timezone compatible, making it break in GMT timezones with a negative offset.

Also, the dispatch done within the hook sets off "Cannot update a component from inside the function body of a different component" and could be solved using the following as a guide:
https://stackoverflow.com/questions/60526786/react-warning-cannot-update-a-component-from-inside-the-function-body-of-a-diff

Defining an environment variable like this ( "start": "EXTEND_ESLINT=true react-scripts start") makes it incompatible with Windows as EXTEND_ESLINT=true isn't a valid environment definition.

This can be solved by introducing cross-env. This will ensure the PRISM dev environment will work on any platform.

Make the app more mobile-friendly or add modal notifying users that the app is not optimized for mobile yet.

Technical documentation is generated and published on GitHub

Hey 👋
I am facing some issues in setting up a local environment.Since there isn't any Contribution guide, so I am not sure whether did I miss something or it's a bug somewhere (dependencies versions most probably)
I cloned the repo and install dependencies, without any configuration to the files I tried starting the dev server but I end up with some eslint plugin issue

Google wasn't a good help in this case, so maybe someone who already faced a similar issue might be able to help me.

git clone https://github.com/WFP-VAM/prism-frontend.git --depth=1
cd .\prism-frontend\
npm install
npm start

Tools for monitoring system performance and alerting critical errors are published

Handle errors when fetching data.

In particular, have the ability to parse time mismatch "Time dimension value '2020-02-10' not valid for this layer".

And server errors (eg. server offline)

The current Legend button:

Could use some improvement, notably in its style and functionality.

Ideas:

1. The Hide/Show button could be styled to fit more into a Material UI theme, making it complement the switches.

2. It could also be converted to a drop-down style, replacing the 'eye' with a chevron arrow.

3. We could add crosses on every legend section so a user can quickly remove a layer by clicking the cross on the layer's legend.

WMS layers can have multiple styles associated with them but this isn't currently handled by the frontend. For example, WFP's Open Data Cube instance provides multiple styles for the same product which an end user can choose between based on regional differences or for different temporal aggregation. You can see this from the GetCapabilities request: https://odc.ovio.org/wms?request=GetCapabilities where the product 'rfh_dekad' has 5 different style options ('rfh_200' to 'rfh_1500').

Without the style attribute sent in the WMS request, ODC returns a default style, 'rfh_600' in this example. We need to be able to specify which style to load as part of the layer's configuration.

Using spatial intersections, impact analysis calculates the number of people exposed to a hazard

Basemap and boundary data are easily configurable, and displayed

We need to centralize information on servers and have a "parameter" approach for layers / types.

Related problems

• With the async context initialization, the selected layers are re-render on server dates loaded.
• When we add/remove a new layer, the previous layers get re-render (not super-efficient)

A first hacky solution (handling constant layers adding):

import React, { Fragment, useState, useEffect } from 'react';
import moment from 'moment';
import { Map } from 'immutable';
import { Source, Layer } from 'react-mapbox-gl';

import { formatServerUri } from '../../../utils/server-utils';
import { LayersMap, LayerType } from '../../../config/types';

const commonQueryParam = {
  version: '1.1.1',
  request: 'GetMap',
  format: 'image/png',
  transparent: true,
  exceptions: 'application/vnd.ogc.se_inimage',
  bboxsr: 3857,
  imagesr: 3857,
  width: 256,
  height: 256,
  srs: 'EPSG:3857',
  bbox: '{bbox-epsg-3857}',
};

function Layers({ layers = Map(), selectedDate }: LayersProps) {
  const [sources, SetSources] = useState(Map<string, any>());

  const queryParam = {
    ...commonQueryParam,
    ...(selectedDate && {
      time: moment(selectedDate).format('YYYY-MM-DD'),
    }),
  };

  useEffect(() => {
    const lastLayer = layers.last() as LayerType;
    if (lastLayer) {
      const { id, serverUri } = lastLayer;
      SetSources(
        sources.set(
          id,
          <Source
            id={`source-${id}`}
            tileJsonSource={{
              type: 'raster',
              tiles: serverUri && [formatServerUri(serverUri, queryParam)],
              tileSize: 256,
            }}
          />,
        ),
      );
    }
  }, [layers]);

  return (
    <>
      {layers
        .valueSeq()
        .toJS()
        .map(({ id, opacity }) => (
          <Fragment key={id}>
            {sources.get(id) ? (
              <>
                {sources.get(id)}{' '}
                <Layer
                  type="raster"
                  id={`layer-${id}`}
                  sourceId={`source-${id}`}
                  paint={{ 'raster-opacity': opacity }}
                />
              </>
            ) : null}
          </Fragment>
        ))}
    </>
  );
}

export interface LayersProps {
  layers: LayersMap;
  selectedDate?: number;
}

export default Layers;

When clicking on an admin boundary when a WMS raster is selected, I would like the median value to be displayed in the tooltip.

With the addition of new API requests to fetch an analysis output, we need a new UX / UI which is differentiated from the standard layer views. A user needs to:

1. Configure an analysis
2. Run the analysis
3. Receive an indication of the analysis job's status
4. View the results as a map or table
5. Download the results

Some rough ideas below but please suggest options / alternatives.

Separate UI element to run an analysis

Analysis pane activated:

After staring an analysis job, some user awareness of status:

Buttons active when the analysis job is complete. User can view or download the results:

View the results as a map:

View the results as a table:

The Data Cube returns Land Surface Temperature (LST) in a scaled-Kelvin format. We need to display data in Celsius. Two steps are needed:

1. Scale to degrees Kelvin by multiplying by 0.02
2. Convert to Celsius by subtracting 273

Reference:
https://icess.eri.ucsb.edu/modis/LstUsrGuide/usrguide_mod11.html#sds

In the config, we would like to be able to specify the comparison operator used for the threshold. <, <=, =>, >

When the cursor is over an admin boundary, we should change it to a pointer.

This example is a good starting point on how to implement this with our current library:

https://github.com/alex3165/react-mapbox-gl/blob/master/example/src/demos/londonCycle.tsx