Areal protection measures

[thomas-fred]

We want to display coastal protection measures (revetments, sea walls etc.) as features on the map. These features may provide risk reduction benefits to infrastructure features (e.g. road segments). They are essentially adaptation options (in that they can reduce risks) but rather than applying to the owning feature, they may apply to one or many other features, at a distance.

Areal protection features for this project will likely be linestrings. It is possible than in future we will want to implement polygon features though (e.g. mangrove forest).

We have an existing features table which holds infrastructure features. It is quite generic -- it could be used for the coastal protection features.

The adaptation_cost_benefit table has a foreign key -- adaptation_cost_benefit.feature_id -- pointing to the protected feature. One implementation for pairing protector and protectee features could be a nullable adaptation_cost_benefit.protector_feature_id field -- a second foreign key from adaptation_cost_benefit to features.

Clicking on a coastal protection feature could query the set of features with a related adaptation_cost_benefit.protector_feature_id equal to the clicked feature. We could then return this set of features via API and highlight these features within the front end.

[thomas-fred]

Any thoughts on how best to implement this, @eatyourgreens ?

[eatyourgreens]

@thomas-fred adaptation_cost_benefit.protector_feature_id seems like a reasonable idea to me. Now that I've got a local copy of the database, I can play around with that idea. When we click on a coastal protection feature, would we also want to show the feature sidebar for the protected features? https://nismod.github.io/irv-jamaica/?path=/story/details-featuresidebar--default At the moment, that only works for a single feature ID. I guess we could show a list of protected features, each of which has its own report with risks and adaptation costs.

[thomas-fred]

Sounds good.

As for the view when clicking on a coastal protection feature, I think we'll want a sidebar to open showing the attributes of the protector feature (probably including some sort of aggregated risk reduction across protected features). As there could potentially be many protected features, I wouldn't try and list all their details in this sidebar. Rather, provide links to each protected feature. It would be nice if you could hover over the link to highlight it on the map. Click the link to close the protector feature sidebar and open the protected feature sidebar (and then be able to see the details).

What do you think?

[eatyourgreens]

As for the view when clicking on a coastal protection feature, I think we'll want a sidebar to open showing the attributes of the protector feature (probably including some sort of aggregated risk reduction across protected features). As there could potentially be many protected features, I wouldn't try and list all their details in this sidebar. Rather, provide links to each protected feature. It would be nice if you could hover over the link to highlight it on the map. Click the link to close the protector feature sidebar and open the protected feature sidebar (and then be able to see the details).

That sounds good to me. Assuming that the API for these features is the same as for existing features (mocks here: https://github.com/nismod/irv-jamaica/tree/main/frontend/src/mocks/details/features) then the sidebar should be straightforward. Linking related features by ID, in the sidebar, shouldn't be a problem either.

I should also update the page URL to include the feature ID, when you select a feature. That seems like it would be useful in general, so that you can share a link that opens the sidebar for a specific feature.

[tomalrussell]

This is all sounding promising :) two notes:

• this functionality will be needed in irv-frontend (the initial use case there is to show mangroves, vegetation on slopes, and catchment afforestation Nature-based Solutions aka NbS) - tagging in @mz8i and @shiarella for info
• it would be nice-to-have an outline of the area of effect, as well as the protection feature itself. In the simple modelling approach we're using for the global analysis, this is in most cases a simple buffer around the planting area. In Jamaica, this may be an area up to some distance/elevation inland of a linear feature.

[eatyourgreens]

I should also update the page URL to include the feature ID, when you select a feature. That seems like it would be useful in general, so that you can share a link that opens the sidebar for a specific feature.

Selected infrastructure assets in the URL is now a feature, as of these two PRs:

• 149.

• 151.

There's a query param that stores the view layer ID and feature ID for a single infrastructure asset, eg. selectedassets=elec_nodes_substation.1100010048.

Example here, for a railway station: https://jamaica.infrastructureresilience.org/exposure?lat=17.99144&lon=-76.91981&zoom=10.74&assets=true&hazards=true&buildings=false&buildingsStyle=type&regions=false&regionsStyle=boundaries&hazardsStyle=&terrestrialStyle=landuse&marineStyle=habitat&netTree=0b.0c.0d.0e.0f.10.11.12.13.14.15.16.17.18.19.1a&fluvial=false&surface=false&coastal=false&cyclone=false&selectedassets=rail_stations.43

[thomas-fred]

Hi @eatyourgreens. I don't know if this is at all useful, but I just made these two responses for api/features/<id>.json: 1000053333.json and 1000053334.json. The first one is a road segment with some adaptation options. The adaptation options now have that extra field, protector_feature_id. If it's null its a conventional adaptation (implemented on that feature itself). If it's non-null, it's the ID of the coastal protection feature. The second file is the referenced coastal protection feature. Let me know if you need anything else to start building that discussed above.

[tomalrussell]

See also draft work https://github.com/nismod/infra-risk-vis/pull/187 towards https://github.com/nismod/infra-risk-vis/issues/188 - the requirements there are about filtering features by region, and including additional cost/benefit columns; part of the proposed solution is a more flexible JSONB column in the adaptation_cost_benefit table.

[eatyourgreens]

@thomas-fred Thanks Fred, I'll take a look. I currently have a very simple API stubbed out, so that selecting a feature on the map fires off a request for features protected by that ID:

[thomas-fred]

Aha, yeah a /api/featuresprotected-by/ endpoint sounds good.

[tomalrussell]

With an extra / - GET /api/features/protected-by/{feature_id} would be more consistent with sorted-by

https://github.com/nismod/irv-jamaica/blob/448eb64ea91bf022ba3b7b5beb8ae6a801f3df89/backend/backend/app/routers/features.py#L49-L52

[mz8i]

Or GET /api/features/{feature_id}/protected-features would probably be most REST-like - but it's probably a bit arbitrary in this case, so the other options like GET /api/features/protected-by/{feature_id} also sound good!

[thomas-fred]

I think @mz8i suggestion makes most sense to me, /api/features/{feature_id}/protected-features