Yesterday I gave a talk at Geomob London on my adventures in vibe coding. The slides are pretty but probably don’t tell the whole story unless you have been reading my regular posts on my projects.

The images in the slides are all cartoons of an old dog learning new tricks and got some praise, the way I made them was interesting, so i thought I would post about it.

I started out by building an empty slide deck on Google Slides, each slide had a title and a few had a handful of words, they all had spaces for an image. I asked Claude:

• I am building a slide deck for a talk about making maps with AI that is called “You CAN teach an old dog new tricks!”
• I want to create about 11 coloured cartoon images to use in this presentation. the style should be light with watercolour style fills (not perfect solid colours)
• The initial one should be based on “You CAN teach an old dog new tricks!” and should have an old dog learning to make a map. This old dog should be the central character in all of the cartoons and should be visibly recognisable as the same dog in most of the cartoons (I will prompt you when the dog should not appear)
• Some cartoons will need to be landscape to fill most of a slide, some should be portrait to fill half of a slide with text filling the other half, I will include this info in each prompt
• What more info do you need? Can you read my slide deck on google slides?

Claude responded by suggesting that it draft prompts for each image and that I use Nano Banana (the image tool in Gemini) to generate the images because it was much better at image generation than Claude!

We then worked through a short process where I uploaded a picture of myself, we refined the spec for the dog character and Claude parsed my slides and suggested a brief summary idea/description of what the dog would be doing in each slide and whether it was landscape or portrait. Very little tuning was needed. Then Claude generated a Character Sheet that I would instruct Nano Banana to use in every image and a prompt for each slide image, here is the first one (the opening slide image at the top of this post):

• Character Sheet (the fixed description — reused in every prompt)
  An old, lean and lanky anthropomorphic dog character, standing or sitting upright like a person. He has grey/silvery fur, and is balding on top of his head with a few wispy grey hairs remaining at the sides. He wears round, black-framed glasses and a red collar. He has a warm, big, toothy grin — friendly and good-humoured rather than fierce. Rendered in a light watercolour cartoon illustration style: soft, loose watercolour washes with visible paper texture and gentle colour bleeds at the edges, not flat solid colours. Plain white background, no scene or setting painted in behind him.
  
• Title slide — “You CAN teach an old dog new tricks!”
  Orientation: Landscape (16:9)
  [Character Sheet] He is sitting at a desk, peering with curious concentration through his round glasses at a laptop showing a simple map on the screen, one paw resting on the keyboard, a pencil tucked behind one ear and a stack of books beside him. His expression is puzzled but determined, like he’s just starting to figure something out. Light watercolour cartoon style, plain background. Landscape orientation, 16:9.

I am particularly impressed at the almost collaborative approach that Claude took to fulfilling this task by drafting the prompts for Gemini.

You can look through the slides and form your own opinion of the images, if I didn’t know better I would almost say that Claude had a sense of humour!

<p>The post You CAN teach an old dog new tricks first appeared on KnowWhere.</p>

When Ed challenged me to make a map of Geomob Events on a podcast, I jumped in scraped the data and produced quite a nice map despite fighting a battle with Gemini to extract the data for the map from the markdown files of the Geomob website. The problem, as Ed pointed out retrospectively was that the events map was going to be difficult to maintain as further events got scheduled, it was very much a snapshot at a point in time and my suggestion that someone could edit the json file of events was not very practical.

Ideally the map needed to auto-update when a new event was added or the details of an event were changed but that would mean detecting changes to the markdown and updating the events file accordingly – that might be possible but it felt complicated and open to errors, I wanted a simpler solution. I thought that a non technical interface to add/update event details that connected to the map might be the way to go. I wondered whether a Google Sheet might be a way to do this, Sheets has a good user access model so that only authorised users can update the events model and avoided having to build a whole admin interface and user management function. Claude suggested that I could publish the sheet as a csv feed/file online and then build the map from that, we tested that and it worked perfectly, there is a lag of a few seconds between updating the sheet and the csv being published but it is as close to real time as most applications would need. I added some validation checks to the sheet to ensure that anyone editing can’t make a deal breaking mistake. Re-using some of the code from the geocoding element of the Mappery WordPress plugin, I added a geocoding app script to the sheet which looks up the event city and geocodes it using the OpenCage Data API.

Once the csv route had been tested it was fairly quick and easy to parse the old json file add it to the Sheet, add the events added to the Geomob website since I built the original and then build a new events map using the styling of the Geomob website and with pretty much the same functionality as the first map. Becaus the data was easy to work with I added a search for a speaker name which shows all of the events at which they have spoken – Ed Freyfogle has spoken at 12 events and is way out in the lead, I am in joint 3rd place at 5 appearances.

The map still doesn’t auto-update but this is a good compromise. More importantly, it opens up the possibility of making more maps in the future using this Google Sheets approach and possibly creating a Form to update the Sheet as an even simpler interface.

<p>The post Mapping a Google Sheet – reworking the Geomob events map first appeared on KnowWhere.</p>

Sorry, this entry is only available in French.

Workshops The conference opened with two days of hands-on workshops. Our team ran five of them, covering the three products end to end: an introduction to GeoNode, an introduction to MapStore, a developer session on building MapStore extensions, and two GeoServer 3 sessions on OGC APIs and on vector tiles. The introductory slides are embedded below, the full workshop material is available on request.

Our Presentations Below you can find all the presentations delivered by our team, grouped by product. If you missed the event or want to revisit some of the content, everything is embedded here for easy access.

Thanks to the organizers of FOSS4G Hiroshima 2026 for a great event, and to everybody who stopped by our booth or joined our sessions. See you at FOSS4G North America 2026 in Sacramento in November.

If you are interested in learning about how we can help you achieving your goals with open source products like GeoServer, MapStore, GeoNode and GeoNetwork make sure to talk to us!

The GeoSolutions team,

I’ve been testing Codeberg for over a year now, with Trajectools being the largest repo that has already moved its headquarters from Github to Codeberg.

I have been very happy with the experience so far and – at the same time – I couldn’t help but notice the further decline of Github performance.

Therefore, in the upcoming weeks, I am planning to move the remaining MovingPandas repos. For anyone who wants to contribute, this means that:

• All further development will move to Codeberg.
  • Codeberg LLM usage policies apply
• GH repos will remain as read-only mirrors for now.
• Issue trackers and pull requests on GH will be deactivated.

5 months ago, I laid down the plans for what was going to happen going forward with my various open source projects. But after that post, it has been nothing but ... silence! If you were to look at my GitHub contribution graph, there was also a noticeable drop-off there too.

So what happened?

What happened was there was a major rug-pull. GitHub copilot changed their pricing model to usage-based billing on June 1 and that completely threw by GH copilot powered plans into complete disarray. The existing subscription at that point pretty much amounted to ~30 spins on the AI slot machine per month, hoping it will produce the outcome I desire and that was just untenable for something I am paying out of my own pocket!

So come June 1, I terminated my GitHub copilot pro subscription and pondered what my next moves were going to be. I wasn't going to give up on the productivity gains that agentic coding gave me, so the option was clearly to look for alternative AI coding provider. Because try as I might (I religiously keep watch on advancements in LocalLlama), locally hosted AI coding models is not (yet) tenable on my personal hardware. I bought that PC to 6 years ago to last a decade at least, and it will still last a decade as long as you give up on locally hosted AI models as desired workload.

I eventually settled on Deepseek and straight away, its payment model was very attractive to me: Just load up your account on credits and reload when credits start running low. This was a low risk approach where I loaded up $20 $10 USD in credits, give it a spin on my various open source projects. If Deepseek didn't pan out for my use cases, no harm, no foul. I simply don't reload with any more credits. But if it did work out for me, I can just load more credits as I go.

So as my initial $20 $10 load is down to its final dollar after several months of sporadic evaluation. I can confidently say that Deepseek adequately meets my AI coding agent needs while maintaining the "bang for buck" that I used to have with GH copilot before their June 1 rug-pull. I will lose some capabilities from GH copilot (cloud agents was nice), but they are acceptable losses.

So what that means in the grand scheme is that I should start ramping up my OSS dev machinery again and resume the plans that I had stated 5 months ago. Our regular broadcasting will resume shortly!

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.

Watch the keynote

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?”

• The most 5 common names?
• How many single name pubs (ie not repeated)?
• Any regional patterns in naming?
• Anything else?

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.

Answers

These answers were all generated by Claude based on the prompt above.

Top 5 most common pub names

1. Red Lion — 489
2. Royal Oak — 402
3. White Hart — 254
4. Crown — 251
5. White Horse — 222

Ignoring “The”

One-off names

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.

Regional naming patterns

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].”

A few more

• 6.3% of named pubs carry a royalty/heraldry theme (king/queen/crown/royal/prince/castle)
• 10.1% are animal-themed (lion, horse, hart, swan, fox, eagle…)
• Density extremes: Cities of London and Westminster tops the ranking at ~61 pubs per 10,000 people; East Ham sits at the bottom with under 1

<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.

Data Pipeline

• Sources: OpenStreetMap (primary, community-verified) + FHRS food hygiene register (fills gaps OSM misses) + VOA business rates data (independent cross-check for confidence)
• Decision: trust OSM’s classification over FHRS’s where they disagree on whether somewhere is really a pub (FHRS’s “pub/bar/nightclub” category catches restaurants, hotels, and private clubs that aren’t genuinely pubs)
• Matching FHRS→OSM in three passes: direct ID join (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 entirely
• Filtering the unmatched residue: excluded clubs/halls/societies/campsites by name pattern, awaiting-inspection registrations.
• 3 Confidence tiers: verified (OSM), likely (FHRS + independently confirmed by VOA), unverified (FHRS only) – there are ca. 4,000 uncertainties that need eyes on to validate.
• Postcode based de-dupe: caught ~90 near-duplicates the distance-based matching missed (same postcode + similar name, just outside the tighter thresholds)
• Choropleth polygons: calculated using geopandas and the topojson library rather than QGIS and then simplified to reduce file size
• Locality enrichment via OpenCage reverse geocoding: neither OSM nor FHRS reliably tags the actual village/town name, so every pub’s coordinates get reverse-geocoded once, cached by id so it’s cheap on refresh

Learning: 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).

App Build

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.

• Iteration 1 — clustering vs. zoom-gating: started with a simple zoom threshold for showing points; a real screenshot of a dense area (Manchester, ~250 raw points on screen) proved that wasn’t enough then switched to MapLibre clustering, tuned by testing the actual worst-case density areas (validated against all 650 constituencies programmatically, not just spot-checked)
• Iteration 2 — panel redesign: the original panel changed its content based on zoom/toggle state, which read as confusing in testing; redesigned to one persistent search+rankings view with a single detail overlay as the only other state
• Iteration 3 — search, three rounds of real bugs: comma in a query breaking matching (“Kings Head, Islington”), then substring matching producing false positives (“kings” matching inside “Kingston”), then apostrophes silently excluding real results (“King’s Head” not matching “kings head”) — each one found via real testing, not anticipated in advance
• Iteration 4 — mobile rethink: dropping the choropleth map (too small on mobile screen) and using a bottom drawer that slides up for search and map click results which feels like the best mobile UX I can come up with
• Iteration 5 — OSM contribution loop: added “Add to OpenStreetMap” / “Edit on OpenStreetMap” links straight into the iD editor for the exact pub

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.

Some Interesting Pub Name Facts

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.

Main highlights

Bookmark manager

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.

Rock-solid camera

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 .

QFieldCloud-delivered project templates

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 ;)

Polished cloud project management

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 !

Wait, there’s more

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.

Still wondering what the summer of stability means for you?

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.

“Danube” release name

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.

• source download md5

• NEWS

• HTML Online en ja zh_Hans fr

• PDF docs: en ja, zh_Hans, fr

• Cheat Sheets:

  • postgis: en ja zh_Hans fr
  • postgis_raster: en ja zh_Hans fr
  • postgis_topology: en ja zh_Hans fr
  • postgis_sfcgal: en ja zh_Hans fr

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

Read full topic

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

Read full topic

Preparing for Scale Before It Hurts

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:

1. Check the note that we keep of where we finished in our last posting session
2. Search the social platform for the next @ or #
3. Download the image in the social post
4. Copy the text of the post if it is relevant to quote
5. Start a new post in our WordPress dashboard
6. Upload the image to WordPress
7. Paste in any content from the social post
8. Finish editing the post, save the draft
9. Schedule for publishing
10. Repeat!

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:

• “This is a map of where people have found and recorded the species, not a map of the species’ true range or population size — a well-visited national park can look “busier” than a remote area the species is actually just as common in, simply because more people are there to record it. Birds and fish can also turn up well outside their usual range — a storm-blown vagrant, a fish following a current — so an isolated sighting far from a species’ other hexagons isn’t necessarily a mistake.“

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.

• source download md5

• NEWS

• HTML Online en ja zh_Hans fr

• PDF docs: en ja, zh_Hans, fr

• Cheat Sheets:

  • postgis: en ja zh_Hans fr
  • postgis_raster: en ja zh_Hans fr
  • postgis_topology: en ja zh_Hans fr
  • postgis_sfcgal: en ja zh_Hans fr

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/

Update

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 broken the Red List Terms of Use by reposting the range maps without prior written consent from IUCN … The Red List Partners have therefore requested that I decline your request for the additional data and that I ask you to please take down what you have done as it is in breach of the Red List Terms of Use.”

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:

• “To increase awareness of the enormous variety of life on our planet, and raise the profile of threatened species, in 2010 IUCN launched the IUCN Red List ‘Species of the Day’ and this was then followed in 2011 by IUCN’s ‘Amazing 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:

• I changed the way users explore the site on a desktop, users are now prompted to explore the map to see what endangered species are at the location of a mouse click rather than showing a mass of meaningless polygons.
• I changed the mobile interface to make it search driven, the user selects a species from the search dialogue and the info card is opened, tapping on the handle of the card minimises the card and displays the map with the extents of the species shown. It’s not perfect but it’s the best I could think of, if you have an idea for how the mobile interface might better work, leave a comment.
• I asked Claude to make an og-image for social media and it did a much better job than just screen shotting.

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.0 Release Notes

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!

Highlights of this release

Full time series support

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:

• Temporal classification: CropHarvest
• Temporal regression: Air Quality (new), Western USA Live Fuel Moisture
• Change detection: BRIGHT, CaBuAr, ChaBuD, Copernicus-Bench, LEVIR-CD, LEVIR-CD+, OSCD, xBD, xBD DistShift (new)
• Spatiotemporal classification: Copernicus-Bench, Digital Typhoon, QuakeSet
• Spatiotemporal regression: Digital Typhoon, SKIPP'D, SustainBench, QuakeSet
• Spatiotemporal segmentation: Benin Cashew Plantations, Copernicus-Bench, FLAIR-HUB (new), Kenya Crop Type, PASTIS, Rwanda Field Boundary, SeasoNet, South Africa Crop Type, Substation, ZueriCrop
• Spatiotemporal pixelwise regression: BioMassters, Copernicus-Bench

and a dozen time series models:

• 1D time series: L-TAE, Presto, Tessera
• 3D change detection: BTC, ChangeStar, ChangeViT, FC-Siamese Networks
• 3D SITS: ConvLSTM, Conv3dLSTM (new), OlmoEarth (new), Satlas
• 4D ocean and atmosphere: Aurora

We also now have temporal and spatiotemporal tasks for PyTorch Lightning integration:

• 1D: temporal regression (new)
• 3D: change detection, spatiotemporal segmentation (new), spatiotemporal pixelwise regression (new)

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!

Fiscal sponsorship and new projects

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:

• TerraTorch: for GeoFM fine-tuning
• TerraKit: for dataset curation
• torchgeo-bench for GeoFM benchmarking

We also welcomed two new TSC members and one new maintainer:

• @romeokienzler (IBM) - TSC, maintainer of TerraTorch, TerraKit
• @Isabelle-Wittmann (IBM) - TSC, maintainer of TerraTorch
• @robmarkcole (EarthDaily) - maintainer of TorchGeo

Security hardening

LLMs have made keeping up with security... a fun challenge. This release includes a number of important steps to harden security across TorchGeo:

• Clarifications to our security policy (#3952)
• Datasets: checksum by default (#3930)
• Models: checksum by default (#3929)
• Convert many datasets from MD5 to SHA256 checksums (#3428, #3894, #3899, #3946)
• Always use 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...

Backwards-incompatible changes

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.

from torchgeo.trainers import ClassificationTask

from torchgeo.tasks import Classification

The 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.

from torchgeo.samplers import RandomGeoSampler
from torchgeo.samplers import GridGeoSampler

from torchgeo.samplers import RandomPatchSampler
from torchgeo.samplers import GriddedPatchSampler

The 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:

• Copernicus-Pretrain: remove JSON metadata (#3458)
• MMEarth: remove avail_bands metadata (#3464)
• SKIPP'D: remove date key (#3438)
• SkyScript: caption is now tokenized (#3788)
• VHR-10: do not return empty list of annotations for samples without objects (#3481)

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:

• ConvLSTM: remove batch_first parameter (#3280)
• MMEarth: several helper functions are now private (#3497)
• OSCD: alpha parameter of plot method is now deprecated (#3571)
• Semantic segmentation: time-series input is now deprecated (#3648)
• Type-related errors were changed from ValueError to TypeError (#3907)

Dependencies

New dependencies

• olmoearth-pretrain-minimal (#3517)
• pyogrio (#1399)
• requests (#3522)
• sphinx-github-changelog (#3425)
• tokenizers (#3788)
• tqdm (#3961)
• ty (#3334)
• types-geopandas (#3334)
• types-rasterio (#3906)
• uv-build (#3699)

Changes to existing dependencies

• geopandas: 1+ is now required (#3444)
• jsonargparse: 4.39+ is now required (#3742)
• jsonargparse: jsonnet signature is now required (#3742)
• lightly: 1.5.1+ is now required (#3521)
• lightning: 2.4+ is now required (#3444)
• myst-parser: 5.1+ is now required (#3708)
• pydata-sphinx-theme: 0.18+ is now required (#3726)
• pytest: fix support for 10+ (#3835)
• ruff: 0.16+ is now required (#3898)
• sphinx: 8+ is now required (#3726)
• torchmetrics: 1.5+ is now required (#3668)
• torchmetrics: detection extra is now required (#3563)
• webdataset: 0.2.101+ is now required (#3957)

Removed dependencies

• mypy (#3334)
• pycocotools (#3500)
• scikit-image (#3500)
• setuptools (#3699)

Datasets

New datasets

• Air Quality (#3619)
• DLRSD (#3498, #3716)
• FLAIR-HUB (#3181, #3978)
• Global Mangrove Watch (#3782)
• Meta CHM (#3757)
• OpenAerialMap (#3309)
• S2-100k (#3637, #3754)
• WorldStrat (#2558)
• xBD DistShift (#3866)

Changes to existing datasets

• AgriFieldNet: fix filehandle leak (#3795)
• AgriFieldNet: add res parameter (#3795)
• ChesapeakeCVPR: don't download prior unless necessary (#3955)
• ChesapeakeCVPR: fix under-sized patches at raster edges (#3688)
• Clay Embeddings: add support for v1.5 NAIP embeddings (#3518)
• Inria Aerial Image Labeling: fix obscure regex replacement bug (#3537)
• Landsat 4/5 TM: fix default bands (#3956)
• NCCM: fix download URL (#3943)
• OSCD: improved plotting (#3571)
• PASTIS: support custom band subsets (#3647)
• PASTIS: better normalization during plotting (#3646, #3881)
• PASTIS 100: add to docs (#3641)
• Sentinel-2: extract true valid data footprint from .SAFE metadata (#2991, #3847)
• SkyScript: tokenize caption, add tokenizer parameter (#3788)
• USAVars: fix download URL (#3955)
• VHR-10: derive length dynamically instead of hard-coding (#3989)

Changes to dataset base classes

• GeoDataset: list files in VSI paths (#1399)
• IntersectionDataset: fix obscure bug when intersecting many datasets (#3722)
• PlottingMixin: add mixin to reduce duplicated plotting code (#3775, #3789, #3831)
• RasterDataset: store valid data footprint in geometries (#2903)
• RasterDataset: add ability to override nodata value (#3847)
• RasterDataset: decouple index CRS and read CRS (#3804)
• RasterDataset: support georeferences via GCPs (#3404)
• XarrayDataset: add support for upside down rasters (#3849)

Utilities

• Add a progress bar to dataset downloads (#3961)
• Add a user-agent to dataset downloads (#3732)
• Add utility to compute valid-data footprints from raster masks (#3663)
• Add utility for quantile normalization (#3451, #3652)

Data modules

New data modules

• Air Quality (#3668)
• Copernicus-Bench Biomass S3 (#3086)
• DLRSD (#3498)
• FLAIR-HUB (#3181)

Changes to existing data modules

• Inria Aerial Image Labeling: remove time series dimension hack (#3538)
• OSCD 100: correct normalization values (#3532)

Models

New models

• Conv3dLSTM (#3860)
• DEO (#3629)
• OlmoEarth (#3517, #3895)
• SatCLIP (#3640)

Changes to existing models

• BTC: derive feature channels statically to improve throughput (#3758)
• ConvLSTM: add classification head, forward_features (#3280)
• CROMA: support non-float32 dtypes (#3974)
• DOFA: support non-float32 dtypes (#3975)
• DOFA: document Sentinel-1 wavelength convention (#3942)
• L-TAE: fix backpropagation bug due to inplace operations (#3737)
• RCF: support non-float32 dtypes (#3976)
• Tessera: document correct Sentinel-2 band order (#3673)

Profilers

• I/O profiler (#3861)

Samplers

• Refactor and add time series support (#3552, #3787)

Tasks

New tasks

• MAE (#3521)
• Spatiotemporal pixelwise regression (#3086)
• Spatiotemporal segmentation (#3962)
• Temporal regression (#3668)

New mixins

• Regression mixin (#3668, #3738)

Changes to existing tasks

• BYOL: fix decoupling between student and teacher networks (#3954)
• MoCo: fix support for non-default augmentations (#3935)
• SimCLR: fix support for non-default augmentations (#3935)

Transforms

• EVI (#3822)
• Lee filter (#3655)
• MNDWI (#3822)
• SAVI (#3822)

Documentation

API docs

• Refactor torchgeo.tasks docs (#3749, #3805)
• Add changelog (#3425)
• Add descriptions to type aliases (#3510)
• Add link to GitHub source code (#3572)
• Fix version switcher (#3693)
• Fix broken links (#3752, #3607, #3971)
• Remove duplicate type hints (#3466)

User docs

• Add uv installation instructions (#3546, #3702, #3753)
• Contributing: document files to modify when adding new models (#3526)
• Glossary: clarify difference between 'index' and 'query' (#3829)

Related libraries

• Add AIDE (#3589)
• Add py4dgeo (#3846)
• Add rs-embed (#3627)
• DeepForest has a CLI, switched to Kornia (#3468)
• TorchGeo now has time-series support (#3980)
• TorchGeo STAC support is a WIP (#3523)
• Update metrics (#3980)

Tutorials

• Add change detection tutorial (#3222)
• Add NAIP road segmentation tutorial (#3446, #3745)
• Update earth surface water tutorial (#3377, #3480)
• Use pretrained weights in CLI tutorial (#3527)
• Convert installs from pip to uv (#3756)

Governance

• Adopt AI policy (#3632, #3830)
• Add CODEOWNERS (#3467, #3661)
• Add new maintainer (#3657)
• Update maintainer affiliation (#3501, #3604)
• Document criteria for becoming a maintainer (#3509)
• Fix typos in governance docs (#3598)
• Move images/logo directories to docs/_static (#3427)
• Add sponsorship badge (#3639, #3833)
• Add Zenodo badge (#3638)
• Add Hugging Face logo (#3726)

Testing

• Migrate CI/CD from pip to uv (#3444, #3703, #3704, #3941, #3969)
• Various improvements to static typing (#3334, #3426, #3429, #3430, #3431, #3432, #3433, #3434, #3435, #3436, #3437, #3439, #3459, #3460, #3461, #3462, #3463, #3465, #3481, #3483, #3484, #3485, #3491, #3492, #3493, #3494, #3495, #3496, #3497, #3506, #3593, #3906, #3936, #3935, #3940)
• Various improvements to code style (#3898, #3907, #3908, #3909, #3910, #3911, #3912, #3913, #3914, #3915, #3916, #3917, #3918, #3919, #3920)
• Various fixes for pre-commit (#3472, #3694, #3778)
• Increase test coverage (#3550, #3567, #3569, #3734, #3801, #3802, #3803, #3979)
• Reduce model test input sizes (#3973)
• Test models in inference mode (#3972)
• Fix filehandle leak in plots (#3800)
• Fix parallel execution race condition (#3765)
• Fix or silence warnings (#3447, #3744, #3798, #3799, #3858, #3890, #3982)
• I/O Bench: always run on the CPU (#3677)
• Skip tests for case study notebooks (#3477, #3665)

Contributors

This release is made possible thanks to the following contributors:

• @adamjstewart
• @adriantre
• @akhellad
• @ArsalaanAhmad
• @ashnair1
• @box1401
• @burakekim
• @calebrob6
• @Chessing234
• @crowmoed
• @DarthReca
• @Dinghye
• @evgeniialappo
• @f-schi
• @FrankFeng-23
• @gatienc
• @hfangcat
• @hkristen
• @isaaccorley
• @kshitijrajsharma
• @mw3iss
• @nightcityblade
• @nilsleh
• @nuglifeleoji
• @piperwolters
• @PLTNGM
• @robmarkcole
• @wolfilip
• @yichiac

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.

Security Considerations

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.

Release notes

New Feature:

• GEOS-12158 Keycloak Role Service for use alongside OIDC Extension

Improvement:

• GEOS-12095 LDAP: conversion from group-member-username to user-search username
• GEOS-12124 Make GWC seeder thread pool sizes configurable via gwc-gs.xml and environment variables
• GEOS-12139 GSIP 241 - GeoWebCache Security-Aware Tile Caching
• GEOS-12140 Improve CoverageAccessLimits’s RasterFilter masking on SecureGridCoverage2DReader reading
• GEOS-12141 WMS nearest match machinery can issue queries that are guaranteed to return an empty result
• GEOS-12151 Allow caching small images used by ImageMosaic in memory
• GEOS-12154 Improve URL validation in SLD processing
• GEOS-12169 Update MapML viewer to v0.18.0

Bug:

• GEOS-11373 Geometry type mismatch in WFS 1.1.0
• GEOS-12144 “application/vnd.ogc.fg+json” output format fails when requesting non-geographical datasets
• GEOS-12145 Missing spatial filter in GeoFenceAccessManager SQL query when only CLIP is applied
• GEOS-12146 Wrong CRS axis order used in SecuredFeatureSource when clipping features for WFS 2.0.0 requests
• GEOS-12149 GeoServer WMTS capabilities put query parameters in the wrong place in generated URLs
• GEOS-12165 GeoServer does not start when fileLockProvider is set: lock wait times out

Sub-task:

For the complete list see 3.0.1 release notes.

Community Updates

Community module development:

• GEOS-12173 Remove the REST module profile from community modules as the module does not exist here

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.

About GeoServer 3.0 Series

Additional information on GeoServer 3.0 series:

• GeoServer 3.0 User Manual
• GeoServer 3.0-RC, a crowdfunded success story
• GSIP-221 MkDocs Migration
• GSIP-226 GeoServer 3
• GSIP-233 Community Pending Profile
• GSIP-236 Lightening up the Core for GeoServer 3
• GSIP-238 UI / UX Refresh
• GSIP 239 Promote OIDC Community Module to Extension

Release notes: ( 3.0.1 | 3.0.0 )

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.

Security Considerations

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.

Release notes

Improvement:

• GEOS-12080 style edit: check image loads
• GEOS-12082 CoverageStore - quick fail for incorrect files
• GEOS-12095 LDAP: conversion from group-member-username to user-search username
• GEOS-12140 Improve CoverageAccessLimits’s RasterFilter masking on SecureGridCoverage2DReader reading
• GEOS-12141 WMS nearest match machinery can issue queries that are guaranteed to return an empty result
• GEOS-12151 Allow caching small images used by ImageMosaic in memory

Bug:

• GEOS-11373 Geometry type mismatch in WFS 1.1.0
• GEOS-11571 The geoserver-2.26.0-printing-plugin is missing some dependend libraries
• GEOS-12138 Improve DescribeDomains expandLimit validation
• GEOS-12145 Missing spatial filter in GeoFenceAccessManager SQL query when only CLIP is applied
• GEOS-12146 Wrong CRS axis order used in SecuredFeatureSource when clipping features for WFS 2.0.0 requests
• GEOS-12149 GeoServer WMTS capabilities put query parameters in the wrong place in generated URLs
• GEOS-12165 GeoServer does not start when fileLockProvider is set: lock wait times out

Task:

• GEOS-12137 Update OSHI from 6.8.2 to 7.3.0
• GEOS-12148 Update GetFeatureInfo to list features (rather than as a table)

Sub-task:

• GEOS-12153 Include description in AttributeMap

For the complete list see 2.28.5 release notes.

Community Updates

Community module development:

• GEOS-12129 Longitudinal profile positive altitude includes first elevation as ascent from zero
• GEOS-12173 Remove the REST module profile from community modules as the module does not exist here

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.

About GeoServer 2.28 Series

Additional information on GeoServer 2.28 series:

• GeoServer 2.28 User Manual
• GeoServer 2025 Q4 Developer Update
• GSIP-234 Advertise and Enforce Attribute Restrictions

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.

Security Considerations

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.

Release notes

Improvement:

• GEOS-12080 style edit: check image loads
• GEOS-12082 CoverageStore - quick fail for incorrect files
• GEOS-12095 LDAP: conversion from group-member-username to user-search username

Task:

For the complete list see 2.27.6 release notes.

Community Updates

Community module development:

• GEOS-12098 Rename JWT Header assembly so it is collected for nightly downloads
• GEOS-12101 Workspace styles not persisted to disk after restore
• GEOS-12129 Longitudinal profile positive altitude includes first elevation as ascent from zero

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.

About GeoServer 2.27 Series

Additional information on GeoServer 2.27 series:

• GeoServer 2.27 User Manual
• CITE Certification achieved
• GeoServer 2025 Q2 Developer Update
• GeoServer 2025 Roadmap
• Content-Security-Policy Headers
• OGCAPI Features Extension
• File system access isolation
• Promote data dir catalog loader to core

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.

The Freeze

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”:

• Understand and follow the full Community Code of Conduct.
• No public or private harassment.

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.

The Appeal

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.

The Rejection

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”.

The Terms of Service

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.

What this teaches

• Being transparent is punished. I asked, in public, “should I stop being transparent ?”. FLOSS.social answered: yes, or you get suspended. The message to anyone using LLM-based tools on the Fediverse is clear: hide it, or else.
• The appeal process is a black box. A rejection with a date and no reasoning, followed two minutes later by a final suspension, is not a review. It is a rubber stamp. The suspension email claims appeals “must sufficiently describe how the behaviour in question will no longer happen”, which assumes the accused agrees the behavior happened. I never agreed to that, because it didn’t happen.
• Moderation tools are being used for ideological policing. My toots were reported by one or more users who were bothered by my enthusiasm for a technology. The moderators then stretched the Community Code of Conduct, whose “harassment” clause I supposedly violated, to cover “expressing support for” LLM use. If talking about a tool can be harassment, then the word has lost all meaning.

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.0 Release Notes

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!

Highlights of this release

Embeddings datasets

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!

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!

Time series datasets and models

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:

1D time series ($$B \times T \times C$$)

• L-TAE
• Presto
• Tessera

3D change detection ($$B \times 2 \times C \times H \times W$$)

• Be The Change
• ChangeStar
• ChangeViT
• FC-Siamese Networks

3D image time series ($$B \times T \times C \times H \times W$$)

• ConvLSTM

4D ocean and atmosphere ($$B \times T \times C \times Z \times Y \times X$$)

• Aurora

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!

Backwards-incompatible changes

GeoDataset: return Tensor outputs when possible

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.

sample = dataset[...]
crs = sample['crs']

crs = dataset.crs

Point datasets (EDDMapS, GBIF, iNaturalist) now use the 'keypoints' key instead of returning the entire index. This enables support for Kornia transforms on these objects.

keypoints = sample['bounds'].get_coordinates()

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.

Models: avoid downloading by default

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.

# 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)

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.

Other

• xView2 was renamed to xBD (#3132)
• SemanticSegmentationTask.predict_step now returns a dictionary (#3357)
• SeasoNet and Substation now return $$T \times C \times H \times W$$ time series by default (#3369, #3371)
• The dataset download backend was changed, and Google Drive datasets may no longer download correctly. Most datasets have been moved to Hugging Face, some remain and require manual download (#3338)

Dependencies

New dependencies

• pytest-socket (#3343)

Changes to existing dependencies

• Python: 3.12+ is now required (#3201)
• geopandas: 0.13+ is now required (#3139)
• h5py: 3.10+ is now required (#3201)
• jsonargparse: 4.35+ is now required (#3201)
• matplotlib: 3.7.3+ is now required (#3201)
• netcdf4: 1.6.5+ is now required (#3201)
• numpy: 1.26+ is now required (#3201)
• packaging: 21+ is now required (#3201)
• pandas: 2.1.1+ is now required (#3201)
• pandas-stubs: 2.1.1+ is now required (#3201)
• pillow: 10+ is now required (#3201)
• pycocotools: 2.0.8+ is now required (#3201)
• pyproj: 3.6.1+ is now required (#3201)
• pytest: 7.3.2+ is now required (#3201)
• requests: 2.25+ is now required (#3201)
• scikit-image: 0.22+ is now required (#3201)
• scipy: 1.11.2+ is now required (#3201)
• shapely: 2.0.2+ is now required (#3201)
• torch: 2.2+ is now required (#3201)
• torchvision: 0.17+ is now required (#3201)
• types-requests: 2.25+ is now required (#3201)
• types-shapely: 2.0.2+ is now required (#3201)
• typing-extensions: 4.8+ is now required (#3201)

Datasets

New datasets

• Clay Embeddings (#3293, #3358)
• Copernicus-Embed: pictured above (#3252)
• Earth Embeddings (#3391)
• Earth Index Embeddings (#3282)
• Embedded Seamless Data (ESD) (#3403)
• Google Satellite Embedding (AlphaEarth Foundations) (#3244)
• Major TOM Embeddings (#3295)
• OSCD100 (#3221, #3411)
• PASTIS100 (#3265)
• Presto Embeddings (#3288)
• Tessera Embeddings (#3245, #3310)

Changes to existing datasets

• BigEarthNetV2: fix downloaded filename (#3363)
• Cloud Cover Detection: don't rename downloaded directories (#3158)
• LEVIR-CD: download from Hugging Face (#3351)
• NLCD: add 2024 data (#3189)
• Point datasets: return keypoints (#3139)
• SeasoNet: $$SC \times H \times W \rightarrow T \times C \times H \times W$$ (#3371)
• SSL4EO-S12: correct docs on # channels for TOA vs. SR (#3379)
• Substation: return time series by default, plotting fix (#3369)
• SustainBench Crop Yield: download from Hugging Face (#3337)
• xBD: rename xView2 dataset (#3132)
• Fix plot docstring reference to getitem (#3353)

Changes to dataset base classes

• Dataset: use index consistently (#3264)
• Dataset: return Sample = dict[str, Any] (#3200)
• GeoDataset: remove 'crs', convert 'bounds' (#3138, #3350)
• GeoDataset: return spatial 'transform' (#3140)
• RasterDataset: add time series support (#3183)
• RasterDataset: refactor open/reproject to single method (#3014)
• XarrayDataset: document that this is an experimental feature (#3362)

Utilities

• download_and_extract_archive: replace torchvision utility (#3339)
• download_url: replace torchvision utility, remove support for Google Drive downloads (#3338)
• check_integrity: replace torchvision utility, add support for cryptographically secure checksum algorithms (#3302)
• extract_archive: replace torchvision utility, enforce stricter tarball checks (#3307)

Data Modules

New data modules

• Cloud Cover Detection (#3145)
• OSCD100 (#3221)
• PASTIS100 (#3265)

Changes to existing data modules

• xBD: rename xView2 data module (#3132)

Changes to data module base classes

• GeoDataModule: don't delete 'crs' and 'bounds' from sample (#3138)

Models

New model architectures

• Presto (#2929, #3414)
• Tessera (#3243, #3310)
• TileNet (#3230)

New model weights

• Tile2Vec (#3230)
• U-Net: add ChesapeakeRSC road segmentation weights (#3407)
• U-Net: add PRUE FTW weights (#3406)

Changes to existing models

• ChangeStar: replace backbone_pretrained bool with backbone_weights enum (#3348)
• EarthLoc: pretrained model now defaults to False (#3341)
• FarSeg: replace backbone_pretrained bool with backbone_weights enum (#3348)
• U-Net: don't download weights unless requested (#3344)

Trainers

• ClassificationMixin: unify features of classification trainers, add class-wise metrics (#3328)
• ChangeDetectionTask: add labels parameter (#3328)
• ChangeDetectionTask: add precision and recall metrics (#3328)
• ClassificationTask: add labels, pos_weight, ignore_index parameters (#3328)
• ClassificationTask: add dice loss support (#3328)
• ClassificationTask: add precision and recall metrics (#3328)
• InstanceSegmentationTask: weights bool to enum (#3349)
• InstanceSegmentationTask: add weights_backbone parameter (#3349)
• ObjectDetectionTask: weights bool to enum (#3352)
• SemanticSegmentationTask: add labels and pos_weight parameters (#3328)
• SemanticSegmentationTask: add dice loss support (#3328)
• SemanticSegmentationTask: add precision, recall, and F1-score metrics (#3328)
• SemanticSegmentationTask: predict_step now returns dict (#3357)

Documentation

• Fix broken or redirected links (#3345, #3381, #3413)
• Move images/logo to subdirectory (#3365)
• API: redesign and reorganize dataset docs (#3385, #3395, #3409)
• API: reorganize model architectures (#3324)
• Tutorials: document more TorchGeo slicing options (#3374)
• User: update related libraries (#3412)
• Version bump (#3129, #3329, #3420)

Tests

• agents: help Copilot and friends better review PRs (#3306, #3336, #3355)
• pytest: ensure no downloads occur during testing (#3341, #3343, #3344, #3348, #3349, #3352, #3405)
• pytest: don't verify checksum of fake files (#3367)
• pytest: document purpose of data module tests (#3354)
• ty: various type hint fixes (#3303, #3304, #3335, #3386, #3387, #3388, #3390, #3392, #3393, #3394, #3396, #3397, #3398, #3399, #3400, #3401)
• uv: replace pip with uv in CI (#3318)

Contributors

This release is made possible thanks to the following contributors:

• @adamjstewart
• @adriantre
• @alecsandrei
• @ashnair1
• @DarthReca
• @gatienc
• @heiyuxiaokai
• @hkristen
• @isaaccorley
• @kshitijrajsharma
• @nilsleh
• @Pratik0405
• @robmarkcole
• @VoyagerXvoyagerx
• @yichiac

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! 🚀

Revamped basic project creation

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.

XLSForm imports: a new path of survey creation

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 .

Project cloning: replicate your field setup in seconds

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:

1. Click the Create Project button.
2. From the three new options, select Clone an existing project.
3. Use the search input to find and select the target project.

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 try it out?

Ready to streamline your field collection workflows? Create your free QFieldCloud Community account today and start leveraging these new project creation tools right away.

🚀 CREATE YOUR FREE ACCOUNT

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.

• source download md5

• NEWS

• HTML Online en ja zh_Hans fr

• PDF docs: en ja, zh_Hans, fr

• Cheat Sheets:

  • postgis: en ja zh_Hans fr
  • postgis_raster: en ja zh_Hans fr
  • postgis_topology: en ja zh_Hans fr
  • postgis_sfcgal: en ja zh_Hans fr

This release is a beta of a major release, it includes bug fixes since PostGIS 3.6.4 and new features.