See below; version 2.4.2 from the ubuntugis ppa.

Expected output is just the version information, no crash.

$ gdal2tiles.py --version
GDAL 2.4.2, released 2019/06/28
Traceback (most recent call last):
  File "/usr/bin/gdal2tiles.py", line 2927, in <module>
    main()
  File "/usr/bin/gdal2tiles.py", line 2917, in main
    input_file, output_folder, options = process_args(argv[1:])

@chrisbennight missed a badge!

I'm having trouble with QGIS interacting with our Thredds WCS endpoint. I'm not sure if its a bug in Thredds or QGIS or neither, or if I'm just interpreting it wrong.

Please see the NetCDF4 file served by Thredds 4.6.14 here:
http://esoil.io/thredds/wcs/SMIPSall/SMIPSv0.5.nc?service=WCS&version=1.0.0&request=GetCapabilities

Specifically the DescribeCoverage endpoint here: http://esoil.io/th

We have a number of ways to supply test Atlas data. Some options include:

• leveraging the TestAtlas and supporting annotations
• using .txt Atlas files
• using .atlas.gz Atlas files
• supplying raw .osm files, created in JOSM

Each option has a specific use case. This task involves creating a README documenting each option, any standardization (for example - do not GZIP your text fi

Currently, the documentation uses a naming convention that's really uninformative - for example, the default hash and range keys are simply called hashKey and rangeKey. Yet, I can't change them however I want, without breaking stuff (it seems like, anyway...).

It would be nice with some documentation about how this library uses the table key schema and indexes. Which parts are calculated

Currently the draft version requires that if a server supports CRS extension then the geometries in POSTs and PUTs should be in storage crs advertised by the server.

This is problematic since it forces the client to also support CRS extension. The client needs to check if the server supports CRS extension possibly reproject the data to storageCRS. Not doing so violates the requirement.

I sug

This is part of Phase 1.

GDELT is a very complex data set and beginners will need to understand what is available. This is a multi-pronged issue as it is tied to #30 .

The implementation is up to the coder who takes this on, but for consideration:

• Create a class that is an "information" or "whatIs" class. The name of the class should be easy to understand and let the user know to

$ radon cc --min B rioxarray --total-average
rioxarray/rioxarray.py
    M 1080:4 RasterArray.to_raster - B
    M 697:4 RasterArray.reproject - B
    M 861:4 RasterArray.clip_box - B
    M 290:4 XRasterBase.write_crs - B
    M 529:4 RasterArray.nodata - B
    M 562:4 RasterArray.resolution - B
    M 603:4 RasterArray._check_dimensions - B
    M 1172:4 RasterDataset.crs - B
    M 223:

At present sno reset exists, but it actually does something totally unrelated to git reset: it throws away uncommited changes in your working tree. That's the equivalent of git checkout .

git reset actually doesn't touch your working tree; it modifies the repository head and possibly the index. So it's a totally different command.

In testing sno, I find myself needing a more gittish re

When using a Merge function on FeatureType level and using an Aggregate function for the geometries of the source objects that are merged, this warning is displayed for the Instance transformation:
"Multiple values for source node w/o tnrasformation context"

This is expected as the mechanism which creates the warning is not aware of the fact that the Aggregate function is a greedy function usi

In episode _episodes_rmd/12-time-series-raster.Rmd

There is a big chunk of code that can probably be made to look nicer via dplyr:

# Plot RGB data for Julian day 133
 RGB_133 <- stack("data/NEON-DS-Landsat-NDVI/HARV/2011/RGB/133_HARV_landRGB.tif")
 RGB_133_df <- raster::as.data.frame(RGB_133, xy = TRUE)
 quantiles = c(0.02, 0.98)
 r <- quantile(RGB_133_df$X133_HARV_landRGB.1, q

Summary

Research on testing framework options for MagicBox repos and finish writing the Set up a testing framework section in the GitHub Workflow docs.

Details

PR #39 has completed the sections on continuous integration and code health checks. However, a need emerged as I wrote about se

Expected behavior and actual behavior

Cropping any raster with any GeoVector should work. Instead, if the GeoVector is bigger than the world, an error is raised.

simple_world.geojson.zip

Steps to reproduce the probl

Description
Improve the documentation on the UnitsDataArray and the use of units

Describe the solution you'd like
Document what cases are handled for units, and which cases are not.

Investigate how -zb can be used to copy lua files for the user that require non-basic packages. One possibility is to force -zb to update all the packages.

It would be very useful to create a template for the schedule of a geospatial workshop to be used in the workshop website. This schedule should be added to this file: https://github.com/carpentries/workshop-template/blob/gh-pages/_includes/dc/schedule.html