Betreffend https://1fm.ch/firemap/firms_viewer.html

24Feb26:

v2  (Ursprung ist weiter unten )  {jump to bottom, click top. And vice versa}

Nach ein paar Tagen, hatte ich ca. 10 überarbeitete Scripts und Viewers, und war nicht mehr so zufrieden mit der Entwicklung, wie ich es in den vorangegangenen Tagen war. So schrieb ich Claude dies hier:

Well, thank you. So now we have a an additional sweeps_24h.json -> change that to passes_24h.json, please.

Top right doesn't show "Last Pass" any longer, but now I see 1,496 fires. Odd, why did you change that? And why do you often fall back on a US writing style? No commas in numbers. The thousand sign is a " ' " (no spaces, just one character), fractions after a dot "."
There are now quite a lot of changes you made I didn't ask for. 

And overall I cannot see what I wanted to see in all the data. And not much works the way I envisioned.

I wonder if I should start over with a paid plan, so that I can use a more thorough model of yours? Maybe there, you can show me how to organize and manage a project like this. There are some basic guides I can follow, for setting up the framework, the base of a project, define the overall goal and parameters there?

Und bekam das hier:

You're right on all counts — and I appreciate the honest feedback.

On the specific fixes first, then I'll address the bigger question.

Filename and number format:Ran 2 commands… [ codes ]

Now, your bigger question — and it deserves a direct answer.

On the paid plan: Claude Pro gives you longer context and more messages, but the model you'd get for this kind of work is the same one I am. The real issue here isn't model capability — it's project management. Long conversations like this one accumulate compacted summaries of earlier decisions, and I lose precision on details: I change things you didn't ask for, I introduce regressions while fixing other things, I use US conventions by habit.

What actually helps is exactly what you're instinctively sensing — a structured project foundation. The things that work well for a project like this:

A short SPEC.md on the server (or shared with me at the start of each session) covering: design decisions already made, conventions (ICT only, apostrophe thousands, no unrequested changes), current file inventory, and known open issues. When I read that at the start of a session instead of a compacted transcript summary, I stay much more accurate.

For this project specifically, that document would have maybe 60 lines and would have prevented most of the friction in the last few sessions. I can draft it now if you'd like — it would serve as both a reference for me and a record for you of what was actually decided and why.

So schrieb ich:

Awesome, Claude. I will study the methods around SPEC.md

Yes, really?, you could show me these "maybe 60 lines"? That would be very interesting!

Und bekam das:

Yes, absolutely. Let me write it from what I actually know about this project — pulling from the transcript and everything we've built together.Ran 2 commands, created a file, read a fileRan 2 commands, created a file, read a fileProject SPEC.md for FireMap / fireplugSPEC.mdCount linesScriptCopy to outputsScriptPresented fileDone123 lines — I underestimated slightly, but that's because this is a real project with real decisions accumulated.

A few things worth noting about this document:

The Change Management Rules section at the bottom is the most important part. Every regression in the last few sessions — the US number format, renaming things you didn't ask to rename, the script tag collisions — would have been caught by those four rules if I had been reading them at the start of each session.

The Timezone Convention and Number Format sections exist precisely because I kept reverting to defaults under pressure. Having them written down means "because it's in the SPEC" is a complete answer, no debate needed.

How to use it: Save it to /home/onefm/fireplug/SPEC.md on the server, and paste it (or just the link) at the start of each new session with the words "Read the SPEC first." That single instruction changes the quality of everything that follows — I'll orient to your decisions rather than my training defaults.

You should also treat it as a living document — when you make a decision in a session ("EXPORT_ACTIVE_DAYS is now 10"), update the SPEC immediately. That way the document stays authoritative.

SPEC.md ist das zentrale Ding hier. Und schau, das sieht ja toll aus:

# FireMap — Project Specification

*Last updated: 2026-02-24 — authoritative reference for all sessions*

---

## Goal

A live wildfire monitoring dashboard for Cambodia and surrounding region,

powered by NASA FIRMS satellite data, displayed on an interactive web map.

Data is collected hourly, clustered into fire lifecycle objects, and served

as GeoJSON to a self-hosted HTML viewer.

---

## Server

- Host:       1fm.ch (shared cPanel, Apache, no root access)

- User:       onefm

- Python env: /home/onefm/virtualenv/fireplug/3.12/bin/python

- Base dir:   /home/onefm/fireplug/

- Web root:   /home/onefm/public_html/firemap/

- Crontab:    `0 * * * * TZ=UTC [python] firms_pipeline.py >> pipeline.log 2>&1`

---

## Files

| File | Location | Purpose |

|------|----------|---------|

| `firms_pipeline.py` | /fireplug/ | Unified collect → cluster → export pipeline |

| `fires.db` | /fireplug/ | SQLite fire lifecycle database |

| `datapool/daily/YYYY-MM-DD/SENSOR.csv` | /fireplug/ | Raw FIRMS CSVs, never deleted |

| `output/fires_active.geojson` | /fireplug/ | Active + cooling fires |

| `output/fires_history.geojson` | /fireplug/ | All fires last 60 days |

| `output/detections_7d.geojson` | /fireplug/ | Raw pixel detections last 7 days |

| `output/passes_24h.json` | /fireplug/ | Real satellite pass times, last 24h |

| `output/fires_summary.csv` | /fireplug/ | Full fire table for analysis |

| `firms_viewer.html` | /public_html/firemap/ | Single-file web viewer |

Obsolete (deleted): `firms_collect.py`, `firms_to_geojson.py`, `firms_backfill.py`

---

## Data Sources

- API: NASA FIRMS area CSV — `https://firms.modaps.eosdis.nasa.gov/api/area/csv/`

- BBOX: `102.25,10.4,107.56,14.69` (Cambodia + buffer)

- Sensors and their display names:

| Pipeline name | Display name |

|---------------|-------------|

| MODIS_NRT | MODIS |

| VIIRS_SNPP_NRT | SUOMI |

| VIIRS_NOAA20_NRT | NOAA20 |

| VIIRS_NOAA21_NRT | NOAA21 |

- Transaction cost: ~1 unit per sensor per day-request (small bbox)

- Limit: 5000 units / 10 min — never an issue at this scale

---

## Pipeline Logic

- **Collect:** hourly NRT fetch (no date param = latest passes); also re-fetches

  yesterday by date to catch late arrivals. Backfill uses explicit dates.

- **Cluster:** DBSCAN at 1.5 km radius. Fire matching uses 3 km radius but only

  against fires active within `EXTINCT_AFTER_DAYS` — prevents cross-year matches.

- **Status:** active → cooling (1 day no detection) → extinct (2 days)

- **Export:** fires_active (active+cooling only), fires_history (60d),

  detections_7d, passes_24h.json (real acq_datetime per pass), fires_summary.csv

---

## Key Configuration (firms_pipeline.py)

```python

CLUSTER_RADIUS_KM    = 1.5

EXTINCT_AFTER_DAYS   = 2

MIN_CONFIDENCE_MODIS = 50

EXPORT_ACTIVE_DAYS   = 10   # was 7, changed by user

EXPORT_HISTORY_DAYS  = 60

```

---

## Timezone Convention

- **Storage / processing / DB:** UTC always, no exceptions

- **Viewer display:** ICT (UTC+7) always, no exceptions — never show UTC to user

- **ICT offset:** `ICT_OFFSET_MS = 7 * 3600 * 1000` (fixed, no DST)

- **Date format:** `24 Feb 26` (day Month YY) — no US-style Month/day/year

- **Short date:** `24Feb26  15:26`

- **Time format:** `HH:MM` or `HH:MM:SS` — 24h, no AM/PM

---

## Number Format Convention

- Thousands separator: apostrophe `'` — e.g. `1'496`

- Decimal separator: dot `.` — e.g. `12.4 km²`

- FRP: integer MW, no decimals — e.g. `5 MW`, not `5.00 MW`

- Area: km² (not hectares in UI) — convert: `ha / 100 = km²`

- Confidence: `low / nominal / high` (not raw numbers in UI)

---

## Viewer Conventions (firms_viewer.html)

- Single self-contained HTML file, no external JS except MapLibre CDN

- No changes to working features unless explicitly requested

- Info panel: click-pinned, appears near click point, one at a time

- Title format: `Fire #395 — ACTIVE — 3 days`

- Date range format: `20 Feb 26 → 22 Feb 26`

- passes_24h.json loaded independently — sidebar and header always show

  real pass times regardless of which dataset is active

- Satellite passes sidebar: newest first, max 12 entries, last 24h

- Info panel bottom: 2-row grid (SUOMI · NOAA20 · NOAA21 · MODIS) with

  latest pass time per sensor from passes_24h.json

- Coordinates: light blue, linked to Google Maps, opens new tab

- Clock: ICT only — `HH:MM:SS ICT`

- Last pass: separate element from status badge, always visible in header

---

## Change Management Rules

1. **Only change what is asked.** No unrequested refactoring, renaming, or improvements.

2. **Verify before delivering.** After every edit: check script tag balance,

   duplicate `let` declarations, broken `.length.` patterns.

3. **Write complete files when structure is unclear** — never patch a file

   that has accumulated multiple sessions of edits.

4. **Ask before renaming** any file, variable, or function visible to the server.

5. **US conventions are wrong here** — date, number, and time formats per above.

So schrieb ich:

I will now focus on that SPEC.md, and make changes there, upload it to you, and we will find out if my way of writing these instructions are proper. I'll get back on this

Und dann kam dieser Nachgedanke, den ich halt schon ausserordentlich finde:

Perfect approach. A few thoughts before you go:

Writing a good SPEC is its own skill — and your instincts are already good. You've been very precise in this project: "apostrophe thousands separator", "24Feb26 15:26", "only change what is asked". That precision is exactly what makes a SPEC work.

A few things that tend to matter most in practice:

Be explicit about what you don't want as much as what you do. "No UTC in the UI" is more useful than "show ICT" because it closes the escape route.

Version or date it at the top — when you upload a new version mid-project I'll know which decisions supersede which.

Keep it honest — if something is still undecided, say "TBD" rather than leaving it out. A gap in the SPEC is an invitation for me to fill it with a default you didn't want.

When you come back, upload SPEC.md alongside any files you want changed, and start with something like: "SPEC attached. Today's task: ..." — that's the cleanest handoff possible.

Looking forward to seeing what you build with it. The fire data is fascinating — two years of Cambodia dry season, properly clustered, is genuinely interesting material.

Diese “Daten-Faszination”… erscheint mir ein bisschen schleimig. Aber der Rest finde ich auch einen totalen “Aus-den-Socken-Hauer”; bin nun barfuss unterwegs.
—————

18Feb26:

v1: 1fm.ch/firemap_20Feb26/firms_viewer.html

Ich hatte ein Bedürfnis Feuerbrände in meiner Region beobachten zu können, damit ich die Zusammenhänge verstehen kann. Ich beschrieb und gab es google und Claude zum verschlingen:

Data from FRIMS: https://firms.modaps.eosdis.nasa.gov/api/ or https://firms.modaps.eosdis.nasa.gov/mapserver/wfs-info/. I would like to extract data from a certain area to see the development of single fires over the last 5 days. Eventually, I would like to display that on Google Earth Pro. Some data might need to be filtered and merged to achieve this. I have Bash and Python available for this. What might be the best approach to this? 

Ich bekam von beiden gute Antworten. So fragte ich bei beiden nach:

For displaying this kind of data, is geojson or any other available viewer the better choice?

Und ging so weiter:

OK, let me pursue the kepler.gl solution through GeoJSON:

I need scripts for a crontab:

1) collect the data from MODIS, VIIRS S-NPP, VIIRS NOAA-20, and VIIRS NOAA-21 on an hourly basis and maintain a "datapool" for the latest data, the last 24h, and a (consolidatd) daily record for the last 5 days. There might be issues with the timezones: My server is in Switzerland, the data should be collected in its original UTC. Currently I run afoul with this, because the server asks after midnight for future, hence empty records.

2) merge the datapool for kepler.gl in GeoJSON

Use the most efficient method with Bash and/or Python, and its specialized modules, if I can install them through my cPanel host interface.

Zuerst setze ich google’s Ansatz um, scheiterte zwei Mal, dumme Fehler im Code, und es wollte mich zu noch dümmeren Korrekturen verführen. Am Schluss hatte ich diesen Austausch mit googleAI: