Humanitarian OpenStreetMap Team has teamed up with local organising partners to host community events in several locations around the world.
Instead of hosting a single event, this year we are investing our time and resources in supporting global, regional, and local conferences and community events around the world to bring the spirit of the Summit to thousands of new people.
I love this idea. Instead of flying-in people to one big event hosted in Europe or Northern America, surely excluding many people from attending because of travel costs and visa requirements, HOT brings the event closer to the community and the people who benefit from their work.
Twelve events are currently planned until the end of 2022:
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, FacebookMeta 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.
Whether you’re just beginning with Leaflet or you’ve been around when Leaflet 0.7 was the current release, this collection of more than sixty Leaflet examples is a valuable resource for anyone. There are basic examples like setting up a Leaflet map or adding a marker, solutions to more complex problems like fitting bounds with padding, and advanced concepts such as overlaying images or searching across layers.
Planet outlines its updated strategy, aiming to become a company that doesn’t just operate earth-observation satellites and provides remote-sensing data. Planet wants to be a company that also runs an earth-data platform allowing users to gather insights from Planet’s data.
The most interesting part of the marketing material is that it’s one of the rare cases that (sort of, in a sugar-coded way) admits that their product isn’t just used to save the environment or ensure every human can eat. Geospatial products are often used to achieve questionable goals, including fighting wars:
There are also security threats, very present as we write this during the war in Ukraine, for which the transparency created by daily broad coverage imagery can help illuminate events in a factual, unbiased and democratized way, reducing likelihood of miscalculation and escalation, and providing a common operating picture for society.
Working in geospatial, we all want to use our skills to create tools or to produce data that ultimately contribute to a better life on earth. But the companies we work for still have to make money, and the clients with the deepest pockets usually aren’t the ones that primarily care about world peace and ensuring every human on earth is well off — a conundrum Tom MacWright captured previously in Ethics in Geo.
A new release of the web-mapping library OpenLayers is out. v6.15 includes, among other things, performance improvements, enhanced styling options for symbols, and bug fixes.
SatSummit is back this year after a four-year break, bringing together experts from the satellite industry, global development, environmental protection, and governments to discuss how satellite data can contribute to addressing the planet’s most pressing issues. It’s scheduled for 28 and 29 September 2022 at Convene in Washington, D.C.
Now here’s a very cool project: Allmaps, a browser application made by Bert Spaan and Jules Schoonman, lets you geo-reference images from public sources such as libraries and public archives. You provide the URL of an image and set the reference points via the Allmaps interface. Ideal for laying digitised images of old maps over modern-day data and understanding how the geography has changed.
A map from 1860s Antwerp from the Boston Public Library layed over a modern-day digital map.
Screenshot from Allmaps.org
What is unique about Allmaps are the technical underpinnings of the application; relying heavily on open standards to access images and store annotations:
Image resources are accessed via International Image Interoperability Framework’s (IIIF) Image API, which doesn’t just return an image; it allows developers to specify region, size, rotation, and format of the returned image — ideal to crop, resize and rotate an image into place on a map.
The map’s control points are stored using a format based on W3C’s Web Annotation Data Model. The custom format uses GeoJSON to represent geographic coordinates of control points while placing the corresponding pixel coordinates inside the properties object.
Allmaps combines existing standards in a novel way, designing for interoperability from the start and enabling sharing of geo-referencing data with other applications.
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.
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.
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.
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.
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.
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.
Some early-internet household names are still going. Amongst them is a familiar face I didn’t think still existed: MapQuest, still used by a surprising amount of people today:
More than 17 million Americans regularly use MapQuest, one of the first digital mapping websites that was long ago overtaken by Google and Apple, according to data from the research firm Comscore.
What reminded me of MapQuest the other day: The Azure-Maps tiles that GitHub now uses to display GeoJSON files. Add a button on each side of the map to navigate towards north, east, south or west, and it will look like a MapQuest map from 2002.
