nasa-gibs / worldview Goto Github PK

WV-1814

User request: Hi, I'm trying to use the satellite images in NASA Worldview to look at cloud cover over particular places. I know the lat/lon of these places, but I'd like to be able to put a marker where they are, so it can be seen if there's cloud cover over these places at exact times. I was just wondering if there was a way of doing this, because once the image is downloaded, I don't know exactly where my locations are. Thanks.

On iPad, if

• image download mode is invoked
• then it's closed
• then you rotate the screen a few times

the usable map area becomes greatly reduced. See attached screen capture - the bottom part of the map is missing.

Use running-data styling on palette hover

Once the vagrant box is built, it says it is "Done, without errors" and that the "Worldview is now ready"
However, errors were displayed for the building of the "config" files "wv-options-validate: ERROR".

If I go to the browser, worldview loads but includes errors on the page and fails to load the components.

Error: An unexpected error occurred. Please reload the page and try again. If you continue to have problems, contact us at "MAIL"

Investigate how to align imagery at the anti-meridian/dateline so that one day is adjacent to the next day

See attached screen capture

Add worldview stamp & adjust the date font and format

Reduce tour steps and dialogue so that the user can get going faster and add 'callouts' to assist the user while they are browsing on their own.

When running vagrant up I got an issue when it was trying to run the following from vm.bootstrap:

if ! rpm -q epel-release; then
    yum install -y http://mirrors.kernel.org/fedora-epel/7/x86_64/e/epel-release-7-5.noarch.rpm
fi

==> default: Cannot open: http://mirrors.kernel.org/fedora-epel/7/x86_64/e/epel-release-7-5.noarch.rpm. Skipping.
==> default: Error: Nothing to do
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

In the "About" window, there is a link to the other open source projects used by Worldview:

• Worldview is built by the NASA/GSFC Earth Science Data and Information System (ESDIS) Project and is grateful for the use of many open source projects.

If on a desktop-sized browser, it links here (and works):
https://worldview.earthdata.nasa.gov/pages/worldview-opensourcelibs.html

If on a mobile-sized browser, it links here (and breaks):
https://worldview.earthdata.nasa.gov/brand/pages/pages/worldview-opensourcelibs.html

This can be reproduced in the desktop if you make the browser small enough to switch into "mobile mode".

It appears to work if the buster package version is reverted to 0.7.12.

In the events tab, change the color of the icon on the left for different events – say blue for hurricanes/cyclones and other water events, and yellow for volcanoes.

Or, have different icons that represent different types of natural events.

openlayers/openlayers#6082
Waiting on this merge:
should fix running-data when rotated
Should optimize rendering of layers for data retrieval

Per user requests, add an ability to reset Worldview to its default state without having to manually revert the URL to https://worldview.earthdata.nasa.gov/

GC docs can be found here: https://wiki.earthdata.nasa.gov/display/GIBS/GIBS+API+for+Developers#GIBSAPIforDevelopers-ServiceEndpointsandGetCapabilities

The worldview-options-template doesn't contain files under a common/ directory, so grunt fails with:

Running "exec:config" (exec) task
>> cp: bin/../options/common/*: No such file or directory
>> Exited with code: 1.
Warning: Task "exec:config" failed. Use --force to continue.

Using --force produces a non-functional site.

Worldview uses PhantomJS for executing various unit tests. The tests havent been updated since the "overlays" were moved to be above "base layers" in the list here

I tried to update this line to
return overlays.concat(baselayers)

In order to have the correct sequence of layers returned from models.layers.get() and display the order of stacked data in the timeline properly, but PhantomJS returns many errors with
$ grunt test

For example, it would be preferable if the list on the left is sorted in the same manner as the /worldview-options-eosdis/common/config/wv.json/measurements/Aerosol Optical Depth.json file. Which is currently in this order "Aura/OMI, Aqua/MODIS, Terra/MODIS, Aqua and Terra/MODIS, Terra/MISR, SeaWiFS Deep Blue"

Worldview currently provides detailed, "human readable" layer descriptions to help users understand how each layer can be used, their limitations, and why they are important. Here's an example:

https://github.com/nasa-gibs/worldview-options-eosdis/blob/master/common/config/metadata/amsr2/CloudLiquidWater.md

At present, these descriptions are only available when using the layer selection widget (i.e., the "+ Add Layers" button). But it would be very helpful if they were more easily available after layers were added to the active layer list.

So this ticket is to add the capability to view these layer descriptions "on demand", likely invoked from the active layer list.

I just updated from Chrome 53.0.2785.143 to 54.0.2840.71 and am not getting the following error when I load our UAT WV instance:
Uncaught RangeError: Maximum call stack size exceeded(…)
Ryan was seeing this previously and apparently I was just behind in my Chrome versions.
This is impacting us, but will also impact any of our providers that use UAT.

If you

• drag the map and don't let go of the mouse button
• move the mouse over the timeline
• and then release the mouse button

the date changes to where you released the mouse. While this could be considered a feature ("move the map and change time with a single click!"), it's probably an undesired behavior and shouldn't change the date.

WV currently assumes that the start/end/default values for the time dimension in a layer are YYYY-MM-DD. However, as we start adding granule layers, it will need to be able to handle YYYY-MM-DDThh:mm:ssZ values. Even if it isn't serving these layers, the WV config scripts will need to not barf on those values.
I saw this in our epic.gibs branch. It may be fixed in master, but until it is fixed, we would not be able to release AST_L1T in production without breaking your builds.

BusterJS is no longer being maintained and already causes weird errors at times when working with newer versions of node.

The plan is to start writing new tests in another framework (likely Mocha but open for suggestions) and keeping buster to run the old tests while we are in the process migrating.

WV-1813
We have a case with the MODIS_Cloud_Phase_Infrared.xml colormaps where there is a non-transparent color in the colormap that should not be in the Legend. Because ref is required, the ColorMapEntry has a ref, but there is no LegendEntry with the same id value. That's technically allowed, but WV is failing with an error:
[colormap] argument of type 'NoneType' is not iterable
I think WV needs to handle the case where there is a ref with no id

Thanks for the feedback @mstuenkel

Comment by @ZachTRice:
Here is a list of potential events to be story-boarded. Adding a check beside the event means the event has been completely story-boarded out. This list will need to be narrowed down to a 9 events initially.

Event Types

• Default (No Event Type)
• Wildfire
• Volcano
• Snow
• Sea and Lake Ice
• Iceberg
• Water Color
• Dust and Haze
• Severe Storm
• Man Made

Top 9 Latest Events

1. Hurricane Florence - 2018
   Type: Hurricane
   Reason for showcasing (optional):
   Features to highlight:
2. California Wildfires & British Columbia Wildfires - 2018
   Type: Wildfire
   Reason for showcasing (optional):
   Features to highlight:
3. Snow in South Africa - August 2018
   Type: Snow
   Reason for showcasing (optional):
   Features to highlight:
4. Saharan Dust Storms - 2018
   Type: Dust and Haze
   Reason for showcasing (optional):
   Features to highlight:
5. Sinabung Volcano - February 2018
   Type: Volcano
   Reason for showcasing (optional):
   Features to highlight:
6. Hurricane Maria - September 2017
   Type: Hurricane
   Reason for showcasing (optional):
   Features to highlight:
7. Larsen C Ice Shelf / Iceberg A68A - July 2017
   Type: Iceberg
   Reason for showcasing (optional):
   Features to highlight:

and 2 more events of different event types

Other Potential Events:

10. Shrinking Aral Sea - 2001-2018
    Type: Man Made (?)
    Reason for showcasing:
    Features to highlight:
11. Eyjafjallajökull Volcano Eruption - 2010
    Type: Volcano
    Reason for showcasing:
    Features to highlight:

This is a very nit-picky thing to point out, but the correct labeling when using the Kelvin scale is to leave out the degree symbol. For layers like "Brightness Temperature," the labels include values such as, "224.9 °K" whereas the correct way to write that value is in the form, "224.9 K" (without the degree symbol). Reference to the "Kelvin" Wikipedia page to verify this https://en.wikipedia.org/wiki/Kelvin.

WV-1596

A relatively obscure bug:

• load a product with daily-only data download (e.g., AMSR2 snow-water equivalent, http://go.nasa.gov/2c6Mtpf)
• go to data download tab
• add a day to the cart
• click "download data"
• go straight back to active layers tab without closing data download window
• click layer settings button - data download window appears in background

"As we start to introduce more logarithmic colormaps, it will become more common that the legend images in Worldview may mislead someone into thinking a color ramp is linear (arguably the default interpretation) when in fact it is not.

I think the initial simple solution to this is to honor the "tickMark" attributes in the GIBS colormap legends. WV wouldn't need to label the tick marks, but presumably one would see tick marks that are not evenly spaced, giving a visual indication that the color ramp is not linear."

One possible enhancement is to add an export to KML option to worldview.

This would assist users who'd like to use the graphical layer add ui to select a bunch of layers and take those layers over to Google Earth and work with the layers in that application.

"The use of Google Earth (GE) to demonstrate geologic principles is becoming more popular in introductory geology courses." [1]

GIBS has a kml export endpoint at:

http://map1.vis.earthdata.nasa.gov/twms-geo/kmlgen.cgi?layers=<layername>&time=<time>

If this seems like an acceptable idea I might be able to help implement a PR for this.

[1] Greene, T.J ., and Shapiro, R.S . 2008. Student-based learning using Google Earth in sedimentology and stratigraphy courses. In Geological Society of America Rocky Mountain and Cordilleran Sectional Meeting, Las Vegas, (abstracts with programs), vol. 40, p. 90 .

Matthew Cechini relayed some possible problems that the running data feature may have when dealing with certain colormaps. In particular, there are a few which have the same color mapped to two different data values. There may be some "best guesses" which can help to decide which value to use, though we may also just want to ignore these cases.

GIBS-1640 and WV-1658

On the GIBS "Available Imagery" page:
https://wiki.earthdata.nasa.gov/display/GIBS/GIBS+Available+Imagery+Products
a number of the example URLs give the "An unexpected error has occurred" message, for example OMI Aerosol Index:
http://go.nasa.gov/1eesTgR

I am working on setting up with your instructions. Full disclosure: I am new to vagrant and virtual box.

I have installed vagrant and virtualbox and cloned your repos successfully. When I get to the step with the vagrant up command I receive the following message:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'matyunin/centos7' could not be found. Attempting to find and install...
default: Box Provider: virtualbox
default: Box Version: >= 0
The box 'matyunin/centos7' could not be found or
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Atlas, please verify you're logged in via
vagrant login. Also, please double-check the name. The expanded
URL and error message are shown below:

URL: ["https://atlas.hashicorp.com/matyunin/centos7"]
Error:

I can find the virtual box listed in the box catalog at: https://atlas.hashicorp.com/matyunin/boxes/centos7

I am running on OSX Yosemite, Vagrant 1.8.7, Virtual Box 5.1.