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.
Jacob Hall wrote a recap about how he mapped his campus at William & Mary:
The most rewarding part of this project was getting to engage with community members in and around campus that I otherwise would have never met.
One of the positive effects of going out and mapping an area, especially when done with such determination, is that you get to know your neighbourhood and its community in intricate detail. At the moment, there is probably no other person in the world who knows more about the William & Mary university campus than Jacob Hall.
The Guardian is hosting an interactive workshop exploring the evolution of Cartography.
[Y]ou will discover how maps, and our relationship to them, have evolved over time. You will learn how the way that a map is designed can influence the way in which it is interpreted, and why this means that even the most authoritative map may not be as objective as we think.
You will also draw on your new understanding of cartography to create your own geographic data, and will touch on how to successfully display geographic data to tell a story, and how geo data visualisation has evolved and influenced modern-day map techniques.
The event is taking place on 26 October, from 5pm to 8pm (BST), and is led by Jess Baker and Paul Naylor, both work at Ordnance Survey. It’s an online event, so you can dial in from anywhere in the world.
[MapLibre] is Amazon Location Service’s recommended map renderer and forms the basis of AWS Amplify Geo’s map display and geocoding capabilities. We’ve been excited to see the project grow since it launched in 2020 and look forward to continuing our work with the MapLibre Organization.
MapboxGL’s license change happened in December 2020. Amazon’s location services debuted only a few days later. MapLibre was forked from MapboxGL after the license change. Is anyone still wondering why Mapbox changed the license for Mapbox GL?
I only occasionally contribute to OpenStreetMap, mainly from the comfort of my desk and rarely on the go. I almost exclusively add and edit Points of Interest when I’m out. I used Go Map!! before, but it didn’t stick. In dense areas like central London, too many features are displayed in the editor. You see points for traffic lights, intersections, crossings, bins, and shops – all at once. Understanding what features exist or need to be added often requires clicking individual points to identify what they are.
Every Door is a new mobile OpenStreetMap editor, built by Ilja Zverev and available for iOS and Android. And it takes a different approach to edit OSM on a mobile phone.
Every Door focuses on fewer things at a time. You edit amenities, street furniture or building entrances and house numbers — but never all at the same time. You pick one group, see what’s already mapped around you and can only edit and add the same feature types. And instead of showing you all of the existing features in the current map view, it downloads just a few closest to your current location. Every Door nicely caters to the way many mappers edit OpenStreetMap. They focus on one goal at a time, say to map all the rubbish bins in a park, and then just work on that until they’re done. And they map the objects closest in proximity.
Every Door shows only a small number of OpenStreetMap data in close proximity available for editing.
A few well-designed features make editing points of interest a breeze. Entering opening hours is a pain in iD, but it’s straightforward in Every Door thanks to a neat interface to select days and times, which doesn’t require composing a long string, hoping it matches the pattern OSM expects. Every Door also caches selected tags for feature types so I can quickly whizz through a park and map all benches that look the same and share the same attributes. All it takes is a brief stop next to one to get a decent GPS signal.
The interface could be more polished, and some interactions aren’t intuitive. But Every Door is a cross-OS app built by one person, presumably in their spare time. I won’t expect this to look like a boutique iOS app that costs 75$ a year. Every Door is a nice app, which takes away much of the complexity of editing OpenStreetMap on the go.
Just in time for FOSS4G next week and the annual OpenLayers Feature Frenzy, the OpenLayers team has released 7.0.0, a new major version. Over 90 pull requests went into this release, but two changes stand out: Internet Explorer is no longer supported. And WebGL rendering has been extended to support lines and polygons alongside points.
A renderer converts geo-data into data structures that browsers can render. In the past, OpenLayers has primarily relied on the Canvas API to render vector data. Compared to Canvas, WebGL is considered more performant, especially when visualising complex geometries or large datasets.
Adding more WebGL-rendering capabilities to OpenLayers has been an ongoing effort in the last few years, and there’s more to come:
The rendering API is still low level and experimental. Future releases will include a higher level styling API.
Technically this is a breaking change, but upgrading should be straightforward, according to the release notes:
[W]e changed the signature for a number of methods on a helper class that had been marked as part of the API in 6.x releases. While this is technically a breaking change, it is unlikely that applications were using this helper class, so upgrades should be straightforward.
Chartographer [is] a visualization tool that breaks down different stylesheet properties by layer and zoom level for easy analysis and debugging. Now instead of panning and zooming around the map to find and identify issues, or scrolling through thousands of lines of JSON looking for mismatched zoom numbers, you can visualize how layers are styled at all zoom levels in a single view.
Chartographer looks like a handy tool if you’re hand-crafting map stylesheets.
I somehow missed this: Bertin.js has reached a significant milestone with its 1.0 release.
A world map produced with Bertin.js. Screenshot from @neocartocnrs.
Bertin.js is a JavaScript library that simplifies creating static thematic maps in SVG, primarily for print, online publications or presentations. You can certainly add a level of interactivity, but Bertin.js isn’t designed to replace, or compete with, interactive-mapping libraries like Leaflet, OpenLayers, or MaplibreGL.
Bertin.js provides a comprehensive API to make thematic maps using classification, cartograms and tooling to add map components, such as titles, footers, legends, or graticules. It is a wrapper around D3’s powerful mapping capabilities, providing reasonable defaults so you can focus on designing your map and don’t have sweat intricate details such as creating a legend and specifying individual pixel coordinates to perfectly align symbols and labels.
