Meeting with EIS Fire 2023.03.29

[danielfdsilva]

Saadiq facilitated a meeting with a EIS Fire scientist to get some initial impressions/feedbach on #496.

Overall the feature was well received with the following comments:

"homepage" for information:
It would be good to have a place where to information about the work EIS Fire is doing with the fire dataset. The current dataset overview page works for this, but when we split the different dataset layers (#493) there may be a lot of repeated content. A comment was also made about cross-linking to other data products and notebooks (reinforces the idea that a better notebook connection is needed (#450).

conditional data visualization:
Currently the data is being filtered by time step (like all other datasets). For vector sources it would be good to allow additional filtering by other properties (in the fire case: fires over x area.). Data driven styling where a color scale is applies based on a property would also be very useful.

accessing underlying data:
A way to download the data being viewed could be useful, but linking to documentation where it is explained how to do it would also suffice.

compound datasets: The fire line dataset makes the most sense when viewed together with the fire perimeter, as the fire line is the part that is currently burning.

The orange here is the fireline and the blue the perimeter.

In this case the dataset is made of these vector 2 layers. Having a way to have an additional raster layer with the fire satellite view could also be useful.

tooltip with information:
The features of a vector dataset have properties baked in that should be surfaced to the user. To avoid having machine names like the image below, scientists could provide a mapping dictionary - it would be a matter of setting up the proper config structure.

seeing more data at low zoom levels:
The current approach with markers doesn't allow the user to understand where big fires are. Adjusting he zoom threshold could help with this, but other options could be considered.

@smohiudd is there anything I did not capture?

[smohiudd]

Thanks @danielfdsilva, this is a great summary of the discussion.

One more point was about the option to download the vector data similar to the veda documentation (https://nasa-impact.github.io/veda-docs/example-notebooks/wfs.html). We're not sure how appropriate this is in the veda ui context but just something to note.

[mccabete]

Thanks for the summary @danielfdsilva! That covers everything I can think of.

[nerik]

Thanks for the summary.

conditional data visualization:

Did you discuss what kind of variables could be mapped? This could be useful in deciding on how we add fields to the dataset frontmatters, etc. Could you elaborate on in the fire case: fires over x area. ?

accessing underlying data:

We could implement a cheap version of this using queryRenderedFeatures/querySourceFeatures

seeing more data at low zoom levels:

Are "big fires" actually a lot of small polygons over an area? (in which case a server-side clustering solution could be appropriate). Or are they big polygons? In this case the ideal situation would be for the server to decide what kind of geometry (point or poly) to be rendered depending on the zoom level, with the frontend merely rendering the appropriate layer style.

[danielfdsilva]

1) The variables to be mapped would depend on what's available in the features and would differ by dataset. fires over x area means filtering to only show fires where the area prop is greater than a certain value. Ideally it would be possible to do some filtering with whatever is available.

2) We could check if it works. But there's also an api to use.

3) Bigger fires should be bigger polygons. Having the server decide between geometries would definitely be good

[mccabete]

Hey @danielfdsilva something just occurred to me. Right now, we can't do great job of evaluating how large fires will look with the zooming, because it's early in the fire season. Most/all of the fires on the map are small. I would anticipate the data changing as the fire season ramps up. We may want to revisit this issue when we are displaying fires with more variability.

[mccabete]

Hey @danielfdsilva,

I got some more feedback from EIS Fire:

• Someone else was also thrown off by the pins not becoming perimeters until you're zoomed in pretty deeply. Seems like it is worth changing the zoom level.
• Could the blue pins be something else? One person suggested flame icons.
  • Could we take the fireline (called "Fire" in the draft) down until we can display it with the fire perimeters? It makes less sense to look at them on their own. Plus, because of the way the datasets are set up right now, firelines all look like they have the most-recent timestamp, but their corresponding fire perimeter has a range of dates.
  • Can we call the datasets something more descriptive than "eis_fire_perimeter"?

[smohiudd]

@mccabete can you confirm the requirement to include the tool tip as Daniel describes above? The way the fields are currently shown by default presents a ux issue since they are not descriptive. Is there a subset of fields that makes sense to show to a non-technical audience?

[mccabete]

@smohiudd -- Is your question if it's a requirement, or if we can provide the content to translate it from a non-descriptive set of columns to a descriptive one?

Is it a requirement? As a first pass, it might not need a tool tip. Ideally, we'd have a minimum of meanfrp, t, and duration. FireID will eventually become useful, but is not there yet.

@danielfdsilva When you say "To avoid having machine names like the image below, scientists could provide a mapping dictionary - it would be a matter of setting up the proper config structure." -- are you saying that the config structure would be difficult to set up? We can (and already have) had to map these column names to more descriptive names, so it's super reasonable to ask us to provide the mapping dictionary.

[smohiudd]

@mccabete my question was more about if it's a requirement for the May 15 release.

[mccabete]

Thanks for clarifying @smohiudd! I would say it is not. Right now most of the information is not ready for public consumption. So this is "high priority" but maybe wont be ready fore May 15th.