Feature request: first-class support for Polars-ST and polars-h3 in leafmap

[3SMMZRjWgS]

Description

I’d like to propose first‑class support for Polars‑based geospatial workflows in leafmap, specifically:

• Polars‑ST (or equivalent Polars‑native spatial extensions)
• polars‑h3 (Polars‑native H3 indexing/traversal)

Motivation / outcome

Right now leafmap is effectively GeoPandas‑first. In many modern pipelines, especially large geospatial / climate workflows, we do most of the heavy lifting in Polars:

• use Polars‑ST (or similar) to store geometry and CRS in Arrow/Polars columns,
• use polars‑h3 to generate and traverse H3 indices in a Polars DataFrame,
• write/read GeoParquet / Parquet on disk.

To visualize these data in leafmap we currently have to:

1. Convert Polars‑ST → GeoPandas GeoDataFrame, or
2. Materialize intermediate GeoJSON files and let leafmap/GeoPandas re‑read them.

The feature request is to let leafmap treat Polars spatial DataFrames as first‑class vector inputs, so a typical pipeline could:

• stay Polars‑native end‑to‑end for ETL, joins, and H3 operations, and
• only adapt at the very last step (e.g. internal conversion to GeoPandas or GeoJSON inside leafmap), instead of every user having to write their own conversion glue.

Concretely, this could look like:

• A new helper such as:

  m.add_polars(df, geometry="geometry", crs="EPSG:4326", **style_kwargs)

  that:

  • accepts a Polars / Polars‑ST DataFrame,
  • internally converts to whatever leafmap needs today (GeoPandas or GeoJSON),
  • preserves geometry and CRS semantics, and
  • works for both regular vector data and H3‑indexed layers (e.g., using a h3_id column created by polars‑h3).

• Or: extending add_vector / add_gdf to recognize Polars‑ST objects and handle them automatically.

The expected outcome:

• Users with Polars‑first pipelines can visualize data in leafmap without writing their own Polars → GeoPandas conversion code for each project.
• Leafmap becomes a natural visualization frontend for Polars‑/Arrow‑native geospatial stacks (Polars‑ST + polars‑h3), which are increasingly common in high‑volume geospatial analytics.

I’m not asking to drop GeoPandas at all—just to make it possible for leafmap to accept Polars‑based spatial DataFrames as inputs in a supported way, even if internally you still go through GeoPandas or GeoJSON for the map backends.

[giswqs]

Good suggestion. It might take a while before I can get to this. Contributions are welcome.