Real problems transformed into systems that work.

Fire Return Letter

Fire re-ignition risk map for Continental Portugal, calculated pixel-by-pixel from 50 years of burnt perimeters.

Problem

The history of burnt areas exists since 1975, but in the form of thousands of annual polygons — it does not answer the operational question 'is this site at risk of burning again?'.

Approach

Rasterization of the entire history and calculation of a score 0–100 with three weighted components: time since last fire normalized by vegetation type (50%), frequency of occurrence since 1975 (25%), and delay relative to the typical fire cycle for that vegetation (25%).

Result

National raster at 10 m with six risk classes, reused as an input layer by other daily risk classification projects.

• Python
• geopandas
• rasterio
• numpy
• matplotlib
• python-pptx

PoF Portugal — Fire Probability

Machine learning model estimating ignition probability per pixel, inspired by AI Probability of Fire from ECMWF and adapted to national data.

Problem

Classic meteorological indices describe conditions favorable to fire but do not incorporate fuel, topography, human presence, or vegetation age — variables that decide whether an ignition leads to a fire.

Approach

Pipeline downloading ERA5-Land reanalysis, calculating Canadian FWI system indices, cross-referencing with fuel, slope, proximity to roads and settlements, and years since last fire; training with gradient boosting on historical ignition records.

Result

Daily raster of probability 0–1 for Continental Portugal, with intermediate storage in Parquet and persistence of results in a database.

• XGBoost
• scikit-learn
• xarray
• netCDF4
• cdsapi (ERA5-Land)
• rasterio
• pyarrow
• MySQL

Fire Simulator Portugal

Forest fire propagation modelling system based on Rothermel (1972) equations.

Project discontinued before production use.

Problem

Reference simulators require a rigorously aligned set of rasters (fuel, canopy, slope, aspect) and a coherent meteorological grid — manual preparation that takes longer than the simulation itself.

Approach

Automatic preparation layer: slope and exposure calculation by blocks for large rasters, realignment and canopy cover correction, construction of weather grids and custom clients for two forecast sources with fallback among them.

Result

Simulation scenarios generated from a date and area, with fuel models defined in a configuration file rather than hard-coded.

• Python
• rasterio
• numpy
• Rothermel
• IPMA API
• Open-Meteo

Fuel Models Pipeline (LiDAR)

Automatic generation of NFFL fuel models and canopy height cartography from national LiDAR, covering 1,013 polygons.

Problem

The available fuel cartography is coarse and outdated; the national LiDAR has the necessary resolution but is distributed across over a thousand independent blocks, impossible to process manually.

Approach

Polygon-based pipeline deriving LiDAR vegetation height and canopy cover, classifying each pixel into one of the 13 NFFL models, followed by mosaicking for continuous national coverage.

Result

Three 10 m rasters per polygon (fuel model, elevation, cover) plus the national mosaic—the input layer used by propagation simulators.

• Python
• LiDAR
• rasterio
• GDAL
• numpy
• NFFL

CAPVI — Update of Surveillance Priorities

Weekly workflow that converts priority surveillance cartography into maps, reports, and published layers, with automatic email delivery.

Problem

The weekly update involved dozens of manual GIS steps, repeated by different people across two phases of the week—slow and prone to discrepancies between operators.

Approach

Single menu that fixes the user and phase, then performs everything: merging final shapefiles, text report with the ten priority municipalities per day, choropleth maps in PNG, updating online layers, and preparing the email.

Result

Weekly cycle reduced to two guided executions, yielding identical results regardless of who runs the process.

• Python
• geopandas
• matplotlib
• ArcGIS Online
• pywin32
• Tkinter

Unified Risk System (Winter Planning)

Dual-domain risk model—hydrological and fire—for year-round patrol planning.

Problem

The patrol effort was planned only for the fire season, leaving the wet semester without an objective criterion, despite the risk existing in other forms — floods and hydrological episodes.

Approach

v5.0 model maintaining both risk domains in parallel, applying seasonal weights to each, and triggering automatic alerts when a threshold is exceeded.

Result

Single priority criterion valid for twelve months, fed by the own meteorological repository.

• Python
• geopandas
• numpy
• MySQL

MeteoDataHub

Central repository of hourly meteorological data for Continental Portugal, served to all other projects.

Problem

Each project called the weather APIs on its own: repeated requests, usage limits reached, and different values for the same time depending on the query moment.

Approach

Fixed grid of approximately 300 points at 12 km, automatic file archival and prediction to MySQL, with an internal API layer for consumption by other systems.

Result

Single source of truth for meteorological data, with its own independent history separate from the external API retention window.

• Python
• MySQL
• Open-Meteo
• pandas
• geopandas
• Task Scheduler

Fire Weather Data Collector

Meteorological data collection application for fire analysis, with full calculation of CFFDRS indices calibrated for Portugal.

Problem

Fire danger indices depend on accumulated values from previous days: a single-point reading gives a wrong number, and no isolated source is reliable enough for an operational service.

Approach

Integration of five meteorological sources with fallback automatically between them, plus 90 days of historical backfilling so the carry-over values (FFMC, DMC, DC) are correctly initialised, with seasonal adjustments for the Mediterranean climate.

Result

Over 25 parameters per location, from −12h to +24h, exported as CSV with metadata; graphical interface for non-programmers.

• Python
• CFFDRS / FWI
• asyncio · aiohttp
• ECMWF EarthKit
• Tkinter
• scipy

MTG FRP — Active satellite hotspots

Real-time collection of hotspots of Meteosat third-generation fire radiative power, clipped to Portugal.

Problem

The official product covers the entire visible disk of the satellite and is published compressed every ten minutes — downloading and saving everything to use a minimal fraction is unsustainable in disk space and time.

Approach

In-memory stream decompression and immediate spatial filtering by the bounding box of Continental Portugal plus 50 km, discarding the rest before touching the disk.

Result

GeoJSON and CSV updated every ten minutes, ready for consumption by GIS and common operational imaging platforms.

• Python
• GeoJSON
• requests
• geopandas
• SQLAlchemy
• MySQL

LSA SAF — Operational Applications Catalog

Systematic study of available satellite products and the concrete application of each to civil protection work.

Problem

The satellite product catalog is vast and described in scientific language; without translation to use cases, it remains unexplored.

Approach

Ten sheets, one per product — daily risk, active hotspots, burnt area, vegetation condition (VCI), thermal condition (TCI), vegetation health (VHI), dynamic return map, composite patrol risk, snow, and flooding — each documenting its source, cadence, limitations, and the decision it supports.

Result

Origin specification for the subsequent acquisition projects, including the active hotspot collector.

• Requirements Analysis
• LSA SAF
• Remote detection

Wind Mapper

Portable wind tool over a user-drawn area, with visualization by arrows over satellite and relief.

Problem

Analyzing wind in an operational area required querying point-by-point values, without understanding the spatial pattern that explains fire behavior on the ground.

Approach

Area definition by coordinates, shapefile, or interactive map; generation of a regular mesh with configurable resolution; query of historical speed and direction for each node.

Result

Vector field drawn over satellite imagery and digital elevation model, exportable for subsequent analysis.

• Python
• cartopy
• tkintermapview
• rasterio
• Open-Meteo

Meteorology

Initial draft of meteorological collection, abandoned in favor of a centralized solution.

Problem

First attempt to solve point-by-point meteorological acquisition within a consumer project.

Approach

Registered here for inventory honesty: the direction was discarded early, upon realizing that the problem required a shared service, not a local function.

Result

Deprecated in favor of MeteoDataHub, which now serves all projects.

• Python

ArcGIS Reports

Massive parallel generation of incident reports in PDF from online layers.

Problem

Producing hundreds of incident reports manually, one by one, in the office application—working days, and any network failure forced a restart.

Approach

Parallelized download and processing with the native ArcGIS library, using official print models as templates, with explicit handling of network failures and resumption of pending work.

Result

Hundreds of PDFs produced in a single run, with a layout identical to the institutionally approved version.

• Python
• arcpy
• ArcGIS Pro
• Parallel Processing
• Pillow
• tqdm

ICNF Burnt Areas

Synchronization of official burnt area and ignition point layers for local copy and for own online layers.

Problem

The official layer is the reference, but it is outside the consumer's control: outages and schema changes break everything that depends on it in real time.

Approach

Paginated REST query in GeoJSON, offline copy writing in GeoPackage, and incremental updates of own layers via insert-or-update operations, with centralized logging of source layers in a single module.

Result

Data always available locally and own layers synchronized, with automatic tests on the process.

• Python
• ArcGIS REST
• GeoPackage
• pyogrio
• pytest

Registration of Patrol Tracks

Automatic audit verifying whether patrols activated location during service.

Problem

Without active location there is no patrol trail, but confirming patrol by patrol, day by day, was unfeasible — and therefore not done.

Approach

Matching engine that links each patrol to its respective route via radio call sign and unit, featuring robust pagination for thousands of records and automatic detection of missing days in the history, reprocessing only those.

Result

Matching accuracy of approximately 95% and interactive HTML dashboards for daily, monthly, and annual periods.

• Python
• plotly
• ArcGIS Online
• pandas

Ortos DGT

Automatic download of national orthophotomaps organized by cartographic sector grid.

Problem

Each annual collection of orthophotos is published as a different service type — which required a distinct manual procedure per year and made uniform collection of time series impossible.

Approach

Hybrid architecture with an orchestrator that detects the service type for each collection and selects the appropriate acquisition engine, maintaining the same output interface for the current collection and historical years.

Result

Uniform acquisition by sector for any published year, without manual intervention.

• Python
• requests
• GDAL
• WMS/WMTS
• shapefile of sectors

RCM / PIR — Municipal Combustibility Risk

Daily publication of municipal risk for the 68 municipalities covered by integrated landscape management areas.

Problem

The source provided risk via an unstable temporal image service with no reliable control over temporal dimension—unusable for generating the day's product and the next day's.

Approach

Direct consumption of the data API instead of the image service, joined with administrative cartography and automatic publication, with two distinct files for the current day and the following day.

Result

Reliable daily product at 01h00, with history controlled by the publisher.

• Python
• IPMA API
• geopandas
• GeoPackage
• ArcGIS Online

Portugal Road Closures

Automatic collection and publication of cut and conditioned roads in Continental Portugal.

Problem

In flood or fire episodes, knowing which roads are cut is decisive for resource routing — and the information was scattered across text alerts.

Approach

Periodic query to the traffic incident API, bypassing the per-request area limit with an 18-cell grid covering the entire mainland, and consolidation of relevant incidents into a single layer.

Result

Geographic layer updated every two to four hours, ready to overlay operational cartography.

• Python
• TomTom Traffic API
• ArcGIS Online
• requests

Audit Signage

Continuous audit of an enforcement layer, with automatic recovery of erroneously deleted records.

Problem

Operational records disappeared from the shared layer without trace of who or why, compromising annual activity targets that depend on counting.

Approach

Periodic verification of the expected universe of records against what is published, with automatic replenishment of missing items from the reference copy.

Result

Guaranteed integrity of the year's record set, without manual oversight.

• Python
• ArcGIS REST
• data audit

RPA Export

Export of an operational layer to six geographic formats from the REST API.

Problem

Each recipient requested the same dataset in a different format — field GPS, office GIS, terrain viewer — and conversion was done manually, one by one.

Approach

Single exporter that authenticates on the portal, reads the layer via API, and writes GeoJSON, JSON, GeoPackage, shapefile, KMZ, and GPX, with credentials outside the code, in an environment file.

Result

A single command responds to all format requests, bypassing desktop software.

• Python
• simplekml
• gpxpy
• fiona
• python-dotenv

ArcGIS Tools

Collection of REST API-based layer management utilities, without an Office license or proprietary libraries.

Problem

Current data maintenance operations required opening the office application on a licensed machine — unviable on a server and in scheduled tasks.

Approach

One script per task (selective removal, export, calculated field updates), each autonomous and dependent only on free libraries.

Result

Data maintenance executable on any machine, including scheduled execution without an interactive session.

• Python
• ArcGIS REST
• geopandas
• openpyxl

pat_igini — Patrols × Ignitions

Export of operational data to GeoPackage, ready to open in free GIS.

Project discontinued before production use.

Problem

Crossing patrol activity with registered ignitions required extracting data from the database for each analysis, always with slightly different queries.

Approach

Three independent scripts that read the operational database, filter by period, and write point layers in a single coordinate system—patrols, ignitions, and their intersection.

Result

Reproducible analysis: same period, same result, without ad-hoc SQL.

• Python
• MySQL
• GeoPackage
• QGIS

Clusters

Office application that produces cartographic notebooks of populated clusters in PDF.

Problem

Characterizing a cluster for protection purposes required manually assembling several layouts—built-up area, urban-forest interface, locations—and then combining them into a single document.

Approach

Graphical interface built on a set of reusable layout generators, featuring a graphical scale, export of the main layout and detail grids, and final assembly into a single PDF.

Result

Complete cartographic notebook per cluster, generated from the selection of a folder and a name.

• Python
• Tkinter
• matplotlib
• geopandas
• PDF

Automation Workspace (Python)

Work repository with the collection of daily automation scripts, organized by entity and theme.

Problem

Dozens of small routines — extractions, checks, conversions — that do not justify their own repository but need to be versioned and locatable.

Approach

Organization by data origin and theme (incidents, municipal plans, susceptibility, SQL queries, personnel data), with dependencies declared in a single file for the entire set.

Result

Foundation from which several routines matured and moved into their own repositories — this is where projects begin.

• Python
• geopandas
• OWSLib
• reportlab
• opencv
• SQL

ArcPy Workspace (Conda)

Parallel collection of routines dependent on the proprietary ArcGIS library, isolated in its own environment.

Problem

ArcGIS's native library requires its own interpreter and conflicts with the open-source geospatial environment—mixing both script families breaks both.

Approach

Deliberate separation by environment, with documented survey of the 26 external dependencies across 72 files and reproducible installation instructions.

Result

Two stable environments instead of one unstable one, with the boundary between them explicit in the repository structure.

• Python
• arcpy
• Conda
• ruff

GTO Activation — Analysis of the Operational Theatre

Geospatial analysis system that transforms a single occurrence record into a complete territorial dossier in 5 to 10 minutes. The largest project in the set.

Problem

When a team is activated for an operational theater, the information it needs—cartography, meteorology, fuel, access—exists, but is scattered across dozens of systems. Gathering it manually takes hours that the incident does not allow.

Approach

Single pipeline starting from the incident number, resolving location, collecting historical and forecast meteorology, calculating susceptibility, preparing input files for propagation simulators, and composing the cartography; the final report is drafted by a locally served language model. The process clock is frozen at an explicit point so all modules use the same instant—previously, an 11-minute execution appeared spread across different hours.

Result

Over 39 thematic maps, meteorological analysis, susceptibility maps, simulator-ready data, and a report with automatic analysis—all within a commute time.

• Python 3.13
• geopandas
• rasterio
• scikit-learn
• contextily
• folium
• Open-Meteo
• Local LLM
• Telegram

App Search

Automation system for processing search and rescue operations.

Problem

In a search, the cartographic product and the temporal reconstruction of team movements are accurate while the operation is ongoing — not the next day.

Approach

Automated spatial processing over operation data, constructing timelines that order the series of events and allow viewing search progression over time.

Result

Application in production, with version logging and technical documentation of concepts used, maintained across successive real-world operations.

• Python
• arcpy
• temporal analysis
• automatic cartography

Fire Reports

Generation of a complete forest fire report from a single incident number.

Problem

Each report required consulting six different systems and copying values between them manually, with transcription error entering every stage.

Approach

Twenty-eight chained steps: the operator enters the number, the system reads the date, collects meteorological data from observation and reanalysis, cartography, online layers and local rasters, and composes an Excel book with images and embedded maps. Collection from portals without API is done via browser automation.

Result

Complete report folder per incident, with traceable data provenance instead of copied values.

• Python
• playwright
• openpyxl
• rasterio
• contextily
• ECMWF

Delivery Guides — Anomaly Detection

Automatic error detection in delivery guides and individual notification of responsible parties.

Problem

Entry errors only appeared in monthly consolidation, when it was already too late to correct, and mass notification dispersed responsibility among those with nothing to correct.

Approach

Migration from a spreadsheet-based flow to direct database reading, with anomaly grouping by recipient, throttling to avoid triggering mail server defenses, and full audit logging of everything sent. The old flow is preserved as a fallback alternative.

Result

Each responsible party receives only their anomalies, on the same day, with a trail of who was notified.

• Python
• MySQL
• SMTP
• pandas
• audit

Operation Kristin Management

Collection of operational management routines focused on the forest road network and situation reports.

Problem

A prolonged operation generates situation reports at fixed intervals, and the characterisation of the forest road network changes as the terrain is traversed—without automation, reporting effort eats into operation time.

Approach

Four functional areas: treatment of the forest road network, production of situation reports, consolidation of operation data, and daily decision support, with documented machine configuration for replication at another post.

Result

Periodic report produced from already registered data, rather than collected anew each cycle.

• Python
• pandas
• geopandas
• GIS

Verify Service — Data Quality

Systematic validation of operational data against business rules, with a navigable report of errors found.

Problem

The data feeding all reports come from human entry; without systematic verification, errors are only discovered when the final number does not match.

Approach

Rule engine over five tables in the operational database, capable of running on a local copy for users without access to the internal network, with automatic tests on the rules themselves.

Result

Interactive HTML report that points to the concrete record to correct, rather than just signaling the existence of a problem.

• Python
• MySQL
• SQLite
• pytest
• HTML

Data Preparation for Simulator

Automates the preparation of the input data folder for propagation simulation in an operational area.

Project discontinued before production use.

Problem

Propagation simulators require a rigid set of files — clipped and aligned rasters, fuel moisture, wind series — whose manual preparation is tedious and fails silently due to misalignment.

Approach

Guided workflow that creates the project folder structure, resolves location by incident number or coordinates, downloads meteograms, crops and aligns rasters, generates points and buffers, and exports humidity and wind files in the required formats.

Result

Portable tool: copy the folder to another post and configure paths once via the interface.

• Python
• GDAL
• rasterio
• playwright
• Tkinter

Transfer Calculation

Automatic calculation of placements from the list of requests and available vacancies, in two implementations.

Project discontinued before production use.

Problem

Allocation was performed manually on spreadsheets, risking duplicate assignment of the same slot or inconsistent application of criteria across cases.

Approach

Two versions of the same algorithm — one in Python, the other in a spreadsheet macro — to function even in posts where nothing can be installed, producing a final formatted file from a template.

Result

Reproducible and auditable result, and the macro version ensures the process runs on any workstation.

• Python
• pandas
• openpyxl
• VBA

Situation Room Support Bot

Automatic communication interface delivering executive summary reports to a messaging channel.

Problem

The coordinator is not at the computer: they requested by phone numbers that were already in the database, and someone had to go fetch and transcribe them.

Approach

Six official commands over the operational database, served to chats and authorized channels, with the service running permanently on the machine and native system scheduling.

Result

In production: executive summary on demand, on mobile, without human intermediary.

• Python 3.13
• python-telegram-bot
• MySQL
• SQLAlchemy
• Windows Service

Bot Hub (plugin architecture)

A single shared bot hosting plugins for multiple projects, instead of one bot per project.

Problem

Each project wishing to notify created its own bot, duplicating authorization lists, error handling, and file delivery — and forcing the receiver to manage multiple conversations.

Approach

Domain-agnostic core that resolves once what is common — authorization, blocking of concurrent executions, task execution, result delivery, progress reporting, and cancellation — and exposes a plugin interface for each project to register its commands.

Result

New project gains its own commands without new infrastructure, and users have a single conversation.

• Python
• python-telegram-bot
• plugin architecture
• Self-hosted Bot API

ArcGIS → WhatsApp

Automatic WhatsApp notification service triggered by changes in geographic layers.

Problem

Not everyone in the field uses the institutional messaging app, but practically everyone uses WhatsApp — and the information that matters originates in a geographic layer, not in a conversation.

Approach

Node.js service that monitors online layers and routes relevant events to a self-hosted WhatsApp API in a container, with its own database for state and recipients.

Result

Geographic alerts delivered on the channel teams already have open; currently the most active project in the suite.

• Node.js
• Docker
• PostgreSQL
• Evolution API
• ArcGIS Online

Local replica of incident data

Own branch of a public fire data project, dedicated to local synchronization as an alternative resource.

Problem

A public incident data service is excellent until it becomes unavailable—which is usually exactly the day it is most needed.

Approach

Contribution to a separate branch of the original project, with a synchronizer that replicates active incidents to a local database, keeping the origin intact and preserving the public project history.

Result

Data availability guaranteed even with the source offline. The bulk of the 805 commits is from the original project — the own contribution is the synchronizer.

• Python
• MySQL
• open-source fork

Emergency Management Dashboard

Real-time operational dashboard for assets, missions, and incidents, featuring an interactive map, timeline, and multimedia panel.

Problem

Monitoring an operation required having several applications open in parallel, each with its own version of the truth and none with the timeline of what happened.

Approach

Next.js application with server-side rendering and custom API routes, integrating official geographic layers into a single view, with server-side verified session authentication and a navigable timeline of events.

Result

Single operational view, with 199 commits of continued iteration on real-world use. Second generation of the project.

• Next.js 14
• React
• TypeScript
• ArcGIS Online
• session authentication

Emergency Dashboard — 1st Generation

First version of the operational dashboard, establishing the data model and visual language.

Problem

Prove that it was possible to gather means, records, and incidents in a single view before investing in a definitive architecture.

Approach

Functional prototype in Next.js, taken to real usage to discover requirements that only appear in service.

Result

Validated the concept and was deliberately replaced by the second generation—the decision to rewrite is documented rather than the prototype being endlessly patched.

• Next.js
• React
• ArcGIS Online

Mobile application for air-transported operations

Flutter application for recording helicopter operations, designed to work offline.

Problem

The recording of these operations is done on paper and transcribed later, because there is no network coverage at the workplace to support a connected application.

Approach

Local-first architecture with an on-device database and reactive state management, synchronizing with geospatial services when a network is available; drawing system documented prior to implementation.

Result

Application under development with detailed change logging and documentation of patterns used—repository and singleton—written for self-learning.

• Flutter
• Dart
• Riverpod
• SQLite · Drift
• ArcGIS

Fuel Height — Legal Compliance

Checks, from drone flights, whether vegetation near critical infrastructure is in violation of legal protection strips.

Problem

Inspection of fuel management strips along roads, power lines, and gas pipelines is done on foot, by sampling, and proof of infringement depends on on-site measurement.

Approach

Calculation of the canopy height model by the difference between surface and terrain obtained from the flight, and comparison of each pixel height with the applicable legal limit for the relevant strip — distinct regimes for road, electrical, and gas pipeline networks.

Result

Objective identification of infringing areas, with the legal criterion explicitly embedded in the code rather than dependent on operator judgment.

• Python
• rasterio
• numpy
• photogrammetry
• CHM

Drone Processing — WebODM

Local photogrammetry installation with end-to-end automation: select folder, process, open results.

Problem

External photogrammetric processing implies sending operation images outside and waiting in a queue; locally, it implies a sequence of manual steps in the interface.

Approach

Open platform installed in containers on the machine, with an automation layer on top of its API that submits the flight, monitors processing, and collects final products.

Result

Locally produced orthomosaics and 3D models, without sending operational data outside. Feeds vegetation compliance analysis.

• Docker
• WebODM
• Python
• pyodm

Drone Processing — v1

First approach to automating photogrammetric processing via command line.

Problem

Realizing which parts of the photogrammetric processing pipeline warranted automation before building serious infrastructure.

Approach

Direct orchestration of processing containers, with file-based configuration and progress monitoring in the console.

Result

Served as a preliminary study; replaced by the web-interface version two months later.

• Python
• Docker SDK
• PyYAML

Local RAG on internal documentation

Question-and-answer system about the section documentation, with natural language data querying — running entirely on the machine.

Problem

The accumulated technical documentation is extensive and the information exists, but finding it requires knowing where to look. Sending service documentation to a cloud service is not an option.

Approach

Vector indexing of documents in multiple formats with a locally served model, agent layer capable of executing small file edits and translating questions into SQL queries, and local web interface.

Result

Operates offline; no documents leave the machine. Currently in consolidation phase.

• Python
• LangChain
• ChromaDB
• Ollama
• PyMuPDF
• Local WebUI

Local LLM server

Language model server compatible with the standard interface, with graphical lifecycle management.

Problem

Several projects need a language model, but each started its own server competing for the same GPU and the same port—with real port collisions from services of other projects.

Approach

A single shared server exposing the sector's standard interface, with graphical start/stop and model selection; the occupied port is now documented in the machine inventory.

Result

Any project points to the same model access and exchange endpoint without changing code. Used by the report generator and the RAG system.

• Python
• llama.cpp
• OpenAI-compatible API
• Tkinter

Code assistant configuration

Versioned rules, commands, and project templates shared by three different programming assistants.

Problem

Work rules defined in the head do not survive a machine change or tool swap, and each assistant stores the configuration in its own format.

Approach

Single repository with global rules, commands, and project structure templates, installed via links to paths each tool expects — one source, three destinations.

Result

Reproducible workflow on any post, explicit enough to be critiqued and improved, rather than implicit.

• Markdown
• AI tools
• environment automation

Floresta Segura — National GIS Platform

End-to-end pipeline from field data collection to report distribution for the national rural fire prevention operation.

Problem

Field teams need to register inspections, validate water points, and map fires with consistent administrative and cadastral information.

Approach

Field Maps and QuickCapture forms, automatic parish/municipality/district calculation, cross-referencing with DGT/BUPi, flagging potential infractions, and dashboard in ArcGIS Experience Builder.

Result

Real-time monitoring, controlled editing, and planning; a Python/ArcGIS Pro process creates backups and PDF, Excel, and shapefile reports, distributed via SharePoint.

Relation

Relates to the SIG automation sheets, ArcGIS reports, and rural prevention from this portfolio, remaining here as an independent institutional platform.

• ArcGIS Online
• Field Maps
• QuickCapture
• Python
• SharePoint

PIGE — Real-Time Operational Management Platform

Daily operational board for tracking ground and helicopter teams and supporting command decision-making.

Problem

Activity, location, multimedia assets, call signs, and urgent requests were scattered and did not form a common operational picture.

Approach

QuickCapture and Field Maps collect movements, photographs, video, GPS, and resource requests; Experience Builder brings together live activity, 12-hour map, planning, requests, and history.

Result

A linked view between ground and air teams, with 1–2 minute latency, nearest patrol calculation, temporal filters, and access to fire risk layers.

Relation

Connects to risk layers and catalogued patrol record sheets; it is the operational origin platform for the PIGE Next-Gen evolution.

• ArcGIS Experience Builder
• QuickCapture
• Field Maps
• GPS
• Multimedia

PIGE Next-Gen — React Dashboard

Independent reconstruction of the main view of PIGE to overcome performance limits and low-code builder interface constraints.

Problem

Direct queries to ArcGIS Online on each load limited speed, interface control, and native playback of field-collected video.

Approach

React Frontend supported by a dedicated server maintaining an updated local cache; self-hosted WhatsApp integration in Docker with Evolution API.

Result

Faster loading times, smoother interaction, video playback directly on the page, and automatic routing of QuickCapture data to operational teams.

Relation

Evolves the PIGE experience and intersects with the already documented WhatsApp automation, but is treated as a separate project due to the new architecture.

• React
• Backend cache
• ArcGIS Online
• Docker
• Evolution API

SEPNA — EMEIF · Alert Register

Platform for registering rural and forest incidents detected by four types of surveillance.

Problem

Tower alerts and video surveillance, patrols from various entities, 112 calls, and aerial assets have different requirements but need a coherent registry.

Approach

Shared and flexible model with dashboard by surveillance type, filterable map, full listing with CSV export, calculation error review, and structured geographic editor.

Result

A single point of entry with more consistent data for fire monitoring and command support systems.

Relation

Feeds the fire monitoring ecosystem, including DIVDIR; remains an independent registry platform.

• ArcGIS
• Dashboard
• Geographic Editor
• CSV
• Multi-entity

DIVDIR — Command Support Dashboard

Consolidated operational view of incidents, assets, and surveillance systems linked to rural and forest fires.

Problem

Decision-makers needed to consult ANEPC incidents, alerts, helitransport activity, drone planning, and surveillance coverage in a single view.

Approach

Dashboard with timeline, counts, and filters; history modules, external links, and state editing; local Telegram bots to convert CAPVI/IPMA reports into published layers.

Result

An updated operational image, with field photos and video, aerial planning, and automated ingestion of reports defined with AGIF parameters.

Relation

Receives data from EMEIF and relates to CAPVI sheets, IPMA, bots, and fire monitoring, while remaining an independent dashboard.

• ANEPC
• ArcGIS
• Telegram
• CAPVI / IPMA
• AGIF

CIPO — Recovery Work Monitoring

Platform built for GNR participation in the inter-ministerial recovery command following Storm Kristin.

Problem

It was necessary to coordinate municipal needs, planning from various entities, and field validation of cleaning of damaged forest paths.

Approach

Field Maps for work validation; continuous synchronization of planning in Google Sheets to ArcGIS layers; daily processing of administrative data.

Result

Public platform with planned versus completed status, automatic SITREP generation, local copy on Google Drive, and republication to GeoSiFOR by AGIF.

Relation

Relates to sheets on Kristin, road network, synchronization, and operational reports; presented as a mission and autonomous platform.

• Field Maps
• Google Sheets
• ArcGIS
• SITREP
• GeoSiFOR

bcariobomvalor

Online Boticário product store with catalog, orders, and a proprietary data preparation pipeline.

Problem

Build a low-cost e-commerce operation, maintaining catalog, invoices, clients, and orders in a coherent database.

Approach

Responsive Next.js website, SQLite-based, and Python pipeline to read PDF invoices and enrich product descriptions.

Result

Architecture, requirements, and technical foundations defined for a store with manual payments via MB WAY or transfer.

• Next.js
• React
• TypeScript
• Python
• SQLite

Our Parish

Single project for communication between citizens and the Parish of Nossa Senhora das Misericórdias, in Ourém.

Problem

Facilitate structured reporting of issues, suggestions, and events and track the response from parish services.

Approach

Flutter application for citizens with GPS, photos, and notifications, linked to the management component used by staff.

Result

An integrated flow from mobile submission to analysis, resolution, and communication of status to the citizen.

• Flutter
• Firebase
• GPS
• Android
• Incident Management

Gaming Industry

Family board game about the industrial world, with a desktop host and clients on the local network.

Problem

Adapt an extensive board game experience into a digital format shared across multiple devices.

Approach

Godot 4 project with GDScript rules, 3D physics data, and WebSocket communication between host and clients.

Result

Menu and dice roll validated; the implementation of the playable board is in progress.

• Godot 4
• GDScript
• WebSocket
• 3D

Monopoly Family Portugal

Multiplayer game with Portuguese cities, designed for television, tablet, computer, and mobile phones.

Problem

Allow a family to share the same board without concentrating all interactions on a single screen.

Approach

A host device displays the board, and players join via QR Code, communicating over WebSocket on the Wi-Fi network.

Result

Cross-platform architecture defined for Android, Windows, and web, with chat and match recording.

• Flutter
• WebSocket
• QR Code
• Android
• Windows

Robot Quest

2D pixel art adventure combining exploration with Portuguese and Math exercises.

Problem

Create a learning experience suitable for young children without separating exercise and play.

Approach

Top-down exploration, war fog, and battles resolved through questions, with controls for keyboard and touch.

Result

Functional game for Windows and Android, with difficulty and progress saved automatically.

• Flutter
• Dart
• Pixel art
• Windows
• Android

Race Board

Board game in development, supported by models and structured documentation.

Problem

Transform the concept of a race into a coherent, documented, and evolution-ready board game system.

Approach

Modeling of rules and components with project documentation and AI tool support.

Result

Design foundation organized to validate mechanics before full implementation.

• Board game
• Models
• AI
• Documentation

OpenClaw Casa

Node.js base for home automation, integrations, and data processing.

Problem

Centralize home automations and integrations into a controllable and testable project.

Approach

Explicit separation of source code, data, configuration, and automated tests.

Result

Versioned technical structure to develop new automations without mixing logic and operational data.

• Node.js
• Automation
• Integrations
• Tests

LLM with llama-server and Vulkan

Environment to execute, serve, and evaluate GGUF models on local hardware.

Problem

Use language models with cost control, data, and GPU resource management, without relying on an external service.

Approach

Vulkan-accelerated llama-server, model catalog, controlled selection, and speed and quality benchmarks.

Result

Endpoint compatible with common APIs, reusable for RAG, reports, and other tools requiring confidential processing.

• llama.cpp
• Vulkan
• GGUF
• Qwen
• Python

Universal Skills Framework

Open framework to write a skill once and reuse it across different agents and environments.

Problem

Each vendor represents instructions, competencies, and memory in a different format, requiring duplicated maintenance.

Approach

Portable Markdown/YAML format, Obsidian-based memory, validators, and synchronization for supported tools.

Result

A versioned source for skills and persistent context, consumed by implementations in Python and TypeScript.

• Python
• TypeScript
• Obsidian
• CLI
• MIT