Figure out how we tie content to location

[colinmurphy01]

We have a method for getting location from the URL (as both lat/long and as WFO grid, with lat/long just redirecting to the WFO grid location). Once we have that, we can use it to fetch from the API. However, what we're still missing is tying together the location from CMS content with the location for the API. Is this URL-based approach a good general solution, or do we need to do something else?

[greg-does-weather]

For MVP, CMS-based locations are polygons of an entire WFO, so for now we actually don't need to consider location at all, just WFO. But we do eventually want to support content that is related to geographies distinct from WFO polygons (e.g., separate weather stories for the northern and southern halves of a WFO).

I think the URL-based approach and the controllers can work by querying for nodes/content and stuffing what we get back into blocks, but then we lose the node-ness of the content which we maybe don't want to do. So that's kind of the thing I think we need to figure out.

[greg-does-weather]

Eric and I discussed, and I think the URL-based approach is going to work. We're going to need to spend some time experimenting to be sure, though.

Outlining my current experimentation thoughts:

• attach WFO information to a weather story
  • Claire already did this. She created a weather story content type and added a WFO field with a list of possible values. We can run with this!
  • Another option might be to create a taxonomy with WFOs, but that might be overkill unless we have other content types that also need to be associated with WFOs. (cc: @kmranjo)
• update the local page controller to query for the most recently-published weather story that matches the location and push it into the render array
• see what happens, because tbh I have no idea what will happen after that

It might be that having the weather story node in the render array is all we need to do, and then we have to wire up the templates accordingly and we're done. I doubt it's that straightforward but we'll see!

[colinmurphy01]

lol

see what happens, because tbh I have no idea what will happen after that

One use case to consider is within hazards. Hazards might be tied to a WFO but they might also be tied to a polygon within the WFO. So in this case would it be:

update the local page controller to query for any active hazard alerts that matches the location (either that's WFO-based or geographical point based) and push it into the render array?

[greg-does-weather]

Yeah, I think that's correct. For MVP, my understanding is we're tying things to WFOs rather than polygons, but that might just be for weather stories. Getting polygons into Drupal is something we haven't explored yet, but whether for MVP or afterwards, we're going to have to.

[kmranjo]

Yeah I think it's a safe bet that there would be other use cases to serve content associated with specific WFOs. Weather stories to start, but potentially other info including the WFO info itself, area-relevant resources, etc. Hazards are a question because they do get created already associated with a WFO but I'm not clear on which field in the output of the API is the association with WFO. Can't tell if it's actually the 3-letter code we are used to or some other method.

[greg-does-weather]

Updating based on some experimentation this afternoon.

Simply dumping the node into the render array does result in the weather story being rendered on the page. There's probably a way to work with this using views, but I don't know how to do that so I'll need to spend some more time playing with that to get a better understanding.

Another option, which I do understand and was able to get working in a dev branch, is to create a weather story block, populate it with the node, and then render it in a new block template. This fits with how we're doing other things, so that's nice but I don't think it's actually as flexible as using views would be. Anyway, the block approach turned out to be pretty straightforward.

[greg-does-weather]

Alright, here's my proposal:

Managing location

To begin with, we will rely on the URL to tell us a user's location for the purpose of determining which information to render. How the URL is populated is separate and distinct from everything else in this proposal.

To start with, we divide information into three broad categories:

1. API data
2. Content-managed data associated with a WFO
3. Content-managed data associated with a geometry (point/polygon)

API data

API data is always managed by modules. The WeatherDataService currently handles all of our API interactions. It reads location data (WFO, grid X, and grid Y; also currently the location name, but we need to nix that eventually) from a Drupal RouteMatchInterface

We'll create module blocks for each kind of API data we need, or collections of API data, as appropriate. We'll use static caches on API calls so we don't hit the same API endpoint multiple times on a single page response.

We'll register the blocks programmatically and use the Drupal UI to place the blocks where we want them to go on the page. We'll use custom Twig templates to render these blocks.

Some API data may be presented to us as geometries. In these cases, we will use the WFO grid cell geometry to represent the user's location, and we can do a fairly simple geometry intersection test to find which pieces of API data are relevant. (We'll do this geometry intersection to account for the case where, for example, a hazard cuts through and only covers part of a grid cell; since we don't know where in the cell our user is, we should show them everything that intersects the cell at all.) Otherwise, the rules for API data will be the same in both cases.

Content-managed WFO data

We will use Drupal views to filter according to the WFO in the URL. These views can result in pages or blocks, and we'll choose depending on our needs.

Content-managed geometry data

[!NOTE] This will be the trickiest, but only because we don't know how to get geometries into the CMS yet.

We will create module blocks that query the CMS for content that intersects the user's WFO grid cell. Exactly how we do this will require some experimentation (hopefully we can do MySQL geospatial queries 🤞), but the important thing for this proposal is that we'll have to write custom PHP to handle this case. #430 shows a basic outline of this approach.

[colinmurphy01]

This seems good to me.

This is looking into the future a bit, but how do you think we'll handle state use cases?

We have yet to design this out but an example might be:

• User is on a state-oriented location page, Tennessee (I believe Tennessee is covered by 4 WFOs)
• User wants to see all hazards within state, user wants to see all weather stories within state

A perfectly fine answer is, I don't know yet.

[greg-does-weather]

I think @kmranjo would have good thoughts here, too. My first guess is we'd create Drupal tags or taxonomies or whatever to relate a state (or other large location – a metro area maybe?) to a set of WFOs.

If we wanted to go further and use the state as a polygon, so we only get a weather story if it applies to that state (e.g., if Memphis has one weather story for north Mississippi and another for western Tennessee, people in Mississippi only see the one of those), we don't have a solution for that yet.

---

This state page thing makes me think the ideal workflow would allow WFOs to create regions they want to have pages for, and maybe they use a map to draw out or select the polygon for that region. Then they can create them arbitrarily for whenever they want/need them, which might be really helpful in an emergency situation?