The data was created from high-resolution satellite images, using machine learning. As such, it only contains only the building geometry, data that can be derived from the building footprint (centroid, area, it the Plus code), and the level of confidence in the mapping. However, no further information about a building are available, like its height, building type, or address.
You can download the data in CSV format, one file per S2 level 4 cell, with the building polygons in WKT. Other common geospatial formats are not available and additional processing and data ingestion may be required for many use cases.
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.
On April 25, with the help of 47 contributors and 2,790 commits, the STAC API specification reached its 1.0.0 version release. With this release, the STAC API specification is fully aligned with OGC API - Features Version 1.0 standard and the project aims to maintain alignment with OGC standards as they mature.
Following this milestone for STAC, the community is now working to align STAC extensions with the API spec so each of the extensions reaches 1.0 at some point.
A comprehensive overview of the current statuses of these extensions can be accessed at stac-api-extensions.github.io. At the time of writing this blog post, none of the extensions have reached the 1.0.0 milestone yet. However, no significant changes are expected for the Fields, Sort, Transaction, Filter, and Query extensions, and they are anticipated to attain the 1.0.0 status in the near future.
Kyle Barron muses different approaches for bringing high-performance geometry libraries written in C/C++ and Rust to the to the Web, using WebAssembly.
It’s my belief that for any project beyond a certain complexity, there should only be three core implementations:
One in C/C++ because C/C++ is today’s de-facto performance-critical language, and it can bind to almost any other language.
One in Rust because removing memory errors brings so much potential and Rust’s ergonomics bring impressive development velocity to low-level code. I believe it’s tomorrow’s performance-critical language.
One in Java because the Java Virtual Machine makes it hard to interface with external C libraries (and it’s yesterday’s performance-critical language?).
The best code is the code that is never written, or so that say. Turf has served my modest needs well in the past, but something as fundamental as geometry operations doesn’t need to be rewritten if we have battle-tested libraries in other languages that we can bind with WebAssembly yielding similar, often better, performance. The JavaScript world has a weird habit of reinventing the wheel, solving the same problems with slightly different approaches. We end up with lots and lots of software that basically does the same thing—having fewer, but more stable options, would be a good thing.
A huge list of geo people and organisations on Mastodon, manually curated by Florian Ledermann. Comes with a handy export tool so you can bulk-follow everyone.
If you have projects that still use OpenStreetMap map tiles with the deprecated URL schema i.e., {a,b,c}.tiles.openstreetmap.org, do upgrade to the newer schema.
tile.openstreetmap.org supports HTTP/2 and HTTP/3 which no longer require the old (a|b|c) aliases to increase browser connection concurrency. Using a single URL improves performance and ability to cache.
It will make your app faster and lowers the burden on maintainers.
Forty-eight recordings of talks from this year’s State of the Map France are available on Peertube. Unfortunately, I can barely order a beer in French, so I won’t be able to recommend any talks.
If you’re working with STAC or want to learn about it, consider following the STAC Google Group for regular news and invitations to join community meetings.
The technical how-to describes how you can use AWS Athena to query OpenStreetMap data from Parquet files on S3. Athena is an analysis layer sitting on top of data source to simplify data access for application such as machine-learning tools or data dashboards. Using analysis-ready OSM data removes storage- and computation-heavy steps to obtain and convert the data into the desired format from the processing pipeline. The example use data from the Daylight Map, which is available from AWS’ Open Data Registry.
Where can you get within 40 minutes from every subway station in New York? Chris Whong’s fun, interactive map shows you, using GTFS data from New York’s Metropolitan Transportation Authority and Turf.js to calculate the isochrones.
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.
One thought about the OGC Tiles API lives rent-free in my head. We’ve had working de facto standards for years. Google Maps introduced the idea of map tiles in 2005, and the Tile Map Service specification followed a year later. We’re nearing twenty years of well-established conventions for tile services, so why now? Why do we need a bloated document to describe what mostly fits in a blog post?
Of course, I didn’t read the OGC Tile API specification or any of its siblings. I read the entirety of the WMS and Styled Layer Descriptor specification for university, and reading OGC documents isn’t something I would recommend for fun.
Tim Schaub’s post doesn’t answer the Why, but it sheds light on what this new set of specs add. The OGC Tiles API allows more detailed descriptions of the services behind an API. It formalises tiling for raster, vector and rendered map tiles and it allows to advertise projections, geographic extend and limitations on tile sets on each zoom level.
You could get all of the information by reading the specs but Tim’s summary does a much better job at lowering the barrier to start developing compliant APIs. We need more readable summaries for OGC standards like this.
