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.
Following last week’s post explaining the tile-addressing schema in PMTiles version 3, Brandon Liu now discusses its compression approach reducing the disk space required to store a global tile dataset to only 91.6 MB.
Update: Brandon clarified on Twitter, the 91.6 MB mentioned above only holds the data required to map Z,X,Y coordinates to the corresponding Tile ID. The actual global map data set is 80GB. (15 August 2022)
Kyle Barron demonstrates how to use deck.gl to render data in GeoArrow format, starting with a GeoJSON dataset of one million building footprints in Utah.
We’ve been able to make web maps with GeoJSON data for some time now, and converting GeoJSON to GeoArrow and preparing the data for deck.gl requires extra development work, so why would you want to use GeoArrow? The short answer: It’s incredibly fast.
GeoArrow overlaps almost exactly with the format that deck.gl expects! So deck.gl can render from GeoArrow’s physical representation very efficiently. For point and linestring geometry types, the underlying coordinates array can essentially be copied directly to the GPU with no CPU processing required. For polygon geometries, only polygon tessellation still needs to happen on the CPU.
We’re looking at the not-so-distant future of web mapping here, when we can render millions of features onto a web map without a noticeable impact on performance.
A new version of MapLibre was released just yesterday. Release 2.2.0 is a minor version in semantic-versioning speak, but it adds a major feature: 3D terrain maps, enabling developers to visualise the topography of land surfaces in interactive maps on the Web.
Mapbox introduced a similar feature to Mapbox GL 2.0.0, the first of the library’s releases after moving away from an open-source license. MapLibre is a fork of Mapbox GL that was created to preserve and continue the work under an open-source license. Thanks to the efforts of MapLibre maintainers, developers can now build interactive 3D maps for the Web using open-source technology.
I’ve played around with a small example based on an example by Oliver Wipfli, and the results look really slick. Some minor issues still exist, for example, the hill shade disappearing when you tilt the map close to a horizontal view.
MapLibre's 3D terrain in action; also demonstrating smaller issues when tilting the map close to a horizontal view.
It’s great to see the project under such active development. Mapbox has paved the way for modern web mapping with vector tiles, but it’s good to have more competition in the space — even better when the competition is open-source.
PMTiles version 3 introduces a new tile-addressing schema. Instead of using Z,X,Y tile coordinates, the new schema uses tile IDs based on the tile’s position within a series of Hilbert curves:
The TileId 36052 corresponds to the Z,X,Y position of 8,40,87. The calculation of ID uses a pyramid of Hilbert curves starting at TileId=0 for zoom level 0. The next zoom level, a 2x2 square, occupies the next four IDs in the ID space TileId=(1,2,3,4), the next level being the next 16 IDs, and so on.
And to not duplicate tiles that contain virtually no information (for example, tiles just showing water) the RunLength indicates how many times a tile will be repeated within the Hilbert curve, so vast areas of the ocean can be represented with just one tile.
Ocean tiles are not only repetitive, but sparse and often contiguous in Hilbert space. This entry:
means that the 44 byte vector tile with a single square in the layer ocean is repeated over 100,000 times, starting at Z,X,Y=11,285,1311 and ending at 11,19,1304.
Neat.
Update: A new post outlines the disk layout and compression approach of PMTiles version 3. (15 August 2022)
Outreachy is an internship program designed for young people to make their first mark in open-source software development, specifically people from underrepresented groups in the tech industry. (So, if you’re a European white dude, you don’t need to apply.) The internships come with a $7,000 stipend for three months and are fully remote.
The mentoring projects for the next round will only be announced at the end of September. Still, it usually includes projects with a data-collection and data-management focus, some with a geospatial element. The most recently completed round included interns at Ushahidi and ODK-X.
The program is an excellent opportunity to get into open source and add a fantastic project to your portfolio. I’ve mentored Outreachy interns before, and some went to build successful careers at big names such as RedHat and Google. (Obviously, because my former mentees are smart and driven software engineers and not because I’m a particularly great mentor.)
We have a new advanced filter feature available in ohsome dashboard. Now you can globally analyze arbitrary combinations of tags and geometry types over the history of OSM.
The Ohsome Dashboard lets you explore the history of OpenStreetMap by looking at arbitrary combinations of tags, OSM object types, periods of time, and areas of interest. Using a more practical description, you see how the length of all ways tagged with highway=primary has developed over the last five years and compare those numbers between Germany, France, and the UK.
Ohsome showing changes of length of primary highways on OpenStreetMap in Germany, France, and the UK.
Amazingly, these results can be produced on the fly. Sure it takes a minute or two to compute, but we’re dealing with vast amounts of data here. The data-exploration products from HeiGIT and the GIScience group at Heidelberg University have come a long way in the last ten years. OSMatrix, which we first released in 2012, was nice to look at, but it wasn’t nearly as helpful in exploring OpenStreetMap’s vast dataset. All of OSMatrix’s data was precomputed into hexagonal bins, and comparisons were only possible for a tiny area.
Django 4.1 brings two new features for handling geographic geometries; allowing developers to create valid and canonical geometries more easily:
GEOSGeometry.make_valid() returns a valid representation of a geometry. Unless the geometry is already valid, then the geometry is returned without changes. The function is very similar to ST_MakeValid in PostGIS.
GEOSGeometry.normalize() returns the canonical, or standardised, representation of a geometry. The method now accepts the optional clone keyword indicating that the normalisation must not change the geometry and instead return a new geometry object.
Additionally, support for GDAL 2.1 and PostGIS 2.4 has been removed, and the Django Admin’s OpenLayersWidget is now deprecated.
Check the release notes for all other changes in Django 4.1.
There’s not a lot of geo content in this episode. Instead, it’s a trip down Memory Lane with James and Ed reminiscing about the good old days of blogging. That time during the mid-noughties when people were writing blogs, linking and discussing each other’s work — and before everyone went to Twitter to complain. I’ve been feeling a bit nostalgic recently about that time, so this episode hit a spot.
Good content is still out there, except everything is now hidden away on Substack or Medium, and even indy sites rarely publicise RSS feeds. Flashy images, memes and hot takes create clicks, so well-written 500-word stories aren’t widely shared. It’s one of the main reasons I started this blog. I want it to be a place to share content, cool projects, and long-form writing beyond three 280-character blocks of words topped off with a meme.
Kyle Onda with a concise overview of file-based and web-API vector data formats. The post looks specifically at the applicability of sharing water data, but the conclusions can easily be transferred to other domains.
