Django 4.1 brings two new features for handling geographic geometries; allowing developers to create valid and canonical geometries more easily:
GEOSGeometry.make_valid() returns a valid representation of a geometry. Unless the geometry is already valid, then the geometry is returned without changes. The function is very similar to ST_MakeValid in PostGIS.
GEOSGeometry.normalize() returns the canonical, or standardised, representation of a geometry. The method now accepts the optional clone keyword indicating that the normalisation must not change the geometry and instead return a new geometry object.
Additionally, support for GDAL 2.1 and PostGIS 2.4 has been removed, and the Django Admin’s OpenLayersWidget is now deprecated.
Check the release notes for all other changes in Django 4.1.
There’s not a lot of geo content in this episode. Instead, it’s a trip down Memory Lane with James and Ed reminiscing about the good old days of blogging. That time during the mid-noughties when people were writing blogs, linking and discussing each other’s work — and before everyone went to Twitter to complain. I’ve been feeling a bit nostalgic recently about that time, so this episode hit a spot.
Good content is still out there, except everything is now hidden away on Substack or Medium, and even indy sites rarely publicise RSS feeds. Flashy images, memes and hot takes create clicks, so well-written 500-word stories aren’t widely shared. It’s one of the main reasons I started this blog. I want it to be a place to share content, cool projects, and long-form writing beyond three 280-character blocks of words topped off with a meme.
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.
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.
