by Jody Garnett (noreply@blogger.com) at October 30, 2026 12:38 AM
by Jody Garnett (noreply@blogger.com) at October 30, 2026 12:24 AM
The PostGIS Team is pleased to release PostGIS 3.7.0! Best Served with PostgreSQL 19 RC 1 , GEOS 3.15.0 , postgis_tiger_geocoder 2025.2 , and address_standardizer.
This version requires GEOS 3.10+, PostgreSQL 14-19, Proj 6.1+, and libgmp. To take advantage of all postgis extension features, GEOS 3.15+ is needed. To take advantage of all postgis_sfcgal extension features SFCGAL 2.3+ is needed. Python 3 is a new requirement to build the documentation images. Visual examples in the docs are off by default. To build docs with them, configure with --with-visual-examples and make sure you have a running PostgreSQL instance; they are then generated automatically when building the docs (or explicitly with make -C regress visual-examples).
This release contains fixes since 3.7.0rc3 release.
Cheat Sheets:
This release is a major release, it includes bug fixes since PostGIS 3.6.4 and new features.
by Jody Garnett (noreply@blogger.com) at October 29, 2026 11:54 PM
by Jody Garnett (noreply@blogger.com) at October 29, 2026 11:53 PM
Doug Greenfield posted his Map of the Week – Map of the 100 Famous Views of Edo saying “The Wikipedia listing has a table listing each print with an image, title and geographic coordinates. Somebody with more time and better programming skills could make a nice interactive map from this table with popups at each location.”
Well I have the time and an AI with some programming skills so I thought “Why not?”
So I asked Claude:
Claude asked me a couple of questions, suggested a way to style the map and pop-ups and suggested that it add a season selector following the classification of the Hiroshige woodblocks and also including the Japanese text from the wiki page to add an authentic feel. I gave it the go ahead and left it whirring while I jumped on a call.
An hour later I had this map which needed a slight tweak to the pop-ups and I decided to add an inset map to give users a sense of where Edo (Tokyo) is in Japan, this isn’t visible in the mobile version.
Claude gave me a summary of what it had done:
There is a lot of functionality and design in this that I did not explicitly request but that is 100% in the spirit of what I wanted. My input time for this simple map was about 15-20 minutes, it helped that the data on the wiki page is so easy to work with. I think the results are pretty good and a few years ago would have been considered great which is an indication of how fast the tech is advancing. The styling is really neat, particularly when you see how little prompt I gave Claude.
<p>The post One Hundred Famous Views of Edo first appeared on KnowWhere.</p>
In geospatial research and software engineering, we frequently encounter a persistent paradox: sophisticated platforms, cutting-edge hazard models, and rich spatial data infrastructures are built with tremendous technical skill and effort – but lack uptake. Why? Because the development process often occurs in isolation from the operational realities, decision-making pressures, and daily workflows of end-users.
When addressing complex crises like climate change adaptation (CCA) and disaster risk management (DRM), a purely top-down or tech-driven development approach routinely fails. Emergency responders do not need generic GIS viewers with a multitude of layers and tools; civil protection officers require clear, actionable, and rapid information products that answer specific questions during an evolving crisis.
This leads to this week’s challenge:
How can we design and develop geospatial information systems that genuinely address user needs, bridge organizational silos, and adapt as real-world requirements evolve?
1. Requirements & Personas: Bilateral interviews, world-café workshops, pain-point mapping
2. Visual & Architectural Mock-ups: Low/high-fidelity UI mock-ups, API design
3. Prototyping & Sprint Reviews: Agile development, continuous cloud deployment
4. Operational Validation: Tabletop exercises (TTX), multi-agency drills
5. Asynchronous Refinement: Annotated slide decks, GitHub tracking, direct iterations
52°North tackled this exact challenge in the Horizon Europe DIRECTED project, working with an interdisciplinary consortium including stakeholders from Real World Labs. By establishing a structured Co-Design Framework around the DIRECTED Data Fabric, we turned end-users from passive recipients into active co-creators of the software platform.
Co-design is far more than asking stakeholders what features they want at the beginning of a project, re-visiting design choices with them once in a while and presenting a finished tool later. It is a continuous, agile conversation that aligns technical possibilities with operational needs.
To turn co-design principles into a tangible engineering process, we structured our work around four key pillars:
1. Dedicated Task Forces and Product Ownership
For each of DIRECTED’s four Real World Labs (RWLs), we established a compact, cross-disciplinary Task Force. Crucially, a representative from the local RWL host acted as the Product Owner. The Product Owner prioritized the development based on the real thematic needs of local practitioners, while developers, modelers, and experts in governance and knowledge co-production supported the technical execution.
2. Iterative Interface Evolution (Mock-ups to Production)
Before committing to backend pipeline engineering, we created interactive Graphical User Interface (GUI) mock-ups based on initial user stories. Presenting these mock-ups during early stakeholder workshops allowed us to refine UI elements, data layer groupings, and decision-support widgets early. This saved plenty of redundant development time.
3. Agile, Sprint-Based Increments
Borrowing from Scrum, development moved in short, bi-weekly sprints. Every iteration delivered a testable software increment. Stakeholders were not evaluating static specification documents; they were interacting with specific and live solutions, enabling continuous feedback and quick pivots when assumptions met reality.
4. Continuous Feedback Loops and Operational Drills
For the DIRECTED project, we tested prototypes directly within real-world emergency management workflows. From Tabletop Exercises (TTX) in flood management to full-scale multi-agency field drills with firefighters and rescue teams, software components were evaluated under operational pressure.
Co-Design Phase
Core Activities
Key Outputs
1. Requirements and Personas
Bilateral interviews, world-café workshops, pain-point mapping
User stories, priority matrices, target personas
2. Visual and Architectural Mock-ups
Low/high-fidelity UI mock-ups, API design
Wireframes, layer panel layouts, dashboard specs
3. Prototyping and Sprint Reviews
Agile development, continuous cloud deployment
Live web client builds, integrated OGC APIs
4. Operational Validation
Tabletop exercises (TTX), multi-agency drills
Stakeholder feedback, acceptance checklists
5. Asynchronous Refinement
Annotated slide decks, GitHub tracking, direct iterations
Final production releases
Our co-design methodology was put to the test across four diverse European regions, each presenting unique hazard profiles, institutional contexts, and user requirements:
1. What was the biggest surprise during the co-design process in DIRECTED? How quickly stakeholders’ focus shifts from complex backend model mechanics to visual clarity and user experience. Modeler teams often want to highlight technical precision, but operational users care most about transparency: Where does this data come from, how old is this simulation, and how uncertain is this prediction?
2. Is co-design more time-consuming than traditional software engineering? Initially, yes. It requires significant effort upfront to build trust, organize workshops, and run feedback loops. However, it saves immense time in the long run by preventing us from building features that nobody uses or understands. It’s a demanding, yet insightful process for everyone involved.
3. How do you manage conflicting feature requests from different user groups? That is where the Task Force Product Owner is essential. By establishing clear acceptance criteria and prioritizing items based on actual operational gaps, we ensure the platform remains focused rather than bloated.
4. How does Open Science play a role in this co-design approach? Open Science and FAIR data principles are the foundation. By relying on open standards (like OGC APIs) and open-source frameworks and solutions, any component co-designed in one region can be reused or extended by another without vendor lock-in.
5. What is the main takeaway for future research and software projects? Don’t build for users in a silo; build with them. Prototype early, test under real conditions, and accept that user feedback will—and should—change your original development plan.
Co-design is not just a theoretical framework; it produces modular, highly reusable open-source software. As part of our commitment to Open Science, the tools and building blocks created during the DIRECTED project are openly available for your own applications:
Are you planning a geospatial platform or looking to incorporate co-design methodologies into your research infrastructure? Reach out to our team to explore collaboration opportunities!
Sorry, this entry is only available in French.
Oslandia took part (actively!) in the QGIS User Conference 2026, which was held in early October in Laax, Switzerland.
The teams led four workshops and talks on the first day:
The second day provided an opportunity to attend talks and forge links with the international community!
On 21 October 2026 the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now known as PHP2Shell. They allow unauthenticated remote code execution on web servers running PHP. Exploitation attempts were observed even before public disclosure. The UK NCSC has issued an alert asking organisations to find and patch every PHP installation, and to take offline what they cannot fix.
Since then we have been receiving questions from organisations running our open source products. Here is the short answer, and what we suggest you check.
No since none of them uses PHP.
The official distributions and Docker images do not include or depend on PHP. PHP2Shell is not relevant to MapStore, GeoServer or GeoNode as released.
The products are not affected, but your deployment might still be exposed. Every installation is different, and we usually have no visibility on how yours was set up. So take a look at the whole stack around your maps.
GeoSolutions leads the development of MapStore and takes part in the security work of the GeoNode and GeoServer projects. When an issue is reported, we help analyse it, prepare and test the fixes, and coordinate the releases with the rest of the community. We are certified ISO 27001. We are doing our best to strengthen security in everything that we do.
Running open source in production does not mean running it alone. With our Enterprise Support Services, Enterprise Subscription Services and Professional Training Services we help organisations:
Want to talk about your MapStore, GeoServer or GeoNode installation? Write to sales@geosolutionsgroup.com.
This post is general guidance on the products as published. It is not an assessment of any specific installation.
TLDR; Direct stemmen via https://geomares.typeform.com/to/YUyu9jo8 .
De vakvereniging Geo-Informatie Nederland (GIN) reikt jaarlijks vakprijzen uit, de Geo Prestige Awards. Er zijn drie categorieën: Professional, Startup en Organisatie. OSGeo.NL is genomineerd in Organisatie.
Genomineerd…, maar nu willen we natuurlijk ook winnen! Daarom vragen wij iedereen die OSGeo.nl, FOSS4G.nl, de PostGISdag en alle open source geo software een warm hart toe draagt om op ons te stemmen!
Here is a closer look at the highlights of the new series 2026.02 of MapStore, our flagship Open Source WebGIS product. On GitHub it is possible to consult the full list of new features, enhancements and fixes we have provided in version 2026.02.00. You can try it right away on the MapStore demo.
We would like to thank all contributors who made this release possible, in particular Municipality of Genoa, TotalEnergies, Open Groupe, University of Naples, KfW and Deutsche Bahn for their valuable contributions (the full list is available at the v2026.02.00 release page in Github). The 2026.02.00 version introduces a wide range of enhancements focused on data source integration, catalog usability, projection management, and widgets flexibility. It represents another important step forward in evolving MapStore into a comprehensive platform not only for geospatial visualization, but also for the seamless integration of heterogeneous data sources and modern web-based analytical workflows.
ArcGIS Feature Service[/caption]
Alongside ArcGIS, the release also brings support for the FlatGeobuf format as a read-only remote layer type, with consistent behavior across the catalog, layer tree, map identify, and styling, including dynamic updates to feature styles. FlatGeobuf datasets can now be visualized both in 2D and 3D environments, thanks to the integration in both OpenLayers and CesiumJS map components. Complementing the initial integration, a set of dedicated FlatGeobuf enhancements introduces a configurable maxFeaturesInView option, which limits the number of features rendered in the current view to avoid performance issues when a map extent covers an entire large dataset. The setting is available both in the TOC layer settings and in the catalog's advanced settings, and applies uniformly to OpenLayers and CesiumJS. The "Zoom to" action has also been enabled directly in the TOC for FlatGeobuf layers, aligning it with the existing user experience of the other layer types. Both the initial integration and these refinements were made possible thanks to TotalEnergies.
[caption id="attachment_13855" align="aligncenter" width="515"]
Support for the FlatGeobuf format[/caption]
Furthermore, Panoramax is now available as a new provider for the Street View plugin, enabling users to explore street-level imagery served by the Panoramax API. The integration includes dedicated configuration options, localization support and proper attribution handling, further diversifying the sources of contextual imagery available in MapStore. This addition was contributed by Open Groupe.
[caption id="attachment_13856" align="aligncenter" width="803"]
Panoramax as the new provider of the Street View plugin[/caption]
New Layer Catalog[/caption]
The refactor is complemented by a set of targeted refinements, including:
Dynamic Projection Definitions[/caption]
Administrators and users with appropriate edit permissions can now search, add, and remove projections on demand directly from the CRS selector, without redeploying the application or manually editing configuration files. Existing statically configured projections continue to work exactly as before, ensuring full backward compatibility with current deployments. This is a particularly valuable improvement for organizations dealing with a large or evolving set of coordinate systems, where flexibility and rapid iteration are essential. This feature was made possible thanks to TotalEnergies.
Timeline plugin[/caption]
WMS Layer Extent Cropping Control[/caption]
disabled property that allows administrators to prevent selection, deletion, and modification of GeoLimits on specific permission rules when required. This feature was contributed by KfW.If you are interested in learning more about how we can help you develop a WebGIS using MapStore or help you achieve your needs with MapStore, GeoServer, GeoNode and GeoNetwork through our Enterprise Support Services, Professional Training Services and Subscription Services please contact us!
The GeoSolutions team,
As you all know by now, the php2shell vulnerability was disclosed and is wreaking havoc all across the technology landscape wherever a PHP installation is involved as everybody is frantically patching their PHP installs to mitigate this vulnerability.
Since MapGuide bundles PHP, this vulnerability sadly also affects us as well and I feel obligated to at least post something about this.
So here's the current situation of this vulnerability in the context of MapGuide.
ACE.dllGEOS.dlllib_json.dllMgFoundation.dllMgGeometry.dllMgHttpHandler.dllMgMapGuideCommon.dllMgMdfModel.dllMgMdfParser.dllMgPlatformBase.dllMgRenderers.dllMgStylization.dllMgWebApp.dllMgWebSupport.dllphp.inixerces-c_3_1mg.dllext/ACE.dllext/GEOS.dllext/lib_json.dllext/MgFoundation.dllext/MgGeometry.dllext/MgHttpHandler.dllext/MgMapGuideCommon.dllext/MgMdfModel.dllext/MgMdfParser.dllext/MgPlatformBase.dllext/MgRenderers.dllext/MgStylization.dllext/MgWebApp.dllext/MgWebSupport.dllext/php_MapGuideApi.dllext/xerces-c_3_1mg.dll
by Jackie Ng (noreply@blogger.com) at October 22, 2026 08:55 AM
52°North and Open Science? Nothing new here, but we’re not interested in a casual relationship. We want to make it official. Therefore, this week’s blog post isn’t about how we address a particular challenge, it’s about making a formal commitment to Open Science practices! To show our dedication, we are signing the NFDI4Earth FAIRness and Openness Commitment.
The NFDI4Earth FAIRness and Openness Commitment aims to promote the implementation of open practices and is composed of twelve items. Signing this commitment publicly signals agreement with the goals, mission, and products of NFDI4Earth.
In the following paragraphs, we will elaborate on 52°North’s commitment to the twelve items.
(1) Commit to the mission of NFDI in bringing together research communities to provide data for the common good, and the role of NFDI4Earth as a facilitator of sustainable, collaboratively developed solutions in Earth System Sciences.
We’re proud that the cooperation between NFDI4Earth and 52°North spans several years. An important milestone was the release of the OneStop4All, a search user interface increasing the findability and accessibility of earth system science resources such as data, software, and educational resources. Hence, we commit to the mission of both NFDI and NFDI4Earth, while also extending our cross-disciplinary integration across various domains through our spatial information systems.
(2) Support and uphold, where appropriate and possible, the principles and values outlined in existing Open Science declarations and statements.
As outlined in a recent post, Open Science services are part of 52°North’s portfolio . We actively monitor relevant Open Science declarations and statements such as GEO’s statement on open knowledge and adhere to the principles and values whenever possible.
(3) Be familiar with relevant data laws and acts, especially those related to geospatial data, in both national and European jurisdictions. These laws facilitate data sharing at both national and international levels.
We regularly inform our staff of relevant data laws and regulations. Given recent developments in AI, we see this as an essential aspect of our work. Moreover, we stay well-informed about regulations for data sharing, such as High-value datasets, and policies created by Infrastructure for Spatial Information in the European Community (INSPIRE).
(4) Give credit to all sources underlying our research findings and, whenever possible, credit is given through proper citations.
Seeing this as good scientific practice, we always cite the foundational work (including research data, software, publications, educational resources, etc.) that build the basis for our deliverables.
(5) Choose to publish Earth System Sciences data in Earth System Sciences domain repositories and other suitable research infrastructures that meet all four aspects of FAIR principles and consider the specific characteristics of Earth System Sciences data.
The discovery of such domain repositories is greatly facilitated by the OneStop4All’s repository guide. We will use and promote this feature in our projects and publish in relevant repositories.
(6) Strengthen FAIR and Open Data practices by supporting educational networks, robust training programs, and the production of educational materials that promote transparency and accessibility of research outputs.
As mentioned in a recent post, Open Science capacity building is a service we already deliver and plan to extend in the future. We have also been offering seminars and workshops promoting the use of open standards and software at universities and research organizations for several years.
(7) Adopt Data Management Plans as important tools for all research projects. These plans are invaluable for strategically planning data documentation, publication, and collaboratively monitoring data management activities. We seek and consider expert curation and guidance for them.
We will regularly include Data Management Plans in funding proposals to demonstrate solid scientific practice and a well-thought-out strategy for sustainable data management.
(8) Where possible, use open and permissive data and software licences that legally enable the envisioned free and open sharing of Earth System Sciences data.
Most of our work centers around software development and we’re keen to release it, whenever possible, under open licensing models (such as the Apache License 2.0) as stated on our homepage.
(9) Support and align scientific work with governing bodies and organizations that advance the underlying causes of this commitment.
Rather than working in isolation, we strive to align and integrate our work with broader initiatives such as the European Open Science Cloud, NFDI and GEO.
(10) Recognize the vital role that Earth System Sciences domain repositories and their curation services play in achieving and preserving the highest possible FAIRness and Openness in the Earth System Sciences. As researchers, institutions, and funding agencies, we endeavour to ensure the sustainability of these repositories and other relevant research infrastructures.
We contribute to ensuring the sustainability of the domain repositories by promoting their use through, for instance, the OneStop4All in our projects.
(11) Collaborate with data curators and repository managers and leverage their expertise to make Earth System Sciences research outputs transparent, machine-readable, interoperable, and re-usable in the long term. They use diverse approaches, such as the NFDI4Earth Label, to document and advance interoperability across data repositories.
Working closely with data curators and repository managers is important, particularly when it comes to providing high-quality metadata, which is key to fulfilling the FAIR principles. Beyond supporting this effort, we actively engage with OGC bodies to improve open access and machine readability of both data and metadata.
(12) Adhere to and contribute to international standards for harmoniing Earth System Sciences data, metadata, data quality, and application programming interfaces (APIs). Support their implementation and development across research infrastructures, as this is crucial for effective interdisciplinary research and advancements in novel analysis methods such as Artificial Intelligence or Machine Learning (AI & ML).
Interoperability has been one of 52°North’s core topics since day one, twenty years ago. With the advent of (agent-based) AI, ensuring transparency and machine-readability is more important than ever, and we regularly contribute to OGC initiatives.
So, this looks like a handshake between 52°North and the NFDI4Earth FAIRness and Openness Commitment! Fortunately, this commitment doesn’t require us to make any drastic changes to our internal workflows. It does, however, raise the awareness of the importance of adhering to FAIR and open principles. Do you also see the importance of this commitment? Are you ready to sign it, too?
The PostGIS Team is pleased to release PostGIS 3.7.0rc3! Best Served with PostgreSQL 19 RC 1 , GEOS 3.15.0 , postgis_tiger_geocoder 2025.2 , and address_standardizer.
This version requires GEOS 3.10+, PostgreSQL 14-19beta3, Proj 6.1+, and libgmp. To take advantage of all postgis extension features, GEOS 3.15+ is needed. To take advantage of all postgis_sfcgal extension features SFCGAL 2.3+ is needed. Python 3 is a new requirement to build the documentation. Visual examples in the docs are off by default. To build docs with them, configure with --with-visual-examples and make sure you have a running PostgreSQL instance; they are then generated automatically when building the docs (or explicitly with make -C regress visual-examples).
This release contains fixes since 3.7.0rc3 release.
Cheat Sheets:
This release is a release candidate of a major release, it includes bug fixes since PostGIS 3.6.4 and new features.
In water resources administration, the difference between reactive management and sustainable governance lies in data quality, process efficiency, territorial vision, and technological autonomy. With the launch of our new dedicated website at sirh.icarto.es, we want to highlight the main reasons why river basin authorities choose the Water Resources Information System (SIRH) by iCarto.
Many public institutions suffer from scattered data stored in physical files, paper registries, and disconnected spreadsheets across departments. SIRH stems from the integration of administrative management and Geographic Information Systems (GIS). It centralizes water administration into a single geospatial database, enabling authorities to locate, analyze, and query abstraction points, discharges, distribution networks, agricultural plots, and administrative boundaries on interactive maps within a unified operational environment.
Governing a strategic resource like water should not entail vendor lock-in or prohibitive recurring software licensing fees. With SIRH, 100% of code and data ownership remains strictly with the institution. This means zero recurring license costs and total freedom to scale the number of users, servers, or regional offices without financial penalties, all built on open standards and leading open-source GIS technologies.
SIRH connects spatial insights with every administrative stage necessary to ensure the operational and financial sustainability of river basins. It enables automated workflows and transparent tracking for application status, renewals, and official permit issuance, combined with automated consumption estimates based on institutional and spatial parameters. Furthermore, it professionalizes revenue collection through batch invoicing and payment tracking by geographic zones or basins.
Most technology projects in the public sector fail not because of code, but due to a lack of day-to-day user adoption. At iCarto, we do not deliver off-the-shelf or rigid software: we configure the platform alongside technical teams through collaborative co-design and dedicate 40% to 50% of total project effort to hands-on workshops and capacity building. Our three-phase roadmap (Registry & Mapping, Procedures, and Billing) ensures a gradual rollout tailored to local institutional and territorial realities.
Once the core registry and billing foundation is consolidated, SIRH expands through advanced modules. SIRH Mobile, a field inspection tool leveraging GPS positioning for paperless data collection synchronized with the central database, and the Digital Customer Portal, a web environment where water users can transparently check permit statuses, submit online applications, and review billing statements.
SIRH brings 10 years of experience enhancing spatial management for water concessions and users. Its effectiveness is proven through consolidated national and regional deployments across 2 countries (Mozambique since 2018 and Eswatini since 2024), supporting 5 water authorities. Today, SIRH manages over 5,000 georeferenced licenses, 4,000+ registered water users, and 100+ active institutional users.
We invite you to explore SIRH’s modular architecture, view GIS map interface previews, and learn more about our ongoing projects at https://sirh.icarto.es.
La entrada Why Choose SIRH for Integrated Water Resources Management? se publicó primero en iCarto.
Prezados leitores,
Sempre que preciso instalar uma nova instância do GeoNode, sigo os procedimentos que já compartilhei aqui no blog:
– Instalação do GeoNode 5 no Ubuntu 24.04
– Instalação do Certificado SSL no GeoNode
– Atualizar camadas do GeoServer para o GeoNode automaticamente
O passo a passo ajuda bastante, mas, a cada instalação, lá estava eu novamente: preparando o servidor, instalando dependências, criando o projeto, ajustando configurações e habilitando o HTTPS.
Ao preparar um ambiente para mais um curso, pensei: por que não automatizar esse processo?
A ideia foi transformar essa sequência em um instalador reutilizável. Agora, basta preencher um arquivo de configuração e executar um comando para iniciar a instalação.
Testei o procedimento em uma máquina nova, utilizando o GeoNode 5.1.0, e o resultado foi a aplicação funcionando com HTTPS habilitado.
Vamos ver como utilizar!
1. O que o instalador faz?
O instalador utiliza o projeto Docker oficial do GeoNode e automatiza as principais etapas de preparação do ambiente:
O pacote contém um script de entrada em Bash, o instalador em Python, um arquivo de parâmetros e as instruções de uso.
2. Antes de começar
O instalador foi preparado para uma máquina nova com Ubuntu 24.04 e arquitetura x86_64. O perfil padrão considera uma VM com aproximadamente 16 GB de RAM, com ajustes iniciais para os serviços.
Por padrão, a instalação verifica um mínimo de 14 GiB de RAM e 30 GiB livres no disco de destino. Esses limites podem ser alterados no arquivo de parâmetros, permitindo utilizar máquinas menores para testes e atividades acadêmicas. Veja os exemplos no tópico 11.
Para instalar com HTTPS, você também precisará de:
O instalador prepara o software dentro da máquina. A criação do servidor, os registros de DNS e a liberação das portas devem ser feitos previamente.
Utilize uma máquina nova, sem outra aplicação ocupando as mesmas portas.
3. Baixe e descompacte o pacote
Baixe o arquivo geonode-installer-0.1.12.zip, disponibilizado junto a este post, ou acesse o repositório no GitHub, e transfira-o para o servidor. Em seguida:
unzip geonode-installer-0.1.11.zip cd geonode-installer-0.1.11
4. Configure a instalação
Abra o arquivo de parâmetros:
nano geonode-install.env
Ele contém as seguintes opções:
GEONODE_PROJECT_REF=5.1.0 GEONODE_VERSION=5.1.0 DJANGO_BOOTSTRAP_VERSION=5.2 SYSTEM_USER=geonode PROJECT_NAME=curso_geonode INSTALL_DIR=/opt/geonode/curso_geonode HOSTNAME=geonode.seudominio.com.br ENABLE_HTTPS=true LETSENCRYPT_EMAIL=contato@seudominio.com.br SERVER_IPV4= UPDATE_LAYERS_ENABLED=true UPDATE_LAYERS_INTERVAL_HOURS=1 MIN_RAM_GB=14 MIN_DISK_GB=30 GEOSERVER_XMS=2G GEOSERVER_XMX=4G UWSGI_PROCESSES=4 CELERY_WORKERS=2 WAIT_SECONDS=1800
Para uma instalação semelhante à deste exemplo, os principais campos a alterar são:
| Parâmetro | O que informar |
|---|---|
HOSTNAME |
Domínio, subdomínio, IP ou localhost, sem protocolo e sem barra no final. Para HTTPS, utilize um domínio. |
LETSENCRYPT_EMAIL |
Seu endereço de e-mail. |
SERVER_IPV4 |
Opcional: IP público da VM para conferir sua presença na resolução DNS. |
PROJECT_NAME |
Nome do projeto, usando letras minúsculas, números e underscore ( _).
|
INSTALL_DIR |
Diretório da instalação dentro de /opt.
|
SYSTEM_USER |
Usuário que será criado para os arquivos do projeto. |
UPDATE_LAYERS_ENABLED |
true para habilitar a atualização automática de camadas; false para desativar.
|
UPDATE_LAYERS_INTERVAL_HOURS |
Intervalo de verificação: 1, 2, 3, 4, 6, 8, 12 ou 24 horas. |
MIN_RAM_GB |
RAM mínima aceita, em GiB. O valor 0 desativa a checagem. |
MIN_DISK_GB |
Espaço livre mínimo no destino, em GiB. O valor 0 desativa a checagem. |
Atenção à versão do Django: DJANGO_BOOTSTRAP_VERSION controla apenas o Django utilizado para gerar a estrutura inicial do projeto. A versão que executa dentro dos containers é determinada pelas dependências da aplicação.
Os parâmetros de versão permitem selecionar outras referências, mas isso não garante compatibilidade automática entre todas as combinações. A instalação apresentada neste post foi testada com o GeoNode 5.1.0.
5. Confira a configuração
Antes de instalar, execute:
python3 instalar.py --env geonode-install.env --check
Esse comando valida os parâmetros e consulta a resolução DNS do endereço informado, sem instalar pacotes.
Se você preencher SERVER_IPV4, ele também confere se esse IP aparece na resolução do domínio.
Essa checagem não testa a liberação das portas nem o acesso externo ao servidor.
6. Inicie a instalação
Com os parâmetros preenchidos, execute:
sudo bash instalar-geonode.sh --env geonode-install.env
Pronto! A partir desse ponto, o instalador executa as etapas automaticamente.
A primeira construção das imagens pode demorar, dependendo do processamento da máquina e da velocidade dos downloads. Mantenha a sessão SSH aberta enquanto acompanha a execução.
Embora o comando seja iniciado com sudo, o download do projeto e sua geração são executados com o usuário definido em SYSTEM_USER. As operações administrativas, como instalar pacotes e executar o Docker, continuam sob responsabilidade do root.
O usuário criado não recebe senha habilitada, acesso ao sudo ou inclusão automática no grupo Docker.
Ao final, o instalador aguarda a resposta HTTP ou HTTPS e verifica o estado dos principais serviços. Enquanto isso, informa quais componentes ainda estão pendentes. Um container aparecer como “Started” não significa que sua inicialização já terminou.
Com HTTPS desativado, o Let’s Encrypt não é exigido nessa verificação. Após a validação, o instalador configura a tarefa de atualização automática de camadas, caso ela esteja habilitada.
7. E o certificado SSL?
Com esta configuração:
ENABLE_HTTPS=true
o instalador gera as URLs HTTPS e habilita o mecanismo de emissão de certificados Let’s Encrypt incluído no projeto Docker.
Assim, não é necessário executar separadamente a instalação do Certbot no host nem copiar manualmente os certificados para o Nginx.
O domínio precisa estar apontando corretamente para o servidor, e a porta 80 deve permanecer acessível para a validação e renovação do certificado. Se houver um registro DNS IPv6, ele também precisa estar correto.
8. Posso instalar em localhost ou acessar por IP?
Sim! Para usar HTTP localmente, configure:
HOSTNAME=localhost ENABLE_HTTPS=false LETSENCRYPT_EMAIL= SERVER_IPV4=
Nesse caso, a solicitação de certificado fica desativada e o endereço será:
http://localhost/
Também é possível instalar em uma VM e acessar pelo IP da rede interna. Por exemplo:
HOSTNAME=192.168.186.142 ENABLE_HTTPS=false LETSENCRYPT_EMAIL= SERVER_IPV4=
Nesse caso, o endereço será, por exemplo:
http://192.168.186.142/
Use um IP fixo ou uma reserva DHCP e permita o acesso à porta TCP 80 na rede.
O instalador ajusta automaticamente os cookies de sessão e CSRF: em HTTP, eles não exigem HTTPS; em HTTPS, essa exigência permanece habilitada. A proteção CSRF continua ativa nos dois modos.
Lembre-se de que localhost representa a própria máquina. Para acessar uma VM de outro computador, utilize o IP ou domínio dessa VM. Os limites de memória e disco podem ser ajustados conforme o tópico 11.
9. Como acessar pela primeira vez?
Após a conclusão, abra no navegador o domínio, IP ou endereço local configurado.
O usuário inicial é:
admin
A senha é gerada automaticamente e fica no .env da aplicação. Para consultá-la, considerando o diretório deste exemplo:
sudo awk -F= '/^ADMIN_PASSWORD=/{print $2}' \
/opt/geonode/curso_geonode/.env
Existem, portanto, dois arquivos com funções diferentes: geonode-install.env contém os parâmetros do instalador; o .env criado no diretório da aplicação contém as configurações e senhas dos serviços. Não compartilhe esse segundo arquivo.
10. Como acompanhar os serviços?
Para consultar os containers, informe explicitamente os caminhos da instalação:
sudo docker compose \ --project-directory /opt/geonode/curso_geonode \ --env-file /opt/geonode/curso_geonode/.env \ -f /opt/geonode/curso_geonode/docker-compose.yml \ ps -a
Para acompanhar o consumo de recursos:
sudo docker stats
Para consultar os logs:
sudo docker compose \ --project-directory /opt/geonode/curso_geonode \ --env-file /opt/geonode/curso_geonode/.env \ -f /opt/geonode/curso_geonode/docker-compose.yml \ logs --tail=100 django geoserver celery geonode letsencrypt
Esses comandos funcionam mesmo quando seu usuário não tem permissão para entrar na pasta do projeto. Ajuste os caminhos se tiver utilizado outro INSTALL_DIR.
Se ocorrer uma interrupção, o instalador permite tentar novamente com o mesmo arquivo de parâmetros, preservando o projeto já gerado. Ele não executa atualização automática de versão nem apaga volumes para recomeçar.
11. Como ajustar memória e disco para testes?
Os limites mínimos ficam no arquivo geonode-install.env:
MIN_RAM_GB=14 MIN_DISK_GB=30
Eles representam critérios de validação do instalador, não o consumo fixo do GeoNode. Para uma VM de testes com menos recursos, você pode reduzir esses valores e ajustar os serviços. Por exemplo:
MIN_RAM_GB=7 MIN_DISK_GB=20 GEOSERVER_XMS=512M GEOSERVER_XMX=1G UWSGI_PROCESSES=2 CELERY_WORKERS=1
Esse exemplo é um ponto de partida para testes, não uma garantia de capacidade para qualquer conjunto de dados. Também é possível desativar as checagens:
MIN_RAM_GB=0 MIN_DISK_GB=0
OBS: Desativar a validação não reduz o consumo dos serviços nem evita falta de memória ou disco. Configure os recursos conforme o uso previsto.
O comando –check valida o formato desses parâmetros. A comparação com a memória e o espaço disponíveis ocorre durante a instalação.
12. Como atualizar as camadas automaticamente?
Quando utilizar esta automação?
Esse recurso é útil principalmente quando você publica camadas diretamente no GeoServer, por exemplo, conectando um banco PostGIS externo, e deseja incorporá-las ou atualizar suas informações no catálogo do GeoNode.
As camadas enviadas e gerenciadas pelo próprio GeoNode já seguem seu fluxo integrado de publicação no GeoServer e não dependem dessa tarefa adicional.
A automação também não é responsável por atualizar os registros do banco: quando uma camada consulta uma tabela PostGIS, os dados são lidos pelo GeoServer diretamente dessa fonte. O updatelayers atua na integração das camadas com o catálogo do GeoNode.
O instalador incorpora essa automação baseada no procedimento apresentado no post: Atualizar camadas do GeoServer para o GeoNode automaticamente.
Para habilitar, configure:
UPDATE_LAYERS_ENABLED=true UPDATE_LAYERS_INTERVAL_HOURS=6
Nesse exemplo, o workspace é verificado às 00h, 06h, 12h e 18h, conforme o horário do servidor. São aceitos intervalos de 1, 2, 3, 4, 6, 8, 12 ou 24 horas.
Na primeira execução, a tarefa executa updatelayers. Nas seguintes, compara um checksum dos arquivos do workspace geonode e executa o comando somente quando identifica alterações. O novo checksum é salvo apenas após uma atualização bem-sucedida, e um bloqueio evita execuções simultâneas.
Essa detecção acompanha arquivos do workspace; alterações apenas nos registros de uma tabela PostGIS não acionam a atualização.
Após a instalação, o agendamento pode ser alterado diretamente:
sudo nano /etc/cron.d/geonode-updatelayers-curso_geonode
Para consultar os registros:
sudo tail -n 100 \ /var/log/geonode-updatelayers-curso_geonode.log
Os nomes desses arquivos acompanham o PROJECT_NAME.
Se o GeoNode já estiver instalado por uma versão compatível deste instalador, você pode configurar somente essa tarefa, usando os parâmetros originais da instalação:
sudo python3 instalar.py --env geonode-install.env \ --configure-updatelayers
Esse comando não reconstrói as imagens nem reinicia a aplicação. Para remover o agendamento, configure UPDATE_LAYERS_ENABLED=false e execute novamente a mesma opção.
13. Como desinstalar e repetir a instalação?
Para facilitar os testes e atividades acadêmicas, o pacote também oferece comandos de desinstalação.
Execute a partir da pasta do instalador, fora do diretório da aplicação, utilizando o **arquivo de parâmetros original da instalação**.
Para visualizar o plano sem apagar nada:
sudo python3 instalar.py --env geonode-install.env \ --uninstall-geonode --preview
Para remover o GeoNode:
sudo python3 instalar.py --env geonode-install.env \ --uninstall-geonode
O script solicita o nome do projeto para confirmar e remove os containers, redes e volumes identificados do projeto, o diretório da aplicação e os componentes do updatelayers criados pelo instalador. A pasta pai, como /opt/geonode, também é removida se estiver vazia.
Banco de dados, camadas e arquivos enviados são apagados definitivamente, sem backup automático.
Nesse modo, o Docker, as imagens e os caches permanecem disponíveis. Por isso, uma nova instalação pode ser mais rápida.
Para solicitar também a remoção do Docker, preservando o bloqueio caso existam recursos de outros projetos:
sudo python3 instalar.py --env geonode-install.env \ --uninstall-geonode --remove-docker
Limpeza completa da VM. Em uma VM descartável e exclusiva para testes, existe uma opção mais abrangente:
sudo python3 instalar.py --env geonode-install.env \ --uninstall-geonode-completely
Será necessário digitar:
APAGAR TODO O DOCKER
Esse modo remove todos os containers, volumes, redes personalizadas, imagens e caches do Docker local, inclusive de outros projetos**, além da aplicação, dos componentes do seu updatelayers e dos pacotes Docker.
Para conferir o plano antes, acrescente –preview.
O modo completo atende à instalação Docker local padrão usada neste tutorial. Configurações como Docker remoto, armazenamento personalizado, Swarm ou namespaces de outros runtimes continuam bloqueadas.
O usuário do sistema, seu diretório pessoal e dependências gerais, como Python e Git, permanecem. Arquivos usados como bind mounts fora do diretório da aplicação também não são apagados. Portanto, essa limpeza não equivale a restaurar o sistema operacional.
Após concluir, para instalar novamente:
sudo bash instalar-geonode.sh --env geonode-install.env
14. Do servidor vazio ao GeoNode funcionando
Na instalação que motivou este post, utilizei uma máquina nova e o GeoNode 5.1.0. Ao final, o portal estava acessível pelo navegador com HTTPS funcionando.
Antes de utilizar o ambiente em um curso ou projeto, vale realizar os testes do seu fluxo: carregar camadas, abrir os dados, criar mapas e dashboards e conferir as permissões de acesso.
A automação reduz o trabalho repetitivo de preparar o ambiente. A validação com os dados e as atividades que serão utilizados continua sendo uma etapa importante.
Agora, na próxima instalação, o procedimento será bem mais curto: preencher o arquivo de configuração, executar o comando e acompanhar a criação do ambiente.
Até o próximo post!
GeoServer 3.0.2 release is now available with downloads (bin, war, windows), along with docs and extensions.
This is a stable release of GeoServer recommended for production use. GeoServer 3.0.2 includes the latest GeoTools 35.2, GeoWebCache 2.0.2, along with mapfish-print-v2 2.5.2 and ImageN 0.9.3. There is a new GeoServer Cloud 3.0.2 release - representing the first time an updated GeoServer Cloud is made available on release day.
Thanks to Jody Garnett (GeoCat) for making this release, Andrea Aime (GeoSolutions) for testing, and Alessio Fabiani (GeoSolutions) Gabriel Roldan (Camptocamp) for the GeoServer Cloud release.
This release addresses security vulnerabilities and is an important upgrade for production systems. Details about the fixes will be provided at the start of November.
See project security policy for more information on how security vulnerabilities are managed.
The OGC API Maps community module has been aligned with the final OGC API - Maps 1.0.0 standard.
Dataset map: Draw several collections into a single map, choosing and ordering them with the collections parameter.
The map preview provides a palette to select collections, the first one drawn at the bottom.
Filtering: Maps can be filtered using CQL2 Text, CQL2 JSON or ECQL, using the queryable attributes of each collection.
Conformance: Each optional conformance class (subsetting, scaling, background, crs, output formats, and more) can be enabled or disabled from the Services > Mapping settings page. Invalid parameters are now reported as a bad request rather than an internal error.
For more information see OGC API Maps in the user manual.
Thanks to Andrea Aime (GeoSolutions) for the OGC API - Maps development, and Jody Garnett (GeoCat) for the 3.0.x backport and improvements to the conformance table editor.
The GeoFence extensions are now available for GeoServer 3, completing Milestone 4: Integration of the GeoServer 3 crowdfunding campaign.
GeoFence has been updated to Jakarta EE, Spring Framework 7 and Hibernate 7:
geofence plugin now communicates with a standalone GeoFence server using REST,
as Spring remoting is no longer available.geofence-server requires a PostgreSQL / PostGIS database, H2 is no longer supported.
Existing GeoFence users should review the migration guide before upgrading, as the datasource configuration file has been renamed and the GeoFence authentication provider has been removed.
Thanks to Emanuele Tajariol (GeoSolutions) for this work, and to the GeoServer 3 crowdfunding sponsors for making it possible.
GeoServer 3 is supported by the following organisations:
Individual donations: Abhijit Gujar, Hennessy Becerra, Ivana Ivanova, John Bryant, Jason Horning, Jose Macchi, Peter Smythe, Sajjadul Islam, Sebastiano Meier, Stefan Overkamp.
GeoServer 3.0.2 comes with a new FIPS community module. FIPS 140-3 is a United States government standard for cryptography modules, and many federal agencies and their suppliers are only allowed to run software that uses a validated one. In summary:
Keep in mind that the module works on Linux only and needs a new data directory: there is no migration tool yet for an existing one.
Thanks to Andrea Aime (GeoSolutions) for the FIPS module development.
New Feature:
Improvement:
Bug:
Task:
For the complete list see 3.0.2 release notes.
Community module development:
Community modules are shared as source code to encourage collaboration. If a topic being explored is of interest to you, please contact the module developer to offer assistance.
Additional information on GeoServer 3.0 series:
GeoServer 2.28.6 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.6 includes GeoTools 34.6 and GeoWebCache 1.28.6. GeoServer Cloud 2.28.6 is also available alongside today’s release.
Thanks to Peter Smythe (AfriGIS) for making this release, Andrea Aime (GeoSolutions) for testing, and Gabriel Roldan (Camptocamp) for the GeoServer Cloud release.
This release addresses security vulnerabilities and is an important upgrade for production systems. Details about the fixes will be provided at the start of November.
See project security policy for more information on how security vulnerabilities are managed.
New Feature:
Improvement:
Bug:
Task:
For the complete list see 2.28.6 release notes.
Community module development:
Community modules are shared as source code to encourage collaboration. If a topic being explored is of interest to you, please contact the module developer to offer assistance.
Additional information on GeoServer 2.28 series:
Release notes: ( 2.28.6 | 2.28.5 | 2.28.4 | 2.28.3 | 2.28.2 | 2.28.1 | 2.28.0 )
GeoServer 2.27.7 release is now available with downloads (bin, war, windows), along with docs and extensions.
This series has previously reached end-of-life, with this release issued to address an urgent bug or security vulnerability. Please apply this update as a mitigation measure only, and plan to upgrade to a stable or maintenance release of GeoServer.
GeoServer 2.27.7 is made in conjunction with GeoTools 33.7.
Thanks to Peter Smythe (AfriGIS) for making this release, and Andrea Aime (GeoSolutions) for testing.
This release addresses security vulnerabilities and is an important upgrade for production systems. Details about the fixes will be provided at the start of November.
It is worth repeating that the 2.27 series has reached end-of-life. While we understand that this is the last series supporting Java 8 please update to the supported 2.28 or 3.0 releases.
See project security policy for more information on how security vulnerabilities are managed.
Improvement:
Bug:
Task:
For the complete list see 2.27.7 release notes.
Community module development:
Community modules are shared as source code to encourage collaboration. If a topic being explored is of interest to you, please contact the module developer to offer assistance.
Additional information on GeoServer 2.27 series:
Release notes: ( 2.27.7 | 2.27.6 | 2.27.5 | 2.27.4 | 2.27.3 | 2.27.2 | 2.27.1 | 2.27.0 )
A student finishes a QGIS exercise, saves the project and sends the file to the instructor. The analysis is complete—but the map is still difficult to share with a colleague, a client or the public.
That last step, taking a desktop GIS project onto the web, is increasingly part of practical GIS training. A review of publicly listed courses turns up examples around the world that include QGIS Cloud in their teaching: from publishing a first web map to working with cloud databases and web GIS.
After writing about being laid off in April, I went almost five months without paid work. As I wrote in that post, I started with some severance. After that, I learned how to participate in Colorado's unemployment insurance benefits system. Just before reaching that program's limits, I was offered a position at Colorado State University, and I accepted. Colorado recorded 2,400 people hired in September 2026, and I was one of them.
Surprisingly, I found the job posting on the Larimer County Economic and Workforce Development Program's current job openings list, using "python" as a keyword. Not on LinkedIn. Not in my professional network. The algorithms were feeding me nothing but jobs at defense contractors with cringey names stolen from Tolkien, and my personal network was not hiring. I stumbled onto a local job on a local job board and nailed the interviews. It was not how I imagined that I would find a new position.
I've benefited from good luck. I'm lucky to have found the posting in a local listing. I'm lucky that the hiring team was open minded about an older and perhaps over-qualified applicant. I'm lucky that I have a nice list of accomplishments that are recent enough to be relevant and old enough to have been plausibly earned through actual interest and perseverance. I'm lucky to have friends who will answer the phone and attest to me being a decent person.
It's a tough time to be unemployed in the USA, which has uneven and often meager benefits, and is banking on magical AI/LLM solutions to all our problems. Hit me up if you're having trouble navigating Colorado's unemployment insurance system and have nowhere else to go for help.
As I alluded to in my previous post, I've got a new job. I'm a research associate at Colorado State University, working at the Cooperative Institute for Research in the Atmosphere (CIRA). For the first time in over 20 years, I'm working for a local organization, the biggest local institution, in fact. Riding my bike to the office, learning to pack a lunch, all the things. I'm helping several research projects use satellite imagery to derive global cloud properties in near real-time.
Yesterday I attended an orientation session for new CSU employees. I've been married to a CSU professor for 21 years and already know everything there is to know about the school. Joining the employee union was a new experience. I wish there had been more of us.
A few people have asked how the scoring works, and one or two have asked, a bit pointedly, why their pin 40 km from Lagos only got half marks. Here’s the longer version of the info box: how to play, how the points add up, and where it all comes from.
Every day you get 5 cities. For each one you drop a pin on a map with no labels: no names, no roads, just coastlines, borders, rivers and lakes. Then you answer 3 multiple-choice questions about the city.
Each city is worth up to 100 points, so a perfect day is 500.
And a sting in the tail:
Two kinds of help, both at a price:
Score 325 or more and you unlock a bonus round of 2 hard cities. It’s scored separately, so it doesn’t change your daily score, but it’s worth it for the bragging rights.
If you want a warm-up there are 2 practice sets, which you can replay as often as you like:
The map uses Natural Earth’s borders, with one change: Crimea is shown as part of Ukraine. In disputed areas such as Kashmir I don’t label anything. The borders are there for the game and aren’t a statement about who does or should own what.
It’s a personal project, free and with no adverts. The questions come from Wikipedia under its CC BY-SA licence, and every city links back to its article, which is worth a read when a question catches you out.
Play today’s quiz at knowwhereconsulting.co.uk/quiz/cities/
<p>The post KnowWhere Cities Quiz – how it works first appeared on KnowWhere.</p>