August 2026
Zarrista is a new Python library for working with Zarr data. Implemented in Rust, it delivers significant performance improvements over Zarr-Python, the go-to library for handling Zarr data in Python. Work is currently ongoing to integrate Zarrista into Zarr-Python to bring those benefits to the wider Python community.
to avoid fracturing the ecosystem, we plan to integrate Zarrista as a native backend into Zarr-Python.
We hope that a Zarrista backend for Zarr-Python can deliver these performance improvements without any need for end users to change their code. Follow Zarr-Python PR #4064, which uses Zarrista to prototype generic backends for Zarr-Python.
Under the hood, Zarrista uses the Rust Zarr library Zarrs; Zarrista itself only introduces a thin layer between Zarr-Python and Zarrs, adding almost no Zarr-specific functionality.
Zarrista is built as a “dumb, direct” binding to Zarrs, the Rust Zarr library. Zarrista exposes as many APIs as possible from Zarrs, while avoiding creating its own APIs from scratch.
This means that Zarrista’s source code contains no Zarr-specific logic at all. All Zarr-specific logic is either lower-level in Zarrs or higher-level in Zarr-Python. This keeps Zarrista itself maintainable and means that any improvements can be submitted to Zarrs directly, which benefit both Rust and Python users.
The performance gains are handsome: according to the benchmarks, there’s a 1.9× to 2.7× boost compared to Zarr-Python when reading local data.
I recently covered the Geoviz library, a thematic-mapping JavaScript library based on D3. For those who prefer to do their data visualisation in R, there’s Geovizr, so you can make maps in R.
geovizr is an R package for thematic mapping. It’s an R wrapper around the geoviz JavaScript library, itself based on the d3.js ecosystem. Like the original JavaScript library, the package can be used to create a wide range of interactive, zoomable vector maps, taking advantage of d3’s many features: proportional symbols, pictograms, typologies, choropleth maps, spikes, tiles, Dorling cartograms, etc. It can also be used to create pretty static vectorial maps in SVG format, suitable for editorial cartography.
Raphael Hagen and Shane Loeffler outline a complete guide to visualising NetCDF data on a web map without precompiling tile sets.
Their approach uses VirtualiZarr to create virtual Zarr references stored in Icechunk; icechunk-js, a JavaScript library to read Icechunk data; and zarr-layer, which renders Zarr data on MapboxGL or MapLibreGL maps.
Many small, single-purpose open-source libraries working together here — the way it should be. The result is surprisingly performant, considering everything is rendered on the fly, read directly from NetCDF.
With a new approach to transforming geometries, ohsome-planet now transforms OpenStreetMap data from PBF to GeoParquet faster and without relation-size constraints.
This release presents a complete rework of our approach to assemble geometries for complex mutlipolygon [sic] relations. Our new approach tackles two challenges at the same time. First, processing performance was a bottleneck for relations with a very high number of members. As a consequence we had to limit geometry building to relations with a fixed member count, e.g. below 600. Although most relations in OSM have fewer members, there are still enough common cases, such as country boundaries and lakes, that we weren’t able generate in previous versions. Second, the correct handling of invalid geometries and edge cases made processing even slower.
With our new geometry assembler, we can process the global OSM planet history file about 10x faster than before. You will notice this speed-up effect also for smaller regional extracts. On a Lenovo ThinkPad P14s Gen 5 with Intel® Core™ Ultra 7 165H × 22 and 64GB RAM transforming Germany latest pbf into Parquet took just 27 minutes.
Impressive update from the folks at HeiGIT.
In rather unsurprising news, Google has added new AI-driven functionality to Google Maps; this time, it’s an agentic assistant for Ask Maps, allowing users to order food or find and book hotels.
Aisha Malik, Techcrunch:
With the new agentic food-ordering capabilities, users can open Ask Maps in Google Maps and ask a question like, “Where can I order vegan avocado toast and an oat milk latte near home?” The tool will then surface nearby restaurants that have what they’re looking for.
After selecting a restaurant, users can tap the “Order online” option to place an order through supported platforms such as Square, Toast, or Uber Eats. Ask Maps will add the items to a cart. Users can choose to add more items to their cart, then pay for the order on the supported platform.
This might be a really bad example, or I’m just old-fashioned, but who uses Google Maps for these things? I’m sure most people have one or two favourite coffee shops in their neighbourhood so they know where to get their latte. Do coffee shops even do deliveries? And ordering avocado toast? Who looks forward to brownish avocado on soggy toast after it’s been roaming around for thirty minutes because the driver first has to drop two McDonald’s breakfasts five blocks away?
Additionally, users can use Ask Maps to find a hotel for their next trip by entering a query like, “For next weekend’s conference in downtown Miami, find me a decently priced, top-rated hotel with an artsy vibe within walking distance from a gym and restaurants.” Ask Maps will then compare prices and check availability before providing a list of options. Once users find an option they like, they can click through to the partner’s website to book the stay.
A more relatable use case, but does it actually make finding and booking a hotel easier? A real selling point would be an agent that finds and books the hotel mostly autonomously. The example process isn’t that much simpler than starting with “hotels in downtown Miami.” Sure, it narrows the search by vibe and proximity to amenities, but I still have to sift through results, weed out promoted content, and book the hotel myself.
I’m struggling to see the appeal of replacing working functionality with AI agents, especially when there are no clear benefits. But it’s the industry’s current imperative, useful or not.
Curated by Will Cadell:
A curated, tracked list of Model Context Protocol (MCP) servers for geospatial, GIS, mapping, and earth-observation work — geocoding, routing, PostGIS, STAC/imagery, QGIS/ArcGIS, weather, and the commercial location platforms.
The list currently includes 55 MCP servers and a Claude skill, which recommends appropriate servers and can add new ones.
Update (12 Aug 2026): The list now includes 77 MCP servers.
140 session recordings from this year’s FOSS4G Europe are available on Youtube and OSGeo’s PeerTube.
STAC makes it possible to find geospatial data if you already know what data exists and where to source it from. It’s like the search function on a website. What we’re missing is a search engine that supports pure discovery, finding not just data but also the data sources.
MAAP’s STAC Collection discovery aims to fill this gap. A thin API layer sits between STAC catalogues and a search client. Search queries are routed to a predefined set of STAC catalogues, and individual responses are bundled and returned to the client in one response.
Henry Rodman:
The underlying technology is intentionally simple. Rather than maintaining its own copy of collection metadata, stac-fastapi-collection-discovery forwards each search request to a configurable set of upstream STAC APIs, combines the responses, and returns the results directly to the user. Because the service remains stateless, results always reflect the current state of the upstream catalogs without requiring synchronization or scheduled indexing. The searches are idempotent and are performed in parallel so requests can be processed very quickly.
The service also inspects each upstream STAC API to determine which search capabilities are supported, allowing it to expose only the parameters that are common across the selected catalogs.
The underlying technology is open source so you can roll your own multi-catalogue search. stac-fastapi-collection-discovery implements a STAC-API-compliant API for searching across catalogues; this is the backend. STAC Collection Discovery is the corresponding front-end for exploring search results.
Enough has been said about the botched rollout and subsequent reversal of a generative-AI feature in Google Earth. I’m wondering why this keeps happening: rushed AI rollouts with no one questioning whether they are a good idea in the first place.
Ed Parsons:
We are living through a corporate panic. In boardrooms across Silicon Valley, leadership is terrorized by the prospect of being left behind in the generative AI gold rush. The mandate from the top has devolved into a blunt directive: Add AI to everything, everywhere, immediately. I felt this at the end of my time at Google I can only imagine how much stronger this has become…
It doesn’t matter if the product calls for it. It doesn’t matter if the product’s entire historical equity is built on being an objective record of reality. If a product doesn’t have a generative text-to-image prompt box slapped onto it, senior leadership panics.
In their haste to check an AI box, the architects of this feature completely lost sight of what makes Google Earth valuable. Google Earth is not a canvas for creative writing; it is a reference library. You don’t want an AI “interpreting” or “reimagining” a map any more than you want an AI to creatively hallucinate your bank statement.
Google prides itself on hiring only the smartest talent, to the point that if you don’t have a big-name university or former employer on your CV, it’s likely not going to be looked at. Someone comes up with the idea; fine, we all have silly ideas sometimes. But all these smart people you’ve assembled think it’s a good idea to slap generative AI features on everything without guardrails? Or someone did speak up and wasn’t heard? Or nobody spoke up for fear of repercussions?
Trends have come and gone. Once decision-makers realise how much money they wasted on useless features, this current trend to add AI features everywhere will pass too. What is different from previous trends is that some AI features can be used to produce dangerous results, and a lot of damage will be done before the current craze has passed.