nsidc / qgreenland

Source code for generating the QGreenland package hosted at https://qgreenland.org/
https://qgreenland.readthedocs.io
Other
36 stars 9 forks source link

Online-only NRT weather data #637

Open trey-stafford opened 1 year ago

trey-stafford commented 1 year ago

Migrated from Jira(https://nsidc.org/jira/browse/QGR-35):

See 11/1/20 email from Joe MacGregor

trey-stafford commented 1 year ago

Joe's email notes the potential benefit of having a variety of weather-related layers to assist with flight planning. E.g., OIB sometimes used maps from a variety of sources to make flight-planning decisions but ideally they would be able to see all of the relevant data in a single map interface.

Joe suggested 6-hour or daily updated conditions/forecasts and suitable symbology for the following variables:

Even a few such layers might be useful from a planning perspective.

trey-stafford commented 1 year ago

Related issue: https://github.com/nsidc/qgreenland/issues/565

GIBS provides WMS layers for precipitation, land surface temperature, sea surface temperature, etc. I'm not sure if they provide WCS, but maybe that's not necessary for e.g., flight/fieldwork planning.

MattF-NSIDC commented 1 year ago

We may want to add temporal controller documentation if/when we add these layers.

Let's try and get this in v3alpha4!

trey-stafford commented 1 year ago

GIBS' WMS service providing data in our project's CRS ("EPSG:3413") contains a few layers related to weather conditions: https://gibs.earthdata.nasa.gov/wms/epsg3413/best/wms.cgi?VERSION=1.3.0

None of these appear to be "near real time" though. For example, the "Cloud Fraction (Day, Best Available, MODIS, Aqua)" layer has data from 2002-07-03 through 2023-07-10 (today's the 21st).

Many of these layers also have multiple options (e.g., there are 4 layers available for "Cloud Fraction" for Day/Night and Terra/Aqua).

One cool looking layer that's unrelated to weather: "Fires and Thermal Anomalies" (there are multpile options for this layer too, but the "MODIS_Combined_Thermal_Anomalies_All" might be a good candidate - it's a combination of Day+Night observations from MODIS Aqua + Terra.

trey-stafford commented 1 year ago

The full GIBS product catalogue is here: https://nasa-gibs.github.io/gibs-api-docs/available-visualizations/#visualization-product-catalog

Some of the EPSG:4326 layers might be useful (e.g., "Precipitation (Day, AIRS, Aqua)" and "Precipitation (Night, AIRS, Aqua)"). The drawback to using these layers, of course, is that QGIS has to do on-the-fly reprojection

trey-stafford commented 1 year ago

The Canadian MSC GeoMet platform provides wms services for various weather layers, but they do not seem to work with our project CRS.

MattF-NSIDC commented 1 year ago

do not seem to work with our project CRS.

Do you have a symptom / error message we can record in case we run in to the same thing later?

trey-stafford commented 1 year ago

Primarily extremely slow loading times (or not loading at all). Some layers require the user to select one of several options for transformation between source CRS and project CRS.

I can sometimes get layers to show up for portions of the project background extent. In any case, not very user friendly. I think that's the key thing here - when adding wms layers - ensuring that those layers are responsive and cover our primary areas of interest.

trey-stafford commented 1 year ago

One major issue I see with timeseries layers in QGIS that I only just noticed: the temporal extent of layers is hard-coded!

The "source" URI used to describe the wms layer for saving in the project file looks like this:

allowTemporalUpdates=true&contextualWMSLegend=0&crs=EPSG:3413&dpiMode=7&featureCount=10&format=image/png&layers=MODIS_Terra_CorrectedReflectance_TrueColor&styles&temporalSource=provider&timeDimensionExtent=2000-02-24/2023-08-02/P1D&type=wmst&url=https://gibs.earthdata.nasa.gov/wms/epsg3413/best/wms.cgi?VERSION%3D1.3.0

The timeDimensionExtent=2000-02-24/2023-08-02/P1D is the problem here. QGIS gets this value from the initial getCapabilities request it makes. E.g. from https://gibs.earthdata.nasa.gov/wms/epsg3413/best/wms.cgi?VERSION=1.3.0&SERVICE=WMS&REQUEST=GetCapabilities:

      <Layer queryable="0" opaque="0" cascaded="0">
        <Name>MODIS_Terra_CorrectedReflectance_TrueColor</Name>
        <Title>Corrected Reflectance (True Color, MODIS, Terra)</Title>
        <CRS>EPSG:3413</CRS>
        <EX_GeographicBoundingBox>
            <westBoundLongitude>-180</westBoundLongitude>
            <eastBoundLongitude>180</eastBoundLongitude>
            <southBoundLatitude>38.8072</southBoundLatitude>
            <northBoundLatitude>90</northBoundLatitude>
        </EX_GeographicBoundingBox>
        <BoundingBox CRS="EPSG:3413" minx="-4.1943e+06" miny="-4.1943e+06" maxx="4.1943e+06" maxy="4.1943e+06"/>
        <Dimension name="time" units="ISO8601" default="2023-08-03" nearestValue="0">2000-02-24/2023-08-03/P1D</Dimension>
        <MetadataURL type="TC211">
          <Format>text/xml</Format>
          <OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="https://gibs.earthdata.nasa.gov/wms/epsg3413/best/wms.cgi?request=GetMetadata&amp;layer=MODIS_Terra_CorrectedReflectance_TrueColor"/>
        </MetadataURL>
      </Layer>

At project load time, QGIS makes getCapabilities requests for all of the WMS layers, so it should be possible to update the end date of the temporal extent each time the project file is opened, but that does not happen.

Instead, QGIS uses the hard-coded temporal extent set in the URI to determine the Animation range of the Temporal Controller. This is problematic because users would need to know that the detected animation range is outdated.

I tried to remove the TimeDimensionExtent=2000-02-24/2023-08-02/P1D from the layer source URI but this just results in NULL values being set, and the temporal controller doesn't detect any time range for the layer. This seems counter to the configured temporal options in the Layer Properties. I have the "Dynamic Temporal Control" set to "Automatic". I would expect QGIS to...dynamically request and set the temporal extent!

Image

Note there was a recent issue that fixed QGIS crashing when the TimeDimensionExtent is unset.

MattF-NSIDC commented 1 year ago

This sounds like it's worthy of a bug report!

trey-stafford commented 1 year ago

Created an issue here: https://github.com/qgis/QGIS/issues/54043

trey-stafford commented 1 year ago

Draft PR that's on hold until the above issue can be resolved: https://github.com/nsidc/qgreenland/pull/707

This PR just adds a couple of true color MODIS timeseries layers from GIBS. This does not exactly provide NRT weather data, but it does provide a nice reference satellite layer that's up-to-date through the previous day.

MattF-NSIDC commented 1 year ago

Unless we find another dataset (maybe on another protocol? We only know for sure that WMST is impacted) that avoids this limitation, this isn't going in v3.