August 2026
Open-source spatial-data editor Placemark has switched from Mapbox GL JS to MapLibre GL JS. All of Placemark’s dependencies are properly licensed as open source.
Tom MacWright, creator of Placemark:
This meant swapping out both the Mapbox frontend code as well as switching to a different tile service - we’re now using OpenFreeMap for tiles, OpenMapTiles-based styles, openrouteservice for the routing drawing mode, and MapTiler for the satellite layer. Forks of Placemark no longer require a Mapbox API token to work, but they do require a MapTiler token to support Satellite tiles, and an openrouteservice token to do route-drawing.
The big upside here is that this makes Placemark cleanly open source: all of its dependencies have proper open source licenses like MIT, ISC, Apache-2.0, BSD-3-Clause, or similar[2]. Mapbox GL’s license is not open source and requires the developer to have a Mapbox account and follow their Terms of Service. So: you can now fork Placemark and build cleanly-licensed open source applications on its codebase. I recommend it!
Put together by Max Lenormand, this visual explainer of the Zarr format shows how Zarr uses chunks and shards to make accessing large geospatial data cubes actually performant.
GPS is notoriously imprecise in some environments, like dense urban areas or beneath tree canopy. In a recent announcement, Google said it improved the quality of the GPS signal on its Pixel Watch 5 using 3D data from Google Maps and an AI-driven process.
Lindsey Lanquist, Google:
Thanks to Google Maps, they had three-dimensional models of buildings around the world. And the team paired that data with AI to cut down on errors caused by the GPS signal bouncing off buildings. “You need to know where all the buildings are,” Frank says. “But you also need really good AI to do it right.”
Unfortunately, the announcement is a pure marketing fluff piece with little substance. Lanquist doesn’t disclose any details about the method beyond using Google Maps data and something something AI in the process. The maps in the post show a more precise GPS track compared to the Pixel Watch 4. Despite claiming that the Pixel Watch 5 outperforms the Apple Watch Ultra 3 and Garmin Fenix 8 Pro, Google fails to provide statistical evidence.
Mehul Solanki, Sparkgeo:
Can You Run a Vector Tile Server on AWS Lambda Without PostGIS?
The quick answer is yes, and here is how we did it. Serving vector map tiles are typically associated with long-running servers like PostGIS, pg_tileserv, Martin, or a full GeoServer stack that can result in high monthly costs. We took a different approach to keep the Canadian Institute of Forestry (CIF) API lightweight and low cost: a serverless vector tile server running on AWS Lambda, backed by SQLite and SpatiaLite.
The post has a lot of details about the setup, but the gist is this: an SQLite database is just a file, so you can bundle it in a Docker image that serves as the base image for the Lambda function. The API and the data behind the API live in the same container.
When your data never changes, running a database server to make that data available is indeed costly. Usually, you’d pre-render the tiles and serve them from a low-cost object store. But it’s hard, if not impossible, to run filtered queries, aggregations, or exports to other data formats from pre-rendered vector tiles, so a self-contained SQLite database is the fit-for-purpose middle ground.
Popular GeoJSON editor geojson.io received a major update, including an overhaul of the application architecture, based on Placemark Play.
Andrew Sepic, Mapbox:
geojson.io’s core had aged in place for a while. Under the hood, it had already been through one generation of map tech — originally built on Leaflet-based Mapbox.js library, then refactored to Mapbox GL JS and Mapbox GL Draw in 2022 — but the application itself never changed alongside it. The UI was built entirely with D3, using its selection and data-join API as a general application-construction tool rather than for what it’s best known for: data visualization. D3 has no built-in component model or state management, so anything beyond simple DOM bindings meant hand-rolling patterns a modern framework gives you for free.
Rather than start from the ground up, we forked Placemark Play — an open-source geojson editor, also built by Tom MacWright, with an editing model designed from the start around multiselect and structured data editing — and adapted it into geojson.io’s new foundation.
This new version looks and feels good. The update adds a ton of new features, like multi select and bulk editing, editing history with undo/redo, style editing and custom base maps. Most of these new features go way beyond what I usually use geojson.io for: To create simple test data when I needed it, or to quickly preview a GeoJSON file. With these changes, geojson.io is shaping up to be a tool for serious spatial-data editing.
Published yesterday in The Journal of Open Source Software: “JupyterGIS: A Collaborative GIS Environment for JupyterLab”
JupyterGIS is a JupyterLab (Kluyver et al., 2018) extension that enables web-based Geographic Information System (GIS) workflows. It provides a familiar GIS interface inspired by traditional desktop GIS tools, real-time collaborative editing, and a Python API for programmatic control, making it a powerful tool for geospatial data analysis and visualization. JupyterGIS supports a wide range of geospatial data formats, including GeoTIFFs and Cloud-Optimized GeoTIFFs, Shapefile, GeoParquet, and PMTiles, and provides advanced features such as symbology editing, spatio-temporal animations, and a browser-based processing toolbox powered by WebAssembly (WASM) builds of GDAL (Rouault et al., 2026).
Why a paper for a piece of software, you might ask, especially when it’s only a couple of short paragraphs? The Journal of Open Source Software aims to make research software a credible academic output and to provide peer review of the software’s quality. It gives researchers a resource they can cite in academic publications, and peer review ensures that the software is functional and adheres to open-source principles. This is particularly important because it allows other researchers to reproduce results from the cited software.
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.
