Make changes to spatial bounds for campaigns and deployments

[heidimok]

Context

CASEI was built with the assumption that spatial bounds would exist for every campaign. In the case of the AASE campaign, that assumption changed because we couldn’t find information about spatial bounds. This resulted in a build failure.

Discussed Options

• Make the coordinates required. Do not allow form to be saved without the coordinates field filled in.
• Have a default placeholder for when we don't know where a campaign took place. For example coordinates 0,0,0,0 or the entire world (-90, 90, -180, 180? Need to figure out what it is)
• Render alternate views in the frontend (and fix all the places where we assume that the coordinates are required). Change our assumption such that spatial bounds are not required such that we need to render alternative view for pages that don't have spatial bounds. We would have to guard against this case in all the place in the code base that currently assume that every campaign has bounds. Potential trickle effects: Make sure that this is our new assumption going forward and consider how it impacts other areas of the software. For example, a future filter on spatial bounds or a search function would assume that not every campaign has spatial bounds.

Decision

1. Add requirement to the spatial bounds in the MI so that curators must input spatial bounds for campaigns and deployments
2. If the spatial bounds are not identified, set default coordinates to include the whole world
3. Whenever a deployment is added or changed, automatically update the spatial bounds of the campaign to include the new spatial bounds so that a curator doesn’t have to update it manually.

Updated Decisions (updated Mar 7, 2023)

• [x] If the spatial bounds for a campaign, or deployment within a campaign, are not found, set default coordinates to whole world. (COMPLETED in Spatial bounds issue #441)
• [x] Remove spatial bounds from campaign (Campaigns currently have optional spatial_bounds attributes. We should remove this field and only care about the spatial bounds of the deployments)

[smwingo]

only addition/really clarification i have: under "Decision" #3 - Whenever a deployment is added or changed, automatically updated the spatial bounds for the campaign:

if campaign bounds not originally entered, and campaign form is saved with default/whole world bounds, when curator adds a deployment (or multiple deployments) and the specific bounds for that deployment(s - which the spatial bounds need to required separately for each deployment) the campaign spatial bounds need to automatically update to be the inclusive set of all deployment spatial bounds.

A more ideal scenario would be for the campaign bounds to be the set of the separate deployment domains, but i'm not sure how this would be in implementation since most campaigns will have a single deployment but some have lots of deployments -- perhaps need to have discussion also on:

• one domain box for one deployment, one deployment in one campaign = single domain box at each level
• one domain box for one deployment, many deployments in one campaign = [which option is best/implementable? ]
  • single domain box per deployment at deployment level, many domain boxes at campaign level - OR -
  • single domain box per deployment at deployment level, single domain box at campaign level

[heidimok]

Sharing the result below:

Changes:

• If a campaign doesn't have spatial bounds the map will show the whole world (without outline)
• In the description text it'll say "We have not yet determined the spatial bounds for this Campaign."

[heidimok]

Will put task 2 for this as a Sprint 3 goal.

[CarsonDavis]

@smwingo @edkeeble @alukach @naomatheus

Previous Discussions

So, reading over what has been discussed so far:

• CASIE expects spatial_bounds for every campaign
• begin requiring spatial_bounds for campaigns and deployments
• if not given, default to whole world?
• calculate campaign level spatial_bounds based on deployment?
• complicated aggregate polygon for campaign is ideal, as opposed to simple square

Current Situation

So, overview from the current situation on the database:

• campaign has an optional spatial_bounds that defaults to null
• deployment has an optional spatial_bounds that defaults to null

Potential Update

So, one possible option is to:

• remove spatial_bounds entirely from campaign
• leave spatial_bounds on deployment. Make it required. Default to whole world?

Challenges

This solves all the front end issues, but has some curator and migration challenges.

Future Curation

• will curators be able to enter spatial_bounds for all deployments?
• if whole world is the acceptable backup, do we really want a database full of misleading whole world values for every campaign?

  Migrating

  When we remove spatial_bounds from campaign, what will we do with the value

• try to move it to the deployments?
  • this feels very inaccurate
• delete the value and lose it?
  • we might need to give curators time to enter values for deployments before migrating?
  • I guess if we want to brute force the migration we can just delete all campaign values, and change all missing deployment values to the whole world?

[alukach]

Thanks @CarsonDavis . We discussed this during our Feb 9 meeting (you may have been away).

My memory of the take-aways was:

1. Deployments currently have optional spatial_bounds attributes. This is good. Sometimes curators don't have spatial bounds for a deployment and we don't want to block them.
2. Campaigns currently have optional spatial_bounds attributes. We should remove this field and only care about the spatial bounds of the deployments.
3. Logic around aggregating deployment spatial bounds and handling deployments without spatial bounds should take place on the frontend. No need for the backend to enforce any logic (e.g. default to the whole world) as this is a false representation of what we know. When the frontend encounters a campaign with no related deployment spatial bounds, it will render a map with no polygons and display a message stating something along the lines of "we don't know the spatial bounds".

Regarding Carson's questions about migrating, I think we should discard the values from Campaign.spatial_bounds. I think those were always a human-generated aggregate of the deployment's spatial bounds (I could be wrong on this) so nothing of true value would be lost.

[heidimok]

Can we take a look to see this issue in the backlog https://github.com/NASA-IMPACT/admg-backend/issues/261 get closed as a result of the changes in this issue?