geemap: the Python front end Google Earth Engine never shipped

The gap the package was built to fill

Google Earth Engine is a cloud computing platform holding a multi-petabyte catalog of satellite imagery and geospatial datasets. It offers both JavaScript and Python APIs for making computational requests against those servers. The README identifies the problem precisely: compared with the comprehensive documentation and interactive IDE of the JavaScript API, the Python API has relatively little documentation and limited functionality for visualizing results interactively.

geemap was created to close that gap. It is built on ipyleaflet and ipywidgets, which means maps render as live widgets inside a notebook rather than as static images or a separate web app. That single choice explains most of what the package is for.

Two audiences are named explicitly. The first is students and researchers who want to use the Python ecosystem of libraries and tools to explore Earth Engine data. The second is existing Earth Engine users who want to move from the JavaScript API to Python without starting over.

The project is MIT licensed, has 4030 stars and 1156 forks, is not archived, and was last pushed on 2026-09-22. There is also a stated funding line: NASA support under Grant No. 80NSSC22K1742, issued through the Open Source Tools, Frameworks, and Libraries 2020 Program. That is a rare thing to see stated plainly in a README.

The JavaScript-to-Python converter is the underrated feature

Most of the feature list is about mapping. The item that deserves more attention is the automated JavaScript-to-Python conversion module, which lives at `geemap/conversion.py` and is described as greatly reducing the time needed to convert existing Earth Engine JavaScripts into Python scripts and Jupyter notebooks.

This is the pragmatic path for the second audience. Earth Engine has a large body of existing JavaScript, written against an API with years of examples in the wild. Rewriting that by hand is what makes migration projects die. A converter that produces a Python draft in one pass changes the cost from weeks to an afternoon of cleanup.

The related feature is syntactic compatibility rather than semantic conversion. The package supports Earth Engine JavaScript API-styled functions in Python, naming `Map.addLayer()`, `Map.setCenter()`, `Map.centerObject()` and `Map.setOptions()` explicitly. So even where the conversion is imperfect, you can keep the familiar call shape and change the data plumbing around it.

The rest of the feature list is standard map tooling: display data layers interactively, create split-panel maps, retrieve data with the Inspector Tool, plot by clicking the map, convert between GeoJSON and Earth Engine, use drawing tools, and work with shapefiles without uploading them to your Earth Engine account. That last one removes a real friction point, since uploading assets to a cloud account just to overlay a local shapefile is a common and avoidable step.

Reading the dependency list as a map of the scope

`pyproject.toml` is the most informative file in the repository, and it starts with a floor that will catch people out:

requires-python = ">=3.12"
dependencies = [
    "anywidget",
    "bqplot",
    "earthengine-api>=1.6.12",
    "eerepr>=0.1.0",
    "folium>=0.17.0",
    "geocoder",
    "ipyevents",
    "ipyfilechooser>=0.6.0",
    "ipyleaflet>=0.19.2",
    "matplotlib",
    "numpy",
    "pandas",
    "plotly",
    "pyperclip",
    "pyshp>=2.3.1",
    "python-box",
    "requests",
    "scooby",
    "xarray",
    "xee>=0.1.0",
]

Python 3.12 minimum, with classifiers listed for 3.12 and 3.13. The core dependencies describe the whole stack in one glance. `earthengine-api` is the actual Earth Engine client. `ipyleaflet` and `anywidget` are the interactive map and widget layer, with `ipyevents` handling map interaction events and `ipyfilechooser` handling local file picking. `folium` and `plotly` are the static-map fallbacks, `bqplot` is for 2D plotting, and `xarray` and `xee` cover array-based analysis and Earth Engine export.

The small entries are as telling as the big ones. `pyshp` reads shapefiles directly, which is how the no-upload claim is delivered. `geocoder` handles place-name search. `scooby` generates the environment report that most scientific Python packages ship for reproducible bug reports.

There is also a command line entry point declared as `geemap = "geemap.cli:main"`, which the README does not mention at all.

Optional extras show where the project is heading

The extras in `pyproject.toml` are more revealing than the core list, because they show what the maintainer expects people to build.

There are eleven of them, gathered behind a single `all` extra: ai, backends, dev, extra, lidar, raster, sql, apps, vector, workshop and maplibre. The `ai` extra pulls in a specific stack rather than a generic wrapper: `langchain`, `langchain-google-genai`, `langchain-community`, `google-generativeai`, `google-cloud-aiplatform`, `google-api-core`, `google-cloud-storage` and `iso8601`. That is a deliberate commitment to writing natural language prompts against Earth Engine services.

`backends` adds `keplergl` and `pydeck`, the two 3D and large-scale visualization libraries, so you can escalate from a 2D leaflet map when the data warrants it. `dev` is where you see the project's current tooling direction: `pyrefly>=1.2.0`, `pytest>=9.1.1`, `jupyterlab`, `watchfiles` and `beautifulsoup4`.

Maplibre as its own extra is a sign that the traditional leaflet rendering is no longer the only map backend being tracked. `workshop` presumably corresponds to the GeoPython Conference material, and `sql` suggests a path from Earth Engine results into a database.

Taken together, the extras describe a package that is widening well beyond interactive mapping. That is a reason to look at it before committing to a specific feature set, since the maintenance burden of eleven extras is real.

A JavaScript side that the README barely mentions

The repository tree contains `js/`, `karma.conf.cjs`, `tsconfig.json`, `tsconfig.webpack.json` and `package.json`, which means this is not a pure Python project. There is a TypeScript component that gets bundled into the Python package:

"build": "esbuild js/*.ts --format=esm --bundle --outdir=geemap/static"

The output directory is `geemap/static`, inside the Python package, so the compiled JavaScript ships as package data. The build script also lists a `dev` mode with sourcemaps and watch, a `typecheck` script running `tsc --noEmit`, and a test setup that runs Karma in single-run mode, with a separate `test:watch` variant.

That test stack is unusual and tells you something: Karma, Jasmine and Puppeteer together are a browser test harness. Puppeteer launches headless Chrome so the widget's client-side behaviour is actually exercised in a browser, not just typechecked. The runtime dependency list is minimal, with `lit` at version 3 as the only production dependency, which is a sensible choice for custom elements.

So the map widget you interact with in a notebook is a web component, written in TypeScript, tested against a real browser, and bundled into the wheel. The README's ipyleaflet and ipywidgets framing describes the Python side of that arrangement, not the whole of it.

Releases, Docker, and the documentation you will actually use

The most recent tagged release is v0.38.7, published on 2026-09-18, with v0.38.6 a week earlier on 2026-09-11. Reading those two notes is informative about where the effort goes. v0.38.7 is three items: defaulting the release workflow to draft releases, streamlining release documentation to a single GitHub web UI path, and suppressing new Pyrefly findings before upgrading to v1.2.0. v0.38.6 is largely dependency bumps, including enabling Pyrefly type checking in GitHub Actions.

So the recent work is typing, release tooling and dependency maintenance rather than headline features. For a package with 58 open issues and a wide surface, that is the correct allocation, and it tells you the codebase is under active typing pressure.

The Dockerfile shows how the team runs the whole thing for demos. It starts from a Jupyter base notebook image, installs geospatial system packages through conda including gdal, proj, geos, rasterio, pyproj, fiona, geopandas, rioxarray, maplibre, pmtiles and flask, sets `PROJ_LIB` and `GDAL_DATA` environment variables, then installs the package with pip and fixes permissions for the notebook user.

For actually learning the package, the documentation is at geemap.org, with an API reference, an examples page of notebooks and GIF animations, a YouTube channel, more than 360 notebook examples in a companion repository, and a workshop from the GeoPython Conference 2021. The package is also on PyPI and conda-forge, and the README asks that you cite the 2020 Journal of Open Source Software paper if you use it in research.

Editorial conclusion

geemap is worth understanding as three products wearing one name. It is an interactive mapping layer that puts Earth Engine results on an ipyleaflet map, a converter that rewrites Earth Engine JavaScript as Python, and a compatibility shim that lets you keep writing JavaScript-shaped calls like `Map.addLayer()` after you have moved to Python. The dependency list is the best documentation of its scope, running from `earthengine-api` and `ipyleaflet` through `folium` and `plotly` to optional extras for AI backends, SQL, vector and raster work. Releases at v0.38.7 in September 2026 show active work on typing rather than features. Install from conda-forge or PyPI, install `earthengine-api` alongside it, run the notebook examples in Colab or Binder, and treat the conversion module as a starting point that still needs a human reading the output.

Frequently asked questions

Official sources

1. gee-community/geemap on GitHub
2. License: MIT
3. Project website
4. README
5. Releases