Instead of using an established navigation service and handing over details about where you’re going, how about running the infrastructure required for routing and navigation on a server you control so you know where your location data is going.
That’s the idea behind Headway, a batteries-included software stack including a front-end application, basemap, geocoder and routing engine. With just a few commands, You can spin up a Headway instance on your local machine within minutes. You can build Headway using data from over 200 preconfigured metropolitan areas, a custom OpenStreetMap extract, or the whole planet.
Headway bundles many well-known open-source software, such as MapLibre for its map client, Pelias for geocoding, Valhalla for routing, Planetiler to prepare vector tiles from OpenStreetMap, and many more.
For most people, even the nerdy folks out there, running and maintaining a personal Headway instance for your navigation needs is still likely too much effort and cost. But for anyone trying to build a business that needs navigation, Headway is a fantastic starting point to make a product.
Leaflet was one of these libraries that I thought were done. While there have been constant updates and new releases throughout the years, there were rarely any massive, ground-breaking additions. Leaflet is built perfectly against its small, well-defined scope. Huge changes just weren’t necessary.
Even great software is never done because it needs to keep up with the latest technological developments. And so development of a new major release for Leaflet was announced as part of the 1.9 release notes. The work for the next major version catches up with recent developments in the browser market, the JavaScript landscape and compiler tooling:
Dropping support for Internet Explorer.
This has been a long time coming, but now that Internet Explorer is officially end-of-life, it’s time to say goodbye. Going forward, Leaflet will move to an evergreen strategy that targets browsers like Firefox, Chrome, Edge and Safari.
Embracing modern JavaScript.
To maintain backwards compatibility, Leaflet is written entirely in ES5, a version of JavaScript supported by legacy browsers. So we have not been able to make use of many great JavaScript features (e.g. standardized classes, instead having to rely on our own implementation). By adopting a more modern version of the ECMAScript standard, we can start working towards aligning Leaflet with what is expected from a modern JavaScript library.
Standardized modules.
When we released Leaflet v1, the landscape in the JavaScript world was very different and full of competing module standards such as CommonJS, AMD and UMD. Today, ECMAScript modules have become the clear way forward to unite the JavaScript ecosystem under one banner. Moving forward, Leaflet will only be distributed in a single standardized module system, greatly reducing complexity of our distributed code.
Removing the Leaflet global.
As a developer using Leaflet, the capital letter L is probably intimately familiar to you. This is the Leaflet global where all of Leaflet’s functionality lives. To allow compiler tooling to better eliminate dead-code through a process called tree-shaking, we are removing this global variable. To preserve backwards compatibility with older plugins, we will provide a shim that can be imported manually that will restore this functionality.
There’s no release date, not even an estimate, and maintenance of the 1.x branch will continue in the meantime.
What3Words isn’t fit for purpose, not for any purpose, really. The more people realise this, the better, especially the ones outside the usual geo crowd.
Felt have hired Erica Fischer and are reviving development of Tippecanoe, which hasn’t seen many updates in the last couple of years. The last release was on over two years ago.
Tippecanoe is an essential tool for geospatial-data providers. It creates vector tile sets from various geospatial formats and optimises the data for visualisation purposes, so the resulting maps allow viewers to understand the density of a data set without clustering or excluding data.
Speaking in the Felt blog, Erica hints at what might be next in store for Tippecanoe:
The special challenge of Tippecanoe at Felt is that it is being applied to user uploads with no opportunity for manual configuration, so it has to be able to make efficient, faithful, good-looking tiles without being given any hints about what kind of data it is tiling. I already know that it doesn’t currently do very well at low zoom levels with topographic contours, or with gridded data represented as individual polygons, or with continuous urban parcel polygons, or with branching systems of rivers, and I’m sure the uploads will also soon reveal other usage patterns that need to be detected and given some special treatment.
Felt will maintain Tippecanoe in a fork; Brandon Liu, of Protomaps fame, has also been working on another fork — and they are planning to unify development going forward.
Initial OGC API support has been added, allowing to expose layers specified in the Mapfile to be exposed as collections and the layer’s features as items.
MapServer, together with PostGIS, was one of the first open-source GIS libraries I used as a Geography student some 20 years ago. If my memory isn’t too clouded, MapServer was among the first open-source products to implement OGC standards. Fantastic news that it’s still under active development and keeping up with the latest developments in the industry.
Speaking of local FOSS4G events: FOSS4G:UK is scheduled for PostGIS Day, 17 November. There won’t be a single location, instead FOSS4G:UK takes place simultaneously at 10 locations across the UK.
The event is free to attend for anyone interested — organisers ask you to donate £20 to OSGeo:UK, MapAction or another charity.
In addition to local schedules, keynotes and selected sessions will be streamed to all locations, and sessions will be streamed online if you can’t attend in person.
A small FOSS4G meeting will be hosted at Vanderbilt University in Nashville, TN between 30 November and 2 December 2022. Tickets are only $25, there will also a free online stream available.
Craig Kochis has got you covered if you want to learn how to build a WebGL map application without any libraries. It’s a very detailed post that covers the basics of WebGL for maps and rendering vector tiles and also looks at different ways to make interactions like zooming feel more natural and performant.
Tim Schaub built and ran a crawler on public STAC catalogs to better understand the current adoption of the standard. A couple of figures stand out:
About a third of the catalogs are static, but API-based catalogs provide access to disproportionally more items and assets.
The vast majority of catalogs already implement STAC 1.0.0, which was only finalised in May.
Almost half of all items across all catalogs are not satellite images or other spatial data; they are additional meta represented in various formats such as JSON, XML or HTML.
Jochen Topf has published a the preliminary report on the shortcomings of OpenStreetMap’s data model. It’s a very very in-the-weeds document, providing an in-depth discussion of the current state of OSM’s data model and ways to improve and future-proof it.
The report vets the data model against the backdrop of anticipated growth of the OSM data set and its implications for data processing, it looks at the lack of a native polygon geometry type (a classic!), limitations related to mapping large objects or and those with fuzzy boundaries, its incompatibility with standard GIS software, and many others. Topf also suggests solutions addressing some of the problems, including removing untagged nodes, introducing an area type, limiting the length of tag values, changing the database management system, and offering different data formats via the API and for exports.
How many of the proposed changes will be implanted remains to be seen, Topf himself is cautious:
I am not proposing any action or, at most, minor steps. This is not because those are not important issues, but because I cannot see a clear path to any improvements. Often the goals are too vague to be actionable.
Implementing just some of the proposed changes would be if big lift, every tool interacting with the OSM data and API will be affected; every editor, every command-line script that coverts data, every export tool. It would require constant engagement with the community and strong technical leadership.