DEV Community: Panagis Tzivras

The Map Works. Now Comes the Conversation.

Panagis Tzivras — Tue, 10 Nov 2026 17:29:38 +0000

Preparing ARGOS : : for its first potential municipal presentation, and discovering that explaining software is another kind of engineering.

Most of my work on ARGOS : : happens somewhere between a database, a terminal, and a map of Kefalonia.

There is usually something concrete to investigate. A dataset has changed. A pipeline needs checking. A layer behaves differently than expected. Something that worked perfectly on my laptop has suddenly decided it hates phones.

The usual routine.

But recently, I found myself working on something quite different.

A presentation.

Not a new dataset. Not an API endpoint. Not another improvement to the map.

Fifteen minutes to explain what I've been building to people who might actually have a use for it.

And that introduced a surprisingly different set of engineering questions.

What should I show first? How much background does somebody need? Which limitations belong in the demonstration? How do I make the map understandable without explaining the entire architecture behind it?

And perhaps most importantly, how do I leave enough room to hear what the people across the table actually need?

This is a build log about preparing for that conversation.

The meeting itself is still pending.

From building features to explaining decisions

ARGOS : : is my independent, open-source geospatial initiative for Kefalonia, Greece.

It brings together geographic datasets, environmental information, and documented spatial analyses in an interactive map. The idea is to make information about places, infrastructure, and changing conditions easier to explore, question, and understand.

I build it alongside my full-time data engineering job.

Time is therefore not just a personal constraint. It has become something of an architectural principle. 😄

For the potential municipal presentation, I've prepared roughly fifteen minutes of material.

Enough to introduce the platform, demonstrate a couple of working examples, and explain why the underlying information matters.

Not enough to show everything.

And that turned out to be a useful restriction.

When you're building software, it is tempting to show how much you've built. Every layer represents work. Every analysis has a story. Every feature has a reason for existing.

But an audience doesn't need to see your development backlog.

They need to understand what they're looking at.

So I started asking a different question:

What should someone understand after seeing this example?

A flood-susceptibility layer can start a conversation about terrain, water accumulation, and the limitations of geographic screening.

A fire-service accessibility analysis can show how a road network, estimated travel speeds, and documented assumptions produce an estimate of accessibility.

Neither requires a tour of the database.

Both require enough context for someone to understand what the result does and does not mean.

The challenge isn't demonstrating that the platform contains information.

It's demonstrating how that information can be interpreted responsibly.

The first conversation widened the picture

I contacted the Municipality of Argostoli to introduce the project and eventually had an encouraging telephone conversation with a municipal contact.

We discussed potential applications, including geographically relevant visitor information accessible through QR codes and the mapping of emergency assembly points.

He also mentioned that he would explore whether other municipal colleagues might be interested in seeing the platform.

Nothing formal was agreed. No pilot, partnership, or development commitment. The possibility of a presentation remains open.

But the conversation was useful even without a meeting date.

Until then, much of my preparation had naturally centred on environmental and Civil Protection examples.

Flood susceptibility. Wildfire screening. Accessibility. Changing conditions.

Those are important applications, but they're not the whole purpose of a digital twin.

A geographic platform can potentially support many different questions. Infrastructure, public information, municipal assets, environmental conditions, accessibility, and how places relate to one another.

Different departments see the same island through different responsibilities.

That made me reconsider what I wanted from the presentation.

Rather than arriving with a list of features and asking which ones people liked, I wanted to understand something more fundamental:

Where does geographic information become difficult to find, maintain, combine, or explain in someone's everyday work?

It's a question I cannot answer from my terminal.

The limitations belong in the demonstration

One of the principles behind ARGOS : : is that the map should not simply display a result and expect people to trust it.

Sources matter.

Methods matter.

Assumptions matter.

And limitations matter just as much.

Preparing the presentation made me think about how those details should appear while someone is looking at the geographic result.

Consider three examples.

Flood susceptibility: A terrain-based screening layer can highlight places where runoff may concentrate or water may accumulate. It does not predict when flooding will occur, how deep the water will be, or whether local drainage infrastructure will prevent it.

Fire-service accessibility: A network analysis can estimate travel times using road connections and assumed speeds. It cannot establish actual emergency response times without operational observations and further validation.

Marine conditions: A modelled field can describe predicted waves or currents at a particular resolution and valid time. That doesn't make it a direct local observation or a guarantee of conditions at a specific beach.

Those aren't footnotes.

They change how the information should be interpreted.

The map already provides a “How do we know?” route to explanatory information associated with its analytical layers. That gives me a way to bring sources and limitations into the demonstration rather than relegating them to a methodology document nobody has time to open.

Some of the analyses also have documented misses.

I think those deserve a place in the project record alongside successful checks. A model that gets something wrong can be informative, provided the failure is investigated rather than hidden.

A useful map should make uncertainty easier to investigate, not easier to overlook.

There will inevitably be questions I cannot answer during a presentation.

Sometimes the answer will be that the existing data is insufficient.

Sometimes it will be that a result has been internally checked but not independently validated against real-world observations.

And sometimes local experience may reveal something the model simply doesn't know.

That's not necessarily a failed demonstration.

It might be the beginning of a useful technical conversation.

The demo is another kind of test

I've spent some time rehearsing the presentation.

Not just the words, but the software.

Opening a geographic deep link.

Checking that the intended layer appears.

Making sure the legend is visible.

Opening the explanatory information.

Closing a panel without losing the geographic context.

Moving between a slide and the live map.

These sound like trivial interactions.

When you're developing alone, they usually are.

But in a fifteen-minute presentation, every unnecessary click steals attention from the actual subject.

And I discovered something interesting:

A feature can be technically functional without the workflow around it being ready to demonstrate.

A layer might render correctly. Its data may be available. Its information panel may work.

But if reaching the explanation requires several awkward interactions, the audience can lose the thread long before you reach the interesting part.

That means rehearsing a demonstration is also a form of interface testing.

Not a replacement for automated tests, data checks, or proper usability testing.

A different perspective.

You're no longer asking only whether the component works.

You're asking whether a person unfamiliar with the project can follow what is happening.

For me, that distinction has already been useful.

It has also influenced the ongoing visual design work around ARGOS : :. Giving the geography more room, making evidence easier to reach, and reducing unnecessary interface complexity are not merely aesthetic decisions.

They affect how easily someone can understand the map.

And understanding is rather important when the software is trying to communicate geographic evidence.

From technical assumptions to local knowledge

Building ARGOS : : has required making countless decisions about what information to include and which questions might be useful.

Some of those decisions came from available datasets.

Others came from research, engineering constraints, and my own familiarity with Kefalonia.

But knowing an island and understanding how its public services work are not the same thing.

A municipal employee may know about a road that regularly becomes inaccessible, a location that floods despite appearing unremarkable in a terrain model, or an important dataset that exists only in an internal spreadsheet.

That knowledge doesn't automatically appear in OpenStreetMap, Copernicus products, or a PostGIS database.

And it shouldn't be invented to fill the gap.

An actual conversation could help identify where the published geographic picture agrees with local experience, where it doesn't, and which missing information would genuinely improve an analysis.

That is one reason I'm interested in the potential meeting.

Not because I expect someone to validate everything I've built.

Quite the opposite.

I want to find out which assumptions survive contact with people who deal with the island's practical problems.

Where the outreach stands

After the initial telephone conversation, I sent a follow-up email with my availability.

As I write this, I haven't received a response, and no meeting has been scheduled.

I don't know the reason, and I don't think there's much value in guessing.

Municipal schedules are their own world, and the discussion was exploratory from the beginning.

My full-time job also has some substantial deadlines at the moment, so I'll follow up when I have enough room to give the conversation the attention it deserves.

For now, ARGOS : : remains publicly accessible, the presentation material is prepared, and the possibility of a meeting remains open.

There is no launch date, partnership announcement, or pilot waiting behind this article.

Just a working project and a conversation I'd like to have.

What I hope to learn

If the meeting happens, my objective is fairly simple.

Show what works today.

Explain what doesn't.

And listen.

I'd like to understand which geographic questions municipal teams regularly encounter, what information they already maintain, and which gaps might be worth investigating.

I'd also like to hear the technical objections.

Who maintains the data?

How frequently does it change?

What happens when a source is unavailable?

How do we distinguish an estimate from an observation?

Which results are useful for exploration, and which would need substantially more validation before supporting an operational decision?

These are questions worth answering whether or not any formal collaboration follows.

Preparing for this potential meeting has already made me look at ARGOS : : differently.

For months, the central challenge has been getting the pieces to work together: data pipelines, spatial processing, APIs, map layers, evidence, and infrastructure.

Now I'm thinking more about what happens when the person looking at the map wasn't involved in building any of those pieces.

Can they understand what it shows?

Can they find out where the information came from?

Can they question the result?

Can they tell me something about the geography that the software missed?

I suspect those questions will become increasingly important as the project develops.

The map is ready to open.

I'm interested in what they'll ask when it does.

Explore the project: ARGOS : :

Open the working map: argos-geo.org/map

Source code: GitHub

If you've brought an independent technical project to a local authority, what helped make that first conversation useful?

The Cable: How a €12 adapter turned a laptop into infrastructure

Panagis Tzivras — Sun, 25 Oct 2026 13:10:36 +0000

Frankie was alive. But Frankie was not yet a server. This is the story of the cable that changed the verdict.

The adapter arrived on a Tuesday

I had ordered it from a local electronics shop in Argostoli. USB 3.0 to Ethernet. Realtek chipset. The clerk did not ask what it was for. I did not explain that a 2008 MacBook Air was waiting for it.

I powered Frankie down, plugged the adapter into the USB port, ran an Ethernet cable to the router, and powered back on.

The kernel saw it immediately. A new interface appeared. DHCP fired. I opened a terminal.

ping -c 100 8.8.8.8

One hundred packets sent. One hundred received. Zero percent loss. Round-trip times under two milliseconds. The same router that had given Frankie nine percent loss over WiFi now gave perfect reliability over copper.

The b43 driver was no longer in the critical path.

I configured a static DHCP reservation on the router so Frankie would always get the same local address. Then I tested the one thing that mattered.

I ran the backup script.

It SSHed into the Oracle VM. It checked disk space. It checked load average. It streamed a pg_dump over the encrypted tunnel. Four minutes later, a 132 MB file sat on Frankie's disk, verified with pg_restore, containing every table, every spatial index, every road segment and building footprint in the ARGOS : : twin.

I ran it again. It passed. I ran it a third time. It passed. I deleted the test files and ran it a fourth time, this time with the full cron environment exported, mimicking the minimal shell that cron provides at 04:00.

It passed.

The wall was down.

Headless

With a reliable network path, Frankie could finally become what it was meant to be. I changed the default boot target from graphical to multi-user. Cold boot. The screen showed a text login prompt. No LXQt desktop. No wallpaper. No mouse cursor.

I closed the lid. The machine kept running. No sleep. No suspend. No lit panel generating heat in a closed chassis. The machine stands vertically on the table, exhaust side down, so the fan can pull air through without cooking the chips. mbpfan manages speed based on temperature sensor readings. Core temperatures stayed in the sixties. The NVIDIA 9400M GPU idled without a display server asking it to render anything.

From the Windows laptop across the room, I opened an SSH session. All three services responded. Then I opened X2Go. The remote desktop connected. X2Go creates its own session. It does not need a local GUI to exist. Frankie was headless and accessible at the same time.

Reversibility is preserved. If I need a local GUI for maintenance, one command brings it back without changing the default. If something goes seriously wrong, GRUB recovery mode leads to a root shell. The transformation is not a prison. It is a preference.

The services

Three things now run on Frankie.

File sync. Syncthing bridges Frankie and the development laptop. I tested it with a project image, synced it across, then deleted it on the source. The file survived in a versioned archive with a timestamp suffix. Sync proven. Recovery proven. The bridge is solid.

Git mirror. Gitea runs under a dedicated system user, backed by SQLite.

The backup. The script runs daily at 04:00. It connects to the cloud VM, streams the full PostGIS database, writes to a temporary file, verifies the dump with a restore listing, and only then atomically promotes it to a final archive. The previous good dump survives until the replacement is proven. Four manual test runs passed. The first unattended cron run is the real examination.

The infrastructure, right now

Local dev: Frankie, 2008 MacBook Air, Lubuntu, headless, USB Ethernet, mbpfan tuned to 55/60
File sync: Syncthing, versioned, tested
Git mirror: Gitea
Backup: Daily pg_dump from Oracle VM, atomic promotion, four test runs passed
Production database: Oracle Cloud VM, PostGIS 16, pgRouting
Site: Cloudflare Pages, global CDN
Tiles: GitHub Pages, PMTiles
Builds: GitHub Codespaces

There is no procurement department. There is no EU grant. There is one person, a vertical laptop on a table, and a €12 cable that turned a waiting machine into a server.

The lesson

Frankie was never going to be fast. A Core 2 Duo with under 2 GB of usable RAM will not run Docker. It will not compile a spatial index. It will not serve map tiles to a thousand users.

But Frankie does not need to be fast. Frankie needs to be reliable. And reliability, on this hardware, is a design problem, not a purchasing problem.

The b43 WiFi ceiling forced the Ethernet adapter. The slow CPU forced lightweight services. The limited RAM forced careful process management. Each constraint removed an option and sharpened the design.

Six months ago, this machine was headed for recycling. The WiFi was broken. The trackpad was erratic. The battery held minutes. The screen had lines.

Today it stands vertically on a table next to the router, lid closed, running three services, safeguarding a database, mirroring a repository, and syncing files across devices. It will never be fast. It does not need to be. It needs to do one job, reliably, while the island sleeps.

The backup script runs tonight at 04:00. We will know tomorrow morning if the safeguard actually safeguards.

Frankie is alive. Frankie is a server. And if you walk past that table at four in the morning, the only light you will see is the Ethernet port blinking next to the router. 🤖

The Wall: How a Wi-Fi driver killed the server dream

Panagis Tzivras — Thu, 22 Oct 2026 11:36:47 +0000

Eight percent packet loss, a kernel panic, and the €15 answer that was hiding in plain sight

The morning after Frankie came alive, I wrote a backup script.

A hundred lines of bash that would SSH into the Oracle VM, check that PostgreSQL was healthy, check that disk space was above 5 GB, check that load was below 4.0. If everything passed, it would pull a pg_dump, gzip it, and store it on Frankie's 120 GB disk. Two dumps kept. Everything older deleted. A safeguard, not an archive. Geographic redundancy: the VM in Frankfurt, Frankie on Kefalonia. The job would run at 04:00, when the island sleeps and the WiFi air is quiet.

I finished the script at 23:00. I ran one test before bed.

ping -c 100 8.8.8.8

Sixty percent loss.

That was from across the room. I moved Frankie next to the router. Eighty-eight percent signal. Two hundred seventy megabits per second negotiated rate. Locked to 2.4 GHz, powersave disabled.

ping -c 100 8.8.8.8

Nine percent loss.

The b43 driver, the open-source driver for the Broadcom BCM4321, has a hard ceiling. I spent the next three hours proving it.

The ceiling

The internet is full of tuning advice for b43. Disable powersave. Lock to 2.4 GHz. Force legacy rates with iw. Add module options. I did all of it.

I disabled powersave in NetworkManager. I locked the connection to 802.11b/g with nmcli. I installed iw and forced legacy-2.4 bitrates. I moved the machine until it was touching the router. The signal indicator showed full bars. The negotiated rate showed 270 Mbit/s, a figure that is impossible on 2.4 GHz channel 1 with 20 MHz width, which means the router was using 40 MHz channel bonding, a mode b43 handles badly.

I forced 20 MHz width. I forced lower rates. I added options b43 nohwcrypt=1 qos=0 to /etc/modprobe.d/b43.conf.

ping -c 100 8.8.8.8

Nine percent loss. Round-trip times spiking to 86 milliseconds. The driver was not failing because of configuration. The driver was failing because it is the driver. The b43 codebase for the BCM4321 rev 05 has a ceiling, and that ceiling is 8 to 10 percent packet loss at full signal.

This is not a signal problem. This is a driver problem.

The escape hatch that was not

Every forum thread about the BCM4321 ends the same way. "Just use the proprietary wl driver." I tried.

I installed bcmwl-kernel-source. I blacklisted b43, bcma, ssb. I rebooted.

The kernel panicked. dmesg showed wl_module_init call stacks. The wl driver crashes on init with this kernel, on this hardware, after the 193-package upgrade that fixed everything else. The upgrade that brought b43 to life did not make wl viable. They are mutually exclusive on this machine, and wl loses.

I reverted. Removed the blacklist, reloaded b43, reconnected. Nine percent loss. But at least it connected.

What nine percent means

Nine percent packet loss does not matter for browsing. Falkon retries. Pages load. It does not matter for SSH: type a command, if a packet drops, the terminal hangs for half a second, then recovers. It does not matter for writing this article in Geany, which is entirely offline.

But nine percent matters for an unattended 04:00 backup job pulling a multi-gigabyte PostgreSQL dump over SSH. A dropped packet in the middle of an scp does not recover cleanly. The transfer hangs. The cron job fails. The safeguard is not safe. A backup that fails silently is worse than no backup, because it gives you false confidence.

I tested this. I ran the script manually. It failed twice in three attempts. The third attempt completed, but the transfer took fourteen minutes for a 1.2 GB dump because TCP was constantly retransmitting. Over a wired connection, the same transfer would take four minutes.

Frankie could not be a server over WiFi. Not because the WiFi was weak, but because the driver was honest about its limits.

The €15 answer

A USB Ethernet adapter costs €15. Any USB 2.0 to RJ45 adapter works on Linux without drivers. Plug it in, the kernel sees eth0, DHCP fires, ping shows zero percent loss. The backup script works. The cron job works. Frankie becomes the server it was meant to be.

I do not have the adapter yet. On the island, it might take a week to find one. Until then, Frankie is in limbo. The script is written. The cron is ready. The machine waits.

The pivot

If Frankie cannot come to the work over WiFi, and the adapter is not here yet, then Frankie's role must change. I stripped the server plan. No headless conversion. No 04:00 cron. No Tailscale tunnel. Frankie stays in the GUI, running LXQt, waiting.

The options without the adapter are real but limited. Frankie can be a learning sandbox: break it, reinstall it, try Arch, try Ansible, try Docker. The WiFi flakiness does not matter because the work is local. Frankie can be a distraction-free writing machine: Geany, Vim, Markdown, no browser, no notifications. Frankie can babysit an Arduino or an ESP32 over USB. The machine does not need internet; it needs a serial port and a screen.

But none of these are what Frankie was meant to be. Frankie was meant to be a server. A backup anchor. A quiet machine in the corner that pulls a dump while I sleep.

That future costs €15. Not €1,500 for a new laptop. Not €500 for a used ThinkPad. €15 for a USB Ethernet adapter that removes the wireless variable entirely.

Sometimes the cheapest solution is the one you pay for.

The infrastructure, right now:

Local dev: Frankie, 2008 MacBook Air, Lubuntu, LXQt, no GPU acceleration, b43 WiFi with 9% loss, mbpfan tuned to 55/60
Production database: Oracle Cloud Always Free ARM VM, PostGIS 16, pgRouting
Site: Cloudflare Pages, global CDN
Tiles: GitHub Pages, PMTiles
Builds: GitHub Codespaces
Email: Resend SMTP, daily VM health reports at 08:00 EEST
The backup script: Written, tested, failing. Waiting for a cable.

There is no procurement department. There is no EU grant. There is one person, a drawer of old hardware, and a shopping list with one item on it.

Frankie is alive. But Frankie is not yet a server.

ARGOS : : The map works on phones now

Panagis Tzivras — Wed, 21 Oct 2026 12:42:24 +0000

ARGOS : : started on a 27-inch monitor. Wide screen, mouse, keyboard, time to think. That is how you build a digital twin. It is not how you use one.

Civil protection happens in trucks, on beaches, at fire posts, in the rain. The person who needs the map is holding a phone, possibly with gloves, possibly in a hurry, possibly without a desk in sight. If the map does not work on a phone, it does not work where it matters.

v0.0.8 is the first mobile-focused release. Not a redesign. A repair of the worst friction.

What changed:

44 px touch targets. The layer toggles, the zoom buttons, the legend items. Every interactive element is now at least 44 px in both directions. No more fat-finger misses.
Layer drawer auto-dismiss. Tap the map, the drawer slides away. The map is the focus; the UI gets out of the way.
Marine slider no longer buried. The wave height slider was hiding under the legend on small screens. Now it sits above it, reachable.
Bilingual gold toast. Toggle a layer, and a small gold banner confirms: "Ενεργοποιήθηκε" in Greek, "Enabled" in English. No ambiguity about whether your tap registered.
Popup sizing. Building popups now fit within a 375 px viewport. No horizontal scroll. No clipped text.

What did not change:

The models are the same. The data is the same. The validation is the same. This is a usability pass, not a content update. The map is still a screening baseline with directional validation, not an operational forecast. The marine layer is still unvalidated. The Ithaca ferry is still not modelled.

But the map is now usable on the device you actually carry.

Test it. Open argos-geo.org/map on your phone. Toggle the wildfire layer. Tap a building. Ask the twin a question. It works. It is not perfect. It is better than last week. And next week it will be better again.

Meet Frankie, the 17-year-old laptop that was supposed to build ARGOS : :

Panagis Tzivras — Tue, 20 Oct 2026 12:05:24 +0000

A 2008 MacBook Air, six hours of Linux archaeology, and the belief that one person with a drawer of old hardware can still matter

I am writing this from a 2008 MacBook Air that macOS abandoned a decade ago. Its name is Frankie. It took six hours to bring it to life, and for one evening, I believed it would be the machine that kept ARGOS running while I am on Kefalonia.

The context

ARGOS : : is a digital twin for an island, built by one person. There is no procurement department. There is no EU grant. There is one person and a drawer of old hardware.

The production database runs on an Oracle Cloud VM. The site runs on Cloudflare Pages. The tiles run on GitHub Pages. The heavy builds run in GitHub Codespaces. Every piece of infrastructure was chosen because it does the job without requiring a team to maintain it. The stack is small because the team is one person. The stack is public because the methodology should be auditable. That is the design, not a compromise.

But I still need a local machine. For the Git commits. For the YAML edits. For the SSH into the VM when something breaks at 23:00 and the Codespace has gone cold. For the fieldwork notes I write on the balcony after walking a ravine.

I did not buy a new laptop. I pulled the MacBook Air 2,1 out of a drawer. The one with the Nvidia 9400M chip that Apple stopped supporting somewhere around Mountain Lion. The one that modern macOS will not even boot on.

The archaeology

Lubuntu 24.04.5 LTS. That was the starting point. Lightweight, supported, sane.

The first attempt failed. The Calamares installer hit a known bug :fixconkeys-part1 timed out after 30 seconds, leaving the disk half-erased and the boot chain corrupted. I rebooted into a grey box with an inverted flag. The fix, found in a forum post from 2023, was to edit /etc/calamares/settings.conf in the live session, comment out two lines, and run the installer again. It worked the second time, though the installer window went black mid-process and I had to trust the fan noise.

Then the display. The live session booted fine, but the installed system showed corrupted text — white boxes where characters should be, inverted colors, blank desktop icons. nomodeset fixed the text but turned the sky brown and the sea purple. The real fix was nouveau.noaccel=1: disable GPU acceleration entirely, tell the kernel to stop asking the 9400M for help. The CPU draws every pixel. No 3D. No hardware compositing. Just a Core 2 Duo doing graphics the hard way, like it is 2006.

And it worked. Colors correct. Icons visible. Desktop stable. The trade-off: no 3D acceleration, which is irrelevant for a machine that was never going to run a game.

Then the WiFi. The Broadcom BCM4321 chip is a known problem child. The proprietary wl driver loads but crashes on this kernel. The open-source b43 driver works, but the signal indicator always shows full bars, whether you are next to the router or three rooms away. The connection is real; the bars are fiction. I can live with that.

The trackpad took three attempts. The first driver moved the cursor but would not click. The second clicked but had no right-click. The third, a manual xinput configuration, gave me both.

Then the heat. The default fan control waits until 63°C before it starts ramping. By then the palm rest is already hot. I installed mbpfan and tuned the curve: low_temp = 55, high_temp = 60, max_temp = 86, polling_interval = 1. The fan stays silent below 55°C, starts a gentle ramp at 55 instead of waiting for 63, and never hits full speed unless the CPU is at 86. A cooler machine with slightly more fan noise. I chose usable.

Then the suspend. The MacBookAir2,1 has a documented kernel quirk: close the lid, and sometimes it wakes to a black screen that never clears. I call it a design feature that forces me to shut down properly. If I step away, I save and power off.

Six hours. From a forgotten drawer to a working desktop.

The first evening

I installed Geany, a lightweight editor that opens in under a second. Falkon, a Qt browser that loads pages without choking. I disabled the screensaver entirely, it was rendering while idle, heating the machine for no reason. I set the monitor to switch off after six minutes.

I wrote the first draft of this article on Frankie itself. The text appeared as I typed. The fan hummed quietly. The palm rest was warm but not hot. For one evening, it felt like the plan would work.

Frankie was alive.

But alive and useful are different things. The next morning, I would learn what a 2 GB Core 2 Duo actually feels like in 2026.

The infrastructure, at that moment:

Local dev: Frankie, 2008 MacBook Air, Lubuntu, no GPU acceleration, b43 WiFi, manual trackpad config, mbpfan tuned to 55/60
Production database: Oracle Cloud Always Free ARM VM, PostGIS 16, pgRouting
Site: Cloudflare Pages, global CDN
Tiles: GitHub Pages, PMTiles, 10.88 MB vector tileset
Builds: GitHub Codespaces, ephemeral, rebuilt on demand
Email: Resend SMTP, daily VM health reports at 08:00 EEST
Storage: MinIO on the VM, 30-day backup retention
Domain cost: €1 per month. The rest is built, not bought.

The big twins , Volos, DestinE, HARMONIA Piraeus, run on HPC clusters and EU budgets and consultant teams. ARGOS : : runs on one person, a free VM, and a drawer of old hardware.

That is not a limitation. That is the point.

Or so I thought.

The Sea Looks Calm When It Isn't

Panagis Tzivras — Thu, 01 Oct 2026 06:06:04 +0000

I spent years reading water before I ever wrote a line of code. So when I say this, it comes from both sides of me: the sea on a map and the sea in front of you are not the same object.

Myrtos Beach is one of the island's best-known beaches. White pebbles, steep cliffs, water that shifts from turquoise to deep blue in a few meters. On most summer days it looks like the safest place on Kefalonia. It is not always.

This is the story of the first marine layer in ARGOS, and of the honest limits of what a model can promise you about the sea.

The night it earned its keep

On the night the marine layer went live, the model logged an exposure score of 73.3 for Myrtos. Class: high. Window: 22:00 to 23:00 EEST. Waves from 316 degrees, about 2 m significant wave height.

Nothing about that sentence is measured at the shoreline. It is computed from Copernicus Marine model data, twice a day, for fourteen pilot beaches around the island. The nearest model cells sit 3.1 to 6.9 kilometers offshore, and the model speaks from there. What the beach does with that energy is a translation, not a measurement.

I want that sentence to sit in your chest for a second, because it is the whole piece.

The sea's shape

Within the ARGOS EMODnet window, the deepest cell is 3,841 meters. Our bathymetry comes from EMODnet at roughly 100 meters per pixel, with contours drawn down to 3,500 meters. Kefalonia's west coast is where that deep water leans closest to the shore.

Along Myrtos' open-water bearing of 291 degrees, the corrected EMODnet contours put 25 m of water about 2.1 km from the shoreline, 50 m at 3.0 km, and 100 m at 4.2 km. The 200 m contour lies about 10.0 km offshore. The beach's assigned CMEMS cell sits 3.36 km from the beach centroid, between the 50 and 100 m contours; at roughly 100 m per pixel, this is shelf-scale context, not swim-zone bathymetry.

That geometry matters because it is why a beach can look like a swimming pool and behave like something else. The energy does not need a storm to arrive. It needs a direction, a period, and a floor that shoals the right way.

The layer

Fourteen beaches. Copernicus Marine Mediterranean forecasts: waves and two-dimensional surface currents, refreshed twice daily. The exposure score is a direction-gated wave score at 70 percent plus a current score at 30 percent. The gate exists because a wave from the wrong direction is noise, and from the right direction it is the whole story.

The bathymetry you just read is context, not an input. Our exposure score does not use the EMODnet shelf layer directly; the CMEMS models carry their own model-resolution bathymetry. It knows the sea state. We supply the geography.

What we could not validate, so we are saying so

There is no independent wave buoy on Kefalonia. The published POSEIDON network has no Kefalonia station; its named Ionian mooring is Pylos. We checked. The answer is no.

So this layer ships unvalidated, first in the validation queue. The interim path is cross-checking against KefaloniaPress daily beach scores and the quality documentation that ships with the Copernicus products themselves. The first version of this story had a cleaner ending. This is the honest one.

What it is not

Not a rip-current warning. Not measured beach safety. Not a lifeguard-grade forecast. Not a safe-or-unsafe certification for any beach, ever.

It is an exposure screening: modelled offshore wave and current conditions, translated into a beach exposure assessment. Direction-gated, twice daily, bilingual, and public about its own uncertainty.

The ask

If you are a lifeguard, a boat operator, or someone who has watched Myrtos for thirty years: your observations are the validation this layer is missing. The map will only get as honest as the ground truth it is fed.

Built in Kefalonia. Watching over the places we call home.

Links:

https://argos-geo.org/map · https://github.com/argos-geo/kefalonia-digital-twin

The Answer You Didn't Want: Fiskardo Evacuation Routing

Panagis Tzivras — Thu, 17 Sep 2026 15:16:27 +0000

During a wildfire, how long does it take to move people out of Fiskardo by road?

That was the question. It sounds like a database query, because it is one: load the road network, pick a start, run pgRouting's pgr_dijkstra, read the cost. Milliseconds of compute. One number.

The first number the twin gave me was absurd. And my instinct was to distrust the model. That instinct was correct, but for the wrong reasons. The model was not lying. My data was wrong in five ways. The sixth way was me.

This is the story of all six.

Round 1: The dead table

The routing query ran cleanly and returned plausible-looking paths. The problem: it was reading an old import table left over from an earlier iteration. The geometry looked like Kefalonia. The connectivity was garbage. The network I was querying was a ghost.

Lesson one of geospatial debugging: a query that runs is not a query that is right.

Round 2: The real network was somewhere else

The live road network lived in a different table. Not a bug, just archaeology. But it means everything the first queries "proved" was noise. I threw the results away and started over.

Round 3: cost_m is not a distance

The cost column in my routing table was named cost_m. I assumed meters. It was minutes. (pgRouting itself returns cost and agg_cost; the misleading name was ours.)

Every distance I had reported so far was actually a travel time. This is the kind of error that doesn't crash. It just quietly corrupts every conclusion you draw from it, forever, until someone reads the schema with suspicious eyes.

Round 4: Mixed SRIDs

Somewhere in the pipeline, two projections had crept in. Geometry in one spatial reference system was being measured against geometry in another. Distances were quietly, consistently wrong by a factor only a geodesist would guess.

A digital twin with two coordinate systems is not a twin. It is two maps arguing.

Round 5: The row-order bug

pgr_dijkstra returns path segments. The results looked scrambled: segments out of order, the route jumping back on itself.

The bug was mine. I was reading the result rows in the order the database happened to return them instead of ordering by seq. The path was correct the whole time. I was reading the sentence word by word, in a shuffled order, and calling it gibberish.

Round 6: The road that might not be there

The final answer was now stable. But it was still wrong in a way no query could detect.

The route took an enormous detour inland, ignoring a 15 km coastal road in favor of 29 km of mountain. The prime suspect is a connectivity gap on the Evreti stretch. A node that doesn't quite snap. Invisible to every attribute query. The autopsy is still open.

What we know for certain: the router prefers a 29 km detour over a 15 km coastal road, the road's data looks clean, and local knowledge says the road is fine. The model and the map disagree, and the argument is documented.

A suspected data gap, wearing a software bug's clothes.

The answer

After six rounds, the twin gave me its answer:

Agia Effimia Marina. 29.0 km. 44 minutes. 116 road segments.

That is the answer you didn't want. Forty-four minutes is not a comfortable number if you are standing in Fiskardo watching smoke. At every round of this forensic, a prettier wrong answer was available. Faster numbers. Shorter routes. Numbers that would have looked great in a demo.

The value of this digital twin was never going to be that it produces answers. Any GIS produces answers. The value is that this answer survived six rounds of me trying to break it, and it is still standing.

The lighthouse test

The same engine, asked a different question, once ranked an abandoned lighthouse on an uninhabited islet as the hardest place to reach in an emergency: 108.1 minutes from the nearest fire station. Island-wide worst. The tower was leveled in the Italian bombings of 1942; what remained was felled by the 1950 earthquake. Technically correct, contextually meaningless.

Put the two stories together and you get the real design principle:

The twin finds edge cases and reports reachability honestly. Humans supply context and priority.

A bombed lighthouse and a hospital get the same accessibility score. That is not a flaw in the model. That is the model telling you exactly which decisions it cannot make for you.

Why this matters for civil protection

Evacuation planning runs on numbers. If those numbers come from an unvalidated model with a dead table, a minutes-as-meters column, and an unsolved coastal detour, the plan is a rumor with a map attached.

The uncomfortable number, validated, is worth more than the comfortable one, invented. That is what "no black boxes" means in practice. Not a slogan on an open data page. Six rounds of forensic debugging before a single digit goes public.

Every model in ARGOS carries its validation with it: what was tested, against which events, what worked, what didn't. This routing layer is no exception.

The methodology, the code, and every wrong answer along the way are public. A map that argues back must also admit when it is unsure.

Links:

Built in Kefalonia. Watching over the places we call home.

ARGOS v0.0.1 is live: a digital twin of Kefalonia

Panagis Tzivras — Thu, 20 Aug 2026 16:56:16 +0000

Three weeks ago I started building a map that argues back.

Today it is public.

🗺️ argos-geo.org/map

What you can do:

Click any building, road, beach, or POI
See travel time to the fire station and nearest ferry port
Toggle wildfire risk and flash-flood layers
Find the lighthouse nobody asked about (102 minutes, boat-only)

The stack: PostGIS + FastAPI + MapLibre GL + PMTiles. Hosted on GitHub Pages. Costs €0/month.

The data: OpenStreetMap, Copernicus DEM, Sentinel-2, NASA FIRMS, EFFIS. All open. All attributed.

This is a static snapshot. Phase 2 adds real-time feeds. Phase 3 adds a municipality pilot.

I wrote about how it happened:

Panagis Tzivras

Aug 18

I built a digital twin of a Greek island and it found a lighthouse no one asked about

#opensource #geospatial #postgressql #digitaltwin

5 min read

Coming next: Build Log #2. Why the model thinks Greek firs burn like pine (and why it is wrong).

Built in Kefalonia. Watching over the places we call home.

# Build Log #1: Processing my first Sentinel-2 pass in 48 hours

Panagis Tzivras — Wed, 19 Aug 2026 16:01:26 +0000

48 hours and moderate sleep later, ARGOS just processed its first Sentinel-2 pass over Kefalonia.

This is what that looks like.

What I was trying to do

I wanted a baseline vegetation map of the entire island. Not from a government PDF, not from a paid dataset- from the European Space Agency's Sentinel-2 satellite, freely available, updated every 5 days. The goal was simple: download the latest cloud-free acquisition, run it through a processing pipeline, and get an NDVI layer I could query against.

The stack

Python + rasterio + xarray for data handling
GDAL for reprojection (Sentinel-2 comes in UTM 34N, I need EPSG:4326 for the web map)
A very patient laptop

The problem

Sentinel-2 data is "free" the same way a 500-piece puzzle is "free"- every piece is there, but no one warned you about step seven. The SAFE format, the multiple granules, the 10m vs 20m resolution bands, the cloud masking- none of it is hard individually, but the pipeline has about twelve steps and step seven fails silently if you forget to resample the 20m bands before stacking.

I forgot. Twice.

The fix

A very ugly Python script that I am not proud of but that works. It downloads the granule, filters clouds, calculates NDVI, reprojects to WGS84, and drops a GeoTIFF into a folder that PostGIS will eventually ingest. The script is 180 lines. 40 of them are error handling. That's the honest ratio.

The honest part

The NDVI map looks beautiful. Green valleys, dry ridges, the whole island in false colour. But "beautiful" and "useful" are different things. I spent hour 36 staring at a perfectly rendered map and realising I had no idea whether an NDVI of 0.3 meant "stressed vegetation" or "just rocks." The satellite sees what it sees. Context comes from knowing the island.

What's next

Layer 2: wildfire risk index. Slope + aspect + NDVI + fuel type. The model will be wrong. It already thinks Greek firs burn like pine. But that's Build Log #2.

Links

This is Build Log #1 of the ARGOS series. Build Log #2: Why the model thinks Greek firs burn like pine (and why it's wrong).

I built a digital twin of a Greek island and it found a lighthouse no one asked about

Panagis Tzivras — Tue, 18 Aug 2026 18:10:48 +0000

I built a digital twin of a Greek island and it found a lighthouse no one asked about

One person, one laptop, zero budget, one island.

The problem

Kefalonia is the sixth-largest island in Greece, which sounds impressive until you try to answer a simple question: if a fire starts on that ridge, how long until the fire truck actually arrives?

I spent my summers on Kefalonia. It's the sixth-largest island in Greece, which sounds impressive until you realise what that means in practice: 254 km of coastline, three municipalities, one fire station with a volunteer watch, and exactly zero real-time flood monitoring. When the August fires hit Zakynthos 20 km away, the civil protection alert arrives by SMS. When the February 2025 storm washed out roads, the information travelled at the speed of someone driving to check.

I work in data. I know what Copernicus produces. I know what EFFIS tracks. I also know that none of it reaches the municipality inbox in a format anyone can use. The data is free. The gap is distribution.

So I started building the distribution layer.

What ARGOS is

ARGOS is an open-source digital twin of Kefalonia. One PostgreSQL/PostGIS database that holds the whole island: 12,217 road segments, 22,013 buildings, 1,831 POIs, 197 beaches, 29 trails, terrain from Copernicus DEM 30 m, vegetation from Sentinel-2, and two hazard layers that have already been tested against reality.

The stack is deliberately boring:

PostGIS 16 for the spatial engine (SQL I can write, no Java servers to maintain)
FastAPI for the API (/layers, /buffer, /intersect, /aggregate - all demo queries < 500 ms)
MapLibre GL + PMTiles for the map (9.4 MB single file, served from GitHub Pages, HTTP 206 range requests)
GitHub Codespaces for the dev environment (docker compose up -d, zero local setup)

Boring stacks ship. This one shipped in six weeks of Saturday mornings.

The map that argues back

The live map is at argos-geo.org/map. Click anything - a building, a beach, a road segment - and it answers. The popup tells you how many minutes that building is from the fire station and the nearest ferry port. Not as-the-crow-flies. As-the-ambulance-drives. Or doesn't drive, as the case may be.

The lighthouse problem

Here's my favourite edge case. The model ran its first accessibility analysis and found the hardest place to reach in an emergency. It wasn't a mountain village. It wasn't a remote beach. It was a single building with a travel time of 102 minutes.

That's a lighthouse. On an uninhabited islet. Built by the British in 1824, bombed by the Italians in 1942, flattened by the 1953 earthquakes. Accessible only by boat. No roads. No permanent population. The algorithm correctly flagged it as the most isolated structure in Kefalonia.

The model doesn't know what's "important" to humans. It just knows what's hard to reach. A bombed lighthouse and a hospital get the same accessibility score. Context comes later.

Oh, and - it's an island.

The algorithm knew that too. It just didn't think it was worth mentioning.

The hazard layers (or: why I don't trust my own model yet)

ARGOS WATCH: Wildfire Risk v1.1

Five-factor weighted index: slope, fuel proxy (NDVI), road proximity, aspect, and historical burn scars from EFFIS. Validated against 24 real fire perimeters (2017-2026). Burned areas score 63.6 vs the island baseline of 59.1. Very-high-risk enrichment is ~3.7×.

But here's the honest part: the model thinks Greek fir (Abies cephalonica) burns like Mediterranean pine. It doesn't. Different fuel load, different crown fire behaviour, different moisture retention. The satellite sees NDVI = 0.6 and says "green = fuel." The local says "fir = doesn't crown-fire like pine." Build Log #2 is about exactly this failure.

ARGOS WATCH: Flash-Flood / Debris-Flow v1

D8 drainage network × receiving slope × upstream burn-scar exposure. Validated against the February 2025 storm. The model's top-ranked ravines: Τραπεζάκι 97.5, Πόρος 96.9, Περατάτα 94.6. Those names match the news reports. The model ranked reality correctly.

Both layers are screening baselines, not forecasts. Directionally validated, not calibrated. I say this explicitly because credibility comes from admitting limitations, not hiding them.

The architecture

Every pipeline step is a numbered, committed script in scripts/. Every model has an open methodology document with an honest limitations section. The whole stack runs in a GitHub Codespace. The whole thing costs €0/month to host.

The code is MIT. The derived layers are CC BY 4.0. The sources are all open: OpenStreetMap, Copernicus DEM, Sentinel-2, NASA FIRMS, EFFIS. Attribution is architecture, not decoration.

The three sub-brands

ARGOS GEO - the twin itself: data, pipelines, API, map
ARGOS WATCH - hazard intelligence: wildfire + flash-flood screening, validated in the open
ARGOS COMMONS - whatever this grows into next, with the people who gather around it

What's next

v0.0.1 is a static twin: snapshots, not streams. Phase 2 adds real-time feeds (Open-Meteo weather, ADS-B aircraft, EFFIS/Copernicus EMS alerts), a 7-day hazard outlook, and historical playback. Phase 3 is a municipality pilot: three months, no cost, they provide feedback.

The long-term goal isn't to replace civil protection. It's to give them a layer they don't have: local granularity on top of satellite data. EFFIS shows Greece burns ~50,000 hectares annually. ARGOS is trying to answer which 16 km² of Kefalonia burn first.

Links

🗺️ Live map: argos-geo.org/map
🐙 GitHub: github.com/argos-geo/kefalonia-digital-twin
🌐 Website: argos-geo.org
📧 Email: hello@argos-geo.org
🦋 Bluesky: @argos-geo.org
🐘 Mastodon: @argos_geo@mapstodon.space
🐦 X: @argos_geo

Built in Kefalonia. Watching over the places we call home.

If you know Mediterranean fuel models, Greek forestry data, or municipal civil protection workflows, I need you. Drop a comment or email hello@argos-geo.org.

This is Build Log #0 - the debut. Build Log #1 (Sentinel-2 processing and the crime scene Python script) is already live and a few days old, which in internet years makes it practically vintage. Build Logs #2-10 are coming: the Greek fir problem, drainage mapping, the Vardiani lighthouse, stack decisions, containerisation, the Copernicus → inbox gap, API-first architecture, hosting on Cloudflare Pages, and what "building in public" actually means when your model is wrong.