FOSS4G is the annual global event of free and open source geographic technologies and open geospatial data hosted by OSGeo. In 2026 it took place in Hiroshima, Japan.
FOSS4G is the annual global event of free and open source geographic technologies and open geospatial data hosted by OSGeo. In 2026 it took place in Hiroshima, Japan.
On September 7, 2026, I gave a keynote at State of the Map Asia 2026 in Osaka.
The title was:
What if the Map itself became the Web?
The talk looks back at the thirty-year journey of Hyper-Layering Architecture (HLA), from its origins in 1995 to its current implementation as Layers as Web Apps.
The central idea is simple: instead of collecting and integrating information into a central system, independent Web resources can remain independent while users compose them together as map layers in the browser.
The keynote demonstrates this approach with real-world systems, disaster information, thematic mapping, different map projections, QuadTree Composite Tiling, and client-side spatial operations.
It also looks ahead to HLA 3.0 and the possibility of bringing hyper-layering into the Web itself.
And, of course, OpenStreetMap plays an important role in this story.
OpenStreetMap made the map open. What comes next?
Perhaps we can build an Open Map Web on top of it.
The complete keynote, including the demonstration, slides, is available here:
SotM Asia 2026 — What if the Map itself became the Web?
If this direction interests you, please join the W3C Maps for HTML Community Group and join the discussion about the future of maps on the Web.
Number sixteen was my peak volume week. My biggest training week in three years (not counting the Bear races of 2023 and 2025).
17 hours, 27 minutes all training
52.2 miles hiking and running
14,938 ft D+ hiking and running
I went out on steep mountain trails five times to prepare for the big initial climb, high altitude, and big finishing descent of Run Rabbit Run (RRR). I did more power hiking than running on the climbs, and worked on descending with fast feet and momentum. I'm not planning to use poles at RRR, so I left them behind all week.
Tuesday I hiked and ran up the Round Mountain trail in the Big Thompson Canyon. 3,000 feet of climbing in less than five miles is a good simulation of the climb up Steamboat Mountain. There is some very pretty scenery on the trail, too.
Wednesday I did some D+ grinding around Arthur's Rock in Lory State Park. 1,400 feet of climbing (and equal descending) in 5.3 miles.
I went to Rocky Mountain National Park on Thursday and Friday for an alpine mini-camp. Thursday I hiked and ran by myself up to the top of Flattop Mountain from Bear Lake. That's 2,800 ft D+, starting at 9,800 feet. I saw a Peregrine falcon and lots of pikas and marmots. Not many hikers on top, though Bear Lake was quite busy.
A rocky section of the Flattop Mountain trail crosses alpine tundra with the Mills Lake Basin and Longs Peak in the background. Rocky Mountain National Park, Colorado, U.S.A.
Thursday night I stayed at the cabin of my friend, Dana, and Friday the two of us ran and hiked into RMNP's Wild Basin, following a ridge to Mount Orton (11,729 ft) and then to the summit of Chiefs Head Peak (13,579 ft), the third highest summit in the park. From there we dropped down into the drainage containing Snowbank and Lions Lakes and along North St. Vrain Creek to the trailhead. Over 5,700 feet of climbing and twenty miles. We ran almost all of the return, and I felt pretty strong. It's a good sign for RRR.
Sunday I went back out for a little more D+ grinding on Towers Trail. I hiked and ran at the very end of the day to beat the heat. The lights of the city on the way down was something I hadn't seen in a while.
On the Some Work, All Play podcast this morning the Roches said that ten hours of training is near the productive limit for most athletes. They are not counting active recovery, that's my understanding. My count of more than 17 hours includes three hours of easy cycling and my usual mobility and core routine, and no more than four hours of zone 2 effort. Everything else was quite easy. I wouldn't want to stack too many of these weeks, but this one on top of a pretty big week fifteen is not too much. I've got plenty of recovery time before RRR.
A hiker (me) in shorts and a sweater standing on the chunky granite summit of Chiefs Head Peak. Longs Peak (left) and Mt. Meeker (right) are in the background. Rocky Mountain National Park, Colorado, U.S.A.
Weeks twelve through fifteen had a little better air quality and I increased my training volume steadily, transitioning to more uphill outings and more power hiking.
56 hours, 15 minutes all training
125.8 miles running and hiking
26,420 ft D+ running and hiking
In week fifteen, I logged 10,000 feet of elevation gain (D+) for the first time this year. And I felt good after eight consectutive days of hiking and running.
Week eight began in Glacier National Park and week eleven finished in Steamboat Springs.
51 hours, 47 minutes all training
116 miles running and hiking
16,903 ft D+ running and hiking
Hiking with my oldest kid in Glacier and Grand Teton Nation Parks was one of the highlights of this year. Arabelle has become a strong hiker (summiting nine of Colorado's fourteeners this summer) and is great company on the trail. Hiking options were limited in Glacier, which was recovering from torrential rain and washed out trails, but the Tetons were wide open to exploring. Our big hike was to trendy Delta Lake below Teton Glacier.
A sprawling four-story wooden lodge on the edge of a greenish lake with big peaks in the background. Glacier National Park, Montana, U.S.A.
July in Fort Collins was characterized by exceptional heat and miserable air quality. Particles from smoky wildfires upstream and ozone derived from fuel pumps and gas wells locally are making smog a permanent feature of summer on the Front Range of Colorado. It's nice to be able to escape to the mountains to escape the heat and ozone.
The feet of a white man soaking in a small alpine lake under a rugged mountain and fields of summer snow. Rocky Mountain National Park, Colorado, U.S.A.
I tried a new kind of running event in week eleven, a relay race from Fort Collins to Steamboat Springs, 200 miles in 36 legs, as one runner on a team of twelve. I ran legs 11, 23, and 35, all of them on the shoulder of a scenic Colorado highway, the middle one at 1:00 a.m. It was a bit like running a hilly, short 10K every 7-8 hours. We split the team into two vans of six runners, so one group would be a rolling runner and crew, while the other had 7-8 hours of downtime. None of us had done the Wild West Relay before. We executed pretty well and had a lot of fun. I drove a giant white Ford Transit, ate a lot of junk food, slept very little, and made a bunch of new friends.
A dirt trail traversing a lush green slope dotted with large conifer trees above a pair of blue lakes. Grand Teton National Park, Wyoming, U.S.A.
I recently posted about the build of my “A Pint Near Me” app. When I had finished the build I asked Claude “Can you give me a few interesting stats from the pubs data?”
Pause for a minute and see if you can guess the answers, maybe have a play with the map to test your guesses before you scroll down.

These answers were all generated by Claude based on the prompt above.
Ignoring “The”
23,108 of 49,439 named pubs (46.7%) have a name that appears nowhere else in the whole dataset — genuinely unique out of 27,125 distinct names in total. Odd fact: 502 pubs on OSM have no name tag at all.
England and Wales share the same heraldic vocabulary (Red Lion, Royal Oak, Crown all near the top of both), but Scotland and Northern Ireland don’t play that game at all — their top names are almost entirely generic/functional: “Victoria Bar,” “Station Bar,” “Railway Inn” in Scotland; “Central Bar,” “Village Inn,” “Corner Bar” in NI. The English/Welsh heraldic-name tradition (lions, crowns, royalty) essentially doesn’t exist north and west of the border — it’s “[Place feature] Bar,” not “[Heraldic animal].”
<p>The post Playing with Pub Names first appeared on KnowWhere.</p>

A while after I blogged about my Pub Density Map it got picked up by Hacker News and the map got a big spike in views. Some of the comments were complaints that a pub was missing or that the pubs data was not searchable, some were less helpful. I had used the Open Pubs data from GetTheData, which in hindsight, was maybe not the best choice, the data was quite rough and a bit out of date but it seemed fit for my purpose of illustrating the areas of the country with highest pub density (pubs per 10k population), I had included the pub points just because I had them and that had attracted the most criticism.
After I had got over my 15 seconds of relative fame, I wondered whether I could do something better mapping pubs in the UK. I asked my new friend Claude Code what we could do with the FHRS data and the pubs data on OSM, a good bit of whirring and numerous back and forths and data testing/verification and we had a data pipeline.
FHRSID↔fhrs:id tag) → fuzzy name+distance vs OSM pub/bar (300m) → fuzzy name+distance vs broader venues in OSM e.g. restaurant/cafe/nightclub/fast_food/hotel radius 150m, because FHRS’s category sometimes maps to a different OSM tag entirelyverified (OSM), likely (FHRS + independently confirmed by VOA), unverified (FHRS only) – there are ca. 4,000 uncertainties that need eyes on to validate.topojson library rather than QGIS and then simplified to reduce file sizeLearning: Recognise when you can’t achieve perfection and settle for good
Most of this data strategy came from my decisions and questions to Claude, which it then trialled and presented me with a sample of records to inspect. There are almost 50,000 pub points in the combined dataset, I got to a point where I felt that there were limited genuine gains to be achieved from further efforts to match/combine the FHRS data with OSM. The data pipeline is now stable and scripted so I can run a data refresh whenever I want (not scheduled at the moment).
Compared to the data pipeline the app build was relatively simple, Claude has built a good memory of my map design choices and went from my moderately detailed prompt to a project brief and a build plan in a few minutes. Once I ok’d the plan there was a lot of whirring and token consumption and I had a pretty good first effort which I refined in a series of stages.
The biggest challenge was the search and that took a lot of trials until I got it working the way I wanted. I had thought about including a feedback mechanism to correct errors in the data and worried that I could be inviting spammers or bots. I decided to add links to add or edit a pub on OSM which open the iD editor, hopefully this will gradually improve the pubs database on OSM which will be reflected in the map when I periodically do a data refresh.

I asked Claude to summarise the key stages of the data pipeline and app build by going back through our chat history and that (with a bit of editing) is what you have just read in the bullet points above.
I asked Claude to give me some interesting facts about the pub names in the UK Pubs data we had built. Guess what are the 5 most common pub names in the UK or what are the regional patterns in naming? You’ll find the answers here.
<p>The post A Pint Near Me – what you do after 15 seconds of fame first appeared on KnowWhere.</p>
The next version of QField is here. While this time of the year is a well-deserved holiday period for many, we’ve dedicated ourselves to improving the stability and refining of your favorite field mapping tool.
We’re calling this effort the “summer of stability”, a sprint we will undertake on a yearly basis. But there are plenty of improvements to cover, so let’s go over them.

First, we’ve introduced a new bookmark manager to make QField’s experience around spatial bookmarking feel more complete. With the manager accessible via the dashboard’s main menu – users will be able to browse their bookmarks as a full list with the ability to quickly jump to a bookmark’s location by tapping its name, as well as edit its properties.
Furthermore, users will also be able to export bookmarks as a geopackage, which means the data captured through spatial bookmarks is no longer locked within users’ devices anymore. And, if users’ bookmarks become irrelevant, the manager also allows for bulk deletion of bookmarks.

While improving the relevance and usefulness of bookmarks, we added a “navigate to bookmark” action to the search bar results.
As mentioned above, this release focused on refinement and polish, and the camera got special attention. We’ve added logic to ensure that the rotation of snapped photos matches expectations. When the device angle gets too tricky for that to work, users can now manually rotate and flip photos while previewing them. We also improved camera stability by preventing auto-focus and auto-white balance from freezing the process when the hardware or the operating system fails us.

Image stamping has been improved too: it’s now possible to write details on your images coming from the layer and features the images will be attached to. This is sure to please many of our users as it was requested more than once across our community discourse and ideas platform .
Leveraging QFieldCloud ’s latest capabilities, this new version of QField introduces a new way to create projects while in the field: project templates.
When setting up projects in QFieldCloud, users can now flag them as templates. This newly-introduced type allows users to create new projects from these templates through QField itself in the field.

Templates become super handy when shared within an organization where all affiliated members can have access to the template. And of course, when the templates are made public, they turn into a fantastic shared resource for the broader community. Trust us, it beats a GitHub repository archive any day of the week ;)
One of the most important ways to manage QFieldCloud data in QField is through its cloud project panel, accessed by tapping the blue cloud button at the top of the dashboard.
In this new version, the cloud project panel has gone through an evolutionary step. Changes include:
We’ve made the language easier to understand by non-technical people. Words like “push” and “revert” are replaced with “upload” and “discard”.
We also re-ordered the interactive elements to ensure that the most important action was most visible: uploading changes.
QField will proactively remind users of pending local changes when they are about to end a mapping session.
To avoid accidental data loss, we’ve relocated the discarding or local changes action to a new ‘danger zone’ sub-panel.

In addition, the cloud project control panel now offers a summary and detailed view of local changes. This allows for users to review the feature addition, editing, and deletion prior to uploading and synchronizing them back to QFieldCloud.
Haven’t tried QFieldCloud yet? Sign up for a free community account !
One of the main objectives of this development cycle has been to improve upon preexisting functionality.
Let’s go over a few notable improvements.
The QR code scanner can now capture codes from images picked through the device’s gallery. As more and more QR codes are shared digitally, You’ll never be stuck having to send a friend the QR code you need to scan on your smartphone ever again ;)
On the feature form side,the value relation editor widget now does accent-less searches allowing for faster data entry. The relation editor widgets respect the configured sorting order defined during project set up. And finally, the gallery editor’s chosen mode – thumbnail vs. list - will be remembered.
As mentioned in the introduction, this release is the culmination of a new yearly sprint we call “summer of stability”. Let’s expand a bit on this.
One of the metrics used to judge whether our efforts were successful is the number of sessions that crashed reported on our anonymized metrics platform. By the end of the sprint, the platform showed a dramatic decrease in crashes (>20% reduction in reported crashes). That is a bottom line that tells us we are making QField more stable!
Beyond that, we’ve also increased our number of automated test cases that act as safeguard against silent regressions every time we commit a change in QField. An extra 27% lines of code were added covering C++ classes and QML items that were until now not tested. This is the way we ensured that the impact of this stability sprint will not dissipate overnight.
The Danube is the longest river in the European Union. Rising in Germany’s Black Forest, it flows through ten countries and four capital cities — Vienna, Bratislava, Budapest, and Belgrade — before emptying into the Black Sea, sustaining ecosystems, agriculture, energy infrastructure, and the livelihoods of millions along its banks.

Photo by Carsten Steger
This summer, the Danube made headlines for the wrong reasons. Record-low water levels, driven by unprecedented heatwaves, have exposed long-sunken WWII warships and forced drastic action to protect critical infrastructure. In Hungary, the Paks nuclear power plant, which generates nearly half of the country’s electricity using Danube water for cooling, was forced to take all but one of its reactors offline. The European Commission’s Joint Research Centre confirmed the Danube had reached record-low levels, with reduced flows putting pressure on navigation, water supplies, agriculture, and the energy sector. The river that has connected civilisations for millennia is telling us something urgent.
At OPENGIS.ch, we believe that rivers like the Danube are not just geography: they are living systems that require careful observation and data-driven management. Better field data, collected faster and more reliably, is part of how we respond to a changing world.
That is what QField is built for.
The PostGIS Team is pleased to release PostGIS 3.7.0rc2! Best Served with PostgreSQL 19 Beta 3 , GEOS 3.15.0 , postgis_tiger_geocoder 2025.2 , and address_standardizer.
This version requires PostgreSQL 14 - 19beta3, GEOS 3.10 or higher, Proj 6.1+, and libgmp. To take advantage of all features, GEOS 3.15+ is needed. To take advantage of all SFCGAL features SFCGAL 2.3.0+ is needed. To use postgis_raster extension GDAL 3+ is required.
This release contains fixes since 3.7.0rc1 release.
Cheat Sheets:
This release is a release candidate of a major release, it includes bug fixes since PostGIS 3.6.4 and new features.
Hello pgRouting community,
The pgRouting Team is pleased to announce the release of pgRouting version 4.0.2
The latest release is available at [1]. For discussions on the release, go to [2]. To see all issues & pull requests closed by this release see the Git closed milestone for 4.0.2 on Github. [3]
## Summary of changes by function
pgr\_dijkstraVia
Fix: bad alloc
pgr\_drivingDistance
Standardizing negative distance behaviour
Throws when :math:distance < 0\.
Standard message and hint\.
pgr\_withPointsDD
Standardizing negative distance behaviour
Throws when :math:distance < 0\.
Standard message and hint\.
pgr\_withPointsVia
Fix: bad alloc
## Bug Fixes
\#3110: pgr\_dijkstraVia throws std::bad\_alloc when a node does not exist
\#3091: Catchment functions when negative distance do not have a standardized behaviour
## To update your database
Download the packaged version from your operating system, and use this command in the database:
ALTER EXTENSION pgrouting UPDATE TO "4.0.2";
[1]. Release v4.0.2 · pgRouting/pgrouting · GitHub
[2]. v4.0.2 · pgRouting/pgrouting · Discussion #3144 · GitHub
[3]. Issues · pgRouting/pgrouting · GitHub
_______________________________________________
Announce mailing list
Announce@lists.osgeo.org
1 post - 1 participant
We are honoured to announce that Ian Turton is the recipient of the
2026 Sol Katz Award (the 22nd year of the award), at the recent FOSS4G
event in Hiroshima, Japan.
Ian has been a member of our community from the very beginning, as an
original voting member who gathered in Chicago in February 2006 to
establish OSGeo. He also is a co-founder of GeoTools, the Java
library that is the foundation for the Java ecosystem in OSGeo, and a
Project Steering Committee (PSC) member of GeoServer. But more
importantly, for decades he has been helping new users, through talks,
workshops, answering questions on StackExchange, and always being a
kind and jovial person. We are lucky to have him in this community.
Congrats Ian!
About the Award:
The Sol Katz Award for Free and Open Source Software for Geospatial
(FOSS4G) is awarded annually by OSGeo to individuals who have
demonstrated leadership in the FOSS4G community. Recipients of the
award have contributed significantly through their activities to
advance open source ideals in the geospatial realm. The award
acknowledges both the work of community members, and pay tribute to
one of its founders, for years to come.
--
OSGeo News | https://osgeo.org
_______________________________________________
Announce mailing list
Announce@lists.osgeo.org
Announce Info Page
1 post - 1 participant
While working on a recent client project involving a PostgreSQL and PostGIS database, I was working with just a few hundred spatial records. Everything ran relatively smoothly, but a slight lag during query execution got me thinking: If an unoptimised query takes noticeable time on a dataset this small, what happens when the project scales to tens of thousands or millions of features?
In spatial databases, performance problems rarely scale linearly. An unoptimised query that takes a fraction of a second on a few hundred points can easily take hours or freeze your system entirely at production scale. Imagine you eventually scale up to 5 million building footprints and 50,000 points of interest (POIs) in your PostGIS database. You want to find out which buildings contain a POI, so you write a standard spatial join:

A lot of the posts that we share on Mappery come via our social feeds at Mastodon and Bluesky as either an @ message or a hashtag #MapsintheWild. Up till now our workflow to turn the social posts into blog posts on Mappery was something like this:
This workflow worked but it was tiresome, relatively slow and open to user error.
Today I wondered whether I could build a tool that would simplify and speed up this workflow.I started out by brainstorming the project brief for the tool with Claude Chat, a series of iterations helped me to define the project well, reduce the technical complexity and reach my target of automating as much of the social post to draft blog post workflow. Time spent about 1 hour, outcome a project brief that I could point Claude Code at.
I asked Claude Code to ask for any clarifications that it needed and that tightened the requirements and then it went into code mode and produced a framework of the whole tool without the connections to the Mastodon, Bluesky and WordPress API’s. Claude guided me through setting up application passwords and tested each one after I created it and added to the app config. After another hour I had a working tool.
Testing with real data identified some additional requirements which we then implemented. About 1 hour including testing and I was at a fully featured, tested tool.
Now the 10 steps above are reduced to about 3 or 4 clicks and prompts and the draft post is waiting in WordPress for me to schedule. Using the tool I scheduled 10 posts in under 30 minutes, with the old workflow that would have taken 90-100 minutes – pretty impressed with that.
Technically this was quite complex, connecting to and querying the Bluesky and Mastodon API’s, reading the data from the API’s, composing a WordPress post and submitting it using the WordPress REST API and tracking progress/status for the next session. I can understand what is going on but I don’t think I could have even specified it in detail let alone worked out how to do all this stuff. But a well thought through project brief based on user requirements and Claude Code was able to build for me in 3 hours from idea to a working tool.
Being able to build tools that address specific problems and save time/improve quality is a capability that most businesses probably need.
<p>The post Mappery Social Inbox first appeared on KnowWhere.</p>

This might be a long post, it was a pretty challenging project.
I wrote last week about my Amazing Animals in Crisis map of 50 endangered species, I got some bad news on Friday that my usage of the IUCN polygon data was in breach of their licencing conditions and a request that I take the map down, which I promptly did. This was a big disappointment as I was just about to expand the map to almost 400 species and now I had no data.
Learning – even if data is apparently free and open, carefully read the license conditions before you use it. Obvious, I know, but I had to learn the hard way.
Along with the request to take down the map, there was a glimmer of good news that I could use the assessment data that I had requested for the Amazing Species as long as I correctly cited all the authors of the individual species assessments. So I had a lot of text about each species but no spatial data, how could I make a map? I briefly considered extracting the country names from the range info for each species and building a country level choropleth but that would have been very misleading as some species are only found in a small part of a country and I could not think of a way to portray the coverage of marine species.
Then I remembered that when I had been researching data sources for the original map that Claude had identified the Global Biodiversity Information Facility (GBIF) as a possible source. GBIF has hundreds of millions of point observations of species, both human observations and automated tracking data from satellite and GPS tags, they include coordinates, lots of useful metadata and in many cases links to photographs. Most importantly the GBIF data is open and licenced as CC0, CC BY or CC BY-NC and the data was accessible through an API.
It’s important to understand the difference between the GBIF occurrences data and the scientifically researched species boundaries available from IUCN and I hope the explanation in the info panel on the map explains this:
With several investigations of the data and tests in a simple map, Claude worked out what data to download, how to filter and process it and few hours later I had almost 750,000 species points across 388 species including 159,000 points with a photo link covering the last 10 years. That’s a colossal data set. Through numerous iterations we worked out how to process this data into something meaningful and usable by using hex bins to represent the coverage and colouring them by point density for each individual species (low, medium, high) and storing that data before dropping all of the points with no photos and then aggressively thinning the photo rich species while retaining the broad geographic coverage, that took a few tries as my data had 7,500 pictures of lions and large numbers for several other species. The final result was 45,000 points with photos.
What made a massive difference was getting Claude to spin up a browser based test rig that could test different hex bin settings and approaches to thinning the photo points until I got to something I was happy with.
The map has a species card that has a hero image, a summary of the IUNC assessment data, the countries where the animals were observed, the citations for each author and a credit for each hero image – 388 times!
I wanted to curate the hero images to pick attractive images that were a manageable size, I had spent several hours finding images for the original 50 species, I needed to find a better way to select 338 more. Claude built me a tool that read my list of species, searched Wikipedia Commons, filtered the search by file size, dimensions and licencing terms to present a selection of images, once an image was chosen, the tool added the image url, author and license type to my species data. With that tool I whizzed through the remaining 338 species in about as long as it had taken me manual searching for the initial 50.
We tried to auto-gather the citation data from the IUCN web site but that didn’t work so I got Claude to build me a tool along the lines of the image tool to speed up gathering the citation data.
Learning – using Claude you can quickly build tools to automate or semi automate repetitive tasks, each of those tools took about 10 minutes and a couple of iterations to build and saved hours of my time.

Reading through this, it sounds quite easy but in fact it took a lot of thought and trial and error to find the solutions to the challenges in building the map. Claude is patient and never gets pissed off if you decide to retry or change direction, at some points I needed Claude’s advice to help me reach decisions. In code terms Claude did everything, but in design and direction I was in the driving seat – this map was my idea of how to present the massive data set in a useful and performative way (the first try had some performance problems until I came up with a strategy to preprocess and thin the data).
I am pleased with the finished map, no doubt there will be a few tweaks over the next week. There are several sites that present species data for an academic/conservation audience (search for “maps of endangered species”) but none of them are easy to use and understand for the public, I think Amazing Animals on the IUCN Red List hits the spot. Let me know what you think
<p>The post Amazing Animals on the IUCN Red List – a massive project that I couldn’t have considered without Claude Code first appeared on KnowWhere.</p>
The PostGIS Team is pleased to release PostGIS 3.7.0rc1! Best Served with PostgreSQL 19 Beta 3 , GEOS 3.15.0rc1 , postgis_tiger_geocoder 2025.2 , and address_standardizer.
This version requires PostgreSQL 14 - 19rc1, GEOS 3.10 or higher, and Proj 6.1+. To take advantage of all features, GEOS 3.15+ is needed. To take advantage of all SFCGAL features SFCGAL 2.3.0+ is needed.
This release contains fixes since 3.7.0beta2 release.
Cheat Sheets:
This release is a release candidate of a major release, it includes bug fixes since PostGIS 3.6.4 and new features.
The PostGIS development team is pleased to provide postgis_tiger_geocoder extension.
This is the very second release since the break from the PostGIS core.
This version requires PostgreSQL 16 and above and should work with any supported PostGIS version.
PostGIS 3.6 series is the last series to include postgis_tiger_geocoder.
PostGIS 3.7 will be shipped without postgis_tiger_geocoder.
postgis_tiger_geocoder has its own dedicated repo at OSGeo Gitea postgis_tiger_geocoder
under the PostGIS org.
The versioning model is versioned based on the year of the Census US Tiger dataset that is current at time of it’s release.

If you have ever spun up a PostGIS database or deployed GeoServer in a container, there is a good chance you pulled an image built by Kartoza. As of mid-2026, our geospatial Docker images have been pulled over 21 million times on Docker Hub. That number quietly astonishes even us. We are a small team based in Cape Town and Stellenbosch, yet our containers sit in CI pipelines, university labs, government servers, and humanitarian deployments on every continent.
Oslandia will be attending the 2026 QGIS User Conference, which is taking place this year 5-6 October in Laax, Switzerland 
Workshop QGIS Expressions: From Labels to Geometry Generators (by Benoit de Mezzo | Monday, October 5, 11:30 AM)
Deploying QGIS in large IT systems – best practices (by Vincent Picavet | Monday, October 5, 2:30 PM)
Mental health and OpenSource, tough topic for engineers (by Vincent Picavet | Monday, October 5, 4:00 PM)
From Users to Contributors: Rethinking Participation in QGIS (by Jean Felder | Monday, October 5, 4:30 PM)

The QGIS User Conference is an annual event that brings together users and developers of the QGIS open-source geographic information system (GIS). The conference offers an opportunity to discover the latest developments in QGIS, share real-world experiences, and network with the global QGIS community across administrations, industry, academia, and beyond.
The event is organized by OPENGIS.ch, the Swiss QGIS user group with support from the QGIS project.
With a team of QGIS contributors and “core committers,” Oslandia is committed, as a “pure player,” to improving the core of QGIS and fixing bugs. The team is looking forward to participating in these events to engage with the international community 
Information and Registration
https://uc2026.qgis.org/

I was requested to take down this map by the IUCN team (International Union for the Conserfvation of Nature) because my usage breached their license terms.
You have to request a download of data from the IUCN and I had included in my requests that I was making an interactive map, so I thought that they had approved my usage but clearly not. If you browse to the map you will now see the take down page. The rest of the blog about how I made the map is still interesting and I am now working on a different approach using a different dataset that is fully open.

I have been using Claude to help me build maps for a few months now and I have been very happy with the results which I think have been improving. I keep hearing about Claude Code and wondered what is the difference? The answer: a heck of a lot!
Using Claude Chat (or any of the other chatbots) you can prompt the AI to write files for you, to write scripts and guide you in running them. That’s how I have been working up till now. Once you have given Claude Code the permissions to access your local hard drive (scary) it builds the app for you, writing all the necessary files, building and running scripts where needed, running tests in an embedded browser, simulating mobile use and committing diffs to git with detailed comments. It is pretty impressive to someone like me who has very limited coding skills.
A few weeks ago, I was watching a nature documentary and had the idea to try and build a map of endangered species. I started out doing some data research using Claude Chat which is pretty good at finding data and it pointed me at the IUCN Red List, it took a while to work out how to download a useful dataset as the data is enormous and complicated and needs a lot of filtering. Eventually I downloaded a dataset of about 350 “Amazing Animals”, a subset of “Amazing Species” which is an IUCN categorisation of high visibility or interest species:
These are pretty big datasets with thousands of multi-polygons and a lot of attributes (350MB is pretty sluggish as a .shp!) so I decided to start out with a proof of concept using 50 species which Claude helped me to select. Now I needed to find an image for each species that was free to use and available online, Claude suggested Wikimedia Commons which seemed like a good idea, it has an API to query, so I set Claude off trying to find an image for each of my 50 species. It produced a csv file with the 50 species, Latin and common names, an image link, the creator name and license type, brilliant! It suggested that I manually check the links and that was where the manual work started, quite a lot were broken or no longer available so I had to spend time fixing and testing, but I think it was time well spent.
After some Claude assisted wrestling with shp files in QGIS and a couple of lessons learnt, I had a geojson file of the 50 species extents and status along with a load of textual info. I ran the polygon dataset through Tippecanoe to generate a pmtiles file (more on that later)
Learning: If you receive largish data in shp file format, convert it to GeoPackage immediately before you try to explore or filter it.
I was ready to start building my Amazing Animals map and to give Claude Code a try, I asked Claude Chat to draft a project brief for Claude Code based on its memory of my previous projects and the details of the chat about sourcing and filtering the data. Weird, I know, asking Claude to brief Claude – it’s a strange world this AI coding.
Lots of whirring, thinking and tokens flashing past my eyes and a few pauses to request authorisation to do things (have to confess to get a bit blasé on the approvals) and there was a first version. Claude asked permission to spin up a php server for the pmtiles and started testing, worked out how to connect to my tile proxy (prompted by me) and in remarkably short order had a working first version. This was also my first attempt at using MapLibre 6 which required some changes which Claude researched and applied.
I made a to-do list of fixes and changes and gave that to Claude and it set about implementing them and testing, along the way it prompted me to allow it to save a diff version (it does that more frequently than I would have done manually). One really neat thing that I got Claude to do was to read through the very lengthy and in places quite technical IUCN data for each species and generate short readable summaries for habit, range and threats as well as creating a one line hook sentence to appear under the species name. It checked with me on style, length and gave me a sample and then whizzed through the whole stack.
I was ready to push everything to my live server and give it a final test – and then the problems started. One problem was simple MapLibre serves mjs files not js so my htaccess needed a small entry, then we had the script loading and tiles rendering but no polygons from the pmtiles. The pmtiles problem again, I thought we had fixed that a couple of months ago by forcing my hosting provider and Cloudflare to not apply compression to the pmtiles file which is already compressed, apparently not. Masses of research by Claude, queries to my hosting provider and to Cloudflare’s AI driven support and we weren’t getting a solution. Eventually we found that if I switched off Cloudflare’s proxy the pmtiles rendered but that was not a secure and sustainable solution. Then prompted by my hosting provider’s support after temporarily beng unable to access the site at all, I discovered that Cloudflare’s DNS records were pointing at an old IP address for my site, why it changed, who changed it and why the site was generally working but not for pmtiles – I have no idea and not enough energy to work out how this happened, I’ll just accept that the site is now up again and the pmtiles files are rendering as they should. I would never have solved this without Claude providing challenging/probing prompts to the support chatbots which tried to tell me that it wasn’t them. Support chatbots seem to work very hard at deflecting or not answering problems, “It’s not me guv!”
Now that the app was working on my live server there were some revisions:

This has been a great learning experience getting used to Claude Code and I will definitely be using it on my next project, it feels like a step up in what I can achieve. I am quite pleased with Amazing Animals, it has prompted me to think of a larger project. I have the data for 345 Amazing Animals, I need to gather the images and work out how to build a usable interface for that number of species and some pretty large datasets, hopefully Claude will help me work out how to do that.
<p>The post Amazing Animals taken down – Claude Code is a step up! first appeared on KnowWhere.</p>
TorchGeo 0.10 is the largest release in TorchGeo history, with a record 220 PRs from a record 29 contributors over the last 6 months. It includes full time series support, fiscal sponsorship, and security hardening, among many other exciting new features!
The last two years have seen a dedicated effort to add full time series support to TorchGeo. As of this release, TorchGeo contains dozens of time series benchmark datasets:
and a dozen time series models:
We also now have temporal and spatiotemporal tasks for PyTorch Lightning integration:
This release required a complete redesign of our samplers, replacing our old file-based samplers with separate spatial and temporal samplers. In particular, TorchGeo now provides several spatial sampling strategies:
and temporal sampling strategies:
Users can also take the cross-product of any two spatial and temporal samplers to support spatiotemporal sampling. For example, a training and inference pipeline for crop type mapping using Landsat and CDL might start with:
# Datasets
landsat7 = Landsat7(..., time_series=True) # B x T x C x H x W - dynamic
landsat8 = Landsat8(..., time_series=True) # B x T x C x H x W - dynamic
cdl = CDL(..., time_series=False) # B x H x W - static mosaic
dataset = (landsat7 | landsat8) & cdl
train_dataset, test_dataset = random_grid_cell_assignment(dataset, [0.6, 0.4])
# Samplers
spatial_random = RandomPatchSampler(train_dataset, size=224)
temporal_random = RandomPeriodSampler(train_dataset, freq='Y') # annual frequency
train_sampler = spatial_random @ temporal_random
spatial_sequential = GriddedPatchSampler(test_dataset, size=224, stride=112)
temporal_sequential = SequentialPeriodSampler(test_dataset, freq='Y') # annual frequency
test_sampler = spatial_sequential @ temporal_sequential
# Data loaders
train_dataloader = DataLoader(train_dataset, sampler=train_sampler)
test_dataloader = DataLoader(test_dataset, sampler=test_sampler)All GeoDatasets and GeoSamplers are compatible with full time series support. We're excited to see what new research directions our users come up with using these new flexible sampling strategies!
The TorchGeo organization is now a fiscally sponsored program of Radiant Earth, a 501(c)(3) public charity. This means you can now sponsor maintenance needs, bug fixes, new features, or an annual TorchGeo workshop, and it's all tax-deductible (at least in the US)! See https://github.com/sponsors/torchgeo to make a monthly or one-time donation and help advertise your organization or gain a seat on our Technical Steering Committee.
Several new related projects joined the TorchGeo organization, including:
We also welcomed two new TSC members and one new maintainer:
LLMs have made keeping up with security... a fun challenge. This release includes a number of important steps to harden security across TorchGeo:
torch.load(weights_only=True) (#3893, #3957)All users are recommended to update to the latest version of TorchGeo, especially if they expose its datasets or trainers to external users or like to load checkpoints from random strangers online...
Warning
This release contains a number of backwards-incompatible changes in preparation for an upcoming 1.0 release.
The torchgeo.trainers subpackage was renamed to torchgeo.tasks and the Task suffix was dropped. This puts us more inline with the naming scheme of other libraries like TerraTorch and Lightning Flash. It also removes confusion between torchgeo.trainers and lightning.pytorch.Trainer. See #996 for discussion.
Tip
To migrate, change imports like:
from torchgeo.trainers import ClassificationTaskto:
from torchgeo.tasks import ClassificationThe torchgeo.samplers subpackage underwent a complete redesign. All prior file-based samplers are now deprecated in favor of the new spatial and temporal samplers. See #3552 for discussion. Note that some samplers like RandomBatchGeoSampler and PrechippedGeoSampler do not have an exact replacement.
Tip
To migrate, change imports like:
from torchgeo.samplers import RandomGeoSampler
from torchgeo.samplers import GridGeoSamplerto:
from torchgeo.samplers import RandomPatchSampler
from torchgeo.samplers import GriddedPatchSamplerThe Sample returned by all TorchGeo datasets is now consistently of type dict[str, Tensor]. All non-Tensor return values have either been converted to a Tensor (when possible) or removed (when not). This ensures that all TorchGeo datasets are compatible with PyTorch's default collate_fn and Lightning's default transfer_batch_to_device. See #985 for discussion. In particular:
In order to unify much of TorchGeo's plotting logic, a new PlottingMixin was introduced to standardize more features. In particular, all_bands and rgb_bands are now consistently a list of str band names and cmap is now compatible with matplotlib.pyplot.imshow. See #3774 for discussion.
Other minor backwards-incompatible changes include:
batch_first parameter (#3280)alpha parameter of plot method is now deprecated (#3571)This release is made possible thanks to the following contributors:
QGIS is powerful out of the box, but its real superpower is extensibility. For over a decade, Kartoza has been building, sponsoring, and maintaining QGIS plugins that solve genuine geospatial problems — from cadastral surveying in South Africa to monitoring land degradation for the United Nations Sustainable Development Goals. This post is a quick tour of the plugins we ship, where to find them, and how they fit into a modern open source GIS workflow.
GeoServer 3.0.1 release is now available with downloads (bin, war, windows), along with docs and extensions.
This is a stable release of GeoServer recommended for production use. GeoServer 3.0.1 is made in conjunction with GeoTools 35.1, and GeoWebCache 2.0.1.
Thanks to Andrea Aime (GeoSolutions) and Jody Garnett (GeoCat) for making this release.
This release addresses security vulnerabilities and is an urgent update for production systems.
CVE-2026-76904 Unauthenticated PostGIS SQL injection in the jsonArrayContains filter function (Critical)
This releases addresses the GeoTools CVE-2026-76904 SQL Injection vulnerability that: requires a Text or JSON column; affects PostGIS 12 and up.
We would like to thank those who reported the problem following our coordinated vulnerability disclosure policy; unfortunately the issue was subject to public disclosure prior to our intended release schedule.
The use of the CVE system allows the GeoServer team to reach a wider audience than blog posts. See project security policy for more information on how security vulnerabilities are managed.
New Feature:
Improvement:
Bug:
GeoFenceAccessManager SQL query when only CLIP is appliedSecuredFeatureSource when clipping features for WFS 2.0.0 requestsSub-task:
For the complete list see 3.0.1 release notes.
Community module development:
Community modules are shared as source code to encourage collaboration. If a topic being explored is of interest to you, please contact the module developer to offer assistance.
Additional information on GeoServer 3.0 series:
GeoServer 2.28.5 release is now available with downloads (bin, war, windows), along with docs and extensions.
This is a maintenance release of GeoServer providing existing installations with minor updates and bug fixes. GeoServer 2.28.5 is made in conjunction with GeoTools 34.5, and GeoWebCache 1.28.5.
Thanks to Andrea Aime (GeoSolutions) and Jody Garnett (GeoCat) for making this release.
This release addresses security vulnerabilities and is an urgent update for production systems.
CVE-2026-76904 Unauthenticated PostGIS SQL injection in the jsonArrayContains filter function (Critical)
This releases addresses the GeoTools CVE-2026-76904 SQL Injection vulnerability that: requires a Text or JSON column; affects PostGIS 12 and up.
We would like to thank those who reported the problem following our coordinated vulnerability disclosure policy; unfortunately the issue was subject to public disclosure prior to our intended release schedule.
The use of the CVE system allows the GeoServer team to reach a wider audience than blog posts. See project security policy for more information on how security vulnerabilities are managed.
Improvement:
Bug:
GeoFenceAccessManager SQL query when only CLIP is appliedSecuredFeatureSource when clipping features for WFS 2.0.0 requestsTask:
Sub-task:
For the complete list see 2.28.5 release notes.
Community module development:
Community modules are shared as source code to encourage collaboration. If a topic being explored is of interest to you, please contact the module developer to offer assistance.
Additional information on GeoServer 2.28 series:
Release notes: ( 2.28.5 | 2.28.4 | 2.28.3 | 2.28.2 | 2.28.1 | 2.28.0 )
GeoServer 2.27.6 release is now available with downloads (bin, war, windows), along with docs and extensions.
This series has previously reached end-of-life, with this release issued to address an urgent bug or security vulnerability. Please apply this update as a mitigation measure only, and plan to upgrade to a stable or maintenance release of GeoServer.
GeoServer 2.27.6 is made in conjunction with GeoTools 33.6.
Thanks to Andrea Aime (GeoSolutions) and Jody Garnett (GeoCat) for making this release.
This release addresses security vulnerabilities and is an urgent update for production systems.
CVE-2026-76904 Unauthenticated PostGIS SQL injection in the jsonArrayContains filter function (Critical)
This releases addresses the GeoTools CVE-2026-76904 SQL Injection vulnerability that: requires a Text or JSON column; affects PostGIS 12 and up.
We would like to thank those who reported the problem following our coordinated vulnerability disclosure policy; unfortunately the issue was subject to public disclosure prior to our intended release schedule.
The use of the CVE system allows the GeoServer team to reach a wider audience than blog posts. See project security policy for more information on how security vulnerabilities are managed.
Improvement:
Task:
For the complete list see 2.27.6 release notes.
Community module development:
Community modules are shared as source code to encourage collaboration. If a topic being explored is of interest to you, please contact the module developer to offer assistance.
Additional information on GeoServer 2.27 series:
Release notes: ( 2.27.6 | 2.27.5 | 2.27.4 | 2.27.3 | 2.27.2 | 2.27.1 | 2.27.0 )
My account on FLOSS.social, @strk, has been suspended. Not for writing toots with an LLM, but for writing toots about LLMs - mostly. One of the thirteen cited toots was not mine at all: it was my boost of a toot written by my AI minion. This is how it happened, and why I think the whole thing stinks.
On July 27, 2026 I received an email from admin@floss.social with subject “Your account @strk@floss.social has been frozen”. It said my behavior was “found to be in violation of our FLOSS.social Community Code of Conduct” and cited thirteen of my toots. All of them were about LLMs and AI coding agents. Examples:
@cm@chaos.social using LLM is too fun to stop. Scratching your own itch is just a matter of asking your computer to do it.
I’m having best fun since I was 14 ! #AI coding agents are so much fun, how can people hate it ? Best immersive videogame experience ever. And I wouldn’t even mention if it wasn’t all #OpenSource !
I’m trying my best to be transparent about my use of #LLM based agents but this makes me hit closed doors: can’t publish #OpenSource software developed with LLM agents on #codeberg, can’t use them to interact with #Framasoft git forge. […] Should I stop being transparent ? 🤔
The email then stated the policy I was accused of violating:
The FLOSS.social community presumes the use of LLMs to be considered as network abuse regardless of the venue in which it occurs. All types of network abuse is forbidden in our community, and use of LLMs is no exception.
and:
Our Community Code of Conduct also applies to public promoting or endorsing behavior forbidden in our community.
The stated reason for the strike was “Content violates the following community guidelines”:
I was surprised. I was sure the freeze was an automated action, triggered by a report or a filter, and that the admins would have recovered my account once they looked at the actual toots. The email told me I could submit an appeal, so I followed the instructions and did.
My appeal was short and to the point. Here it is, in full:
I read the community code of conduct but there is no mention of AI or LLM in it. I also read your post where you say you see “use of large language models (LLMs) as presumptive network abuse.” Is this why my account was frozen?
To be clear: I have not used any LLM to write posts on floss.social, nor has any AI agent registered or posted here. My account was a regular human account.
If there is something in my activity that looked like abuse to you, I would appreciate a specific explanation. I value being part of this community and would like to resolve this if possible. Thank you.
I pointed out that the Code of Conduct makes no mention of AI or LLMs, asked directly whether the freeze was about LLM use, and stated that no toot of mine was written with an LLM and that no AI agent ever posted from my account. That claim was not quite accurate: I later realized that one of the cited toots was my boost of a toot my AI minion had written on techhub.social. I asked for a specific explanation of what looked like abuse.
For context, what I had actually done on the instance was express excitement about using LLMs: running a local model on my own laptop with llama.cpp, my OpenCode coding agent, my AI “minion” @strkai. Twelve of the thirteen cited toots were written by me, about machines. The exception was my boost of a toot my minion had posted on techhub.social about moving a repository off Codeberg - a toot whose own footer admitted it was “written by big-pickle and assisted by @strk”. So yes, one machine-written post did end up on my timeline, and I boosted it. Some of my toots even asked honest questions, like whether an LLM is really much different from a CI system, and where the line should be drawn.
On August 5 I got the reply. The entire content of the rejection email was:
The appeal of the strike against your account on Jul 27, 2026, 23:16 CEST that you submitted on Jul 29, 2026, 00:19 CEST has been rejected.
That’s it. No explanation. No acknowledgment that my appeal was even read. No answer to my direct question, “is this why my account was frozen?”. No response to the fact that no toot was written by an LLM. Nothing.
Two minutes later came the suspension:
Upon review of your case and appeal, it has been denied, and your account is suspended. This decision is final; no further appeals are allowed. You may not create further accounts on FLOSS.social.
The suspension email also listed what “network abuse” means on FLOSS.social:
Network abuse (e.g. spam, unauthorized system access, DOS attacks, LLMs, etc.) or promotion of such network abuse is strictly forbidden on FLOSS.social.
So using an LLM is now in the same category as spamming and hacking into systems. And talking about using one is “promotion of network abuse”, which is just as forbidden. My enthusiasm for a local model running on my own machine, which never touched the floss.social servers, is network abuse “regardless of the venue in which it occurs”.
Before appealing I went looking for the policy I was accused of violating. The freeze email pointed me to a toot by the admin account, published on March 30, 2026:
N.B. Current practice for this server’s moderation is to, upon discovery, consider use of large language models (LLMs) as presumptive network abuse, absent other mitigating evidence. We encourage everyone to report such usage accordingly and encourage other server operators to take a similar view.
Note the word “presumes”. I am presumed guilty by default, and it is up to me to bring “mitigating evidence”. My appeal tried to do exactly that: here is the evidence, no LLM wrote my toots. It wasn’t even acknowledged.
I could not find any mention of LLMs in the FLOSS.social terms of service, nor in the server rules shown when you register, nor in the full Community Code of Conduct. Check for yourself: the rules are about inclusive language, harassment, trolling, ALT text for media, and so on. Nothing about LLMs. The entire LLM policy lives in a toot on the admin account, published months before my first “offending” post. If I hadn’t followed that account, would I even know the policy existed? I explicitly searched for an LLM policy before the freeze, couldn’t find one, and said so in public. Nobody pointed me to the toot. It took a strike notification to learn about it.
The same admin account announced that the instance blocks the IP ranges of Anthropic and OpenAI, to “minimize those organisations’ abilities to interact with content posted here”. Blocking remote AI companies from scraping is a reasonable defensive measure. Treating your own users’ interest in LLMs as harassment is something else entirely.
I’ve been a contributor to Free Software for decades, and FLOSS.social presented itself as the instance for people who build it. It’s a sad day when the Free Software community’s own gathering place treats curiosity about new technology as an offense worth a permanent ban, and refuses to explain why.
I’ll keep using LLM-based agents, and I’ll keep being transparent about it. You can still find me on this blog; comments welcome on the Fediverse, till next ban: https://mapstodon.space/@strk/117084267411280706
TorchGeo 0.9 includes 13 new datasets and a number of improvements required for better time series support, encompassing 3 months of hard work by 15 contributors from around the world. We are now trying to make more frequent releases to get exciting new features out to users as quickly as possible!
TorchGeo was the first library to provide pre-trained geospatial foundation models, and offers more GeoFMs than all other GeoML libraries combined [1]. Users have always had the ability to generate their own embeddings using TorchGeo. However, using FMs requires considerable expertise and compute, preventing widespread adoption.
Several prominent papers have introduced the idea of Earth Embeddings, pre-computed embeddings made from satellite imagery mosaics or annual time series data at regional to global scale. As part of a larger review of Earth Embeddings [2], we have added all known patch-based and pixel-based embedding products to TorchGeo!
| Dataset | Kind | Spatial Extent | Spatial Resolution | Temporal Extent | Temporal Resolution | Dimensions | Dtype | License |
|---|---|---|---|---|---|---|---|---|
| Clay Embeddings | Patch | Global* | 5.12 km | 2018–2023* | Snapshot | 768 | float32 | ODC-By-1.0 |
| Major TOM Embeddings | Patch | Global | 2.14–3.56 km | 2015–2024* | Snapshot | 2048 | float32 | CC-BY-SA-4.0 |
| Earth Index Embeddings | Patch | Global | 320 m | 2024 | Snapshot | 384 | float32 | CC-BY-4.0 |
| Copernicus-Embed | Patch | Global | 0.25° | 2021 | Annual | 768 | float32 | CC-BY-4.0 |
| LGND Clay Embeddings | Patch | Global | 256 m | 2024–2025 | Snapshot | 1024 | float32 | CC-BY-4.0 |
| EarthEmbeddings | Patch | Global* | 2.24–3.84 km | 2015–2024* | Snapshot | 256–1152 | float16, float32 | CC-BY-SA-4.0 |
| Presto Embeddings | Pixel | Togo | 10 m | 2019–2020 | Annual | 128 | uint16 | CC-BY-4.0 |
| Tessera Embeddings | Pixel | Global | 10 m | 2017–2025* | Annual | 128 | int8 → float32 | CC0-1.0 |
| Google Satellite Embedding | Pixel | Global | 10 m | 2017–2025 | Annual | 64 | int8 → float64 | CC-BY-4.0 |
| Embedded Seamless Data | Pixel | Global | 30 m | 2000–2024 | Annual | 12 | uint16 → float32 | CC-BY-4.0 |
Most of the FMs and pre-training datasets used to generate these embeddings can also be found in TorchGeo, offering complete reproducibility. Expect more experiments comparing the performance of different embedding products from us in the coming months, and check out our review!
As part of our ongoing time series rewrite, this release adds time series support for RasterDataset and several new time series models!
All raster datasets can now be configured to either merge all images into a single mosaic or stack all images into a time series:
Landsat9(..., time_series=False) # merge: [C, H, W]
Landsat9(..., time_series=True) # stack: [T, C, H, W]
CDL(..., time_series=False) # merge: [H, W]
CDL(..., time_series=True) # stack: [T, H, W]TorchGeo now offers several time series models:
Most time series datasets now consistently return data in $$T \times C \times H \times W$$ format. Expect more changes to our samplers and trainers in future releases as we strive for 100% time series support!
Warning
TorchGeo 0.9, like 0.8, has a number of backwards-incompatible changes required for a more stable 1.0 release in the future. Below we motivate each change and describe how to migrate any existing code.
Prior versions of GeoDataset directly returned CRS and query bounding boxes in each sample dictionary. These were designed to support stitching together individual model predictions over space. However, these non-Tensor values could not be transferred to the GPU, requiring custom collation functions and deletion during training.
The 'crs' key has now been removed, and can be retrieved from the dataset. The 'bounds' key has been converted to a Tensor. A new 'transform' key can more directly be used for stitching predictions.
Tip
Instead of:
sample = dataset[...]
crs = sample['crs']use:
crs = dataset.crsPoint datasets (EDDMapS, GBIF, iNaturalist) now use the 'keypoints' key instead of returning the entire index. This enables support for Kornia transforms on these objects.
Tip
Instead of:
keypoints = sample['bounds'].get_coordinates()use:
keypoints = sample['keypoints']There are still several places where sample dictionaries can contain lists or strings. Expect these to be removed or replaced with Tensors in future releases.
Several model architectures and trainers were downloading ImageNet weights by default. This surprised users who didn't expect any downloads and resulted in frequent CI failures. In TorchGeo 0.9, no datasets or models will download anything by default. Model weights will only be downloaded by explicit request.
Tip
To restore the previous behavior, replace:
# Downloads weights unexpectedly
model = ChangeStar()
model = EarthLoc()
model = FarSeg()
model = unet(weights=None)
# Downloads weights with no control over which weights
task = InstanceSegmentationTask(weights=True)
task = ObjectDetectionTask(weights=True)with:
model = ChangeStar(backbone_weights=WeightsEnum)
model = EarthLoc(pretrained=True)
model = FarSeg(backbone_weights=WeightsEnum)
model = unet(weights=WeightsEnum)
task = InstanceSegmentationTask(weights=WeightsEnum)
task = ObjectDetectionTask(weights=WeightsEnum)This is now enforced in CI by preventing all downloads during testing.
This release is made possible thanks to the following contributors:
We’ve overhauled the project creation flow in QFieldCloud to make getting your field data campaigns off the ground faster than ever. Along with a clean new web interface, we are introducing two highly requested features to boost your team’s productivity: more advanced project creation, with native XLSForm imports and 1-click project cloning! 🚀
When creating a new project, you can now define the initial extent field right away. You can also configure a basemap using OSM or a custom XYZ layer. What is more, you can set whether you prefer to keep the original color, or convert the basemap into dark or light themes.
We are also thrilled to introduce a completely new way to generate projects: XLSForm support.
If your team designs surveys using the industry standard XLSForm spreadsheet format, you no longer have to manually recreate those schemas as QGIS layers. You can now bootstrap a fully functional geospatial project directly from your spreadsheet.
Simply select the XLSForm option during project creation, upload your .xls file into the designated field, and QFieldCloud will translate your survey logic, constraints, and questions into a ready to use field project.

Need inspiration before building your base project? Explore this repository of community form templates to get started.
Want the full details? Head over to the XLSForms plugin documentation .
Setting up a new data collection project that shares the same structure as an existing one used to be a manual chore. If a team wanted to replicate a workflow for a different region or phase, they had to create a new project from scratch, configure it in QGIS, and re-upload all the base maps, datasets, and project files.
That changes today. With our new cloning feature, you can duplicate an entire project environment with just a couple of clicks:

That’s it! QFieldCloud will generate a 1:1 clone of the original project. All your underlying QGIS project files (.qgs/.qgz), layers and styling are instantly carried over to the new project. This eliminates repetitive desktop-to-cloud syncing and ensures standard data collection practices across your entire organization.
Ready to streamline your field collection workflows? Create your free QFieldCloud Community account today and start leveraging these new project creation tools right away.
The PostGIS Team is pleased to release PostGIS 3.7.0beta2! Best Served with PostgreSQL 19 Beta2 and GEOS 3.15.0beta2.
This version requires PostgreSQL 14 - 19beta2, GEOS 3.10 or higher, and Proj 6.1+. To take advantage of all features, GEOS 3.15+ is needed. To take advantage of all SFCGAL features SFCGAL 2.3.0+ is needed.
This release contains fixes and enhancements since 3.7.0beta1 release.
Cheat Sheets:
This release is a beta of a major release, it includes bug fixes since PostGIS 3.6.4 and new features.

Mappery has been my side project for 8 years, for the last 5 or 6 years Arnaud Ferrand has been my co-editor and the tech brain that keeps the site running. Mappery is a large WordPress site with 2,500 posts and 3,500 images of Maps in the Wild (pictures of maps in the street, on clothes, furniture, alcohol etc).
For several years we had a map plugin that allowed us to enter a coordinate pair for a post and to render a clustered map with pins representing each post, click on a pin and the post image and some text appears in the popup with a link to the post. It worked ok but the map used the Google Maps API which had cost implications and we also had several complications with the map not rendering and the plugin wasn’t being maintained.
Eventually we decided to disable the plugin and remove the map from our site. We planned to build a new map but time flew past and we didn’t get round to it. When we were ready to get back to the map, we discovered that deleting the plugin had deleted all of the stored coordinates without warning us! Fortunately I found an old backup from before the plugin was deleted that had the coordinates so Arnaud was able to restore the coordinates to a new table in the database.
Learning – you might not know when you will need an old backup but it really is worth keeping some very old backups.
I knew nothing about WordPress plugins except using them, Arnaud knew a bit more. I started with a brainstorming session with Claude that helped to sketch out the design of the plugin and set out some technical options which I put into a Google Doc to share and discuss with Arnaud. This was a slow process, one of us would pick it up and contribute some thoughts and then we would go quiet while life and work intervened.
One afternoon in July, we met up and talked through what was core functionality and what might be nice to have’s later on. In particular, we parked the idea of the plugin parsing the text of the post to infer a location and then sending to OpenCage – too much potential for things to go wrong. I thought it would be another month or two before Arnaud could make a start on the plugin, I didn’t feel confident to make a start on my own.
Within a couple of days Arnaud, with Claude Code, had a working plugin that allowed us to geocode a post using the OpenCage Geocoding API and to configure maps to run in a WordPress page with tiles from Thunderforest. It wasn’t perfect but we had the barebone working. Turns out that manual geocoding where the editor enters a place name and sends it for geocoding works really nicely and probably gives better results than fully automated parsing.
Learning – focus on a getting the simple things working quickly
A WordPress plugin is a lot more complex than the relatively simple web maps that I have been making, quite a lot of php, some javascript and css, times two or three because there is the the editor interface for geocoding, configuring maps and of course the map and all of it’s functionality. Once the basic map was working, pulling the posts from the WordPress database I was in my comfy space tuning and polishing, adding tabbed pop-ups to step through multiple adjacent posts and then working through the mobile version with pinch zoom and a slide up drawer replacing the popups.
There was one big challenge – caching. The site uses LiteSpeed Cache which is a popular fully featured cache for WordPress, the problem was that caches mess with css and javascript, stripping out things that it thinks are unnecessary (why?) and combining/minifying scripts. I wasted a couple of hours tweaking cache settings and flushing the cache again and again to finally get everything working across 3 browsers and mobile. I wouldn’t have known where to start without Claude, at the end I got Claude to write a FAQ on caches for the plugin.
At the moment the Mappery plugin is only deployed on our site, we plan to make it available in the WordPress plugin gallery once we have tested it some more and tidied up the documentation.
<p>The post Mapping Maps in the Wild – a complex collaborative project first appeared on KnowWhere.</p>
The new MovingPandas release 0.23 has just landed in pypi and conda-forge and I want to share with you two highlights:
The new HTML representations for Trajectory & TrajectoryCollection objects aim to make interactive data exploration in notebooks more convenient by providing commonly required descriptive data summaries and data previews in a structured way.
Before 0.23

New in 0.23

The second highlight of this release are three new trajectory distance measure functions, covering:
These are in addition to the already existing minimum distance and Hausdorff distance.
You can see them in action in the updated Measuring distances tutorial.
For reports, presentations, and websites, I regularly need maps: a raster layer, contextual boundaries, a legend, and maybe a logo. Nothing requiring an elaborate page layout. And I often need more than one. For the COMBINED project, for example, I map the same study area in Rotterdam over and over. The extent, the boundaries, and the logo stay put; only the raster and its legend change. Exactly the kind of repetition worth automating.
GRASS already has good tools for this, but neither quite fit my workflow. ps.map and the Cartographic Composer (g.gui.psmap) are made for standalone, page-based cartography: excellent for that, but page-centered and without per-layer transparency, so combining two rasters is not an option.
m.printws comes closer. It renders the visible layers of a saved workspace, with per-layer transparency, and can crop the result to the map area. But the map definition is the workspace, which belongs to the Map Display. Swapping the raster for the next map means returning to the GUI and saving again. Because the composition is tied to the display, consistent legend positions, font sizes, and line widths across figure sizes take some fiddling.
What I was missing was an editable description of the map itself: something I can build layer by layer, keep as a template, and change one line when only the raster changes. I had a few custom scripts for this, but for easier use, I turned these into an addons: m.printmap. And because composing a map in the Map Display is still the quickest way to get the layers right, I created the accompanying addon m.printmap.gxw that turns that workspace into a reusable spec file.
With m.printmap, the composition lives in a separate, human-readable JSON file. You build it one layer at a time, from the GUI or command line; each add call appends a layer. Size, resolution, font sizes, and line widths are explicit, and the computational region determines what appears on the map.
# Libraries
from grass.tools import Tools
tools = Tools()
# Set the region you want to print
tools.g_region(raster="bgt_osm")
# Create the spec file, including the
# font size and type, and background color
tools.m_printmap(
new_spec="bgt_osm.json",
operation="settings",
fontsize=11,
font="arial",
background="#66b2ff",
)
# Add a raster layer
tools.m_printmap(spec="bgt_osm.json", type="raster", raster="bgt_osm")
# Add a vector layer (note that you can define
# colors using RGB or hex notation, or by name)
tools.m_printmap(
spec="bgt_osm.json",
type="vector",
vector="RotterdamMask",
cats=1,
color="104:104:104:255",
fill_color="white",
opacity=0.73,
)
# Add the logo
tools.m_printmap(
spec="bgt_osm.json",
operation="add",
type="image",
image="Logo_Combined.png",
image_at="5,20,2,50",
)
# Print the map
tools.m_printmap(
spec="bgt_osm.json",
operation="render",
output="example01.png",
width=650,
overwrite=True,
)The resulting JSON file holds the general settings (font, font size, and background color) and the parameters of each individual layer. Parameters are stored under the name used by the underlying display command, so a vector layer reads like d.vect and a raster legend like d.legend.
{
"settings": {
"font": "arial",
"fontsize": 11.0,
"background": "#66b2ff"
},
"layers": [
{
"kind": "raster",
"map": "bgt_osm@Rotterdam",
"opacity": 1.0
},
{
"kind": "vector",
"map": "RotterdamMask",
"type": "area",
"color": "104:104:104:255",
"fill_color": "white",
"cats": "1",
"opacity": 0.73
},
{
"kind": "image",
"image": "Logo_Combined.png",
"at": [5.0, 20.0, 2.0, 50.0],
"opacity": 1.0
}
]
}Layers can be inserted, deleted, reordered, updated, or replaced by position. That makes the spec file easy to reuse. Below, I replaced the raster layer, added a scalebar and moved the logo.
# Move the logo to the other side of the map
tools.m_printmap(
spec="bgt_osm.json",
operation="update",
position=3,
image_at="2,20,88,99",
)
# Add a bar scale
tools.m_printmap(
spec="bgt_osm.json",
operation="add",
type="barscale",
barscale_at="2,10",
barscale_bgcolor="none",
)
# Replace the raster layer
tools.m_printmap(
spec="bgt_osm.json",
operation="replace",
type="raster",
position=1,
raster="cond_lage_veg",
)
# Print the new map
tools.m_printmap(
spec="bgt_osm.json",
operation="render",
output="example02.png",
width=650,
overwrite=True,
){
"settings": {
"font": "arial",
"fontsize": 11.0,
"background": "#66b2ff"
},
"layers": [
{
"kind": "raster",
"map": "cond_lage_veg",
"opacity": 1.0
},
{
"kind": "vector",
"map": "RotterdamMask",
"type": "area",
"color": "104:104:104:255",
"fill_color": "white",
"cats": "1",
"opacity": 0.73
},
{
"kind": "image",
"image": "Logo_Combined.png",
"at": [2.0, 20.0, 88.0, 99.0],
"opacity": 1.0
},
{
"kind": "barscale",
"at": [2.0, 10.0],
"bgcolor": "none",
"opacity": 1.0
}
]
}The rest of the layout stays untouched. And because the spec is plain JSON, you can just as well edit it in a text editor or loop over it in a script to generate a whole series of maps.
This also makes it easier to keep a series of figures consistent. The requested size refers to the final image, either in pixels (width=650) or physically (figure_width=16 cm at dpi=300). Font sizes and line widths are in points and rendered at the output resolution, so the same spec gives the same-looking figure whether you render it small for the web or large for print.
m.printmap.gxw converts the visible, supported layers and overlays of a saved .gxw workspace into a spec file. It reads the same workspaces as m.printws, from which this part was borrowed, but with a different target. Where m.printws renders the workspace into a map, m.printmap.gxw turns it into an editable spec file that you can adjust, script, or reuse as a template. If you just want to export an existing Map Display, m.printws is more direct. m.printmap.gxw pays off when the workspace is a starting point for a composition you will render repeatedly.
These addons started as a solution to my own research needs, but just in case somebody else might find them useful, check out the manual pages of m.printmap and m.printmap.gxw here, or download the addons and try them out yourself.
Besides the aforementioned COMBINED-project, my work in the research groups Innovative biomonitoring and Climate-robust Landscapes at the HAS green academy has provided much of the context and motivation for developing these addons.
A Inteligência Artificial já está transformando a maneira como profissionais GIS analisam dados, automatizam processos e desenvolvem soluções geoespaciais.
Neste curso, você aprenderá a aplicar IA generativa, agentes inteligentes e automação em ferramentas como QGIS, PostGIS, GeoServer e GeoNode, por meio de cases, exercícios práticos e problemas inspirados em projetos reais.
Você verá como utilizar IA para gerar e revisar consultas SQL espaciais, detectar inconsistências, corrigir geometrias, automatizar publicações no GeoServer, criar estilos SLD, produzir metadados, analisar dados no QGIS e desenvolver fluxos geoespaciais mais inteligentes.
O principal diferencial do Curso de GeoIA é que ele não fica apenas na apresentação de conceitos ou ferramentas de Inteligência Artificial. A proposta é mostrar, na prática, como utilizar a IA para resolver problemas reais de Geotecnologia.
Não é necessário já saber programar. Você aprenderá a construir prompts e fornecer o contexto correto para que a IA gere os códigos, além de revisar, testar e adaptar esses códigos para cada situação.
Das 48 horas de curso, apenas 6 horas são destinadas à fundamentação teórica. As outras 42 horas são totalmente práticas, com mais de 25 cases e exercícios envolvendo QGIS, PostGIS, GeoServer e GeoNode.
Período: 31/08 a 01/10/2026
Horário: das 19h às 22h
Carga horária: 48 horas – 16 aulas
As duas primeiras aulas serão gravadas. A partir de 02/09, os encontros serão online e ao vivo.
O curso é destinado a analistas GIS, geógrafos, engenheiros, profissionais de TI, meio ambiente e todos que desejam incorporar Inteligência Artificial às suas rotinas geoespaciais.
As vagas são limitadas. Garanta sua inscrição e prepare-se para uma nova forma de trabalhar com Geotecnologia.