In the geospatial world, like everywhere else, AI is the hottest topic. Anyone who’s looked at a map in the last five years is now talking about foundational models and geospatial embeddings. Some (probably many)—myself included—still struggle to get their heads around those concepts.
Kiri Carini:
I get that end users (which is where I’d put myself on the expertise spectrum) don’t need to understand all the ins and outs of how embeddings are generated. But if we’re going to use them beyond novelty or experimentation, we need to understand enough to know what level of confidence and trust to place in them when applying them to real work.
Kiri’s list is an excellent starting point to learn about geospatial foundational models and embeddings.
I love a good deep dive into often-overlooked map-related challenges. Here Hanbyul Jo wonders why Mapbox chose to vertically display labels in Hangul, whether the choice improves legibility, and since when Koreans horizontally read and write Hangul instead of vertically.
Darren Wiens of SparkGeo demonstrates an AI-driven approach to generating audio descriptions for interactive web maps. The overall process is simple yet effective:
Convert the current map view to an image.
Upload the image to OpenAI’s API to return a text description of the images.
Upload the text description to OpenAI’s API to receive the audio of the text description.
It’s one example of how new generative AI technologies can be put to good use. It is simply impossible for humans to provide alt-text for large interactive maps and AI is the one (the only?) way to make textual descriptions of maps scalable.
You can serve PMTiles directly from a cloud object storage but in some cases, you want to control who accesses data and how often—and you need a server for that. Craig Kochis wrote up two examples of how to serve PMTiles using a NodeJS server application from a co-located file and S3.
A webinar on cloud-native geospatial technologies and their applications in the pacific region features four speakers:
Wei Ji Leong of Development Seed introduces cloud-optimised data formats for geospatial data, focussing on imaging, multi-dimensional data cubes, point clouds and vector data.
Alex Leith of Auspatious talked through the history of Digital Earth platforms, and how cloud-native spatial data have shaped and influenced their development.
Leo Ghignone from the University of Tasmania explained how IMOS, the Integrated Marine Observing System, use cloud-optimised data to support oceanographic research around the Great Barrier Reef.
Fang Yuan of Frontier SI shared a perspective from application developers who used cloud-native data to implement scalable and performant geospatial solutions.
In his NACIS conference talk, Brandon Liu positions Protomaps as an altenative to what he call scarcity maps: Tile services offered by commercial companies that cost a small fortune once your project becomes popular and exceeds the number of tile requests in the free tier.
Nothing is free in this world, even hosting PMTiles yourself isn’t. If you want to convince someone that hosting Protomaps is a financially viable alternative then you need to compare numbers.
So let’s do some quick math and compare a rough estimate of the costs for hosting PMTiles on S3 to the monthly costs of Mapbox Vector tiles.
For the sake of simplicity, let’s assume that clients make 1.5 million tile requests per month. The costs incurred on S3 fall into two categories. Data storage and transfer.
On 3 November, the size of a PMTiles dataset based on OpenStreetMap covering the whole world was 107.62 GB. AWS charges $0.023 per GB and month to store data in S3, so the cost to store a global map is $2.47.
To estimate the transfer costs, we need to know the average size of a PMTile that is delivered over the network. The Protomaps website conveniently has an example that shows size of each tile response. I zoomed and panned around on the map and logged the individual size of about two hundred requests. The average size per tile in my sample was 68.88KB. 1.5 million tile requests at 68.88KB rack up about 103GB in transferred data. AWS charges $0.09 per transferred GB from S3 to the internet, so the overall data-transfer cost is $9.27.
The cost to host and serve a world-wide map dataset is about $12. But here’s a catch. If you put a Cloudfront CDN in front of your S3 bucket (which you probably want to do), then data transfer from S3 to Cloudfront is free, so is the first terra-byte from Cloudfront to the internet. Chances are your can host your PMTiles for less than $5.
The same 1.5 million vector-tile requests on Mapbox will cost you $325; a significant difference. Even considering the labour costs of setting up the infrastructure and data on AWS, and making the occasional update, PMTiles will save money. Like a lot of money.
Disclaimer: This is an informed estimate not a scientific study. I literally did this on the back of an envelope. It’s not my fault, if you take these numbers to your boss to convince them to adopt Protomaps and it turns out you’re paying $25 per month.
The guide includes detailed descriptions of increasingly popular data formats like COG, Zarr, COPC, GeoParquet, FlatGeobuf and PMTiles. It’s an essential bookmark if you deal with geospatial data on the Web in any form.
Very Spatial has compiled a collection of free and open books on spatial analysis.
I am teaching a straight forward, stand-alone Spatial Analysis class for the first time in a couple of decades. That means that I have been looking at resources to share with the class, especially reference materials that they can access given that they will mostly forget what I tell them by February once the next semester is in swing.
FlatGeobuf and GeoParquet are analysis-focused formats. They’re useful for answering queries like What is the sum of attribute A over features that overlap this polygon? But their design does not enable cloud-native visualization like COG does.
You can convert FlatGeoBuf and GeoParquet data into cloud-friendly formats using tools like Tippecanoe:
The best-in-class tool for creating vector tiles from datasets like FlatGeobuf and GeoParquet is tippecanoe, originally developed by Mapbox, but since v2.0 maintained by Felt. Tippecanoe doesn’t just slice features into tiles, it generates smart overviews for every zoom level matching a typical web mapping application. It adaptively simplifies and discards features, using many configuration options, to assemble a coherent overview of entire datasets with minimal tile size.
The output from Tippecanoe can be PMTiles a format that can be read in the browser:
The last missing piece is a cloud-friendly organization of tiles enabling efficient spatial operations. This is the focus of my PMTiles project, an open specification for COG-like pyramids of tiled data, suited to planet-scale vector mapping.
The post doesn’t go into any technical details. I enjoyed as a short and sweet overview of these new(ish) formats and how they are related.
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.
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.
Circles are only supported in a few geo-data formats because most of today’s formats are based on the Simple Features specification, which doesn’t define circles.
Tom MacWright, writing on the Placemark blog, explores why circles are so hard to implement into geo-data applications and why Placemark ended up with three circle definitions: geodesic, degree and Mercator circles.
A quick tutorial by Bert Temme about how to turn a shape file into PMTiles using Tippecanoe:
In this blog we created in a few easy steps vector tiles from shapefile of worldwide railroads in PMTile format using Tippecanoe, and deployed to a standard webserver. No complicated backend WMS/WFS mapservers are needed anymore to get this working.
Iván Sánchez Ortega reporting from his activities during the latest OGC code sprint:
when pygeoapi is requested a coverage from GIS client (preferring image/tiff or application/ld+json or the like), the raw data is returned. But when it’s a web browser (preferring text/html), then a webpage with a small viewer is returned.
It’s an interesting deep-dive into HTTP content negotiation, how it relates to geo-data problems and what OGC API implementations could do better.
Development Seed[^1] have published a summary of two talks from this year’s PostGIS Day. One talk introduces and compares two projects, TiMVT and TiFeatures, which simplify creating tile and OGC-Features services using data from a PostGIS database. The other talk covers PgSTAC, a set of SQL functions and triggers to stand up Postgres databases to host STAC catalogs.
The Map is a short documentary about a revolutionary redesign of New York City’s iconic subway map. Filmmaker Gary Hustwit documents the process as digital agency Work & Co works with the MTA to create a new “live map” — one that updates in real-time — to help New Yorkers and tourists better plan their journeys. The film examines the evolution of wayfinding and user interfaces, and shows how good design and the latest digital technology can simplify one of the world’s most complex transit systems.
During a recent workshop on the fringe of this year’s SatSummit, participants discussed how to design APIs that simplify ordering satellite data. Matthew Hanson wrote a summary of the workshop, noting the complexity of decision-making that goes into ordering data and tasking a satellite; arguably one reason why we haven’t seen a production-ready ordering API so far:
It turned out the most interesting discussions were centered around tasking as a process, rather than the details of a transactional API with a data provider. Tasking is really about the negotiation, as Phil Varner (Element 84) put it: a user says “This is what I want” and the provider responds with “This is what I can offer”. The questions that arose were less about detail and more about how users should interact with the provider. How do users want to discover what is feasible? How do they evaluate multiple possible options and request one or more of those options?
And consequently, how the ordering APIs could be designed:
There was a general consensus that users start by making a “feasibility request. Included in the request is usually a spatial Area Of Interest (AOI) and a date/time range, Time of Interest (TOI), and possibly some additional parameters constraining the options. What is returned by the provider is a list of possible results that may vary by total area of coverage, time of acquisition, price, resolution, sun angle, or by virtually any collection parameter.
Rather than the provider trying to make a decision of what the user wants from the available options, this choice should be pushed back to the user.
The user then gets to pick their preferred options and places the order for the product best suited for their needs.
Detailed notes of the event are on GitHub, providing some early and still rough outlines of potential API states and parameters, amongst insights on more high-level discussions.
There’s a new Carpentries-style lesson teaching the fundamentals of processing geospatial raster and vector data with Python. It teaches the basics of vector and raster data, how to access raster data via STAC, how to do calculations on raster data, and parallelisation with Dask.
The course is designed for in-person workshops, but you can easily follow the instructions at home.
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.
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.
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.
Detailed editing in OpenStreetMap, adding buildings, turn restrictions, or street crossings can be laborious and time-consuming. But more data and newer tools are available to assist armchair mapping from the comfort of your home:
Mapillary provides street-level imagery and point data extracted from the images, which you can use to guide editing in popular editors like iD or JSOM.
RapiD, an extended version of OpenStreetMap’s default iD editor, provides additional datasets from Microsoft, Esri, ~Facebook~Meta and functionality to integrate the data into OpenStreetMap.
Open Mapping Hubs and Meta recently hosted an online workshop introducing how to use Mapillary and RapiD to edit OpenStreetMap, and the recording is available on YouTube.
Both helpers come with caveats. During my very unscientific review (I checked a few neighbourhoods around the world that I’m familiar with), I noticed that Mapillary images can be pretty outdated – most images I saw were from 2019 or earlier, some even from 2014. And for RapiD, the OpenStreetMap Wiki includes a big banner saying that every edit must be reviewed individually, otherwise the modifications are considered an import.
Christopher Beddow takes an in-depth look at Visual Positioning Systems (VPS), the solutions companies like Google, Niantic, or Snap have built, and what possibilities the technology opens.
VPS is naturally associated with Augmented Reality (AR), because of the way it enables AR services. It serves as one of several bridges between the more legacy geospatial topics like maps, data, location, and the world building that demands more than legacy systems typically offer.
Advancements in alternative positioning technologies seem to rekindle the hype around augmented reality. So far VPS is mainly used with video games and in product demonstrations of navigation technology, but I haven’t seen any applications of augmented reality beyond that.
Giles van Gruisen explains the underlying concepts of Felt, and more generally web maps, a tad downplaying the complexity involved:
Don’t worry if these concepts are a bit confusing at first, this stuff is tricky!
That’s one way to put it, considering what is involved in making zooming and panning performant interactions:
Specifically, when the user starts any gesture that might affect the viewport position, we immediately take note of the original viewport state. Then, as we calculate the new viewport position, we can easily derive a transformation that we can use to translate and scale existing element geometries to their new positions and sizes. So, rather than continuously projecting every last coordinate pair on every single frame, we calculate a single “viewport transformation” that can be applied to all of them.
To take it a step further, we don’t actually need to apply that transformation to every single element individually, but rather to a single parent layer that contains all of the shapes as children. This results in a single compositing layer being translated and scaled, and makes for highly efficient zoom and pan gestures. Finally, when the user stops their gesture, we do actually recalculate the projected position of each coordinate pair, and in a single frame swap the old geometries for the new, and remove the temporary transformation.
Whenever I read an article like this, I feel grateful for anyone building and maintaining map libraries and applications. This is complicated stuff, and seeing how easy it is to put a map on the Web these days makes you realise how much thought and work goes into these solutions.
I’m forced to clarify this because we are getting more and more support requests from people who have been mislead by YouTube tutorials that a simple python script can be used to determine the location of any phone simply by entering the phone number.
Chris Holmes wrote an excellent summary of the Cloud-Native Geospatial Outreach Event, which took place in April and gathered people working with new cloud-native geo-data formats and APIs, like COG, Zarr, STAC, or COPC. Chris highlights selected talks to get you started with the formats, how organisations adopt them, and tutorials going deeper into technical details.
Flatgeobuf is a relatively new binary format to encode geographic vector data. Unlike vector tiles, Flatgeobuf is a lossless encoding format, which is streamable and enables random feature access.
Horace Williams wrote a comprehensive overview of what goes into a Flatgeobuf file and how it is structured internally.