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?
Top comments (0)