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.
