The SparkGeo team has tested Lovable and asked it to create a simple interactive map showing Canadian cities and their population.
results weren’t always consistent. Running the same prompt twice sometimes yielded drastically different outcomes: one time clean and functional, the next time oddly styled or partially broken. In one case, even after explicitly stating not to use any frameworks, Lovable still generated a React-based implementation. A quick follow-up prompt corrected this, and to its credit, the revised output was clean, readable vanilla JavaScript.
That responsiveness is promising, but also highlights an important caveat: some knowledge of development (especially in geospatial UI) is still necessary. Without it, spotting issues or debugging quirks could become a frustrating barrier. Lovable gets you 80% of the way there, but that final 20% – the part where accuracy, accessibility, and usability matter most, still depends on human expertise.
Even for simple applications, you need a knowledgeable engineer to create a finished product. This is fine if you treat generative AI assistants as a tool, not the solution.
But an important question lingers. While engineers rely more and more on generative AI to build applications, they spend less time understanding the concepts and libraries they’re working with, making mistakes and gaining experience allowing them to understand and improve the code they write. By extension, engineers never learn enough about the technology they’re putting to work, maybe even unlearn some of the things they know now. If that turns out to be the case, who will maintain applications largely built with AI in the future?
react-google-maps is a library containing React components and hooks for building Google Maps user interfaces. It includes components to render maps, customisable markers, info windows and control panels. The hooks allow developers to access underlying object instances, such as the Map object, or to load additional APIs, like the geocoding or direction services. If you work in React and use the Google Maps JavaScript API, this library will save you a couple lines.
Python library Lonboard promises super fast visualisation of huge geospatial datasets in Jupyter notebooks. The demo renders over three million data points in under three seconds; a load that brings other libraries to their knees.
We’re sharing lonboard, a new python library, to fill this need. On a dataset with 3 million points, ipyleaflet crashed after 3.5 minutes, pydeck crashed after 2.5 minutes, but lonboard successfully rendered in 2.5 seconds.
Impressive speed, all without clustering or downscaling the data. Lonboard renderes exactly the amount of features that it finds in the data set. How is this possible you ask? Lonboard employs efficient binary data encodings, as opposed to more traditional text-based formats like GeoJSON:
Lonboard is so fast because it moves data from Python to JavaScript (in your browser) and then from JavaScript to your Graphics Processing Unit (GPU) more efficiently than ever before. Other Python libraries for interactive maps encode data as GeoJSON to copy from Python to the browser. GeoJSON is extremely slow to read and write, resulting in a very large data file that must be copied to the browser.
With lonboard, the entire pipeline is binary. In Python, GeoPandas to GeoArrow to GeoParquet avoids a text encoding like GeoJSON, resulting in a compressed binary buffer that can be efficiently copied to the browser. In JavaScript, GeoParquet to GeoArrow offers efficient decoding (in WebAssembly). Then deck.gl can interpret the raw binary buffers of the GeoArrow table directly without any parsing (thanks to @geoarrow/deck.gl-layers).
The 8.0 release brings several API simplifications. Some of them are not backwards compatible, so make sure to read the upgrade notes. The new StadiaMaps source replaces the Stamen source, because Stamen no longer hosts map tiles. Several WebGL improvements are also part of this release. And finally, a new loader API for image layers makes working with non-tiled raster data more modular and faster.
My colleagues at Development Seed have released eoAPI:
Say hello 👋 to eoAPI, a cloud-native backend for standing up a modern, open geospatial data infrastructure. Built around the STAC specification, eoAPI makes massive earth observation (EO) data archives discoverable and interoperable. EO data is accessible through open community standards for data discovery, allowing your data to connect seamlessly to scientific notebooks, AI pipelines, and dashboard interfaces.
eoAPI bundles open-source software into a package, which simplifies standing up modern geospatial data infrastructure to aid discovery and visualisation of geospatial vector and raster data and make it available through open standards:
pg-STAC is an optimized Postgres schema to index and search large-scale STAC collections.
stac-fastapi is an Open Geospatial Consortium (OGC) Features API compliant FastAPI application for STAC metadata search.
titiler-pgSTAC is a TiTiler extension that connects to pgSTAC to support large-scale dynamic mosaic tiling for visualizing STAC collections and items.
tipg is an Open Geospatial Consortium (OGC) Features and Tiles API for vector datasets.
Getting started is easy with infrastructure-as-code templates allowing you to deploy eoAPI with opinionated but reasonable defaults:
eoapi-cdk - A set of AWS CDK constructs to deploy eoAPI services.
eoapi-template - An AWS CDK app that shows how to configure the eoapi-cdk constructs.
eoapi-k8s - IaC and Helm charts for deploying eoAPI services on AWS and GCP.
The softwares is available open-source and free under the permissive MIT licence.
Mapbox GL marked a paradigm shift in web mapping; away from pre-rendered tiled raster maps towards more dynamic vector maps rendered in the client.
Konstantin Käfer looks back at the early days of Mapbox GL:
Luckily, the time was right for a new approach. Several things fell into place that enabled the creation of Mapbox GL:
We had just developed the Mapbox Vector Tile format, enabling efficient delivery of small chunks of geodata to the client. Over the past decade, this format has become tremendously successful and is now an industry standard that is used across the entire geospatial community.
WebGL was becoming widely available, having been standardized just two years earlier.
Mapbox GL was a game-changer. Too bad they decided to switch to a proprietary license.
This has been lurking in my feed reader for a while, but it’s still worth sharing: Google offers a new set of Web Components to compose and add basic maps applications to websites, removing the need to write extensive JavaScript.
The basic example shows how to add a map with a marker to a website:
More interactive maps can be built with auxiliary components for buttons, layout and overlays.
This is a positive development: Web Components allow developers to add basic map functionality to websites without resorting to additional frameworks with potentially heavy footprints. I’d like to see more proposals like this.
Open-source alternatives are available (for OpenLayers) or have not seen significant development in recent years (for Leaflet).
Initially we turned to Mapbox, an established leader for generating and publishing online maps. But when we embedded a map from Mapbox on our staging website, we found it assigned a tracker that could not be disabled without violating Mapbox’s terms of service.
They ultimately settled for MapTiler in combination with MapLibre. Go open source!
A new major release is available of the open-source WebGL mapping framework MapLibre GL.
This release is a big step for MapLibre GL JS! With more than 500 commits, and almost a year in the making, version 3.0.0 is surely our best release yet.
Notable changes include:
The release completes the transition to WebGL2, bringing better interoperability with other WebGL2-based frameworks and better performance through parallelisation,
transformCameraUpdate provides a hook that allows you to manipulate the map’s camera state, ideal for use with reactive front-end frameworks where the camera-state properties are stored externally,
Better, continuous interpolations when using HCL interpolations via interpolate-hcl,
Several improvements to stabilise 3D terrain display.
Several performance improvements make MapLibre generally faster.
VersaTiles is a set of open-source applications that form a complete stack to create, host, and visualise OpenStreetMap data on the Web using vector tiles.
From the VersaTiles website:
VersaTiles lets you use OpenStreetMap based vector tiles, without any restrictions, locked-in paid services or attribution requirements beyond OpenStreetMap. You can use the freely downloadable tilesets from VersaTiles on your own infrastrure, in any way you like. Our open spec, royalty free and permissively licensed conatainer format works with virtually any webserver or CDN — with no requirement to pay unreasonable prices for “Tiles-as-a-Service”.
It includes a tile generator, based on TileMaker that produces tiles in the Shortbread schema. A converter produces tiles in the custom *.versatiles format from MBTiles. The VersaTiles format results on a smaller footprint—compared to MBTiles—and it doesn’t use SQLite under the hood. That means you can host it pretty much anywhere, either using the VersaTiles server or on a CDN; and clients can utilise HTTP range requests to access a subset of the data. The front-end is based on MapLibre, and includes map styles and a range of open-source fonts.