Innovation: Rate of spread - interactive web map (MVP)

**As a** *Forest Protection Technician* **I want** *to evaluate the potential rate of spread for an area* **So That** *I can assess the risk related to prescribed burns*

**Additional Context**
- Prototype available here: https://wps-mapserver-prototype.apps.silver.devops.gov.bc.ca/rate-of-spread
- This story has been created in order to enumerate all the outstanding features required to grow the rate of spread experiment into a product of it's own, so that it can be estimated and prioritised accordingly.
- This story has to be split into technical tasks, and user stories.
- This story has to be split into a number of separate stories/tasks.
- This story is for MVP only (there are many cool things that can be added! limit this story to MVP only)
- IDEA: It would be very cool to take the CFFDRS r-code to javascript translation and create an entirely seperate npm repository for it. I suspect this is something that many other people could use. This may also be a way to solve the web worker function reference issue!

**Acceptance Criteria**
- [ ] TBD: Eric, please add outstanding functionality below:
- [ ] Given (Context), When (action carried out), Then (expected outcome)
- [ ] Given (Context), When (action carried out), Then (expected outcome)
- [ ] TBD: Toggle between ROS and HFI
- [ ] TBD: Access control (idir only for both interface and map tilesets)
- [ ] TBD: Must be able to serve N simultaneous users (needed to
- [ ] TBD: As a user, I want the map to load in under N seconds.
- [ ] Resolve web worker function reference problem on built code (right now all code is inline!)
- [ ] Speed improvement: caching (put an nginx proxy in front of mapserver)
- [ ] Speed improvement: different source data for different scales.
- [ ] Re-factor code (code was hastily written, needs cleanup, comments and must pass linting)
- [ ] Implemented all FTL types (R-code : javascript translation).
- [ ] Map all FTL types in 2018_FTL raster to appropriate fuel types.
- [ ] Write unit tests to validate all r-code -> javascript translations.

Start with the linked rate-of-spread prototype and inventory the MVP gaps listed in this issue. The scope must first be split into technical tasks and user stories, with concrete acceptance criteria for the ROS/HFI toggle, access control, performance, web workers, FTL translation, fuel mapping, refactoring, and tests. Done means the MVP scope is defined and each resulting task has a verifiable outcome.

Written by the indexing model from the issue text.