The first alpha release of the forthcoming major version of LeafletJS is out.
This release marks a major modernization of the Leaflet codebase. We’ve dropped support for Internet Explorer, removed legacy methods and polyfills, adopted modern standards like Pointer Events, and now publish Leaflet as an ESM module. The global L is no longer part of the core package (though it’s still available in the bundled version leaflet-global.js for backward compatibility).
While the release doesn’t include any significant new features (not that there’s anything wrong with that), some breaking changes will be relevant to the majority of Leaflet developers:
The removal of factory methods; instead of L.Map("map"), you will directly import and instantiate the Map class with new Map("map").
Mouse and touch events have been replaced with Pointer events, making it easier to build web maps for devices with varying input methods.
Leaflet is now published as an ESM module, you can now import Leaflet components with import { Map } from "leaflet";.
There’s no timeline for the final release yet. Currently, the version milestone only has one open ticket, so this is a good time to upgrade your apps and plugins. There is the Leaflet V1 Polyfill for those who want to upgrade to Leaflet 2 but don’t want to fix breaking changes in their applications.
places.pub is an early-stage, experimental API that provides place objects compatible with ActivityPub protocols to enrich posts with location information or announce geosocial activities such as “arrived” (in other words, checking in), leaving, or travelling between places.
One important need for geosocial software is that all objects in ActivityPub, including Place objects, need to have a permanent URL as their id property, which shares the description of that object in Activity Streams 2.0 format. However, there isn’t a good dataset of geographical objects — countries, states or provinces or regions, cities, buildings, businesses, parks, streets — available in AS2 on the Web right now. That is slowing down experimentation in the Geosocial Task Force.
The API serves two functions: it enables social-networking applications to find locations and access places via unique URLs. It’s a surprisingly small application that runs on OpenStreetMap data hosted on Google Cloud Public Datasets.
Instead of sloshing the huge OSM dataset back and forth, I used the version of the data stored in the Google Cloud Public Datasets system on BigQuery. This let me ignore the effort of moving data, and just focus on giving it a good ActivityPub-compatible interface using a Google Cloud Run function.
So, who’s going to build an ActivityPub-compatible Swarm clone?
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?
I’d love to see a similar interface for generating GDAL commands; Cameron Kruse:
Tippecanoe has great documentation in its ReadMe with all the info you need to get started, but I’ve often found that half the battle is finding the commands, deciding which ones to use and stringing them together into a coherent command you can actually run in your terminal. I’ve made this a little easier by taking many of the Tippecanoe features and converting them into an interface you can use to generate your commands. The premise of this tool is you select all the options you want from the dashboard and a command is generated below you can copy and paste in your terminal.
The good folks at Heigit have released ohsome-planet, a handy tool to turn OpenStreetMap history data from PBF into GeoParquet files, ready to use in common GIS applications.
Working with raw OSM data presents several challenges due to its complex structure. Typically, users require data that is readily compatible with Geographic Information System (GIS) applications. Our new tool streamlines this process, providing a structured and GIS-ready dataset for improved usability.
The tool also enriches OSM element data by integrating information from OSM changesets and administrative boundaries. This additional contextual data allows for more efficient and straightforward spatial analysis, further improving the utility of OSM datasets.
The tool is written in Java and you have to build it yourself; a small price to pay for more easily accessible free and open data.
Apple Maps now shows the borders of Indigenous land in Australia and New Zealand.
Apple Newsroom:
Beginning today, Apple Maps now displays Indigenous lands in Australia and Aotearoa New Zealand. By gathering information from Indigenous advisors, cartographers, Traditional Owners, language holders, and community members, Apple Maps will show reserves and Indigenous Protected Areas, Indigenous place names, Traditional Country, and dual-language labels. Indigenous lands place cards feature information about the local area and Traditional Owners, and can be curated to allow communities to add their own photos, destinations on their land, and text in their own language. Representation of Indigenous lands in Apple Maps provides users with a more comprehensive experience while also recognising the stories and significance behind them.
Apple Maps will now include more than 250 dual placenames for cities and towns across the country, with more to be added.
I’m struggling to confirm this. On the latest versions of both macOS (15.3.2) and iOS (18.3.2), no traditional place names are shown instead or in addition to the English names. It’s technically feasible to show two names simultaneously for a location, as we’ve seen with Gulf-of-Mexico travesty—it just hasn’t been done.
When I search for “Naarm,” the traditional name of the Melbourne area, only “Melbourne” shows up as a match. Likewise, a search for “Gadigal” or “Cadigal” returns matches in the Sydney area, like “Gadigal Station,” but not Sydney itself.
I love a good deep dive into often-overlooked map-related challenges. Here Hanbyul Jo wonders why Mapbox chose to vertically display labels in Hangul, whether the choice improves legibility, and since when Koreans horizontally read and write Hangul instead of vertically.
Meta, one of the founding members of Overture Maps Foundation, has successfully transitioned its suite of global basemaps used across apps such as Facebook and Instagram to Overture’s base data layers
The goal was to build an up-to-date, validated, global basemap using OpenStreetMap that could power all of Meta’s use cases. Daylight included validation checks designed to find and correct mapping errors, building footprint detections, lidar derived building heights, name translations, and a global land cover layer. This global dataset was made publicly available and has served the maps at Meta for the past five years.
As a founding member of Overture, Meta has been deeply involved in developing the processes that produce Overture’s published data. In fact, the very same validation processes and pipelines that were used in Daylight are also now used to produce Overture’s regular data releases.
Notice the past tense. There is no official announcement confirming Daylight’s end of life. But there hasn’t been an update since November 2024 after more than four years of at least twice-monthly releases.
Update (30 April 2025):Daylight has indeed reached its end of life. I missed the announcement in May last year, and then again, when I was looking for an official statement while writing this post, I didn’t see the update buried in between all the data updates.
If you are a student or early-career developer and want to make your mark in open-source geospatial, the following geospatial organisations are participating in the 2024 Google Summer of Code: