Our current station locations for PROMICE and GC-NET layers is from the map_GC-Net_PROMICE_kml GitHub repo, which used "2017-2018 average of station GPS data" for station locations.

New stations have been added. The PROMICE and GC-Net automated weather station data in Greenland dataset from GEUS includes a AWS_metadata.csv with location data for stations (published May 2023 w/ citation indicating 2022; the last station added in the AWS_metadata.csv is QAS_Lv3 on 2022-08-29)

Dataset URL

No response

More info

No response

Dataset URL

https://arcticobservingviewer.org/web-services

Rationale

From: QGR-39

Could provide these as an online layer or download data from WFS, cut to one of our boundaries, and include in Core.

PyQGIS seems to be translating some fontFamily= values from the style files to Helvetica, which is a non-free font. This would be fine if it would translate the fonts to an open font that can be downloaded by QGIS >= 3.28.

We could either throw an error for style files which contain any value other than a few allow-listed values, and/or we could provide a script that updates all ancillary/styles/*.qml files to use Open Sans with e.g. s/fontFamily="[A-Za-z ]+"/fontFamily="Open Sans"/g

Issue description

All 3 of the asset URLs for this dataset are not fetchable. Does the URL need updating, or is the data no longer available?

System information

N/A

Thanks for putting this package together!

I'm wondering if there is a way to retrieve individual data files without first downloading the entire QGreenland package. This would be very helpful for butting together a mybinder notebook as part of the NSF EarthCube notebooks call.

DockerHub? Or GHCR?

Dataset URL

https://www.ncei.noaa.gov/access/world-ocean-atlas-2023/

More info

From: QGR-175

Currently using 2018 data. Looks like 2023 data is available in same resolution and format.

NOTE: 2018 data contains significantly more variables than 2023 (temperature and salinity).

• Joe M. has a link to some data. It’s apparently really large but we could point users to it.

• Someone at GEUS noted making a QGIS compatible version of the dataset from Joe M.

Dataset URL

TODO

Rationale

Has 1m satellite imagery for coast

This ticket: #579

Reminded me that we have a problem with layer titles being ambigious without the context of the layer groups. Many tools in QGIS only display layer titles in dialog boxes, so a user is stuck with trying to figure out what e.g., a layer titled "January" is (which is a layer under the "Median extent" layer group, which is itself under "Sea ice")

We had some feedback that the USGS earthquakes layer is not very good. We were directed to GEUS:

• http://seis.geus.net/projects/glisn/geus-eqlist.html
• https://eng.geus.dk/nature-and-climate/earthquakes-and-seismology

Consider if we can ingest and use this data. If so, should we keep the USGS layer or replace it entirely?

New dataset is available: http://products.esa-icesheets-cci.org/products/details/cci_sec_2021.zip/

Issue description

We want the User Guide PDF to be focused on a non-contributor audience. It's assumed that contributors will have Internet access, access our docs online, and contribute via GitHub.

System information

N/A

Looks like there is a 2023 product available. See: https://www.gebco.net/data_and_products/gridded_bathymetry_data/

In the "Sea ice" root group. This is already in the layer description but we think it should be more clear from the layer group title.

Is there any way to access QGreenland data outside of the ZIP file here https://nsidc.org/qgreenland/stable/ ?

Can you unzip that on the server into a 'data' or 'src' sub-folder so that we can access the layers individually? If so, you would provide alternate access methods that support older hardware, smaller disks, faster partial downloads, etc. I as a 3rd party can take care of all that via my own interface (probably using datalad).

Issue description

The data is not hosted at the currently-configured URL anymore https://sandbox.oarc.ucla.edu/mapshare/data/world/data/utmzone.zip

System information

N/A

Issue description

I'm not sure what is causing the issue that was resolved by #547 . We use micromamba to install environments, so we shouldn't ever need mamba in the Docker image, especially at runtime. I'm so confused about that... I think we need to look closer at whatever is causing that error!

TODO: Reproduction instructions for error in description of #547

System information

N/A

Dataset URL

TODO

More info

A new version was recently released. Ours is outdated.

There are 3 "Frozen ground/" layers currently:

• "Ground temperature 2000-2016 (10km)"
• "Ground temperature standard deviation (10km)"
• "Permafrost probability (10km)"

All three of these layers are from Obu et al., 2018:

Obu, Jaroslav; Westermann, Sebastian; Kääb, Andreas; Bartsch,
Annett (2018): Ground Temperature Map, 2000-2016, Northern
Hemisphere Permafrost. Alfred Wegener Institute, Helmholtz
Centre for Polar and Marine Research, Bremerhaven, PANGAEA

https://doi.org/10.1594/PANGAEA.888600

This dataset does not have an update with more recent data.

Are there other datasets we could add? Newer dataset we could use to replace the above?

Twila suggests reaching out to colleagues for suggestions:

• Ted Schuur
• Christina Schaedel
• Dr. Sharon Smith

We now use conda-lock for our main qgreenland conda environment. We still use an environment.yml-style file for our "command" environment, however (the environment where dataset transformations take place in, with e.g., gdal installed).

https://github.com/nsidc/qgreenland/pull/547/files#r1224751677

Issue description

A / in the layer title is causing this to happen.

System information

N/A

We can get CI for free for this project, plus we're moving that way in general as a dev group. Our CI isn't very complex, it'd be pretty easy to migrate. And probably easier to read post-migration as well.

While migrating, we might want to consider adding environment caching (#527); the micromamba action can do that pretty well.

Issue description

./scripts/experimental/local_cli.sh layers '*' lists all layers, but ./scripts/cli.sh layers '*' returns:

Usage: __init__.py layers [OPTIONS] PATTERN
Try '__init__.py layers -h' for help.

Error: Got unexpected extra argument (tasks)

Workaround

Escape the string aggressively:

./scripts/cli.sh layers \'\*\'

System information

• Operating system: PopOS
• Operating system version: 22
• QGIS version: N/A
• QGreenland version: 2.0.0

Issue description

I think we need to cut a new release to fix this on "stable". Been a long while since I thought about this...

The broken link is on this page:

https://qgreenland.readthedocs.io/en/stable/tutorials/plugin-how-to.html

System information

N/A

E.g., look through the list here and consider adding WMS/WCS layers: https://www.earthdata.nasa.gov/learn/pathfinders/gis-pathfinder/geospatial-services

GIBS, for example, has numerous science variable layers that work with the temporal controller.

See the associated PR: #586

Issue description

We don't need this; could cache the conda env on the hash of the environment-lock.yml file.

System information

N/A

Issue description

Pre-commit should run in CI to catch violations by users who did not install pre-commit.

System information

N/A

Hi QGreenland- thanks for setting this up- great resource.

I tried to look and see if I could resolve this myself in git, but it looks like not all the actual layers are on git. I'm seeing through a fresh install (v0.54.0 downloaded today) a few troublesome filenames, with "bad" characters. These are:

• the forward slash ('/') in the topo map scale: QGreenland_v0.54.0/Terrain models/Topographic map (1/500,000)/
• greater-than symbol ('>') in the earthquake magnitudes: QGreenland_v0.54.0/Geology/Earthquakes M>2.5 1900-2020/earthquakes.gpkg

Thanks!

Release the next alpha version with changes so far.

Issue description

From: QGR-134

TODO: Is the version specification correct? Maybe started in 3.18?

In older versions of QGIS, the error may manifest in a less visible way like this:

In newer versions, the error is surfaced to the viewport:

Workaround

Install helvetica.ttf (TODO: Find a safe source)

Proposed solution

Require minimum version of QGIS 3.28, which is capable of downloading missing fonts. Pick an open source font that will be used on all operating systems.

Commentary

Matt Fisher

Found this issue on GitHub: qgis/QGIS#46206

Looks like this warning was promoted from being hidden in the symbology menu to the main viewer, but it's still just a warning. I think we need:

Add a note about this to troubleshooting docs
If possible, select a default font for the whole project that is available in all major OSes to minimize the occurrence of the warning.

Trey Stafford

The "Helvetica" font seems to be set in the project file (qgreenland.qgs). I manually did a global replacement of all occurrences of "Helvetica" with "Sans Serif", which resolved the issue when opening the project in QGIS.

Unclear how this attribute gets set. It might be the QT library that's determining a default system font? Perhaps Helvetica is available in the docker image that we use to generate the project file?

I tried getting the default font using the PyQT library but was unsuccessful:

(base) root@1bfc695b3a88:/luigi# python
Python 3.10.8 | packaged by conda-forge | (main, Nov 22 2022, 08:23:14) [GCC 10.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from PyQt5.QtGui import QFont
>>> QFont().defaultFamily()
Segmentation fault (core dumped)
(base) root@1bfc695b3a88:/luigi#

System information

• Operating system: Any except Windows
• Operating system version: Any
• QGIS version: >=3.22
• QGreenland version: Any

Dataset URL

No response

Rationale

From: QGR-36

See email from Walt Meier to [email protected] 8/14/20. Need specific dataset suggestions.

Consider: CFSR, ERA5, MERRA2

Consider remote access as a possibility.

Dataset URL

https://www.hotosm.org/

More info

The humanity open street map layers are inaccurate and are missing locations. We have had strong feedback recommend the removal of these layers as misleading.

Does the package get unreasonably large?

Can we use downsampling? Probably don't need full res for background layer.

The reason we gave up on this in the past was because cutting this layer to the 40° extent resulted in a weird ring-shaped cut where the only data extant afterwards is the data between 40°N and 41°N

I think it's worth taking one more stab at this now that we're using CLI OGR tools. Maybe it will be easier than wrangling the Python bindings?

Then again, maybe we already tried making this work at the CLI. See if @trey-stafford remembers

https://github.com/orgs/nsidc/projects/11/views/1?pane=issue&itemId=30331459 added a new version of the topographic map as a WMS layer.

Dataset URL

TODO

Rationale

@trey-stafford to populate

Can we replace the HOTOSM layers with something else, e.g., from Asiaq?

Aside from populated places, HOTOSM layers were:

• "health_facilities"
• "airports"
• "seaports"
• "waterways"
• "financial_services"
• "education_facilities"
• "points_of_interest"
• "roads"
• "buildings"

Frederik H. from Asiaq says:

You can find the data here: https://kort.nunagis.gl/refserver/rest/services/Kortportal/Kortportal_TekniskGrundkort/MapServer

The building layer is called ‘BYGNING’, and the attribute containing building use is called ‘Info’. It is only in Danish though.

https://www.earthdata.nasa.gov/eosdis/science-system-description/eosdis-components/gibs

Dataset URL

https://arcticdata.io/catalog/view/doi%3A10.18739%2FA2MV9S

Rationale

From: QGR-17

The data is available from ADC in 10+ GB decadal files. Is this the only format to access the data? We are waiting for information from Marco Tedesco. Unclear whether he can provide a publicly archived datasource or if they will email us file(s). The data are currently NetCDF files. Waiting for more emails! See [email protected] mailbox for discussion.

Next step: E-mail Marco again!

Dataset URL

https://www.ncei.noaa.gov/access/world-ocean-atlas-2023/

Rationale

From: QGR-31

Since we already have temperature from WOA, we think it makes sense to get salinity from there as well.

An alternative might be CMIP5, but may be harder to work with: https://psl.noaa.gov/ipcc/ocn/details.html

Dataset URL

https://dataverse01.geus.dk/dataverse/ice_discharge

Rationale

From: QGR-18

We think this part of the dataset would be interesting to include.

Neils says: "Gates could used as symbols in QGRL"

We want to update the Asiaq place names layer ("Places/Towns and settlements") because there are a number of noted data issues.

Dataset URL

https://nsidc.org/data/idbmg4/versions/5

More info

From: QGR-173

Probably little/no change in our processing. Here are the updates to the dataset:

Added bathymetry measurements from the Alfred Wegener Institute,
Helmholtz Centre for Polar and Marine Research, in front of the Northeast Greenland Ice Stream

Added ice thickness for ice caps from Millan et al. (2022) (https://www.nature.com/articles/s41561-021-00885-z)

Included bathymetry data from NASA's 2021 Oceans Melting Greenland (OMG) campaign

Provided a geotiff file of bed elevation

The background layer has an alpha band that is not currently used and appears to be all-nan (double-check this). If this is the case, consider removing that alpha band!

QGIS does not seem to like the 4th band, the following error message gets logged repeatedly while this layer is toggled on:

ERROR 5: /share/appdata/qgreenland/working-storage/wip-package/QGreenland/Basemaps/Background (500m)/background.tif: GDALDataset::GetRasterBand(4) - Illegal band #

QGreenland_v1.0.1 has quite a few issues.
I downloaded the zip from the webpage, unzipped it, and then opened the qgreenland.qgs

1. there are 45 layers that are not available (dialog box)
2. startup is extremely slow
3. Critical: Could not create AF_NETLINK socket (Too many open files)
4. Warning 4: Failed to open /home/data/QGreenland_v1.0.1/Places/Towns and settlements/populated_places.gpkg: Too many open files.

lots of the above two error messages occur (3./4.).

QGIS 3.18.1-Zürich
Arch Linux as of today
very performant laptop with lots of RAM (32G) of which almost nothing is used.