Sorry, this entry is only available in French.

You must be logged into the site to view this content.

So after finally getting MapGuide Open Source 4.0 out the door, I took a self-imposed hiatus from all things mapping/GIS related for several months, permanently moved from Windows to Linux as my daily driver OS just in time before the end of Windows 10 support, and also to mentally recharge and savor the relief of having this major burden (of releasing MGOS 4.0) being finally lifted off of my back.

I now return with a renewed vigor and some rough roadmaps for things going forward in MapGuide and my other various projects. Part of that renewed vigor is due to the advent of ...

GitHub Copilot

MapGuide Open Source

In week 12, I started to get things back on track after being sick. I ran five days, biked one day, and took Saturday off to take my family to a Nuggets game in Denver.

• 12 hours, 9 minutes all training

• 34.8 miles running

• 5,800 ft D+ running (and treadmill)

My energy level was low to mid until Friday, when I rallied for a good interval workout on a 12% incline treadmill indoors and a sauna session after. My fitness didn't advance much in week ten, but I didn't lose a step. According to the machine, I went "up" beyond any of the Quad Rock climbs, and at a pace that I'd love to hit on race day.

Saturday, as I mentioned previously, I sat on my butt in a car and in Ball Arena, with Ruthie and our kids, and then we all met my folks in Denver for an early dinner. It was a wonderfully easy and sociable day. Some days I think we should be living in Denver instead of Fort Collins, and this was one of those days.

Sunday I went out for three hours on the rolling and punchy dirt trails east of Horsetooth Reservoir, intending to get 90 minutes of Z2-Z3 running. It was a great run. My legs felt lively during miles 2-12, and I pushed my gas pedal with enthusiasm. If I'd brought another two gels, I could have avoided bottoming out at mile 14. I'm hoping to feel that good and pain free at Quad Rock.

A dry, yellow-brown landscape under a blue and partly cloudy sky.

Listening to the news about the impact of the current war and the closure of the Strait of Hormuz, I was prompted to think about critical minerals that could also have massive disruptive impact in geopolitical turmoil.

I asked Claude “Can you build a dataset of the most critical minerals, where they are mined (mine sites or countries), shares of world production, price changes over 5-10 years, main usages so that we can build a map of these commodities. Build it in a way that we can extend if we find more data” and it found me some data using these sources:

• US Geological Survey — Mineral Commodity Summaries 2025
• International Energy Agency — Global Critical Minerals Outlook 2025
• World Resources Institute — Critical Minerals Explained
• World Economic Forum — Critical Minerals and Innovation 2026
• Benchmark Mineral Intelligence / Visual Capitalist — production and price data

I then asked for a map “let’s build a map using my standard map app settings that you should have stored in memory. Users should be able to see the map symbols showing percentages of world production for each mineral. a selector to choose an individual mineral or an overall view. an option to show mineral supply by usage. Notes to appear on minerals and use cases (popups or side panels)” and after a few iterations and some data cleanup I ended up with the map at the top of this post. Not perfect but good enough to explore the data and to understand which minerals are used in key aspects of modern life and which countries may have a stranglehold on those minerals.

I am learning how to navigate and better prompt Claude, it has stored some of my favourite settings so there is some consistency in what it generates. The whole process is getting faster. One thing I am beginning to realise is that when you use an AI to do your research and extract or build your data you really need some domain knowledge to do a sanity check otherwise you may be just mapping hallucinations.

I had big plans for week eleven and then came down with a cold. My Wednesday workout's mediocre feeling was the first indication. The rest of the week I shifted into recovery rides and easy runs.

• 10 hours, 23 minutes all training

• 19.2 miles running

• 2,306 ft D+ running

It wasn't a terrible week, to be clear. I didn't fall apart physically, or anything like that. My concern is that it was the first week where I didn't progress very much in my Quad Rock training season.

Having knocked up a simple fuel finder based on a csv download from the government site at the beginning of the week I thought “How difficult could it be to make something more functional and elegant and connect to the government fuel finder API?” Answer – the “more functional and elegant” not too difficult – about 3 hours of vibe coding, Connecting to the API and refreshing regularly – pretty damn hard even with Claude helping me.

For comparison here is the first version using a downloaded file

The map pins are simple, the pop-up has limited info and worst of all there are all those miscoded petrol stations in the North Sea.

I asked Claude to refactor the app and to improve it’s appearance: “I want to build a fuel price search app using the government api https://www.developer.fuel-finder.service.gov.uk/dev-guideline. I have built a rough prototype to explore the data at https://knowwhereconsulting.co.uk/maps/fuel-finder-v1/ this is not a particularly good implementation and it uses a static file rather than the api. I have uploaded the code and data file. before building anything can you review the government api spec and consider how to connect to the api. Polling the api every hour is probably ok, we should note when we polled it and show the update time for each fuel point“

I got back pretty much the front end that you see at the top of this post, took me a couple of hours to tweak the styling. I had to wrestle with the data to exclude some of the petrol stations that were in the North Sea and also prices that were clearly wrong e.g petrol at 1.4 pence or £14 per litre but we got to a workable solution (I think it will need adjusting if prices got over £2.50 per litre and who knows when that might happen!)

Then it was time to try and connect to the government API, I created an account and got my client ID and secret code. I was now in an area where I knew nothing and was totally dependent on Claude working out how to access the API. This was difficult, maybe it was the documentation, maybe it was Claude but it took a while to work out how to download the latest version of the data and how to write a log file tracking the successes or failures of the download, tried CLI and cURL approaches for the cron job but kept getting blocked somewhere (either my hosting service, Cloudflare or the API). At one stage switched to using an external cron service but hit a few more obstacles. I think it took something like 4-5 hours to get this bit running, not helped by my lack of understanding of how to set up a cron job and API endpoints and authorisation.

These are the sites referenced by the government web site, I think my Find Cheap Fuel Near Me stacks up pretty well.

Next steps are to speed up downloads by only downloading changed data and try to find a way to speed up the data load and then maybe a rethink of the mobile interface.

https://www.osgeo.org/foundation-news/osgeo-ambassador-programme-call-for-participation/

In line with its commitment to increase the impact of the organization, OSGeo is excited to announce its new Ambassador Programme.

What is an OSGeo Ambassador?

Someone who helps OSGeo to grow its financial resources through fundraising. These are some fundraising activities that we would love for an ambassador to explore:
• Engage with Organizations such as the European Commission (EC), or the United Nations (UN), to seek grants and other opportunities.
• Liaison with commercial companies and acquire new sponsors.

We acknowledge that it may not be easy for everyone o approach many of these organizations. An ideal candidate would be someone who already has a strong professional network that they can leverage.

As the ambassador will be representing OSGeo, it is critical for them to be aligned with the Foundation’s values and vision., as well as to operate within the OSGeo Code of Conduct.

We are very thankful for all the resources brought by our Ambassadors, and we are happy to offer a 10% recommendation bonus based on the amount they bring to OSGeo.

Why increase OSGeo’s financial resources?

Our budget enables us to support OSGeo’s mission, by providing funding to projects, committees and seeding the FOSS4G conference. By increasing our budget we would be able for instance, to improve the marketing of the organization and to provide more travel grants to attend the conferences. We could also support more projects on getting compliance certification of the Standards they implement (for example with the Open Geospatial Consortium [OGC]).

Sound interesting?
Please drop us an email to board-priv@osgeo.org with an expression of interest. In addition, please feel free to circulate this to your network in order to increase and widen the OSGeo Ambassador program.

1 post - 1 participant

Read full topic

This is a reply to David Gasquez’ blog post Atmospheric Data Portals. As there’s so much in it and much of it overlaps with future plans, I thought it makes sense to write a proper public reply instead of following up in a private conversation.

First of all, read his blog post and follow the many links, there is so much to discover.

One re-occurring thing in the documents linked from the “issues on the earlier stages of the Open Data pipeline” section is that for most portals a static site should be sufficient. I fully agree with that. When it’s done properly, an automated rebuild of some parts when new data is added should work well. These days even powerful client-sided search is possible.

It’s a bit off-topic, but David’s Barefoot Data Platforms page links to Maggie Appleton’s Home Cooked Software and Barefoot Developers talk linked. I highly recommend watching it, it was one of my favourite talks at the Local-first Conference 2024. I always wanted to blog about it, but never found the time.

But now to the concrete points David mentions. If anyone has ideas on how to make those things happen with Matadisco, please open issues on the main Matadisco repo.

Take inspiration from existing flexible standards like Data Package, Croissant, and GEO ones for the core fields. Start with the smallest shared lexicon while leaving room for specialized extensions (sidecars?).

I don’t think Matadisco should go into too much detail on specifying what the metadata should look like. Making one metadata standard to rule them all is destined to fail from my experience (ISO 19115/19139 anyone?). Though there might be a lowest common denominator, similar to what Standard.site is doing for long-form publishing. In order to find out what that looks like, I propose that individual communities start by specifying Lexicons for their own needs. This could be done through tags, which I’ve outlined in the Matadisco issue “Introducing tags for filtering and extension point”.

Split datasets from “snapshots”. Say, io.datonic.dataset holds long-term properties like description and points to io.datonic.dataset.release or io.datonic.dataset.snapshot, which point to the actual resources.

Some kind of hierarchical relationship would be useful. FROST, which Matadisco drew a lot of inspiration from, is centred around IceChunk, which also has the concept of snapshots. But I don’t think we should stop at the concept of snapshots. In my original demo, I scrape a STAC catalogue for Sentinel-2 imagery. Every new image is a new record. They are all part of the same STAC collection, so we could use a similar concept in Matadisco as well.

Add an optional DASL-CID field for resources so we “pin” the bytes.

Yes, that’s something @mosh is keen to have. It’s not only useful for pinning things to a specific version, but also to make it possible to verify that the data you received is the one you expected. It sounds trivial, but the problem would be where to put it. Do you only hash the metadata record it points to? Do you hash the data container (if there’s one)? Or each resource a metadata record points to?

Core lexicon should be as agnostic as possible!

As mentioned above, it might be out of scope for Matadisco and for now it’s left to the individual communities.

Bootstrap the catalog. There are many open indexes and organizations. Crawl them!

Indeed! My first two Matadisco producers are sentinel-to-atproto crawling Element 84’s Earth Search STAC catalogue and gdi-de-csw-to-atproto crawling the GeoNetwork instance of the official German geo metadata catalogue.

Integrate with external repositories. E.g., a service that creates JSON-LD files from the datasets it sees appearing on the Atmosphere so Google Datasets picks them up. The same cron job could push data into Hugging Face or any other tool that people are already using in their fields.

At first this would need to happen for each individual type of record, see the tags proposal above.

Convince and work with high quality organizations doing something like this! I’d definitely collaborate with source.coop for example.

That surely is the goal!

This is a short write-up on the FOSSGIS 2026 conference. It’s a German speaking conference on free and open source geographic information systems and OpenStreetMap. So maybe a blog post in English spreads the word even wider.

While being the biggest edition ever (1000 registrations on-site, 300 online) it was well run and organized as every year. It didn’t even feel larger than usual. The CCC video team streamed live and published the cut videos the same day in outstanding quality as always.

I split this post into two sections, one about interesting talks for the geo world in general and then follow up discussions on my Matadisco talk and ATProto in general.

Talks

I’ve spent most of my time in hallway chatting with people as this is what matters most to me when I’m attending a conference in person. Nonetheless I’ve still managed to see some excellent talks.

Panel discussion on digital sovereignty in the cloud

The conference started with a high-class panel discussion on digital sovereignty in the cloud. The public discussion on that topic is often centered around where servers are located. Though that doesn’t actually matter. US companies can be forced by their government to give access to the data independent of their physical location.

Other topics touched were best practices on switching from proprietary to open source systems.

Barrier-free travelling thanks to paid mappers

Public transport in Germany must be accessible to disabled individuals (reality is far away from that). For routing, you need the data basis for it. This talk gets into the details on how Baden-Württemberg, a federal state in south Germany, works on enabling barrier-free travelling. They decided to add that information of all their 1100 train stations directly to OpenStreetMap. In order to achieve the required high quality they’ve hired through a third party company several experienced mappers from the community.

I really like the idea that OpenStreetMap can now be used as source of truth for that data set. I hope other federal states follow this lead.

Routing talks

I’ve seen two talks about routing. The one about Valhalla routing engine with MapLibre Native was interesting because it was about a special case, where you want to re-route bus lines in case of construction. Although the resulting system is not open source, they’ve contributed upstream to Valhalla, to make it work well with MapLibre Native. Those contributions can be more valuable than a one time source code dump of forked repositories, just to call it open source.

Another one was about Real-time mobility analytics for disaster relief operations, which was interesting to see how routing is used in such cases. The limitations and how such systems really help on the ground.

Matadisco and ATProto

My talk on Matadisco was about the current status of metadata catalogues, the problems and how ATProto can make things better. What I should have made clearer is what Matadisco actually is. I didn’t make it clear that it’s just a schema/convention people would use to announce their data on ATProto. It could’ve been mistaken as a piece of software or a service. You would use Matadisco in order to implement something for your pipeline.

Nonetheless people got the idea and I had good conversations afterwards. I talked with Olivia Guyot about the possible ways on how to integrate Matadisco record publishing into GeoNetwork. With Christian Willmes about creating a portal for combining paleoenvironmental and archaeological data.

While chatting about ATProto at one of the social events Klaus Stein talked about how he would like a social network to be. Users would just put static files somewhere. I agree that having static webspace somewhere without any server component is not only cheap, but also the easiest to get. He is not bothered about other components being operated by other parties, e.g. for indexing. That kept me thinking how far ATProto is away from that. I’d like to build a prototype that is like a static site generator for ATProto records. It won’t be able to act as a full PDS, you would need a WebSocket connection to get the data to a relay. But there could be a minimal service operated by a third party that polls those static PDS for updates and forwards them to a relay.

This morning there was a lot of amused banter amongst my geo-pals about the UK Government’s Fuel Finder API based on an article in The Times (possible paywall) on the problems with the data. You can download the data or access the api from the gov.uk site.

I downloaded the data for this morning (31st March 2026, 11am) and spun up this fuel finder app in a few minutes. It’s nothing special and some of the government signposted sites are a lot better but this shows how poor the raw data is. Surely the developer of the government api could have introduced a simple check to ensure that all coordinates were in the UK not in the sea or in France, Belgium or Holland?

Remember this will only be up to date for a a day or so before prices have shifted, I suppose I could have tried to access the api and built something that would have stayed up to date but given the number of sites already doing this there isn’t a good reason to duplicate there efforts.

I was thinking about what map to make next and I thought about flags, national symbols like birds or animals.

I started out with a very simple prompt to see what Claude would come up with:

I want to make an interactive map of national symbols: Flags, Trees, Flowers, Animal, Symbols,Anything else you can suggest?

It chundered away for a few minutes and came up with this monster

Yes it is truly awful! You can click on the map above to see it in action, it sort of works but the map part is rubbish (but probably represents Claude’s limited sense of world geography) and the linked data is pretty flaky as well. When I challenged Claude it explained that it was using “training data” I guess that means “any old crap that I could scrape.

First up I needed to find a source of data for national symbols, a quick search of Wikipedia turned up this List of National Symbols with a wide range of topics including flags, birds, animals, sports etc and quite good geographic coverage. Claude suggested that it use some world boundaries from D3 and gave me something a lot better looking.

A couple more tries to get all of the data and image links from Wikipedia, tidy up the interface and change the colour scheme and I had a release version. If you are viewing on a mobile you won’t see the map just a country search and the side panel.

The finished version – click map to view

This whole project took a bit over an hour from start to finish, it’s pretty simple and relies on masses of links ot Wikipedia which may get broken in the future. I think it is a much nicer way to view all of the data from the Wikipedia lists than the source web page.

I know someone will dispute the data, don’t tell me what’s wrong with it – update the Wikipedia page and if your update doesn’t get overwritten I will pick it up in a few weeks time (the map is not live linked to the Wikipedia pages).

https://www.osgeo.org/foundation-news/thank-you-angelos-outgoing-osgeo-president/

After years of service, Angelos Tzotsos is stepping down as President of OSGeo and will continue to serve on the Board of Directors for the remainder of his term. We want to take this opportunity to thank him for his leadership on behalf of the community.

Angelos joined the OSGeo Board in 2016 and has served as President since 2019. Over that period, he has been a consistent and active contributor. Not only in his governance role, but also as a developer and project leader across several key OSGeo projects.

He has been a regular presence at code sprints, FOSS4G events and other international conferences, actively representing and advocating for OSGeo and open geospatial software.

Angelos is a true leader by example as demonstrated during his time as the President of OSGeo.

Angelos, thank you for the time and effort you have put into OSGeo over the years as Board member, as project leader, and as President. It is genuinely appreciated.

We look forward to your continued involvement, both as a Board member and a leader in the OSGeo community.

The OSGeo Board of Directors

1 post - 1 participant

Read full topic

El pasado webinar organizado por KAN Territory & IT reunió a la comunidad geoespacial de habla hispana para presentar las principales novedades de GeoNode 5 y explorar cómo evoluciona el ecosistema hacia arquitecturas modernas basadas en la nube.

En este artículo, resumimos los principales conceptos y avances compartidos durante el encuentro.

GeoNode es una plataforma open source diseñada para la gestión, publicación y análisis de datos geoespaciales, ampliamente utilizada para construir Infraestructuras de Datos Espaciales (IDE) y sistemas SIG.

¿Qué es GeoNode y por qué sigue siendo clave?

Permite a organizaciones:

• Centralizar y catalogar datos geoespaciales
• Publicar mapas y servicios de forma sencilla
• Crear dashboards y narrativas geográficas (GeoStories)
• Gestionar accesos y permisos sobre la información
  

Uno de sus grandes diferenciales es que democratiza el uso del GIS, permitiendo que usuarios sin perfil técnico puedan cargar, visualizar y analizar datos.

GeoNode 5: una evolución centrada en usabilidad y escalabilidad

La nueva versión marca un punto de inflexión en la plataforma.

Nueva interfaz y mayor personalización

GeoNode 5 introduce un rediseño completo enfocado en:

• Usabilidad
• Claridad visual
• Experiencia de usuario

Además, permite a los administradores crear páginas y secciones personalizadas, adaptando el portal a cada proyecto o institución.

Nuevo módulo de metadatos

Se incorpora una mejora significativa en la gestión de metadatos:

• Interfaces más simples
• Mayor control sobre la información
• Mejor organización de datasets

Esto facilita la documentación y descubrimiento de datos, clave en cualquier IDE.

Gestión del ciclo de vida de los datos

GeoNode 5 mejora la forma en que se actualizan los datos:

• Reemplazo y versionado más simple
• Actualización directa de datasets
• Mejor control sobre cambios

Calidad de datos y validaciones

Ahora es posible:

• Definir restricciones en atributos
• Validar datos al momento de carga
• Mejorar la calidad de la información desde origen

Sistema de permisos más flexible

Uno de los cambios más relevantes:

• Nuevo sistema de permisos dinámico basado en reglas
• Posibilidad de definir accesos por condiciones contextuales o temporales
• Mayor granularidad en la gestión de usuarios

Esto permite construir portales mucho más seguros y adaptados a distintos perfiles.

Nuevos formatos y exportaciones

Se amplían las capacidades de acceso a datos:

• Exportación en CSV y Excel
• Mayor interoperabilidad
• Integración con otros sistemas

Mejoras en performance y procesamiento

El backend fue optimizado para:

• Procesamiento más rápido
• Mejor manejo de tareas asíncronas
• Mayor estabilidad en entornos exigentes
  

GeoServer Cloud: hacia arquitecturas cloud-native

Uno de los ejes centrales del webinar fue la evolución hacia GeoServer Cloud.

El enfoque es claro:

“Si queremos sistemas realmente cloud-native, todos sus componentes deben ser cloud-native.”

Principales características:

• Arquitectura de microservicios
• Despliegue en Kubernetes
• Procesamiento geoespacial distribuido
• Escalabilidad horizontal

Esto permite construir infraestructuras más resilientes, flexibles y preparadas para grandes volúmenes de datos.

GeoNode Cloud: la nueva generación de plataformas geoespaciales

GeoNode Cloud representa el siguiente paso:

Una implementación de GeoNode diseñada específicamente para la nube, optimizada para entornos modernos.

Beneficios clave:

• Escalabilidad automática
• Reducción de costos operativos
• Sin necesidad de infraestructura física
• Acceso desde cualquier lugar

Integraciones destacadas:

• GeoServer Cloud
• Kubernetes
• QGIS Desktop

En conjunto, esto habilita una arquitectura completamente desacoplada y preparada para crecimiento.

Un cambio de paradigma en las IDE

Lo que vimos en GeoNode 5 no es solo una actualización.

Es un cambio de paradigma:

• De plataformas monolíticas → a microservicios
• De despliegues locales → a cloud-native
• De sistemas rígidos → a soluciones configurables

Conclusión

GeoNode 5 marca un antes y un después en la evolución de las plataformas geoespaciales open source.

Con mejoras en usabilidad, gestión de datos, seguridad y arquitectura, se posiciona como una herramienta clave para organizaciones que buscan:

• Escalar sus Infraestructuras de Datos Espaciales
• Modernizar sus sistemas GIS
• Adoptar tecnologías cloud

¿Querés ver el webinar completo o evaluar GeoNode para tu organización?

Desde KAN acompañamos a organismos y empresas en el diseño e implementación de plataformas geoespaciales escalables.

Contactanos para conocer más.

Non è facile cominciare a raccontare questa storia, quindi comincio da dove mi viene in mente. Avete presente un gasometro? Avete mai visto un gasometro dal vivo o in foto, in video, in televisione? Fino ad alcuni anni fa per me era una parola un po’ strana eppure è diventato uno dei luoghi con cui ho a che fare più spesso nella mia vita quotidiana. A Ventimiglia, dentro un’area archeologica romana abbastanza famosa e importante, ci sono due gasometri. Alcuni anni fa ho iniziato a occuparmi di questi due gasometri e di tutto quello che ci sta intorno che si chiama Officina del Gas è un impianto abbastanza grande, di 12.000 m² che dal 1906 al 1993 ha funzionato per dare il gas alla città.

Prima di iniziare a lavorare veramente alla realizzazione del progetto, con alcune persone molto preparate ho iniziato a studiare la storia di questo luogo e a farmi raccontare dalle persone che ci vivono accanto che cosa rappresenta per loro.

Ma un giorno ho anche condiviso alcune immagini di questi gasometri e di altri gasometri, tra cui quello di Corso Farini a Torino, ed è successo quello che succede sul fediverso, cioè qualcuno ha commentato lanciando un ponte verso un altro mondo diverso, il mondo musicale.

Sembra quasi scontato ma ci sono alcuni generi specifici di musica che sembrano avere un legame profondo con l’immagine e l’essenza stessa di un gasometro e di un’officina del gas. Uno di questi generi è quello che possiamo etichettare come rock industriale, industrial rock, un genere che è molto diffuso soprattutto nel Regno Unito e in Germania. Un altro genere completamente diverso che ha un legame profondo con un gasometro con un impianto industriale è sicuramente la musica elettronica techno e techno industrial. Allora per chiudere temporaneamente il cerchio vediamo alcuni album e gruppi di artisti che hanno realizzato di recente o anche meno di recente una serie di opere musicali legate al gasometro. Non c’è quasi nulla che sia frutto di una mia ricerca: sono tutti suggerimenti che ho avuto sia dal fediverso sia da alcuni colleghi e colleghe che hanno condiviso con me questo percorso ed è interessante vedere che in certi casi addirittura il gasometro compare sulla copertina di un disco.

Ovviamente questa abbuffata musicale molto variegata mi ha fatto pensare che il gasometro, ora che ha smesso di funzionare, rimane un buon posto dove esplorare questa connessione musicale e quindi ho cominciato a lavorare per rendere possibile un ritorno di suoni e musica sotto i gasometri stessi.

Gli album

Questa la selezione sul lato rock

• Paradise dei Pop. 1280
• Endure degli Special Interest
• High dei Royal Headache
• An End Has a Start degli Editors
• Abandoned City degli Hauschka

Sul versante techno, ho queste tracce:

• The bells di Jeff Mills
• Orbit degli Underground Resistance (sempre con Jeff Mills)

E per finire l’incredibile performance di Jeff Mills, Jean-Phi Dary and Prabhu Edouard dentro il sito archeologico di Delos, Tomorrow comes the harvest. La metto qui perché chiude il cerchio in modo mirabile riportando all’unità l’archeologia classica, la musica elettronica e l’archeologia industriale da cui sono partito.

I'm squishing four weeks worth of recap into this one post.

First, the numbers.

• 40 hours, 32 minutes all training

• 99 miles running

• 15,600 ft D+ running (and treadmill)

I'm less concerned with miles than I used to be, but I'm still writing these numbers down for continuity's sake.

I'm running four days a week and riding or other cross-training 2-3 days. Two of my runs are easy, but not slow. One has some high intensity intervals or hill sprints. The other is a 2-3 hour run with 45-60 minutes of tempo pace in the middle. My top speed hasn't increased in the past four weeks, but my easy pace has improved a lot. With five more weeks of training ahead before I begin to taper off, I'm looking forward to getting even faster at zones 2 and 3.

I've been switching between potential race shoes on my faster and longer runs. While the Hoka Tecton X 3 are growing on me, and the Kjerag are fun, I'm 99% sure that I'll run Quad Rock 25 in La Sportiva Prodigio Pros. They're well suited to the course, fit me well, and feel stable, fast, and adequately cushioned.

My favorite run of March was a Friday afternoon outing in Lory State Park with my friend, Dana. He's not training for any event, but is naturally faster than me, so our runs are a great opportunity to go a little harder. On this occasion we did two warm up miles in the valley and then went rapidly up Quad Rock climb no. 3 and quickly down descent no. 3 to what will be the finish on race day. I recorded segment times that were only a few seconds off my personal bests, and wasn't wrecked afterwards.

Last Sunday I went out by myself and ran through the first and second Quad Rock climbs (and matching descents). My calves and hamstrings cramped after a long, hard push in the middle of the run, and I struggled for the last four miles. That's the first time this season, a good reminder to fuel better on my long runs.

30 minutes of mobility and core strength exercises every morning are keeping my body in good shape. I've no Achilles tendinitis. My hips and back are pain free. No foot trouble. Inflammation and swelling in my right knee is troubling, but I'm keeping it in check with ice and, sometimes, ibuprofen. I hear that some people benefit from tart cherry extract as a supplement, and I'm going to give that a try.

After a couple years of being injured, I'm grateful to be close to 100 percent. It feels good.

Sourcepole hat an der FOSSGIS 2026 in Göttingen verschiedene Themen mit Vorträgen abgedeckt:

• Datenkataloge mit STAC und OGC API Records
• Volltextsuche in Echtzeitdaten mit pg_search
• Kollaboratives GIS mit Jupyter Notebooks und JupyterGIS
• QGIS Web Client (QWC) – Neues aus dem Projekt

La Asociación gvSIG pasa a formar parte de la Red Iberoamericana de Observación Territorial (RIDOT), una iniciativa que reúne a instituciones y profesionales comprometidos con el análisis, la gestión y la comprensión del territorio en el ámbito iberoamericano.

Esta incorporación refuerza el compromiso de la Asociación gvSIG con la colaboración internacional y con el impulso de infraestructuras de datos espaciales, estándares abiertos y tecnologías basadas en software libre como pilares para la toma de decisiones y la gestión territorial.

La Red constituye un espacio clave para abordar de forma conjunta retos como el cambio climático, la gestión del riesgo, la planificación territorial o la gobernanza, promoviendo el intercambio de conocimiento y la generación de sinergias entre sus miembros.

Desde la Asociación gvSIG se contribuirá activamente a este ecosistema, aportando experiencia en el desarrollo e implantación de soluciones geomáticas abiertas y en la construcción de modelos basados en interoperabilidad y soberanía tecnológica.

Open data is only as useful as it is discoverable. Finding datasets, whether it’s satellite imagery, scientific research, or cultural archives involves navigating dozens of siloed portals, each of them with different interfaces and APIs. Project Matadisco tries to solve this by using ATProto to create an open, decentralized network for data discovery. Anyone can publish metadata about their datasets. You can then pick the records that matter to you and build views for the specific needs of your community. By focusing on metadata rather than the data itself, the system works with any dataset format, keeps records lightweight, and remains agnostic about storage.

It’s early stage and experimental, but the potential is significant. To see it in action, visit the matadisco-viewer demo. It listens to the incoming stream of ATProto events and renders them. At the moment it’s satellite images only, but that will hopefully change soon.

Above is an example of what crossed my screen while developing (metadata, download at full resolution (253MiB)).

Motivation

Metadata records can be very diverse. They might describe geodata, your favourite news site or your favourite podcasts. What they all have in common is that users usually rely on centralized platforms in order to find them. For geodata, this is often a government-run open data or geo portal. These platforms decide which data gets published.

You might generate a derived dataset or clean up an existing one. If you operate from outside of the original creators, you probably won’t even be able to get your data linked from there. So how will anyone find out about it? That’s a problem of metadata discovery.

The other side of the problem is that even when metadata is available, it can be hard to find. There are large metadata aggregation portals like the portal for European data, with almost 2 million records. How do you find what exactly you are looking for. What if there were specialized portals tailored to specific communities?

For even more details, see the companion blog post of the IPFS Foundation.

The idea

The idea is to support both: an easy way for anyone to publish discoverable metadata, and a way to make that metadata widely accessible to build both large aggregators and specialized portals tailored to specific communities.

The central building block is ATProto. It allows anyone to publish and subscribe to records. Rather than defining a single metadata schema to rule them all, the approach here is more meta-meta. Each record contains a link to the actual metadata. That’s the absolute minimum. Though it could make sense to go beyond this minimalism and store additional information to make it easier to build custom portals.

One example of such additional information is a preview. It’s nice to get a quick sense of the underlying data that the metadata describes. For satellite imagery, this could be a true color thumbnail of the scene. For long form articles, a summary or excerpt. For podcasts it may be a brief audio snippet or trailer.

The implementation

As part of my work at the IPFS Foundation, I started with geodata. The first prototype focuses on [Copernicus Sentinel-2 L2A satellite images].

The metadata is sourced from Element 84’s Earth Search STAC catalogue. It provides free, publicly accessible HTTP links to the images (the official Copernicus STAC does not). A [Cloudflare Worker] checks the STAC instance every few minutes for updates. When new records appear, a link to the metadata along with a preview is ingested into ATProto. The source code for the worker is available at https://github.com/vmx/sentinel-to-atproto/.

Below is the Lexicon schema for this ATProto meta-metadata record, which I call Matadisco. To improve readability, the MLF syntax is used:

/// A Matadisco record
record matadisco {
    /// The time the original metadata/data was published
    publishedAt!: Datetime,
    /// A URI that links to resource containing the metadata
    resource!: Uri,
    /// Preview of the data
    preview: {
        /// The media type the preview has
        mimeType!: string,
        /// The URL to the preview
        url: Uri,
    },
}

Once records are available on ATProto, they can be processed and displayed. I built a simple viewer that renders records conforming to the cx.vmx.matadisco Lexicon schema defined above. A Bluesky Jetstream instance streams newly added records directly into the browser. A demo is available at https://vmx.github.io/matadisco-viewer/.

If you’re interested in seeing the raw records, you can find them on my ATProto dev account.

Prior art

This work builds on ideas by Tom Nicholas, who started a project called FROST. His motivating blog post is an excellent read about data-sharing challenges in a scientific context. His presentation on FROST explains why such a system should remain simple, with the metadata URL as the only required field.

Edward Silverton, who works in the GLAM space, explored a similar idea for publishing IIIF data. We refined his approach to align it more closely with FROST. He published further details on the complete workflow for his use case, which has a broader scope.

There was also a discussion thread on Bluesky about metadata for long-form content to build cross-platform discovery.

What’s next

Possible future steps I want to look into:

• Adding another, different geodata source, such as metadata from the German geodata catalogue.
• Including another image-based source, for example GLAM catalogues that use IIIF.
• Integrating a completely different data source, such as metadata from the podcasts of the German public broadcasting.

As mentioned in the introduction, this is deliberately experimental, things may break or change dramatically. The upside is that no one needs to worry about breakage. Please experiment with these ideas and let us now about them at the Matadisco GitHub repository. Publish records under your own namespace, or even reuse the one I am currently using.

Prezado leitor,

Se você trabalha com dados geoespaciais, principalmente rasters, provavelmente já esbarrou em problemas como:

• Dificuldade de organizar grandes volumes de dados
• Falta de padronização na publicação
• APIs pouco eficientes para busca espacial/temporal

É exatamente aqui que entra o STAC (SpatioTemporal Asset Catalog). Mais do que um formato, o STAC é um padrão moderno para organizar, catalogar e acessar dados geoespaciais, permitindo buscas rápidas e interoperáveis.

Neste guia, você vai aprender a montar um ambiente completo para:

• Organizar seus dados no padrão STAC
• Publicar via API moderna
• Integrar com o GeoServer
• Servir dados raster (COG) de forma eficiente

Este post apresenta, passo a passo, como montar um ambiente completo para criação e publicação de um catálogo STAC (SpatioTemporal Asset Catalog), utilizando Docker, PostGIS, GeoServer e uma API intermediária (adapter). O objetivo é permitir que você organize, publique e consuma dados geoespaciais modernos de forma eficiente.

Antes de começar, é importante entender o papel de cada componente:

• PostGIS → Armazena os metadados espaciais
• pgSTAC → Implementa o padrão STAC dentro do PostgreSQL
• STAC FastAPI → Expõe os dados via API REST
• GeoServer → Publica e renderiza os dados
• Adapter (FastAPI) → Traduz STAC para o formato esperado pelo GeoServer

Um ponto importante: o GeoServer ainda não consome STAC “puro” de forma completa, por isso o uso do adapter é essencial.

Antes de instalar qualquer ferramenta, é importante garantir que o sistema esteja atualizado. Isso evita problemas de dependência e incompatibilidade.

> sudo apt update
> sudo apt upgrade -y

O Docker será usado para isolar cada componente da arquitetura, garantindo reprodutibilidade. Isso evita conflitos de versão e facilita deploy em outros ambientes.

2.1 Adicionar chave GPG:

> curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
> sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

2.2 Adicionar repositório:

echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

2.3 Instalar Docker + Compose:

> sudo apt update
> sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin -y

Com isso, você terá um ambiente isolado para rodar toda a stack sem conflitos de versão.

Agora vamos organizar os diretórios do projeto:

> sudo mkdir -p /docker/geoserver/plugins
> cd /docker/geoserver/plugins

O plugins que iremos realizar o download adicionam suporte a:

• COG (Cloud Optimized GeoTIFF) via HTTP/S3
• Integração com STAC

Sem esses plugins, o GeoServer não consegue trabalhar corretamente com dados cloud-native.

> wget https://build.geoserver.org/geoserver/2.27.x/community-latest/geoserver-2.27-SNAPSHOT-cog-http-plugin.zip
> wget https://build.geoserver.org/geoserver/2.27.x/community-latest/geoserver-2.27-SNAPSHOT-cog-s3-plugin.zip
> wget https://build.geoserver.org/geoserver/2.27.x/community-latest/geoserver-2.27-SNAPSHOT-stac-datastore-plugin.zip

Criamos um Dockerfile para incluir os plugins:

cd /docker/geoserver
nano Dockerfile

O conteúdo do arquivo:

FROM docker.osgeo.org/geoserver:2.27.2

COPY plugins/*.jar /usr/local/tomcat/webapps/geoserver/WEB-INF/lib/

Aqui estamos estendendo a imagem padrão do GeoServer para suportar STAC e COG.

Agora definimos toda a infraestrutura: Banco de dados (PostGIS), API STAC e GeoServer. Vamos então criar o arquivo docker-compose.yaml:

cd /docker
nano docker-compose.yaml

Esse arquivo é o coração da infraestrutura, ele define como os serviços se comunicam e persistem dados. O conteúdo do arquivo:

volumes:
  postgis-data:
  geoserver-data:

networks:
  internal:
  external:

services:

  db:
    container_name: postgis
    image: postgis/postgis:16-3.4
    volumes:
      - postgis-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=postgis
      - POSTGRES_USER=postgis
      - POSTGRES_PASSWORD=senha_postgis
      - IP_LIST=*
      - ALLOW_IP_RANGE=0.0.0.0/0
      - POSTGRES_MULTIPLE_EXTENSIONS=postgis,hstore,postgis_topology,postgis_raster,pgrouting,btree_gist
      - FORCE_SSL=false
    ports:
      - "5432:5432"
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgis-d postgis"]
      interval: 5s
      timeout: 5s
      retries: 10
    networks:
      - internal

  geoserver:
    container_name: geoserver
    build: ./geoserver
    volumes:
      - geoserver-data:/opt/geoserver/data_dir
      - /docker/geoserver/imagem_raster:/opt/geoserver/data_dir/coverages
    environment:
      - TZ=America/Sao_Paulo
      - GEOSERVER_ADMIN_USER=admin
      - GEOSERVER_ADMIN_PASSWORD=geoserver
      - INSTALL_EXTENSIONS=true
      - EXTRA_JAVA_OPTS=-Xms4G -Xmx6G
      - STABLE_EXTENSIONS=importer,wps,pyramid
      - PROXY_BASE_URL=http://192.168.186.140:8083/geoserver
      - GEOSERVER_CSRF_WHITELIST=192.168.186.140
      - HTTP_SCHEME=http
      - CORS_ENABLED=false
    ports:
      - "8083:8080"
    restart: unless-stopped
    healthcheck:
      test: curl --fail "http://localhost:8080/geoserver/web/wicket/resource/org.geoserver.web.GeoServerBasePage/img/logo.png" || exit 1
      interval: 1m30s
      timeout: 10s
      retries: 3
    networks:
      - internal
      - external

  stac:
    container_name: stac-api
    image: ghcr.io/stac-utils/stac-fastapi-pgstac:latest
    environment:
      - PGHOST=db
      - PGPORT=5432
      - PGDATABASE=postgis
      - PGUSER=postgis
      - PGPASSWORD=senha_postgis
    ports:
      - "8085:8080"
    depends_on:
      db:
        condition: service_healthy
    networks:
      - internal

Agora é subir o ambiente:

> docker compose build
> docker compose up -d

Instalar a ferramenta:

sudo apt install -y pipx
pipx ensurepath
source ~/.bashrc
pipx install "pypgstac[psycopg]"

Configurar conexão:

export PGHOST=127.0.0.1
export PGPORT=5432
export PGDATABASE=postgis
export PGUSER=postgis
export PGPASSWORD=senha_postgis

Rodar migração:

> pypgstac migrate

Esse comando cria toda a estrutura STAC dentro do banco:

• Tabelas de collections
• Tabelas de items
• Índices espaciais e temporais

Sem isso, a API STAC não consegue funcionar.

Collections funcionam como agrupadores lógicos de dados. Exemplos: Sentinel-2, Ortofotos, Modelos de elevação.

Crie o arquivo:

nano collection.json

Conteúdo do arquivo:

{
  "id": "raster-test",
  "type": "Collection",
  "description": "Teste de raster",
  "license": "proprietary",
  "extent": {
    "spatial": { "bbox": [[-180, -90, 180, 90]] },
    "temporal": { "interval": [["2024-01-01T00:00:00Z", null]] }
  }
}

Para inserir no banco, execute o comando abaixo:

pypgstac load collections collection.json

Os Items representam os dados reais. Exemplo: Um raster específico, um ortomosaico, uma cena de satélite.

Crie o arquivo:

nano item.json

Conteúdo do arquivo:

{
  "type": "Feature",
  "stac_version": "1.0.0",
  "id": "paraiso-ortomosaico",
  "collection": "raster-test",
  "geometry": {
    "type": "Polygon",
    "coordinates": [[
      [-48.8961561, -25.0593974],
      [-48.8764276, -25.0593974],
      [-48.8764276, -25.0730781],
      [-48.8961561, -25.0730781],
      [-48.8961561, -25.0593974]
    ]]
  },
  "bbox": [-48.8961561,-25.0730781,-48.8764276,-25.0593974],
  "properties": {
    "datetime": "2024-01-01T00:00:00Z",
    "proj:epsg": 4326
  },
  "assets": {
    "data": {
      "href": "http://SEU_IP:9000/rasters/seu_arquivo.tif",
      "type": "image/tiff",
      "roles": ["data"]
    }
  }
}

Inserir item no banco:

pypgstac load items item.json

Se você precisar editar o conteúdo do json e realizar um update no banco, use o seguinte comando:

pypgstac load items item.json --method upsert

Você ainda tem uma outra opção que é a criação automático do arquivo json através do rio-stac, para isso você precisa:

pipx install rio-stac --include-deps
rio stac orotomosaico_cog.tif > item.json

Dica importante:

O campo “href”: “http://SEU_IP:9000/rasters/seu_arquivo.tif” do JSON, é o link para o dado real (idealmente um COG acessível via HTTP ou S3).

Essa é uma das partes mais importantes da arquitetura, pois o GeoServer não consume STAC de forma totalmente nativa. Então esse adapter vai resolver as incompatibilidades do GeoServer com STAC, ajustando links e headers.

Para o STAC funcionar perfeitamente no GeoServer, é necessário realizar alguns ajustes de:

• Content-Type
• Href
• Navegação interna

Devido a esse problema, foi desenvolvido um adapter em FastAPI que: intercepta requisições, ajusta os links (href), corrige headers e diferencia chamadas internas e externas.

Criar API:

mkdir /docker/api
cd /docker/api
nano adapter.py

Conteúdo do arquivo adapter.py

from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse
import requests
import os

app = FastAPI()

STAC_URL = "http://stac-api:8080"

# URLs
PUBLIC_URL = os.getenv("PUBLIC_URL", "http://192.168.186.140:8087")
INTERNAL_URL = "http://stac-adapter:8081"


# -------------------------
# Helper para requisições
# -------------------------
def fetch(url, method="GET", json=None):
    if method == "POST":
        r = requests.post(url, json=json)
    else:
        r = requests.get(url)

    r.raise_for_status()
    return r.json()


# -------------------------
# Detecta se é chamada interna (GeoServer)
# -------------------------
def is_internal(request: Request):
    host = request.headers.get("host", "")
    return "stac-adapter" in host or "geoserver" in host


# -------------------------
# Fix links (inteligente)
# -------------------------
def fix_links(data, internal=False):
    base = INTERNAL_URL if internal else PUBLIC_URL

    def fix(obj):
        if isinstance(obj, dict):
            for k, v in obj.items():
                if k == "href" and isinstance(v, str):
                    obj[k] = v.replace("http://stac-api:8080", base)
                else:
                    fix(v)
        elif isinstance(obj, list):
            for item in obj:
                fix(item)

    fix(data)
    return data


# -------------------------
# ROOT
# -------------------------
@app.api_route("/", methods=["GET", "HEAD"])
async def root(request: Request):
    data = fetch(f"{STAC_URL}/")
    return JSONResponse(
        content=fix_links(data, internal=is_internal(request)),
        media_type="application/json"
    )


# -------------------------
# COLLECTIONS
# -------------------------
@app.api_route("/collections", methods=["GET", "HEAD"])
async def collections(request: Request):
    data = fetch(f"{STAC_URL}/collections")
    return JSONResponse(
        content=fix_links(data, internal=is_internal(request)),
        media_type="application/json"
    )


# -------------------------
# COLLECTION
# -------------------------
@app.api_route("/collections/{collection_id}", methods=["GET", "HEAD"])
async def collection(collection_id: str, request: Request):
    data = fetch(f"{STAC_URL}/collections/{collection_id}")
    return JSONResponse(
        content=fix_links(data, internal=is_internal(request)),
        media_type="application/geo+json"
    )


# -------------------------
# ITEMS
# -------------------------
@app.api_route("/collections/{collection_id}/items", methods=["GET", "HEAD"])
async def items(collection_id: str, request: Request):
    data = fetch(f"{STAC_URL}/collections/{collection_id}/items")
    return JSONResponse(
        content=fix_links(data, internal=is_internal(request)),
        media_type="application/geo+json"
    )


# -------------------------
# ITEM ESPECÍFICO
# -------------------------
@app.api_route("/collections/{collection_id}/items/{item_id}", methods=["GET", "HEAD"])
async def item(collection_id: str, item_id: str, request: Request):
    data = fetch(f"{STAC_URL}/collections/{collection_id}/items/{item_id}")
    return JSONResponse(
        content=fix_links(data, internal=is_internal(request)),
        media_type="application/geo+json"
    )


# -------------------------
# SEARCH
# -------------------------
@app.api_route("/search", methods=["GET", "POST", "HEAD"])
async def search(request: Request):
    if request.method == "POST":
        body = await request.json()
        data = fetch(f"{STAC_URL}/search", method="POST", json=body)
    else:
        data = fetch(f"{STAC_URL}/search")

    return JSONResponse(
        content=fix_links(data, internal=is_internal(request)),
        media_type="application/geo+json"
    )

Agora vamos ao conteúdo do arquivo Dockerfile:

FROM python:3.11-slim

WORKDIR /app

RUN pip install fastapi uvicorn requests

COPY adapter.py .

CMD ["uvicorn", "adapter:app", "--host", "0.0.0.0", "--port", "8081"]

E pra finalizar, você deve adicionar ao seu docker-compose:

adapter:
  container_name: stac-adapter
  build: ./api
  ports:
    - "8087:8081"
  depends_on:
    - stac
  networks:
    - internal
    - external

Agora é só subir o adapter:

docker compose up -d --build

Agora, para finalizar, vamos instalar o nginx e deixar tudo rodando externamente na porta 80. O Nginx atua como proxy reverso, centralizando o acesso:

• /geoserver → GeoServer
• /stac → Adapter
• /stac-api → API direta

E ainda ajuda na organização das rotas, facilidade de exposição externa e melhor controle de segurança.

Vamos criar o arquivo nginx-stac.conf:

cd /docker/
nano nginx-stac.conf

Esse arquivo deve conter o seguinte conteúdo:

server {
    listen 80;

    # -------------------------
    # GEOSERVER
    # -------------------------
    location /geoserver/ {
        proxy_pass http://geoserver:8080/geoserver/;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # -------------------------
    # STAC (via adapter)
    # -------------------------
    location /stac/ {
        proxy_pass http://adapter:8081/;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # -------------------------
    # STAC DIRETO (opcional)
    # -------------------------
    location /stac-api/ {
        proxy_pass http://stac-api:8080/;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Você precisar alterar a seguinte linha do arquivo adapter.py:

PUBLIC_URL = os.getenv("PUBLIC_URL", "http://192.168.186.140:8087")

Para:

PUBLIC_URL = os.getenv("PUBLIC_URL", "http://192.168.186.140/stac")

Agora é só subir o seu container, e pronto:

docker compose up -d --build

Se tudo estiver correto, você verá sua collection retornada via API.

Com essa arquitetura, você passa a ter:

• Um catálogo STAC estruturado e escalável
• Uma API moderna para consulta espacial e temporal
• Integração com GeoServer
• Suporte a dados cloud-native (COG)

Mais do que isso, você construiu uma base sólida para aplicações geoespaciais modernas, preparada para lidar com grandes volumes de dados de forma eficiente.

Spoiler Alert: This is a pretty geeky post that may only appeal to Dead Heads!

I had an idea to go back to my Dead Reckoning project to look at the frequency that different songs were played by the Grateful Dead over the 31 years of gigging. I had already extracted the set lists for nearly all of the 2,313 shows the band played between 1965 and 1995 from JerryBase so I thought this would be relatively simple (it never is).

I asked Claude to parse the 31 years of gig files and make a table ranking the top 100 songs played over this period and showing the number of times played in each year and what percentage of gigs it was played as an indicator of the band’s favourites over time. This was nice and easy and after one small tweak I had a nice table.

Then I asked Claude to make me a heatmap graphic from the table with the colour intensity representing the frequency that a song was played. Hey presto, Claude used mapplotlib and numpy to generate the heatmap and it looked pretty good. The problem was that a 100 row 32 column graphic is pretty hard to read, over quite a few iterations I improved the colour palette to get better definition between the ranges, sorted out the legend which was more difficult than I expected and fought with Claude and the libraries to get a legend and year labels at the top and bottom of the graphic. You can see the result here – even though this is a 1.4Mb image it still isn’t easy to read.

Then I asked Claude if it could turn the graphic into an interactive web page and in a minute it came back with this interactive heatmap of song frequency by year which I think is pretty cool and provides a much better way of exploring the data and spotting the trends.

In a couple of hours I had gone from 31 files listing over 2,300 gigs to an interactive frequency graphic with a lot of help from Claude – without that help I would not have known where to start.

OSGeoNL Startersdag – 17 april, Den Bosch -

Maak kennis met open source geo-software!

Ben je nieuwsgierig naar geo, maar weet je niet waar te beginnen? Of wil je overstappen naar open source software? Dan is de OSGeoNL Startersdag dé kans om een dag lang laagdrempelig kennis te maken met het open source geo-landschap.

Wat kun je verwachten?

• Inspirerende workshops door bedrijven en organisaties gespecialiseerd in open source geo.
• Zeer divers aanbod workshops met onder andere: Introductie GIS Essenties, QGIS, GrassGIS, MapLibre en PostGIS.
• Concrete voorbeelden en use cases: ontdek wat mogelijk is en wanneer je open source software toepast.

Voor wie?

• Beginners in geo
• Mensen die willen overstappen naar open source software
• Iedereen die een nieuwe geo-tool wil leren

Kom ontdekken wat open source geo-software voor jou kan betekenen, maak nieuwe connecties en laat je inspireren!

QField’s first release of the year comes packed with new features as well as a bundle of improvements and polishing. Let’s jump right into it.

Main highlights

3D

This new version of QField comes with a shiny 3D map view, giving users the ability to render their map content on top of a three-dimensional terrain.

Users can rotate the terrain geometry to get a better understanding of elevation profiles, while also adjusting the plane’s extent by panning and zooming with drag and pinch gestures. When the GNSS positioning service is enabled, the user’s current position, as well as ongoing tracking sessions, will be overlaid on top of the 3D terrain geometry.

By default, QField relies on Mapzen Global Terrain tiles to determine terrain elevation. As its name indicates, this is a 30-meter digital elevation model covering the globe and hosted online, which allows QField to render 3D views without any user configuration. But it does not stop there. QField supports additional elevation sources, such as disk-based GeoTIFFs, to work in offline areas. This can be configured when setting up a project by changing the terrain type in QGIS.

COGO operations

Moving on to the next major functionality introduced in this new version: a COGO (Coordinate Geometry) framework to support fieldwork through a set of parameter-driven operations to generate vertices. This has been one of the most requested features by professional land surveyors, so we couldn’t be more excited to deliver it and hear back from our community.

QField 4.1 ships with three COGO tools:

• The XYZ parameters operation generates vertices based on a manually entered pair of X and Y coordinates as well as an optional Z value;
• The distance/angle from point operation generates vertices based on distance and angle values from a given point; and
• The circles’ intersection operation generates vertices at the intersection of two circles, each defined by a point and a radius.

Leveraging QField’s capabilities, a COGO operation’s point parameter can be defined in multiple ways: users can enter values manually or automatically fill in the parameter using either the current GNSS position, the geometry of a pre-existing feature within a point layer, or the coordinate cursor’s location. The latter is super useful when coupled with project snapping.

There’s more

Beyond these two flagship features, this new version contains tons of improvements.

We’re happy to report that the background tracking functionality introduced for Android last year is now available on iOS. Users can now save battery by locking their phone while QField continues to track positions. Upon reopening QField, the collected positions will be written into your project. No Apple will be left behind.

The feature form continued to receive improvements during this development cycle. Starting with this version, Remember Last Value pins are hidden by default. Moving away from an always-shown interface, remember last value pin visibility can now be configured per field. Using the latest QGIS (4.0 and above), users can configure the presence of the pin and whether remembrance should be active by default in the vector layer properties’ attribute form panel.

Position tracking has received a lot of attention during this development cycle focused on optimizations. Tracking is now friendlier to your device battery while user interface responsiveness has been improved when tracking sessions are ongoing. We’ve also spent some time making Bluetooth connections to external GNSS devices even more reliable. If this was an issue for you in the past, give this version a try again.

Finally, something to please our advanced users: QField now offers the ability to tunnel network traffic through a proxy that can be enabled and configured in the settings panel.

‘Barents Sea’ release name

The Barents Sea, a marginal sea of the Arctic Ocean bordered by Norway and Russia, is one of the most ecologically and geopolitically significant water bodies on the planet. Home to some of the world’s largest cod and haddock fisheries, it sustains both marine ecosystems and the livelihoods of coastal communities across the high north. Its waters are a barometer for our changing climate: the Barents Sea is the fastest-warming part of the Arctic, making it a critical area of scientific observation and environmental monitoring. The Nansen Legacy project has been tracking these changes closely (factsheet).

Sea ice in the Barents Sea, Peter Prokosch https://www.grida.no/resources/3636

At OPENGIS.ch, we see the Barents Sea as a powerful symbol of why field data collection matters. Understanding and protecting remote, extreme environments like the Arctic requires tools that are reliable, offline-capable, and built for real-world conditions. That is precisely what QField is designed to deliver.

With QField 4.1 ‘Barents Sea’, we continue building on that mission, bringing new capabilities to field workers, researchers, and environmental stewards wherever their work takes them.

Happy field mapping!

GeoServer 2.28.3 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.3 is made in conjunction with GeoTools 34.3, and GeoWebCache 1.28.3.

Thanks to Andrea Aime (GeoSolutions) for making this release.

Release notes

Improvement:

• GEOS-11886 Sort entries in all .properties files alphabetically
• GEOS-12033 Allow to configure custom CRS authorities and transformations
• GEOS-12037 Support Metatiling on MapBox Vectortiles

Bug:

• GEOS-11964 Metadata Bulk Operations: wicket error
• GEOS-12038 ModificationProxy.replaceCatalogInfo() precludes converting Filters to native query language
• GEOS-12047 Lock timeout and nested lock support in GeoServer
• GEOS-12055 GeoServerSecurityManager.reload() not clearing service caches
• GEOS-12060 REST API with PUT does not allow un un-set a field

Task:

• GEOS-12027 Removing not needed org.restlet.ext.fileupload dependency
• GEOS-12028 Update ‘com.google.code.gson’ dependency version
• GEOS-12029 Update ‘com.google.protobuf’ dependency version
• GEOS-12049 Remove GWC InMemory cache support

For the complete list see 2.28.3 release notes.

Community Updates

Community module development:

• GEOS-11509 OGC API 3D GeoVolumes community module
• GEOS-12002 hz-cluster: homepage pop-up fails
• GEOS-12030 Features templating xstream tags conflict with geofence
• GEOS-12044 STAC search endpoint should report invalid collection names as invalid parameters instead of internal errors
• GEOS-12061 New Community Module for PNG-WIND output format for wind datasets

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* Advertise and Enforce Attribute Restrictions

Release notes: ( 2.28.3 | 2.28.2 | 2.28.1 | 2.28.0 | 2.28-M0 )

I was looking for a simpler project to build after my last couple which had proved more complicated than I had anticipated. I came up with the idea of mapping airports and finding some data on their environmental impact – good idea, but not so easy.

Finding a dataset of airports was relatively easy, the OurAirports dataset has excellent coverage but sourcing open data about passenger numbers or emissions associated with specific airports was challenging to say the least. Eventually I settled for US, UK and EU airports where there was good passenger data from the US FAA, EU Eurostat and UK CAA. Maybe I will come back to this project in the future and try to build out to cover more regions.

Inevitably the data from each source was in different formats, had different coverage and took a lot of wrangling to get into a consistent data model. Claude was my best friend, writing python scripts for processing the data and combining it into a single coverage.

I could not find any consistent emissions data for the 600 airports that I was working with so I used an estimate of 125kg per passenger which is very broad brush (a more accurate calculation would distinguish between short haul and long haul flights, use passenger miles etc but I didn’t have the data).

I had an idea to try and calculate the impact of flights based on the population near an airport. Claude suggested using the WorldPop Global Population raster data for 2024 – and wrote a python script to calculate the population within a 20km radius of the airport using Geopandas, Rasterio and Shapely (I hope you are impressed that I have a clue as to what these libraries do).

The map build was relatively straightforward once I had the data. The default visualisation shows estimated emissions based on passenger numbers on a colour scale green to red and is sized by the population impacted within a 20km zone. The alternative is to show passenger numbers by symbol size. For both visualisations the year slider allows you to select a year and the info pop-up shows that year’s stats. The summary stats update as you zoom in to show the number of airports in the current view and the emissions or passenger numbers.

Although this is best viewed on a laptop or tablet screen, I managed to tweak it to work reasonably on a mobile (view in landscape is better than portrait).

All in all this isn’t perfect and I am not sure how enlightening it is but there are a couple of interesting observations about impact. Some smaller airports can have a bigger impact because they are located close to large populations eg London City Airport is a small airport with about 3.5m passengers n 2024 and estimated CO2 of under 0.5m tonnes but because of it’s location it has a moderate impact on 3.7m people while Heathrow with 84m passengers and 10.5m tonnes of CO2 is more rural and only impacts 1.6m people. Similarly La Guardia has half the emissions and passengers of JFK but impacts double the number of people because of its location.

If you know of an open source of passenger or flight data for other regions or some emissions data, send me a message in the comments and I will try to update the map.

Hace ya algunos años nació gvSIG Batoví, una iniciativa orientada a acercar los Sistemas de Información Geográfica (SIG) al ámbito educativo en Uruguay, especialmente en educación primaria y secundaria.

Su objetivo sigue siendo plenamente vigente: facilitar a docentes y alumnado la comprensión del territorio a través de herramientas geoespaciales abiertas.

gvSIG Batoví es una distribución de gvSIG Desktop adaptada al entorno educativo, pensada para que el uso de los SIG en el aula sea accesible, práctico y motivador.

Su enfoque va mucho más allá de la enseñanza de la geografía. Puede aplicarse a cualquier materia con componente territorial, como historia, ciencias naturales, economía o sociología… o una combinación de todas ellas que permita a los estudiantes conocer su entorno.

A través de mapas temáticos y análisis espacial, el alumnado puede interactuar con la información, comprender mejor los fenómenos y desarrollar pensamiento crítico sobre el territorio.

Además:

• Facilita el aprendizaje mediante la interactividad
• Permite compartir ejercicios e información entre docentes y alumnado
• Es extensible, favoreciendo su evolución continua
• Es software libre (licencia GNU/GPL), lo que garantiza su uso, estudio, adaptación y distribución sin restricciones

Desde sus inicios gvSIG Batoví ha estado especialmente vinculado a iniciativas educativas en Uruguay, como el conocido curso-concurso que ha permitido a muchos estudiantes iniciarse en el mundo de la geomática.

Descarga gvSIG Batoví

Queremos que este recurso siga siendo útil para la comunidad educativa, por lo que puedes descargarlo y empezar a utilizarlo desde aquí:

Descarga de gvSIG Batoví

QGIS 4.0 is out. After years of work by hundreds of volunteers and organisations around the world (migrating to Qt6, reworking the codebase, shipping over 100 new features on top) we have a platform that will serve the community for the next decade. That’s worth celebrating.

It’s also a good moment to be honest about what it takes to keep a project like this healthy, and to ask for your help.

Where we are

QGIS is built by a broad ecosystem of contributors: individual volunteers, companies contributing developer hours, and everything in between. That mix of people and organisations who care about open-source geospatial software is what makes QGIS what it is, and it’s something we’re proud of.

What sustaining memberships fund is the layer of support that makes all that volunteer and contributed work more effective: reliable infrastructure, funded bug fixing rounds, documentation writers, and a small number of specialist tasks that are hard to get done consistently on volunteer time alone.

Our goal

Our annual membership income has grown to €320,000, but our 2026 budget requires €634,000 in expenses. To cover that sustainably we need to grow sustaining memberships by at least €100,000 per year. If your organisation uses QGIS, now is the time to join.

This is what your support makes possible.

A secretary for our volunteer PSC

The PSC runs on contributed time. Over the years the administrative workload around membership, correspondence, procurement, and coordination has grown to the point where it regularly crowds out the work that actually needs experienced people. A part-time funded secretary (€30,000, a first in the project’s history) means PSC volunteers can focus on what only they can do.

More pull request review capacity

The volume of contributions to QGIS has outgrown what volunteers can review promptly. We’ve grown the PR review budget from €30,000 to €40,000, but demand still outpaces funding. Faster reviews mean better code quality and a healthier contributor community. We would like to increase this budget even more.

Security

Security expectations for software used in government, enterprise, and critical infrastructure are rising fast. The EU Cyber Resilience Act and similar regulations are making this concrete for open source projects. QGIS needs to meet that bar: documented processes, vulnerability handling, compliance support, and ongoing code hardening.
We’ve doubled our security budget to €10,000 this year. Security work touches packaging, infrastructure, the plugin ecosystem, and how we respond to disclosures. Growing this budget is a priority and directly benefits every organisation that needs to justify QGIS to an IT or procurement team.

Bug fixing for the 4.x era

Each bug fixing round now costs €55,000, up from €40,000 in the 3.x era. Three rounds per year, €165,000 total. This is what keeps every release stable for the half million daily users who depend on it.

A larger grants programme

The grants programme funds community-driven improvements voted on by the community. It’s been flat at €40,000 for years despite the project growing. Growing it is a direct priority for this campaign.

How to join

We’re looking for:

• 1-2 new flagship members (€27,000+, for larger organisations and federal bodies)
• 5 new large members (€9,000+, for larger cities, provinces, or companies up to 100 employees)
• 10 new medium members (€3,000+, for universities, medium-sized cities, or companies up to 50 employees)
• 20 new small members (€500+, for smaller cities or companies up to 10 employees)

Memberships run for one year and can be renewed automatically. To get started, write to our treasurer at finance@qgis.org or visit the membership page.

Need to convince your manager?

QGIS.org is a Swiss non-profit with external auditing, published financial reports, and transparent governance. A sustaining membership is an investment in critical geospatial infrastructure that your organisation already relies on.

Financial reports · Annual reports · Membership details

Illustration by Muhammad Afandi on Unsplash

QGIS 4.0 is now available! But yes, you have read my title correctly - I would recommend many people don’t upgrade…. yet.

QGIS 4.0 is an ‘Early Adopter’ version - which means that there are new things in there that may break. I would also say for many basic users (and some intermediate users) there isn’t much new that’s changed, so you are not missing out on much (see below for some new things coming up).

Many of the changes for 4.0 are under the hood, so that’s why you won’t see many differences. These changes are important - and will make the software more reliable and easier to maintain.

Rather than upgrading now, I would recommend waiting until 4.2 is released (about July 2026) and by this point QGIS will be more stable, and it will be fine to upgrade then.

You must be logged into the site to view this content.

It is with great pleasure that we would like to welcome COSS as our latest flagship sustaining member!

The COSS National QGIS collaboration launched in Finland to safeguard the sustainability of critical geospatial technology.

About COSS

COSS aims to ensure the sustainability of the open source QGIS geospatial software that is essential to many public organizations’ operations, maintaining up-to-date security updates, and realizing productivity benefits from coordinated development. The collaboration is based on coordination among public authorities and on supporting the international QGIS community.

In the first phase, the following organizations have joined the national QGIS collaboration: the National Land Survey of Finland, the Finnish Forest Centre, the Finnish Transport Infrastructure Agency, the Finnish Environment Institute (Syke), and the Natural Resources Institute Finland (Luke). QGIS is a key part of daily geospatial work for many public authorities.

The main objectives of the national QGIS collaboration are:

• Coordinating national cooperation: active discussion of needs and practices, and information exchange between organizations
• Ensuring sustainability of the software in collaboration with the international QGIS community
• Monitoring development priorities and evaluating participation in crowdfunding initiatives
• Expanding the use of QGIS in the public sector: especially promoting adoption in cities

The purpose of the national QGIS collaboration forum is to enable deeper joint discussion on QGIS development needs and to ensure that this essential technology remains vibrant and secure over the long term.

How to get involved

Going forward, Finnish organizations can participate in QGIS’s international activities and funding jointly and in a coordinated manner through the Finnish Centre for Open Systems and Solutions – COSS, which is a non-profit association that promotes the use of open source and open technologies in both the private and public sectors.

COSS centrally manages the administration related to the membership, communications, and liaison with the international QGIS community, so individual national organizations do not need to build separate connections of their own. 

For more information:

Timo Väliharju
Executive Director, COSS ry
timo.valiharju@coss.fi
+358 50 330 3339
www.coss.fi

Dear QGIS Community,

We are very pleased to announce that this year’s round of grants is now available. The call is open to anybody who wants to make a contribution to QGIS funded by our grant fund, subject to the call conditions outlined in the application form.

This year’s budget is €40k and the deadline for the proposals is in four weeks, on Monday, 13 April 2026. Here’s the full timeline:

Timeline

• 2026-03-16: Call for proposals (4 weeks)
• 2026-04-13: QEP discussion period (2 weeks)
• 2026-04-27: Writing discussion summaries (1 week)
• 2026-05-04: Voting starts (2 weeks) 
• 2026-05-18: Publication of results
• — 6 months of project work —
• 2026-11-16: Deadline for follow-up reports

Procedures

Please note the following guidelines: 

• In the week after the QEP discussion period, the proposal authors are expected to write a short summary of the discussion that is suitable for use as a basis on which voting members make their decisions.
• The proposal must be submitted as a QGIS Enhancement Proposal (QEP) issue in the QEP repo (tagged as Grant-2026). Following this approach will allow people to ask questions and provide public feedback on individual proposals.
• New in 2026: The QEP discussion stage mirrors the contributor voting stage of general QEPs. However, the discussion period is time-bounded to two weeks to ensure a timely progress of the programme. If a valid vote is not achieved within the time frame, the decision remains at the discretion of the PSC. 
• Proposals must clearly define the expected final result, so that we can properly assess if the goal of the proposal has been reached.
• The project budgets should account for PR reviewing expenses to ensure timely handling of the project-related PRs and avoid delays caused by relying on reviewer volunteer time. 

The PSC of QGIS.ORG will examine the proposals, and has a veto power in case a proposal does not follow guidelines or is not in line with project priorities. 

For more details, please read the introduction provided in the application form.

We look forward to seeing all your great ideas for improving QGIS!

With the QGIS Grant Programme 2025, we were able to support 6 enhancement proposals that improve the QGIS project. The following reports summarize the work performed:  

1. QEP 332: Port SQL Query History to Browser — Report
   This enhancement has ported the “history” component of the DB Manager SQL dialog to the main QGIS browser “Execute SQL” dialog. The new command history is fully searchable, and shows historic commands grouped nicely in chronological groups. The history also includes the details of the associated connection, row count and execution time. This change was introduced in QGIS 3.44. Screencasts of the work are available in the original pull request.
2. QEP 333: Add screenshots to PyQGIS reference documentation — Report
   This enhancement has added screenshots to the PyQGIS reference documentation, e.g. for the QgsMapLayerComboBox.html, QgsTableEditorDialog.html, QgsColorButton.html and many more. While the original proposal only promised screenshots for 100 classes, this change ended up adding over 150. The final process for adding screenshots is very straightforward and easy to implement. We’ve seen screenshots being contributed by other developers too, and hopefully this trend continues.
3. QEP 335: Adopt wasm32-emscripten as a build target for QGIS — Report
   With this enhancement, QGIS now officially supports the wasm32-emscripten build target. All qgis-js patches have been upstreamed and qgis-js no longer requires any QGIS patches. This allows for easier creation of new qgis-js version in coordination with new QGIS versions. GitHub Actions CI ensures ongoing Emscripten compatibility. This lays the foundation for future WebAssembly-based QGIS applications and exploration of additional WASM possibilities (QGIS Processing, PyQGIS in browser, …).
4. QEP 336: Trusted Projects and Folders — Report
   Thi enhancement has added trust levels for project files and folder (undetermined, untrusted, and trusted). The trust determination by the user can be temporary (for a single QGIS session) or saved in the user profile’s settings and remembered across sessions. The status can be modified in the corresponding options dialog (or preconfigured in the global INI file). Project trust is used to determine whether embedded scripts are permitted to run (including macros, custom expression functions, map layer actions, and attribute form custom init code).
5. QEP 337: Coverity Scan cleanup — Report
   This enhancement has seen a massive cleanup to the QGIS code base via hundreds of fixes to issues reported by the Coverity Scan tool. From the original 1075 issues identified by Coverity Scan at the start of the project, we are now down to 145 remaining outstanding issues. All false positive issues have been marked accordingly, and many fixes submitted to QGIS to remedy valid issues in the QGIS code. The remaining issues are either non-trivial or ambiguous. Several related projects also saw fixes submitted (including MDAL, laz-perf, untwine, PDAL wrench and tinygltf libraries).
6. QEP 338: SIP Incremental builds — Report
   This enhancement has improved the performance of clean builds through improvement to SIP itself as well as improvements on the QGIS side to not rebuild unchanged code generated by SIP. With code compilation now taking longer than SIP code generation, this effectively gives us incremental builds, just at a larger granularity.

Thank you to everyone who participated and made this round of grants a great success and thank you to all our sustaining members and donors who make this initiative possible!

TorchGeo 0.8.0 Release Notes

TorchGeo 0.8 includes 28 new pre-trained model weights and a number of improvements required for better time series support, including a complete rewrite of all GeoDataset and GeoSampler internals, encompassing 8 months of hard work by 23 contributors from around the world.

Highlights of this release

Open and independent governance

You may have noticed that https://github.com/microsoft/torchgeo is now https://github.com/torchgeo/torchgeo. This is not an accident!

TorchGeo was initially created as an intern project at Microsoft's AI for Good Lab back in 2021. Once we made it open source, we were blown away by how quickly it was adopted by the AI4EO community! Since then, over 100 people from around the world have contributed to making TorchGeo what it is today.

Despite being open source, we have received feedback from many current and potential contributors that they have found it difficult to contribute to TorchGeo due to its ownership by Microsoft. While Microsoft has been an excellent incubator for TorchGeo over the past four years, we believe TorchGeo has outgrown its incubation phase.

Over the past year, we have been working diligently with Microsoft to come up with a solution. As of this release, we are excited to announce the formation of the TorchGeo Organization, a governing body designed to ensure the independence and longevity of the TorchGeo Project. The TorchGeo Organization is led by a Technical Steering Committee (TSC), initially composed of the current maintainers of the TorchGeo Project:

• @adamjstewart (TUM) - Chair
• @calebrob6 (Microsoft)
• @anthonymlortiz (Microsoft)
• @isaaccorley (Wherobots)
• @ashnair1 (Space42)
• @nilsleh (TUM)

TorchGeo now lives at https://github.com/torchgeo, and Microsoft has graciously volunteered to give away the copyright to YOU, the TorchGeo Contributors. We would like all TorchGeo users and developers to take ownership of the project, and thus invite each and every one of you to join our TSC meetings. Please join the #technical-steering-committee channel in the TorchGeo Slack for more information on our monthly meeting schedule.

Other than this new open and independent governance, not much will change with the TorchGeo Project. TorchGeo will always remain open source under an MIT license and be free for all users and developers. We hope this change will open up opportunities for more collaboration, more awesome libraries built on top of TorchGeo, and more confidence in the long-term future of the project!

Change detection support

TorchGeo 0.8 introduces support for change detection datasets (B x 2 x C x H x W)! This includes a new ChangeDetectionTask LightningModule with support for binary, multiclass, and multilabel change detection. This LightningModule supports both early-fusion (all encoders from timm and decoders from SMP) and the following change detection-specific late-fusion architectures:

• Fully Convolutional Siamese Networks (@rcdaudt et al., 2018)
• ChangeStar (@Z-Zheng et al., 2021)
• ChangeViT (@zhuduowang et al., 2024)
• Be The Change (@blaz-r et al., 2025)

TorchGeo also includes the following binary and multiclass change detection datasets:

• OSCD (@rcdaudt et al., 2018) - binary
• xView2 @RitwikGupta et al., 2019) - multiclass
• LEVIR-CD (@justchenhao et al., 2020) - binary
• LEVIR-CD+ (Shen et al., 2021) - binary
• ChaBuD (@julien-blanchon et al., 2023) - binary
• CaBuAr (@DarthReca et al., 2024) - binary
• BRIGHT (@ChenHongruixuan et al., 2025) - multiclass, pictured above

All datasets have a corresponding LightningDataModule that is compatible with and tested against ChangeDetectionTask.

P.S. For other change detection models, check out @Z-Zheng's excellent torchange library!

Backwards-incompatible changes

GeoDataset/GeoSampler: BoundingBox → GeoSlice

Prior releases of TorchGeo used a custom BoundingBox object for GeoDataset indexing:

from torchgeo.datasets import BoundingBox

bbox = BoundingBox(xmin, xmax, ymin, ymax, tmin, tmax)
ds[bbox]

This custom BoundingBox object was quite different from other libraries and lacked a lot of the flexibility needed for time series support. All inputs were required, even if space or time were unimportant, and only integer tmin/tmax were supported.

TorchGeo 0.8 adopts a powerful slicing syntax similar to numpy, xarray, and torch:

ds[xmin:xmax:xres, ymin:ymax:yres]
ds[:, :, tmin:tmax:tres]
ds[xmin:xmax, ymin:ymax, tmin:tmax]

Spatial-only, temporal-only, and spatiotemporal slices are all supported. Each slice can optionally specify the resolution of the returned data. If any min, max, or res values are missing, the defaults for the full dataset are used. While x and y are in float, t is in datetime.datetime for more natural temporal slicing.

If you are using GeoDataset in combination with GeoSampler, no changes are required for forwards-compatibility, as GeoSampler and GeoDataset.bounds now return these slices. BoundingBox is now deprecated and will be removed in a future release.

bbox = (slice(xmin, xmax), slice(ymin, ymax), slice(tmin, tmax))

GeoSampler/splitters: BoundingBox → Polygon, Interval

In previous releases of TorchGeo, if you wanted to select a smaller region of interest (ROI) for training or validation, you could either use the roi parameter of GeoSampler or use roi_split and time_series_split to directly split your GeoDataset. However, only BoundingBox objects were supported.

In TorchGeo 0.8, you can now use arbitrary shapely.Polygon and pd.Interval objects for ROI and TOI bounds. These polygons do not have to be boxes, they can be any shape, including a GeoJSON outline of a complex island archipelago.

roi = BoundingBox(xmin, xmax, ymin, ymax, tmin, tmax)

roi = shapely.box(xmin, ymin, xmax, ymax)  # note change in order
toi = pd.Interval(tmin, tmax)

GeoDataset/GeoSampler: rtree → geopandas

TorchGeo previously used the R-tree library for spatiotemporal indexing of geospatial data. This allowed for fast computation of intersection, union, and indexing. However, R-tree lacks support for a lot of desirable geospatial and geotemporal features, including non-rectangular polygons, automatic reprojection, datetime objects, and spatial/temporal aggregation.

TorchGeo 0.8 switches TorchGeo's spatiotemporal indexing backend from R-tree to geopandas, which supports all of these features and more with similar performance. Geopandas can efficiently scale to large datasets using dask-geopandas and multithreading. Entire shapefiles can be directly stored in geopandas instead of only storing a single bounding box.

This change will be most notable for users who write custom GeoDataset subclasses. If you are using a built-in dataset, you may not even notice this change. In the future, we plan to continue improving support for non-rectangular polygons in both the dataset and sampler so that nodata pixels can be easily avoided.

VectorDataset: fiona → geopandas

Similarly, all VectorDataset classes now use geopandas instead of fiona for data loading. This results in one less dependency and allows for complicated expressions without for-loops, often resulting in faster data loading. The only backwards-incompatible change here is that the get_label method now takes a pd.Series row as input instead of a fiona.Feature.

Change detection datasets: C x H x W → 2 x C x H x W

Previously, our time series datasets were inconsistent, with some datasets returning a single T x C x H x W object, others combining the T and C dimensions into a (T C) x H x W object, and others returning multiple C x H x W objects labeled image1, image2, image_pre, image_post, etc.

All change detection datasets now return a single 2 x C x H x W object. The remaining time series datasets will be changed in the next release to T x C x H x W.

Custom transform deprecation removals

This release removes several custom or private transforms that have been deprecated for several releases or are not compatible with time series data:

CenterCrop is not identical to _ExtractPatches, and you may need to change the patch_size to get full coverage during evaluation. We are planning to upstream a method directly to Kornia or torchvision to better support this.

Dependencies

New dependencies

• geopandas (#2747)
• microsoft-aurora (#2823)
• requests (#2989)
• rioxarray (#1490)

Removed dependencies

• fiona (#2962)
• rtree (#2747)

Changes to existing dependencies

• kornia: 0.8.2+ now required (#3094)
• lightning: 2.5.6 not supported (#3080)
• numpy: 1.24+ now required (#1490)
• rasterio: 1.4.3+ now required (#1490)
• shapely: 2+ now required (#2747)
• timm: 1.0.3+ now required (#2828)
• xarray: 0.17+ now required (#1490)

Datasets

New datasets

• OpenStreetMap: pictured above (#2989, #3116, #3117)
• SolarPlantsBrazil (#2797)

Changes to existing datasets

• Dataset plots: portrait → landscape (#3093)
• BRIGHT: image_pre, image_post → image (#2862)
• BRIGHT: add vmin/vmax to plots (#3097)
• CaBuAr: (T C) → T x C (#2863)
• CDL: add 2024 data (#2939)
• ChaBuD: (T C) → T x C (#2878)
• ChaBuD: fix link to homepage (#3128)
• EDDMapS: add plot method (#2709)
• GBIF: add plot method (#2741)
• LEVIR-CD: image1, image2 → image (#2879)
• iNaturalist: add plot method (#2743)
• OSCD: image1, image2 → image (#2422)
• OSCD: fix documentation of image sizes (#3128)
• MMEarth: add plot method (#2759)
• Sentinel-2: support for .SAFE multiresolution products (#3043)
• Western USA Live Fuel Moisture: add plot method (#2769)
• xView2: multi-temporal semantic segmentation → change detection (#2906)

Changes to dataset base classes

• GeoDataset: rtree → geopandas (#2747)
• GeoDataset: add support for slicing (#2804, #2847)
• XarrayDataset: new base class, still experimental (#1490)
• VectorDataset: fiona → geopandas (#2962, #3114, #3118, #3119)
• VectorDataset: add support for object and instance detection (#2819)
• IntersectionDataset: support spatial-only intersection (#2837)

Utilities

• BoundingBox: deprecated in favor of GeoSlice (#2847)
• pad_across_batches: time series collation function (#2921)
• splitters: rtree → geopandas (#2747)
• roi_split: support arbitrary Polygon roi (#2835)

Data Modules

New data modules

• BRIGHT (#2862)
• PASTIS (#2921)
• PatternNet (#2760)
• SolarPlantsBrazil (#2797)

Changes to existing data modules

• CaBuAr: use video transforms (#2863)
• ChaBuD: use video transforms (#2878)
• LEVIR-CD: use video transforms (#2879)
• OSCD: use video transforms (#2422)
• OSCD: support for non-square images (#3103)
• xView2: use video transforms (#2906)

Losses

• QR: improve numerical stability (#2796)

Models

New model architectures

• Aurora: pictured above (#2823, #3127)
• BTC (#2926, #3122)
• ChangeViT (#2910)
• ConvLSTM (#2898)
• EarthLoc (#2806)
• L-TAE (#2867)
• Swin v1 (#2926)
• U-Net (#2719)

New model weights

• CLOSP (#2904)
• Cityscapes (#2926)
• FTW (#2719, #2956, #3112)
• OAM-TCD (#2869, #3127)
• SeCo-Eco (#2849)

Changes to existing models

• All weight transforms are now exportable (#2893)
• MOSAIKS: new alias for RCF (#2915)
• Panopticon: speed up position embedding (#2888)

Samplers

• GeoSampler: r-tree → geopandas (#2747)
• GeoSampler: add support for slicing (#2804, #2847)
• GeoSampler: support arbitrary Polygon roi, add toi (#2812)
• GridGeoSampler: default stride = patch size (#2722)

Scripts

• CLI: add --version argument (#2912)

Trainers

New trainers

• Change detection (#2422, #2857, #2862, #2863, #2879, #2890, #2910, #2926, #3085)

Changes to existing trainers

• Classification: class_weights list support (#2707)
• Semantic segmentation: class_weights list support (#2707)
• Semantic segmentation: add support for DPT, Segformer, and UPerNet decoders (#2828)
• Semantic segmentation: add support for satellite image time series (#2921)

Transforms

New transforms

• Sat-SlideMix (#2742)
• Rearrange (#2477)

Removed transforms

• AugmentationSequential (#3100)
• _Clamp (#3100)
• _ExtractPatches (#3100)

Documentation

• API: restructure model docs (#2892)
• README: add YouTube channel (#3107)
• README: add new podcast episode (#2947)
• README: add more Slack links (#2953)
• Related Libraries: auto-update metrics (#3001, #3011, #3013, #3120, #3125)
• Related Libraries: TorchGeo rtree → geopandas (#2747)
• Related Libraries: fix TerraTorch weights, URL, conda-forge (#3012, #3083, #3104)
• Related Libraries: add GDL (#3008)
• Related Libraries: add torchange (#3072)

Tutorials

• TorchGeo: introduce new slicing syntax (#2747, #2804)
• Embeddings: rename section header (#3087)

Governance

• Add formal governance (#2514)
• Copyright: Microsoft Corporation → TorchGeo Contributors (#2935, #2968, #3010)
• Rename references to previous GitHub organization (#2941)
• pyproject.toml: add explicit license-files (#3126)

Tests

• Bundle all trainer tests together (#3066)
• Silence shapely warnings in test data (#3077)
• Reduce batch size to silence warnings (#3063)
• No unconditional skips (#3096)

Contributors

This release is made possible thanks to the following contributors:

• @adamjstewart
• @amrirasyidi
• @ashnair1
• @biancazadrozny
• @blaz-r
• @burakekim
• @calebrob6
• @DarthReca
• @FederCO23
• @forrestfwilliams
• @gcaria
• @geonextgis
• @HeshamHM28
• @hkristen
• @isaaccorley
• @keves1
• @mayrajeo
• @MUYang99
• @nilsleh
• @robmarkcole
• @tayden
• @yichiac
• @Z-Zheng

Dados raster estão entre os datasets mais pesados do mundo GIS. Ortomosaicos, imagens de satélite e modelos digitais de elevação frequentemente possuem dezenas ou até centenas de gigabytes.

Historicamente, trabalhar com esses arquivos sempre foi um desafio para profissionais de geotecnologia. Entre os principais problemas estão:

• Leitura lenta de arquivos grandes
• Alto consumo de disco
• Necessidade de armazenamento local
• Dificuldade de uso em ambientes cloud
• Baixa escalabilidade em servidores GIS

Foi nesse cenário que surgiu o Cloud Optimized GeoTIFF (COG).

Hoje o COG é considerado um dos formatos mais importantes para infraestruturas modernas de dados geoespaciais, permitindo trabalhar com rasters gigantes de forma muito mais eficiente.

Neste artigo vamos entender:

• O que é COG
• Como ele funciona
• Por que ele é muito mais rápido
• Vantagens e desvantagens
• Como criar um COG
• Como usar COG com servidores GIS
• Impacto real na performance para usuários

1. O problema dos rasters tradicionais

Um GeoTIFF tradicional não foi projetado para acesso remoto eficiente.

Imagine um ortomosaico de 20 GB. Um usuário acessa apenas uma pequena área no mapa. O que acontece internamente:

Mesmo que o usuário precise de apenas 1% da imagem, o servidor pode acabar lendo uma grande parte do arquivo. Isso gera:

• Alto I/O de disco
• Grande uso de CPU
• Lentidão no acesso
• Pouca escalabilidade

2. O que é Cloud Optimized GeoTIFF (COG)

O Cloud Optimized GeoTIFF (COG) é uma variação do formato GeoTIFF otimizada para acesso eficiente via rede. Ele foi projetado para permitir que aplicações leiam apenas os pedaços necessários do arquivo. Em vez de carregar o raster inteiro, o cliente acessa somente os blocos relevantes.

Isso permite acessar rasters muito grandes diretamente em:

• Servidores HTTP
• Object Storage
• Infraestruturas Cloud

Sem precisar baixar o arquivo completo.

3. Como o COG funciona internamente

A performance do COG depende de três características principais.

3.1 Tiling interno

No COG o raster é dividido em blocos menores chamados de tiles.

Esses blocos normalmente possuem tamanho como:

512 x 512 pixels

Quando um cliente pede uma área específica do mapa, apenas os tiles necessários são lidos.

3.2 Overviews (pirâmide de resolução)

COGs normalmente possuem overviews internas. Isso significa que versões reduzidas da imagem são armazenadas dentro do próprio arquivo. Exemplo:

Quando o usuário está visualizando o mapa em escalas menores, o servidor lê apenas as versões reduzidas. Isso reduz drasticamente:

• Leitura de dados
• Tempo de renderização
• Consumo de CPU

3.3 HTTP Range Requests

Uma das principais características do COG é permitir leitura parcial do arquivo via HTTP. Exemplo de requisição:

GET /imagem.tif
Range: bytes=10000-20000

O servidor retorna apenas aquela parte do arquivo.

Isso permite acessar COGs sem baixar o raster inteiro diretamente em:

• Servidores web
• S3
• MinIO
• Cloud Storage

4. Comparação prática: GeoTIFF vs COG

Comparação visual – GeoTIFF vs COG

4.1 GeoTIFF tradicional

Problemas:

• Alto uso de disco
• Leitura pesada
• Baixa escalabilidade

4.2 COG

Benefícios:

• Leitura mínima de dados
• Muito mais rápido
• Ideal para cloud

5. Vantagens do COG

Principais vantagens:

• Leitura parcial do raster
• Acesso eficiente via HTTP
• Ideal para cloud computing
• Integração com object storage
• Redução de I/O de disco
• Excelente para grandes datasets

6. Desvantagens

Apesar das vantagens, existem alguns pontos a considerar:

• Criação pode ser demorada para rasters muito grandes
• Arquivos podem ficar maiores devido às overviews
• Não é ideal para edição constante
• Exige processamento inicial

Por isso o COG é mais indicado para dados finais de publicação.

7. Como criar um COG

O primeiro passo é converter o raster tradicional para Cloud Optimized GeoTIFF (COG). A maneira mais comum é usar o GDAL:

gdal_translate input.tif output_cog.tif \
-of COG \
-co COMPRESS=LZW \
-co BLOCKSIZE=512 \
-co BIGTIFF=YES

7.1 Parâmetros importantes

7.2 Validação do COG

Depois da conversão, é importante verificar se o arquivo foi gerado corretamente, da seguinte forma:

gdalinfo arquivo_cog.tif

Se aparecer:

LAYOUT=COG

Significa que o arquivo foi criado corretamente.

8. COG e Object Storage

Uma das maiores vantagens do COG é funcionar perfeitamente com Object Storage.

• S3
• MinIO
• Google Cloud Storage
• Azure Blob Storage

Arquitetura típica:

Isso permite criar infraestruturas altamente escaláveis.

9. COG com servidores GIS

Servidores como GeoServer podem acessar COGs diretamente via HTTP.

Fluxo típico:

Uma grande vantagem é que o raster não precisa ficar no servidor GIS.

10. COG substitui o Cache (GWC)?

Não. O COG e cache resolvem problemas diferentes. Enquanto o COG otimiza leitura do raster, o cache otimiza entrega de mapas renderizados.

Arquitetura recomendada:

11. Benchmark de performance

Vamos comparar três cenários. Vamos supor que você tem um ortomosaico de 20GB. Como seria a performance dele nos cenários abaixo:

GeoTIFF tradicional

Primeiro acesso:

3 a 8 segundos

Alta leitura de disco.

COG

Primeiro acesso:

0.5 a 2 segundos

Leitura parcial.

COG + GeoWebCache

Após cache:

20 a 80 milissegundos

Praticamente instantâneo.

12. Conclusão

O Cloud Optimized GeoTIFF se tornou um dos formatos mais importantes para infraestruturas modernas de dados raster.

Ele permite acesso eficiente a grandes rasters, integração com cloud e publicação escalável em servidores GIS.

Quando combinado com object storage e servidores como GeoServer, o COG possibilita arquiteturas altamente performáticas para distribuição de dados geoespaciais.