doi-usgs / hurricane-irma Goto Github PK

I'm not sure how to fix this, but it should be a no brainer for @mbucknell

We pass _blank here: https://github.com/USGS-VIZLAB/hurricane-irma/blob/66048c98c9ac92940422545e136b493df651d886/layout/js/animate.js#L124

but don't use it in the vizlab clicklink function. Maybe this is an issue for vizlab?
https://github.com/USGS-VIZLAB/vizlab/blob/765b5b59ebd5f42b3f1b9b1bad90f3bc47069318/inst/js/vizlab.js#L53

if so, lots of text changes need to happen, including legend.

Are we showing them? do we support any interactions with them?

If we aren't doing mouseovers or onClick events on them, we can massively shrink their contribution to the DOM by converting them from 1,000's of elements, to a single

depending on what we do w/ them, if they don't have interactions we should also lower their z-index so they aren't getting in the way of other mouse events.

We are so close, but I think we need a few things to push this over the edge:

• a processor that figures out which times the sites exceeded flood stage, and add a class for them (like f-4 f-5 f-6 f-7) if a gage was at or over flood stage for timesteps 4, 5, 6, and 7. js would set these to a different color for those timesteps. At each timestep I assume jquery would select all "gages" and set them to the normal color/class, and then select the flood class for that timestep and set that differently. Would need to make sure we also handled hover events on gages during a timestep transition.
• add a second sparkline for "over flood" that is a different color and has no opacity until it is revealed. This would sit on top of the existing sparkline for the site.
• use css transitions and transforms to do two things for the storm location: 1: make it move smoothly between various locations (transitions) and 2) make it so there is only one actual dot that we move around, avoiding the dual dot bug that happens on some mobile devices when you scroll or try to pinch zoom during the animation

--- should we also do the following? ------

• use precip grid instead of the counties. Despite this being denser, I think it would actually improve the animation rendering and reduce the file size because the square/rect elements would be to much simpler than counties. Can draw all squares and use the states border as the clipPath
• use cumulative precip instead of hourly. It may be too boring w/o this (see #118 for this option)
• have the storm change color/name when it is no longer a hurricane

See Harvey for a more exaggerated version of this

https://www.sciencebase.gov/catalog/item/59b31b62e4b08b1644d7c51b

• map w/ correct style from css
• precip for one time stamp
• hurricane path?

This way we can replicate the geometries without paying extra cost to the DOM - so we can have invisible mouseover zones and emphasize borders on hover that would otherwise be covered by adjacent polygons. Another benefit of this for the sparklines is being able to pull the emphasized line to the top level, so none of the others are overlapping. This currently looks like:

I think our default view is great for mobile portrait, but not great for desktop. an easy fix is clipping the viewbox for desktop, and letting it scale.

So "0 0 500 700" becomes "0 0 500 450" on desktop...

also, adjusting the fonts when making this switch would be good.

Just as markers on the map, not as timeseries plots: STN viewer

and perhaps depend only on states that are within the footy

@mwernimont

Can you resize the thumbnails for the appropriate platform? I Slack messaged you the actual files.

Facebook

1560 width
820 height

Twitter

560 width
300 height

VIZLAB Landing page

400 width
400 height

Instagram

1080 width
1080 height

They should be sorted south to north (based on latitude of the site)

The master branch of this repository will soon be renamed from master to main, as part of a coordinated change across the USGS-R and USGS-VIZLAB organizations. This is part of a broader effort across the git community to use more inclusive language. For instance, git, GitHub, and GitLab have all changed or are in the process of changing their default branch name.

We will make this change early in the week of February 6, 2022. The purpose of this issue is to give notification of the change and provide information on how to make it go smoothly.

If you wish to make the change yourself rather than wait for us to do it, it can either be done manually or through some convenience functions in the usethis package.

• From your local version of the repository, change the remote branch name using either of the methods detailed below: usethis or the manual method.
• Verify that the local branches are changed as well (if using usethis) or change them yourselves (if using the manual method).
• If you have collaborators on this repository, let them know that they will need to change their forked/local repos either by running usethis::git_default_branch_rediscover() or by steps 2 and 3 of the manual method. Point them to this issue to facilitate the process!
• Search within your repository for "master" so that you can change references (e.g. URLs pointing to specific commit points of files) to point to "main" instead.
• When you are done, feel free to close this issue!

Using usethis

Note: usethis must be version 2.1.2 or higher

1. Navigate to your project's working directory.
2. Double-check that you have git credentials set up for HTTPS by running usethis::gh_token_help(). If you have not yet set up git credentials for HTTPS, you can do so by creating a GitHub PAT and using gitcreds::gitcreds_set() to register it with git. The PAT must have at least "repo" scope.
3. Rename default branches locally and on all remote repositories at once with usethis::git_default_branch_rename(). For more details see here.
   
4. Verify that the work was successful by running usethis::git_default_branch().

Manual Method

1. Go to <your repository> -> Settings -> Branches and edit the default branch from master to main.
2. All members should update their local settings so that new repositories created locally will have the correct default branch: git config --global init.defaultBranch main.
3. All members must update their local settings to match the change to this repository. They can either do this with usethis::git_default_branch_rediscover() (see above) or else run the following:

git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

We've got some sprawl in the specification of the storm area. Some places need a list of states, other places just take a simple polygon. There's also a view box for the whole viz.

We should have the view-limits function handle all this stuff with:
Option 1) two inputs, a bounding box and a storm area.
Option 2) Or we could just use the bounding box and not have a separate storm area.

This will involve one output from view-limits that is a spatial polygon in lat/lon projection for selection of counties or other spatial units and a named list like: list(FL = "florida") for use in selection of things by state.

This should fit into the existing viz cleanly and clean up a bit of sprawl we've generated.

See here: https://github.com/USGS-VIZLAB/hurricane-irma/blob/master/scripts/process/process.storm_sites.R#L34

Currently only filters on forecast time series. We should be filtering on forecast AND observed.

Also, I don't think this every go used and could probably be removed? https://github.com/USGS-VIZLAB/hurricane-irma/blob/master/scripts/process/process.storm_sites.R#L45

I think we SHOULD keep the period of record filter in. It's currently in use because so many sites went over flood.

The SVG generated for the gage dots should specify the click handler as "openNWIS('xxx', evt);"

Loop through multiple time stamps to create a gif. Would be nice

I don't know...

the gage ID doesn't mean much to people that aren't familiar w/ USGS already. The site names are included in the same metadata, but are ugly and all caps.

Twitter, reddit, facebook, instagram

Working on how to get the sparklines to have an overlay color that only shows when it is above flood stage. I think the best way to do this is to create <rect> clip-paths that are specific to the flooding indices:

<clipPath id="test-path">
	<rect width="50" height="100%" />
</clipPath>

which does this if the clip-path='url(#test-path)'

get error:

Error in needsTimestampOld(item.info) : fetchTimestamp.view_limits must be implemented for view-limits, probably in an R file in 'scripts:'

Thoughts?

Thanks!

even if we don't feature them

I think we need to capitalize the first letter of each word:

see process.storm_counties and county_map_name_2_mouser function for where the code lives to make the tooltip text

and convert to stage (from discharge)

The pop up is good but we need to link to NWIS to be live.

This was lost when I did the z-indexing

Not sure this is something we want to do, but we could work with coastal gages from NOAA.

https://tidesandcurrents.noaa.gov/waterlevels.html?id=8723214&edate=20170909

Service portal here: https://opendap.co-ops.nos.noaa.gov/ioos-dif-sos/

Requests look like this for tab data:
https://opendap.co-ops.nos.noaa.gov/ioos-dif-sos/SOS?service=SOS&request=GetObservation&version=1.0.0&observedProperty=water_surface_height_above_reference_datum&offering=urn:ioos🚉NOAA.NOS.CO-OPS:8454000&responseFormat=text/tab-separated-values&eventTime=2017-08-09T00:00:00Z/2017-09-09T23:59:00Z&dataType=PreliminarySixMinute&unit=Meters

I've got some code over here: https://github.com/dblodgett-usgs/hurricane-irma/blob/master/scripts/fetch/fetch.precip_spatial.R

It's ready to be worked into the viz.yml. I could hack at it but want open PRs to get closed out and someone else could probably do it much quicker than I! If no one else does before, I'll give it a shot though.

Have an embedded fig. Follow what jiwalker did for water-use

these ocean/gulf text boxes are good for the mobile view, but they hug FL too much in the desktop mode.