Rasterio reads and writes geospatial raster datasets



Rasterio reads and writes geospatial raster data.

https://travis-ci.com/mapbox/rasterio.png?branch=master https://coveralls.io/repos/github/mapbox/rasterio/badge.svg?branch=master

Geographic information systems use GeoTIFF and other formats to organize and store gridded, or raster, datasets. Rasterio reads and writes these formats and provides a Python API based on N-D arrays.

Rasterio 1.2 works with Python versions 3.6 through 3.9, Numpy versions 1.15 and newer, and GDAL versions 2.3 through 3.2. Official binary packages for Linux and Mac OS X are available on PyPI. Unofficial binary packages for Windows are available through other channels.

Read the documentation for more details: https://rasterio.readthedocs.io/.


Here's an example of some basic features that Rasterio provides. Three bands are read from an image and averaged to produce something like a panchromatic band. This new band is then written to a new single band TIFF.

import numpy as np
import rasterio

# Read raster bands directly to Numpy arrays.
with rasterio.open('tests/data/RGB.byte.tif') as src:
    r, g, b = src.read()

# Combine arrays in place. Expecting that the sum will
# temporarily exceed the 8-bit integer range, initialize it as
# a 64-bit float (the numpy default) array. Adding other
# arrays to it in-place converts those arrays "up" and
# preserves the type of the total array.
total = np.zeros(r.shape)
for band in r, g, b:
    total += band
total /= 3

# Write the product as a raster band to a new 8-bit file. For
# the new file's profile, we start with the meta attributes of
# the source file, but then change the band count to 1, set the
# dtype to uint8, and specify LZW compression.
profile = src.profile
profile.update(dtype=rasterio.uint8, count=1, compress='lzw')

with rasterio.open('example-total.tif', 'w', **profile) as dst:
    dst.write(total.astype(rasterio.uint8), 1)

The output:


API Overview

Rasterio gives access to properties of a geospatial raster file.

with rasterio.open('tests/data/RGB.byte.tif') as src:
    print(src.width, src.height)

# Printed:
# (791, 718)
# {u'units': u'm', u'no_defs': True, u'ellps': u'WGS84', u'proj': u'utm', u'zone': 18}
# Affine(300.0379266750948, 0.0, 101985.0,
#        0.0, -300.041782729805, 2826915.0)
# 3
# [1, 2, 3]

A rasterio dataset also provides methods for getting extended array slices given georeferenced coordinates.

with rasterio.open('tests/data/RGB.byte.tif') as src:
    print src.window(**src.window_bounds(((100, 200), (100, 200))))

# Printed:
# ((100, 200), (100, 200))

Rasterio CLI

Rasterio's command line interface, named "rio", is documented at cli.rst. Its rio insp command opens the hood of any raster dataset so you can poke around using Python.

$ rio insp tests/data/RGB.byte.tif
Rasterio 0.10 Interactive Inspector (Python 3.4.1)
Type "src.meta", "src.read(1)", or "help(src)" for more information.
>>> src.name
>>> src.closed
>>> src.shape
(718, 791)
>>> src.crs
{'init': 'epsg:32618'}
>>> b, g, r = src.read()
>>> b
masked_array(data =
 [[-- -- -- ..., -- -- --]
 [-- -- -- ..., -- -- --]
 [-- -- -- ..., -- -- --]
 [-- -- -- ..., -- -- --]
 [-- -- -- ..., -- -- --]
 [-- -- -- ..., -- -- --]],
             mask =
 [[ True  True  True ...,  True  True  True]
 [ True  True  True ...,  True  True  True]
 [ True  True  True ...,  True  True  True]
 [ True  True  True ...,  True  True  True]
 [ True  True  True ...,  True  True  True]
 [ True  True  True ...,  True  True  True]],
       fill_value = 0)

>>> np.nanmin(b), np.nanmax(b), np.nanmean(b)
(0, 255, 29.94772668847656)

Rio Plugins

Rio provides the ability to create subcommands using plugins. See cli.rst for more information on building plugins.

See the plugin registry for a list of available plugins.


Please install Rasterio in a virtual environment so that its requirements don't tamper with your system's Python.

SSL certs

The Linux wheels on PyPI are built on CentOS and libcurl expects certs to be in /etc/pki/tls/certs/ca-bundle.crt. Ubuntu's certs, for example, are in a different location. You may need to use the CURL_CA_BUNDLE environment variable to specify the location of SSL certs on your computer. On an Ubuntu system set the variable as shown below.

$ export CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt


Rasterio has a C library dependency: GDAL >= 2.3. GDAL itself depends on some other libraries provided by most major operating systems and also depends on the non standard GEOS and PROJ4 libraries. How to meet these requirement will be explained below.

Rasterio's Python dependencies are listed in its requirements.txt file.

Development also requires (see requirements-dev.txt) Cython and other packages.

Binary Distributions

Use a binary distributions that directly or indirectly provide GDAL if possible.


Rasterio distributions are available from UbuntuGIS and Anaconda's conda-forge channel.

Manylinux1 wheels are available on PyPI.


Binary distributions with GDAL, GEOS, and PROJ4 libraries included are available for OS X versions 10.9+. To install, run pip install rasterio. These binary wheels are preferred by newer versions of pip.

If you don't want these wheels and want to install from a source distribution, run pip install rasterio --no-binary rasterio instead.

The included GDAL library is fairly minimal, providing only the format drivers that ship with GDAL and are enabled by default. To get access to more formats, you must build from a source distribution (see below).


Binary wheels for rasterio and GDAL are created by Christoph Gohlke and are available from his website.

To install rasterio, simply download both binaries for your system (rasterio and GDAL) and run something like this from the downloads folder, adjusting for your Python version.

$ pip install -U pip
$ pip install GDAL-3.1.4-cp39-cp39‑win_amd64.whl
$ pip install rasterio‑1.1.8-cp39-cp39-win_amd64.whl

You can also install rasterio with conda using Anaconda's conda-forge channel.

$ conda install -c conda-forge rasterio

Source Distributions

Rasterio is a Python C extension and to build you'll need a working compiler (XCode on OS X etc). You'll also need Numpy preinstalled; the Numpy headers are required to run the rasterio setup script. Numpy has to be installed (via the indicated requirements file) before rasterio can be installed. See rasterio's Travis configuration for more guidance.


The following commands are adapted from Rasterio's Travis-CI configuration.

$ sudo add-apt-repository ppa:ubuntugis/ppa
$ sudo apt-get update
$ sudo apt-get install gdal-bin libgdal-dev
$ pip install -U pip
$ pip install rasterio

Adapt them as necessary for your Linux system.


For a Homebrew based Python environment, do the following.

$ brew update
$ brew install gdal
$ pip install -U pip
$ pip install --no-binary rasterio


You can download a binary distribution of GDAL from here. You will also need to download the compiled libraries and headers (include files).

When building from source on Windows, it is important to know that setup.py cannot rely on gdal-config, which is only present on UNIX systems, to discover the locations of header files and libraries that rasterio needs to compile its C extensions. On Windows, these paths need to be provided by the user. You will need to find the include files and the library files for gdal and use setup.py as follows. You will also need to specify the installed gdal version through the GDAL_VERSION environment variable.

$ python setup.py build_ext -I<path to gdal include files> -lgdal_i -L<path to gdal library> install

With pip

$ pip install --no-use-pep517 --global-option -I<path to gdal include files> -lgdal_i -L<path to gdal library> .

Note: --no-use-pep517 is required as pip currently hasn't implemented a way for optional arguments to be passed to the build backend when using PEP 517. See here for more details.

Alternatively environment variables (e.g. INCLUDE and LINK) used by MSVC compiler can be used to point to include directories and library files.

We have had success compiling code using the same version of Microsoft's Visual Studio used to compile the targeted version of Python (more info on versions used here.).

Note: The GDAL DLL and gdal-data directory need to be in your Windows PATH otherwise rasterio will fail to work.


The primary forum for questions about installation and usage of Rasterio is https://rasterio.groups.io/g/main. The authors and other users will answer questions when they have expertise to share and time to explain. Please take the time to craft a clear question and be patient about responses.

Please do not bring these questions to Rasterio's issue tracker, which we want to reserve for bug reports and other actionable issues.

While Rasterio's repo is in the Mapbox GitHub organization, Mapbox's Support team is focused on customer support for its commercial platform and Rasterio support requests may be perfunctorily closed with or without a link to https://rasterio.groups.io/g/main. It's better to bring questions directly to the main Rasterio group at groups.io.

Development and Testing



See docs/.


See LICENSE.txt.


See AUTHORS.txt.


See CHANGES.txt.

Who is Using Rasterio?

See here.

  • 1.3.0 release

    1.3.0 release

    We've got some new features done and only two outstanding features. Are there any objections to an alpha release tomorrow?

    For the wheels, getting this patch https://github.com/OSGeo/gdal/pull/4646 could resolve #2233 .

    opened by sgillies 48
  • Add Python file-like VSI Plugin

    Add Python file-like VSI Plugin

    The Goal

    See https://github.com/corteva/rioxarray/issues/246 for details on the origins of this feature.

    The goal is to make it as efficient as possible for rasterio to open a Python file-like object. The biggest benefit of a feature like this comes when a library like fsspec is combined with rasterio. fsspec provides a unified interface for accessing files including remote file systems like S3 or GCS and has the ability to cache files locally. It can provide these files as python file-like objects. An example of using fsspec and providing its file to rasterio looks like:

    import rasterio
    import fsspec
    with fsspec.open('https://sentinel-cogs.s3.us-west-2.amazonaws.com/sentinel-s2-l2a-cogs/13/S/DV/2020/4/S2B_13SDV_20200428_0_L2A/TCI.tif') as fobj:
        with rasterio.open(fobj) as src:

    The Current Issue

    Currently, rasterio uses a MemoryFile, a GDAL supported feature that reads all the necessary data into memory and accesses the data from there instead of disk. This is great, except that it requires reading all of the data from the file before we need it. This means a lot of time (especially for remote resources) and a lot of memory. With the above example and using the rasterio master branch it takes about ~21s on my laptop to do the above.

    The Solution - Attempt 2

    The current version of this pull request uses GDAL's plugin interfaces to add all necessary hooks (callbacks) for GDAL to communicate with rasterio and the file-like objects that you provide to it. This comes as two parts: the virtual filesystem and the individual file handling. Right now the filesystem is all kept in a single python dictionary (virtual filename -> file wrapper object). The file handling is fairly basic and doesn't need to be too complicated as the basic FILE* operations map to file-like objects (ex read, seek, tell, etc).

    I haven't done anything for writing or for multi-range reads.


    • [x] Switch to GDAL Plugin system. I didn't know about this when I started and it could mean moving all the .cpp stuff into Cython which would be great for maintainability. This will be "Attempt 2".
    • [ ] Figure out multi-threading behavior and multi-process behavior. This is mostly related to how the file system treats a file when rasterio is using it. Also, determines if/when we need locking. This includes the GIL. For example, if GDAL is making its own threads (outside of python), then we may need to explicitly create the thread-local GIL.
    • [x] Add tests
    • [x] Add documentation
    • [x] Add docstrings
    • [x] Answer below questions


    1. Will this replace all rasterio handling of non-string inputs (objects)? Probably not, but in that case when is MemoryFile used instead? Do users get a kwarg to choose? Answer: It will replace reading of file-like objects.
    2. Should this be limited to fsspec objects or any file-like object (handling any missing methods gracefully)? Limiting to fsspec objects may let us assume some things. Answer: All file-like objects.
    3. Are users allowed to provide a filename for the open file object to help GDAL know how to refer to it? If so, what happens if a user provides two different objects with the same name? Answer: Yes, but only to match the existing interface of MemoryFile. Conflicts have an undefined behavior.
    4. Can we support multi-range reads in a semi-standard way? Answer: No. Ignore it for now.
    opened by djhoese 42
  • Appveyor builds

    Appveyor builds

    I've been away from Windows for over a decade. Anyone have experience making Windows binaries with Appveyor as described in https://packaging.python.org/en/latest/appveyor.html?

    /cc @brendan-ward

    packaging intermediate 
    opened by sgillies 41
  • rio-calc, take 1

    rio-calc, take 1

    Towards closing #175.

    Usage, for now, like this:

    $ rio calc "0.10*{1} + 125" tests/data/shade.tif out.tif

    Results in a new hillshade with shade values of 125 instead of 0.

    enhancement cli 
    opened by sgillies 30
  • Weird interaction with scipy nightly builds

    Weird interaction with scipy nightly builds

    Expected behavior and actual behavior.

    The Satpy project has a CI environment that installs various dependencies from their "unstable" sources (nightly builds, git repositories, etc). Recently (in the last week probably), I've started getting this exception:

     /usr/share/miniconda3/envs/test-environment/lib/python3.9/site-packages/trollimage/xrimage.py:58: in <module>
        from rasterio.windows import Window
    /usr/share/miniconda3/envs/test-environment/lib/python3.9/site-packages/rasterio/__init__.py:11: in <module>
        with rasterio._loading.add_gdal_dll_directories():
    E   AttributeError: partially initialized module 'rasterio' has no attribute '_loading' (most likely due to a circular import)

    Steps to reproduce the problem.

    I'm still trying to reproduce it locally. Theoretically just doing the import above should cause it.

    Failing job: https://github.com/pytroll/satpy/actions/runs/3055333856/jobs/4956174627

    Environment Information

    • Output from: rio --show-versions or python -c "import rasterio; rasterio.show_versions()"
    • rasterio version (python -c "import rasterio; print(rasterio.__version__)")

        Created wheel for rasterio: filename=rasterio-1.4.dev0-cp39-cp39-linux_x86_64.whl size=1474741 sha256=ebce139195b79b11d1baa440541745a20a689ef45d6fbcd3af0794544d17e758
    • GDAL version (python -c "import rasterio; print(rasterio.__gdal_version__)"): 3.5.2

    • Python version (python -c "import sys; print(sys.version.replace('\n', ' '))"): 3.9

    • Operation System Information (python -c "import platform; print(platform.platform())"): Ubuntu (ubuntu-latest github action)

    Installation Method

    Conda-forge base packages but pip install various packages with pip from git/nightly builds.

    opened by djhoese 29
  • Merge with method=max, min have aliased result on overlap

    Merge with method=max, min have aliased result on overlap


    When working on Linux (Windows is fine), I have an aliased result on overlapping areas when merging datasets with max and min methods. first method is OK.

    The working area: 2021-07-16_09h38_47

    Here is the correct screenshot (first method): 2021-07-16_09h34_35

    And here the broken one (both min and max are a like, I didn't test other methods): 2021-07-16_09h34_40

    When zooming to the pixel, this is what we got: 2021-07-16_09h35_36

    My code is:

    # From the zip uploaded hereafter
    paths = ["14_20200228T143729_S2_T18HXC_L1C_175923_CLIP.tif", "14_20200228T143729_S2_T18HXD_L1C_175923_CLIP.tif"]
    method = "max"  # min or first
    # Open datasets for merging
    datasets = []
        for path in paths:
        # Merge all datasets
        merged_array, merged_transform = merge.merge(datasets, method=method)
        merged_meta = datasets[0].meta.copy()
                "driver": "GTiff",
                "height": merged_array.shape[1],
                "width": merged_array.shape[2],
                "transform": merged_transform,
        # Close all datasets
        for dataset in datasets:
    # Write on disk
    with rasterio.open("test_min2.tif", "w", **merged_meta) as dst:

    It does not seem to happen all the time, but here are my datasets: MOSAIC.zip

    And my results: results.zip

    Operating system

    Linux (through docker), not reproducible on windows !

    Rasterio version and provenance

    Rasterio 1.2.6 via pip (both on windows and linux)

    opened by remi-braun 28
  • Wrap ndarry, transform, and CRS into an object

    Wrap ndarry, transform, and CRS into an object

    There are a number of places where a rasterio operation takes as input a raster or raster band, OR a numpy ndarray, transform, and sometimes CRS. This complicates the function signatures a bit, as it means having parameters that are meaningful in some cases but not others, and it lacks a bit of cohesion between related entities that may be helpful in many cases.

    Perhaps it is time to create a lightweight object (tuple or class) that wraps these together, so that we can pass just one thing around and have it be more equivalent to passing a raster / raster band?

    Something like the Raster object in @perrygeo 's python-rasterstats package, but not wrapping rasters / bands; only ndarrays.

    This surfaced in #578, among others.

    opened by brendan-ward 28
  • Remove deprecated features

    Remove deprecated features

    Closes https://github.com/mapbox/rasterio/issues/516 Closes https://github.com/mapbox/rasterio/issues/794

    Remove deprecated features and API's. See docs/migrating-to-v1.rst for a general description.

    opened by geowurster 27
  • Rasterio 1.2.0

    Rasterio 1.2.0

    Let's do this before the end of October.

    New features include:

    • VSI cache clearing #1078
    • API for driver metadata (like https://github.com/Toblerity/Fiona/pull/950)
    • RPC support #1922
    • More: https://github.com/mapbox/rasterio/milestone/95?closed=1
    opened by sgillies 26
  • Support or supplant vsi* networking virtual file system functionality in GDAL (e.g. vsicurl, vsis3)

    Support or supplant vsi* networking virtual file system functionality in GDAL (e.g. vsicurl, vsis3)

    Between 0.29.0 and 0.30.0, functionality was introduced to specifically support the virtual file system functinality vsigzip, vsizip, and vsitar. As can be seen in this code, along with explicit support for some virtual file systems, some functionality for other virtual file system support that was previously and unintentionally exposed was explicitly disallowed, and calls that had taken advantage of that GDAL functionality began throwing a "VFS scheme {0} unknown" exception upon upgrade of rasterio.

    Part of the GDAL functionality that became inaccessible through rasterio was accessing rasters over HTTP with vsicurl. That feature in particular was useful to myself and others, since we were relying on it to do windowed reads of large rasters over the network, without pulling down the whole file. In this way we can have multiple processes pulling byte ranges of a GeoTiff off of S3 (which supports the byte range HTTP request header), as a mechanism of doing tiling work using rasterio and PySpark (see the OpenAerialMap tiler code here...this "chunking" step had some problems dealing with very large rasters so if you're interested in using these techniques make sure to look to the master branch's version and any unmerged PR's).

    I started a discussion on a merged pull request, which is the place I found the most definitive language about why vsicurl was no longer supported. It was smartly recommended that we start a separate ticket instead of talking on a merged PR, and this ticket can serve this purpose. Please read the prior discussion as if they were the first comments on this issue.

    /cc @sgillies @perrygeo @mojodna

    opened by lossyrob 26
  • Occasional

    Occasional "not recognized as a supported file format" errors when reading from S3

    Lately, we have encountered a strange bug in Terracotta. It basically always leads to errors like these:

    (from https://github.com/DHI-GRAS/terracotta/issues/139)

    Traceback (most recent call last):
      File "rasterio/_base.pyx", line 213, in rasterio._base.DatasetBase.__init__
      File "rasterio/_shim.pyx", line 64, in rasterio._shim.open_dataset
      File "rasterio/_err.pyx", line 205, in rasterio._err.exc_wrap_pointer
    rasterio._err.CPLE_OpenFailedError: '/vsis3/italy-composite/rasters/italy_2018_red.tif' not recognized as a supported file format.


    (from https://github.com/DHI-GRAS/terracotta/issues/10#issuecomment-489826885)

    Traceback (most recent call last):
      File "rasterio/_io.pyx", line 698, in rasterio._io.DatasetReaderBase._read
      File "rasterio/shim_rasterioex.pxi", line 133, in rasterio._shim.io_multi_band
      File "rasterio/_err.pyx", line 182, in rasterio._err.exc_wrap_int
    rasterio._err.CPLE_AppDefinedError: IReadBlock failed at X offset 0, Y offset 0: '/vsis3/bucket/prefix/tile330.tif' does not exist in the file system, and is not recognized as a supported dataset name.

    The errors occur on different versions of rasterio, although anecdotally it wasn't a problem pre-1.0.15. It also seems to occur both during rasterio.open, and when actually reading tiles via WarpedVRT.read.

    The problem is that we have only observed it with huge raster files, and we haven't been able to reproduce this reliably, or in a way where I could share it with you.

    I am opening this issue to see if you have some intuition why the problem might occur. If you think it just adds noise, please feel free to close it.

    opened by dionhaefner 22
  • Using more intermediate VRTs in higher-level tools

    Using more intermediate VRTs in higher-level tools

    For example, gdal_translate uses a VRT under the hood to gather changes and options and then relies on GDALCreateCopy to materialize those changes and produce an output file: https://github.com/OSGeo/gdal/blob/master/apps/gdal_translate_lib.cpp#L2511.

    Rasterio's merge tool could similarly take advantage of an internal VRT. Our existing merge tool produces very large numpy arrays as its only possible output. An example of the direction we might take is shown in #2699.

    Rasterio stack CLI program could also use a VRT. Stacking by itself wouldn't need to use a lot of resources, it would only be when materializing hefty stacks to a file that the deferred work would be done.

    And of course, Rasterio's convert CLI program could use a VRT in the same way gdal_translate does.

    There's no immediate action here. I want to show that #2699 isn't entirely out of the blue and is part of a theme I've been thinking about for a while: Rasterio making virtual datasets using Python XML libs and GDAL reading those datasets.

    cli notebooks tool vrt 
    opened by sgillies 0
  • VRT form of merging

    VRT form of merging

    There's a lot of overlap between rasterio's merge and GDAL's GDALBuildVRT utility. I believe having two different ways to do the same kind of thing is a step backwards for this project. As an alternative to #2573, which wraps GDALBuildVRT, I've reimplemented the GDAL utility in Python, building on existing code in _boundless_vrt_doc.

    Advantages over using GDALBuildVRT:

    • It's compatible with Rasterio dataset objects. GDALBuildVRT only understands GDAL filenames.
    • It returns an XML string, making temporary files on the filesystem unnecessary.
    • It's Python. Easy to read and modify. GDALBuildVRT is C++. Harder to read and modify.
    • It shares code with _boundless_vrt_doc. We can continue to refactor and develop a better virtual dataset story throughout Rasterio.
    • It shares code with merge. The functions could be refactored so that merge uses virtual_merge, which also has the potential to resolve other issues in our tracker (like #507 and #2221).

    The name of this function and the module it lives in are undecided.

    This can totally replace gdal.BuildVRT for OSMnx (in #2573) and doesn't require wrapping GDALBuildVRT. Just because a Rasterio user wants something that GDAL.X does doesn't mean we need to literally expose GDAL.X from Rasterio. GDAL's API design can be improved upon and Rasterio is the project to do those improvements.

    Resolves #2573

    opened by sgillies 2
  • ENH: Add support for merging tiffs with different CRS

    ENH: Add support for merging tiffs with different CRS

    (Following https://github.com/rasterio/rasterio/issues/2696)

    I have been looking into the implementation of rasterio.merge.merge to "prefetch" common bounds from a group of rasters. Once working on my implementation (since the function isn't currently too modular) I realized that I was getting errors when calculating common bounds of tiffs.

    After some investigation, it turns out this was because the CRS of each tif was different, resulting in bounds given in different units. Before implementing my own solution, I looked at the merge implementation again but found no consideration for this. In the end, I implemented a solution based on rasterio.warp.transform_bounds.

    I currently implemented this solution with a separate function since it may be a backward breaking change and I'm not sure whether that is something that would be appreciated. I replicated all existing tests for the new merge function (with support for multiple CRSs) but still need to add tests to check the feature specifically (i.e. actively try to merge tiffs with different CRSs).

    opened by VehpuS 0
  • (How) is the rasterio.merge function taking into account different crs for the rasters

    (How) is the rasterio.merge function taking into account different crs for the rasters

    Discussed in https://github.com/rasterio/rasterio/discussions/2682

    Originally posted by VehpuS December 15, 2022 I have been looking into the implementation of rasterio.merge.merge to "prefetch" common bounds from a group of rasters. Once working on my implementation (since the function isn't currently too modular) I realized that I was getting errors when calculating common bounds of tiffs.

    After some investigation, it turns out this was because the CRS of each tif was different, resulting in bounds given in different units. Before implementing my own solution, I looked at the merge implementation again but found no consideration for this. In the end, I implemented a solution based on rasterio.warp.transform_bounds.

    I'm writing here to check if I missed something. If not, I would be happy to make changes to the merge function to either fix this or specify the assumption that all tiffs (and the target bounds parameters) are assumed to share the same CRS before running merge. I have a good approach for a solution if necessary, but I wanted to confirm my suspicions before implementing a PR.

    opened by VehpuS 3
Mapbox is the location data platform for mobile and web applications. We're changing the way people move around cities and explore our world.
Summary statistics of geospatial raster datasets based on vector geometries.

rasterstats rasterstats is a Python module for summarizing geospatial raster datasets based on vector geometries. It includes functions for zonal stat

Matthew Perry 437 Dec 23, 2022
Fiona reads and writes geographic data files

Fiona Fiona reads and writes geographic data files and thereby helps Python programmers integrate geographic information systems with other computer s

null 987 Jan 4, 2023
🌐 Local tile server for viewing geospatial raster files with ipyleaflet

?? Local Tile Server for Geospatial Rasters Need to visualize a rather large raster (gigabytes) you have locally? This is for you. A Flask application

Bane Sullivan 192 Jan 4, 2023
🌐 Local tile server for viewing geospatial raster files with ipyleaflet or folium

?? Local Tile Server for Geospatial Rasters Need to visualize a rather large (gigabytes) raster you have locally? This is for you. A Flask application

Bane Sullivan 192 Jan 4, 2023
Read and write rasters in parallel using Rasterio and Dask

dask-rasterio dask-rasterio provides some methods for reading and writing rasters in parallel using Rasterio and Dask arrays. Usage Read a multiband r

Dymaxion Labs 85 Aug 30, 2022
Cloud Optimized GeoTIFF creation and validation plugin for rasterio

rio-cogeo Cloud Optimized GeoTIFF (COG) creation and validation plugin for Rasterio. Documentation: https://cogeotiff.github.io/rio-cogeo/ Source Code

null 216 Dec 31, 2022
A light-weight, versatile XYZ tile server, built with Flask and Rasterio :earth_africa:

Terracotta is a pure Python tile server that runs as a WSGI app on a dedicated webserver or as a serverless app on AWS Lambda. It is built on a modern

DHI GRAS 531 Dec 28, 2022
Histogram matching plugin for rasterio

rio-hist Histogram matching plugin for rasterio. Provides a CLI and python module for adjusting colors based on histogram matching in a variety of col

Mapbox 75 Sep 23, 2022
Color correction plugin for rasterio

rio-color A rasterio plugin for applying basic color-oriented image operations to geospatial rasters. Goals No heavy dependencies: rio-color is purpos

Mapbox 111 Nov 15, 2022
How to use COG's (Cloud optimized GeoTIFFs) with Rasterio

How to use COG's (Cloud optimized GeoTIFFs) with Rasterio According to Cogeo.org: A Cloud Opdtimized GeoTIFF (COG) is a regular GeoTIFF file, aimed at

Marvin Gabler 8 Jul 29, 2022
Advanced raster and geometry manipulations

buzzard In a nutshell, the buzzard library provides powerful abstractions to manipulate together images and geometries that come from different kind o

Earthcube Lab 30 Jun 20, 2022
Raster-based Spatial Analysis for Python

?? xarray-spatial: Raster-Based Spatial Analysis in Python ?? Fast, Accurate Python library for Raster Operations ⚑ Extensible with Numba ⏩ Scalable w

makepath 649 Jan 1, 2023
This tool reads the route of a hike and generates a table of iNaturalist observations along the trails.

This tool reads the route of a hike and generates a table of iNaturalist observations along the trails. It also shows the observations and the route of the hike on a map. Moreover, it saves waypoints of the iNaturalist observations for offline navigation with a GPS device or smartphone.

null 1 Nov 21, 2021
gpdvega is a bridge between GeoPandas and Altair that allows to seamlessly chart geospatial data

gpdvega gpdvega is a bridge between GeoPandas a geospatial extension of Pandas and the declarative statistical visualization library Altair, which all

Ilia Timofeev 49 Jul 25, 2022
leafmap - A Python package for geospatial analysis and interactive mapping in a Jupyter environment.

A Python package for geospatial analysis and interactive mapping with minimal coding in a Jupyter environment

Qiusheng Wu 1.4k Jan 2, 2023
GeoNode is an open source platform that facilitates the creation, sharing, and collaborative use of geospatial data.

Table of Contents What is GeoNode? Try out GeoNode Install Learn GeoNode Development Contributing Roadmap Showcase Most useful links Licensing What is

GeoNode Development Team 1.2k Dec 26, 2022
WebGL2 powered geospatial visualization layers

deck.gl | Website WebGL2-powered, highly performant large-scale data visualization deck.gl is designed to simplify high-performance, WebGL-based visua

Vis.gl 10.5k Jan 8, 2023
Geospatial Image Processing for Python

GIPPY Gippy is a Python library for image processing of geospatial raster data. The core of the library is implemented as a C++ library, libgip, with

GIPIT 83 Aug 19, 2022
Minimum Bounding Box of Geospatial data

BBOX Problem definition: The spatial data users often are required to obtain the coordinates of the minimum bounding box of vector and raster data in

Ali Khosravi Kazazi 1 Sep 8, 2022