mbtiles-s3-server is a new Python library, developed by Michal Charemza, which reads vector geo-data from an MBTiles file stored in S3 and serves it as vector tiles. The library leverages range requests to query an SQLite database in S3.
Very much in line with advancements in file-based, cloud-optimised data storage we’ve been seeing in the last couple of years.
Bill Dollins reflects on the value of industry standards after working with proprietary product APIs:
In the geospatial field, the work of OGC gives us a bit more shared understanding. Because of the Simple Features Specification, we have GeoJSON, GML, GeoPackage, and various similar implementations across multiple open-source and proprietary database systems and data warehouses. Each of those implementations has benefits and shortcomings, but their common root shortens the time to productivity with each. The same can be said of interfaces, such as WxS. I have often been critical of WxS, but, for all the inefficiencies across the various specs, they do provide a level of predictability across implementing technologies which frees a developer to focus on higher-level issues.
OGC’s W*S specifications (e.g., WMS, WFS, or WCS) share similar features. Each provides a getCapabilities operation advertising the service’s — well — capabilities and operations to access the service’s items (getMap, getFeature, or getCoverage). The precise parameters required to execute the requests do vary, and so do server responses, but a good understanding of one specification can be transferred to other similar specifications.
The same flexibility and predictability in built into newer standards today, like OGC API - Features, and community specifications like STAC — both share the same foundation. OGC’s processes may be slow, and the specifications may not make for an entertaining read but its diligent process leads to predictable API design, enabling service and client developers to implement applications consistently and predictably.
You appreciate that more once you had the pleasure to build a service against the Salesforce API.
Will Cadell, CEO of Sparkgeo, starts a newsletter:
Starting up a substack to talk about the super-niche topic of strategic geospatial thinking and tools. It’s going to be like 6 of us, but you’re invited. The bonus is that we get to see into the future and, if we are really clever, we get to sculpt it too.
Very niche indeed, but this will be interesting if Will’s recent thread discussing the future geospatial market is any indication. I wish it was a blog and not on Substack. Thankfully there’s also a secret RSS feed if you don’t want to hand out your email to follow along.
The Google Maps API was never an obvious choice for building advanced cartographic data products. It was always something local businesses use to put a map on their website showing where their shops are located.
Google Maps has now introduced data-driven styling, addressing a new audience outside local businesses. Data-driven styling of Google-maintained administrative boundaries that is. Google maintains and provides a data set of boundaries at varying administrative levels and allows developers to join their thematic data to create choropleth maps.
Looking at the documentation, linking your own data to Google’s boundaries dataset isn’t straightforward. To match the records from your dataset to the features from Google’s boundary dataset, you need to find the corresponding place ID from the Region Lookup API. If you have a hundred records, you need to do a hundred location lookups via the API before your map can be fully rendered. Unless you’re already keeping Google’s place ID in your data, which we all do, don’t we?
What’s the point of this approach is over loading and styling a GeoJSON layer, which has been supported by the Google Maps API before? Sure, you don’t have to maintain an administrative-boundaries dataset. But if the geometry and thematic data come from different sources, can we be sure that both represent the same underlying geographic area. Does this number of Covid cases aggregated by council assume precisely the same boundaries Google provides? We can’t know for sure, and the resulting maps might be unintentional lies.
And obvious use cases for maps based on administrative boundaries include election data, demographic information, or the number of COVID cases within a council. The people producing such data sets will likely maintain or have access to official and accurate boundary data sets. They have no reason to use Google Maps.
Google Maps data-driven styling isn’t a well-designed API of a product that solves a real problem. It’s a marketing stunt.
OpenStreetMap US has recently uploaded recordings from State of the Map 2015 to their Youtube channel. Throwbacks like these are a window into the topics that moved the community back then. How do they compare to today’s?
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.
Ed Freyfogle on The OpenCage Blog:
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.
Thought I’d share this to help spread the word.
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.
Once you’re finished watching Chris’ recommendations, you can dive into the humongous 90-video playlist of all of the event’s talks, which should keep you busy for a couple of days.
This year’s FOSS4G in Florence, Italy, hasn’t even happened yet, but planning is already underway for the next edition. FOSS4G 2023 will take place in Prizren, Kosovo. After Florence, that’s an event in Europe two years in a row, deviating from the usual rota: Europe, Americas, rest of the world.
FOSS4G is the world’s largest meeting focusing on open-source geospatial software and open data bringing together developers, users and academics from around the world. It is organised by the Open Source Geospatial Foundation and a local group.
Further details for the 2023 event, such as a date, have not yet been announced.
The Open Geospatial Consortium (OGC), the standards body of the geospatial world, has endorsed the Zarr 2.0 specification as a community standard.
Zarr originated in genomics research but has since been adopted by the geospatial community because of its ability to quickly access multi-dimensional data in chunks. Zarr allows accessing a window of its data without having to first download the entire data set and dissect it locally. Think of a thirty-year time series of a grid of ocean-surface temperature data, where you can just retrieve the area around the Canary Islands for the last three years.
Zarr data can be stored in a wide range of storage systems, including object stores, such as AWS S3 or Google Cloud Storage, or in storage accessible via HTTP APIs. This makes Zarr the ideal candidate for cloud-native storage and processing of large, multi-dimensional datasets.
Community standards are a way for the OGC to formally adopt specifications developed outside the OGC standardisation process. A community-standard endorsement signifies that a specification is mature, established, widely used, and implemented into reference software. This is a big step for Zarr 2.0, showing that it is now a de-facto way to access multi-dimensional data sets over the Web.
A community standard usually represents a snapshot of a specification under constant development. The Zarr community already works on advancements to the existing standard, eventually resulting in a new Zarr 3.0 specification and proposed to the OGC as a new community standard. Other work includes an extension to the Zarr 2.0 specification formilising how georefrenced grids should be represented in Zarr.