GeoViews: mapping libraries on top of the HoloViews stack

A map becomes a HoloViews element, not a special case

GeoViews is the HoloViz package for geographical visualisation, and the way it works is by making geographic objects first-class members of the HoloViews ecosystem. Rather than asking you to call Cartopy directly and then throw away interactivity, GeoViews wraps geographic data so that it can be plotted through the same API as any other HoloViews element, with a data dimension and axes. The README is cut off after the first line of the What is it section, so the wording of the project's own definition is not in the version available here, but the package description in the project metadata is complete: GeoViews is a Python library that makes it easy to explore and visualize geographical, meteorological and oceanographic datasets, such as those used in weather, climate and remote sensing research. The homepage is geoviews.org, and support runs on the HoloViz Discourse forum.

Where to get it, and what you install alongside it

The README does not give an install command, so the honest answer is where the project says to get the package. The badge table points at the PyPI page for geoviews and at three conda channels, pyviz, conda-forge and defaults, so the package is installable from the standard Python channels rather than from a source build. The dependency list in the project metadata is the practical specification of what arrives with it.

dependencies = [
    'bokeh >=3.10.0',
    'cartopy >=0.18.0',
    'holoviews >=1.16.0',
    'numpy',
    'packaging',
    'panel >=1.10.0a0',  # TODO(build): Remove a0
    'param >=1.9.3,<3.0',
    'pyproj',
    'shapely >=1.8.0',
    'xyzservices',
]

Two things in that list deserve a second look before you install. The Panel entry is marked as a pre-release requirement, with a TODO comment to remove the a0 suffix once it is no longer needed, so a strict resolver in your environment may object to it. And the HoloViews floor of 1.16.0 sits above the most recent GeoViews release of 1.15.1, which means a clean install pulls a HoloViews version newer than the GeoViews tag you may have read about in a blog post.

The dependency list tells you what you are agreeing to install

The project metadata lists the runtime dependencies and they are instructive. Bokeh 3.10.0 or newer provides the rendering layer, Cartopy 0.18.0 or newer provides the map projections and coastlines, HoloViews 1.16.0 or newer provides the core plotting API, and Panel 1.10.0a0 or newer provides the serving and dashboard layer. Then come NumPy, packaging, Param with a range from 1.9.3 to below 3.0, PyProj, Shapely 1.8.0 or newer and xyzservices, which is the map tile and provider naming package. So a GeoViews install is a geospatial stack plus the HoloViz stack, not a lightweight addition to an existing environment. The build system also pins Bokeh exactly, with the build requirement of bokeh ==3.10.*, and versioning itself is handled by hatch-vcs on top of hatchling. The package is BSD-3-Clause licensed with the licence file in the repository root.

Python 3.12 and a classifier list that runs ahead of it

The requires-python field says >=3.12, and the classifiers list Python 3.12, 3.13, 3.14 and 3.15, with a Development Status of 5, Production/Stable and an Operating System of OS Independent. That combination is worth pausing on, because listing 3.14 and 3.15 as supported is ahead of what most of the scientific Python stack had settled on when the classifiers were written, so treat the list as an intention rather than a tested matrix. The floor itself is the practical constraint. A team on Python 3.11 cannot install this version of GeoViews, and the correct response is to check the project history rather than to assume an older release will do, since the dependency floors have moved over time as well. The project also carries its own tooling choices that reflect a modern Python setup: a hatch_build.py, a pixi.toml with a pixi.lock, and a .pre-commit-config.yaml.

What the repository contains and how the examples are organised

The top level is a normal scientific Python library layout with a strong emphasis on documentation infrastructure. There is the geoviews/ package, a doc/ directory, an examples/ directory, a scripts/ directory, and the usual project files including pyproject.toml, CHANGELOG.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md and HOWTORELEASE.md. The examples directory is where the project explains itself, and its contents are telling: Homepage.ipynb for the landing example, a gallery/ directory, a user_guide/ directory, an assets/ directory, a conftest.py and a datasets.yml that lists the data the examples fetch. A datasets manifest checked into the repository is a good sign, because it means the example data is pinned somewhere rather than downloaded ad hoc. The repository also uses .git-blame-ignore-revs, which is a sign that the project has run large automated reformatting commits and has decided to keep the history readable rather than pretend they never happened.

A stable release line with regular development behind it

The release history shows a project with a steady public cadence. The recent tags are v1.15.1 published on 2026-01-13, v1.15.0 on 2025-11-14 and v1.14.1 on 2025-08-14, which is roughly one release every two to three months. The last push to the repository was on 2026-10-19, so the branch is moving well ahead of the last tagged release, and the README's badge table separates the latest dev release from the latest release for exactly that reason, pointing at a development site alongside the release tags. The Dev Status classifier of Production/Stable refers to the released package, not to the tip of main, which is a distinction worth keeping in mind when a bug appears in a development build. Support is organised around the HoloViz Discourse, and the project metadata lists a Discord server, a blog, an issue tracker and a funding link.

Where the HoloViews route is the wrong one

Three cases stand out. The first is a one-off static map for a report or a paper figure. GeoViews can do that, but the dependency set is heavy for a task that Cartopy alone handles, and the interactivity is wasted. The second is an environment that cannot install the HoloViz stack at all, for instance a locked-down data pipeline container or a platform with a Python 3.11 ceiling, where the 3.12 floor rules the package out regardless of the fit. The third is a team that has already committed to a different plotting stack. GeoViews is not a standalone plotting library; it is a bridge into HoloViews, Bokeh and Panel, so adopting it means adopting that stack, and if your organisation has standardised on Matplotlib or Plotly for publication figures, the extra layers are a cost without a matching benefit. The HoloViz umbrella also has sibling projects for the same data in different output forms, and the geospatial bridge is the one GeoViews provides.

Editorial conclusion

GeoViews fits a Python team already working with HoloViews, Bokeh or Panel that needs map plots to be interactive and shareable rather than static PNGs, and that is ready to take on Cartopy and Shapely as dependencies. It does not fit a script that needs to run in a minimal environment, since the dependency set pulls in Bokeh, Cartopy, HoloViews, Panel, Param, PyProj, Shapely, xyzservices and NumPy, and it does not fit a team on Python 3.11 or older. Before you adopt it, check the Python floor, because the project metadata requires 3.12 or newer, and check the HoloViews floor, since the dependency list asks for holoviews 1.16.0 or newer while the most recent GeoViews release itself is v1.15.1 from 2026-01-13.

Frequently asked questions

Official sources

1. holoviz/geoviews on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases