qgreenland
qgreenland copied to clipboard
nsidc
Online-only NRT weather data
Migrated from Jira(https://nsidc.org/jira/browse/QGR-35):
See 11/1/20 email from Joe MacGregor
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:
- "present cloudiness" data at various levels. E.g., https://weather.gc.ca/satellite/index_e.html#hrpt (this link doesn't appear to link to data, just animations of data)
- precipitation
- low-level clouds
- surface temperature
- others?
Even a few such layers might be useful from a planning perspective.
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.
We may want to add temporal controller documentation if/when we add these layers.
Let's try and get this in v3alpha4!
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.
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
The Canadian MSC GeoMet platform provides wms services for various weather layers, but they do not seem to work with our project CRS.
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?
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.
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&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!
Note there was a recent issue that fixed QGIS crashing when the TimeDimensionExtent is unset.
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.
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.