MyZubster: Building an Open Ecosystem That Connects Software, Maps and the Physical World

MyZubster is evolving.

What started as a software project is becoming something broader: an open ecosystem where code, geographic data, photographs, documentation and real-world observations can be connected and versioned together.

The current direction is simple to describe:

observe something in the real world, document it, structure the data, version it, and make it publicly inspectable.

We are starting from Rimini, Italy, but the model is designed to be reusable elsewhere.

From software to a real-world data layer

The current workflow looks like this:

text
real-world observation
        ↓
photograph
        ↓
GPS coordinates
        ↓
structured metadata
        ↓
GeoJSON
        ↓
Git
        ↓
GitHub
        ↓
map / gallery / public page
This means a street, a public square, a fountain, a plant, a civic building or even a cloud observation can become a structured digital record.

Real observations already added

Recent work includes photographic and geographic documentation for:

Piazza Ferrari
Via Clodia
Futura Ambiente
Comune di Rimini / Palazzo Garampi
Fontana della Pigna
a garden with botanical observations
papyrus
banana plant
bay laurel
plum tree
sky and cloud observations

The important part is not only storing the photo.

Each observation can be connected to:

a stable ID
GPS coordinates
a category
a capture date
a media file
a GitHub record
a map reference
structured metadata
GeoJSON as the geographic layer

MyZubster uses GeoJSON to structure geographic observations.

For example:

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [
      12.5661150,
      44.0609273
    ]
  },
  "properties": {
    "id": "rimini-fontana-della-pigna-001",
    "name": "Fontana della Pigna",
    "city": "Rimini",
    "category": "landmark",
    "image": "/media/rimini/landmarks/fontana-della-pigna/fontana-della-pigna-001.jpg"
  }
}

GeoJSON stores coordinates in:

longitude, latitude

while human-readable interfaces can display:

latitude, longitude
A structured photographic archive

The media archive is organized by subject and location instead of storing everything in one folder.

Example:

public/media/
├── rimini/
│   ├── civic/
│   ├── gardens/
│   │   └── garden-001/
│   │       └── plants/
│   │           ├── alloro/
│   │           ├── banano/
│   │           ├── papiro/
│   │           └── susino/
│   ├── landmarks/
│   ├── services/
│   ├── sky/
│   ├── squares/
│   └── streets/
│
└── ecosystem/
    └── repository-visualizations/

This separates real-world photographic evidence from project architecture media.

A public photo archive

A public page has also been created to make the photographic material easier to explore.

Instead of requiring someone to manually browse GitHub folders, the archive can present photographs grouped by category.

The idea is to make navigation follow this pattern:

gallery
   ↓
photo
   ↓
observation
   ↓
map
   ↓
repository
Visualizing the software ecosystem

We also added three architecture visualizations describing the MyZubster ecosystem.

They explore the project from different perspectives:

high-level repository overview
technical architecture
repository responsibilities
CI/CD concepts
infrastructure
visual storytelling

The third visualization is currently being used as the primary visual blueprint.

These diagrams are not treated as unquestionable truth.

They are architectural references that must be compared with the repositories that actually exist and the systems that are actually running.

That distinction matters.

Software and physical-world data under the same model

A useful pattern is starting to emerge.

For software, we want to know:

repository
→ responsibility
→ architecture
→ dependencies
→ deployment
→ documentation
→ version history

For a real-world observation:

object
→ photo
→ coordinates
→ metadata
→ category
→ provenance
→ version history

Both are structured records.

Both can evolve.

Both can be inspected through Git.

Repository governance

As the ecosystem grows, organization becomes as important as code.

The project now includes documented rules for:

repository responsibilities
project status
commit naming
branch usage
media organization
data structure
backups
privacy
deployment separation

Repository states can include:

ACTIVE
EXPERIMENTAL
MAINTENANCE
DEPRECATED
ARCHIVED

The goal is to prevent an ecosystem of many repositories from becoming impossible to understand over time.

VPS is not the archive

Another important principle is separation of responsibilities.

PC
→ working files and temporary photo inbox


GitHub
→ source code, public datasets and selected public media


VPS
→ production deployment


Backup storage
→ server backups and recovery archives

The production directory should not become a permanent dumping ground for backups and temporary files.

Building from Rimini outward

Rimini is the starting point.

The project is being built through real observations before trying to scale globally.

That gives us a chance to test:

naming conventions
GPS handling
photo workflows
metadata schemas
privacy rules
repository organization
map interfaces
contribution processes

If those foundations work locally, the same structure can later be reused by contributors in other cities.

AI as an assistant, not the evidence

AI can help with:

plant identification
metadata generation
categorization
duplicate detection
search
validation
documentation

But the photograph, source record and geographic observation remain the primary evidence.

This distinction is important for provenance and trust.

What we are building toward

The longer-term architecture can be imagined as:

MYZUBSTER
│
├── SOFTWARE ECOSYSTEM
│   ├── Gateway
│   ├── App
│   ├── Marketplace
│   ├── Robot
│   ├── Backend
│   ├── Frontend
│   ├── Payments
│   ├── Tari
│   └── Docs
│
├── REAL-WORLD DATA
│   ├── Places
│   ├── Streets
│   ├── Civic
│   ├── Landmarks
│   ├── Gardens
│   ├── Plants
│   ├── Environment
│   └── Sky
│
├── DATA LAYER
│   ├── GeoJSON
│   ├── Metadata
│   ├── GPS
│   └── Media
│
└── VISUAL LAYER
    ├── Repository Dashboard
    ├── Map
    ├── Photo Gallery
    ├── Observation Pages
    └── Architecture Visualizations

Not every part of this diagram is complete.

It is a direction.

The implementation is growing incrementally through actual commits, files, observations and public documentation.

Why build this in public?

Because version history matters.

A photograph can change from an isolated file into a structured observation.

A city location can gain metadata.

A repository can change responsibility.

A map can evolve.

Git allows those changes to remain inspectable.

That is one of the core ideas behind MyZubster:

build a system where both software and observations of the physical world can be documented, organized and evolved transparently.

Follow the project

GitHub:

https://github.com/MyZubster-Ecosystem/myzubster

The project currently contains:

source code
GeoJSON observations
photographic records
repository governance
observation workflow documentation
public visualizations
architecture diagrams

MyZubster is still evolving.

And that is exactly what the repository is meant to show.

MyZubster — observe, structure, version and connect.