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.
Radiant Earth announced two initiatives to further the development and sharing of machine-learning models and the adoption of cloud-native formats for geospatial data.
Source Cooperative aims to provide a marketplace for machine-learning models and training data:
Source Cooperative builds upon Radiant MLHub’s legacy as a neutral and trustworthy data publishing platform and will enable the publication of a wider variety of datasets in addition to machine learning training data products and machine learning models. For anyone who has any kind of data or machine learning models that they need to share, Source Cooperative will allow them to upload it, define how open they want it to be, and even charge for it if they want to.
It sounds a bit like GitHub, but for machine-learning models and training data, with integrated monetisation. The new platform will replace Radiant MLHub, which will end operations in October 2023, and all data will be migrated to Source Cooperative.
Cloud-Native Geospatial Foundation aims to advance the adoption and development of cloud-native geospatial data formats through educational materials and supporting software development efforts.
Both activities are in very early stages with very little detail. You can contribute by participating in community surveys for each initiative.
Google announced that their 3D tiles will be available through the Map Tiles API. Surprisingly, the API isn’t a proprietary design but implements the OGC 3D Tiles standard, which opens the dataset up for visualisations using open-source client libraries such as Cesium or Deck.gl.
You have to register with Google and provide an API key to use Google’s 3D Tiles. The service is free, for now, during its experimental stage.