garmin-img-format-parsing/stage-2-parse-stage-1/readme.md

Updated script:
[landmarks_stage2_configurable_v4.py](sandbox:/mnt/data/landmarks_stage2_configurable_v4.py)

What’s added:

* `edit-config` now supports:

  * `--run-cmd-before-eval`
  * `--run-cmd-zoom`
* global default postprocess tags:

  * `analyze --default-postprocess-tag key=value`
  * `edit-config --default-postprocess-tag key=value`
* interactive group review now has a preview loop:

  * `Enter` / `e` = edit current group
  * `n` = next example
  * `p` = previous example
  * `o` = run external visualizer again on current example
  * `s` = skip group
  * `!` = stop editing
* global `defaults.postprocess` is stored in the same config file and applied to all groups during build, then group-specific postprocess overrides it

Important placeholder support for `--run-cmd-before-eval`:

* `{lat}`
* `{lon}`
* `{z}`
* `{mapset}`
* `{group_id}`
* `{group_label}`
* `{raw_type}`
* `{name}`

So your GPXSee command can be written like this:

```bash
python landmarks_stage2_configurable_v4.py edit-config ^
  --config stage2_config.json ^
  --run-cmd-before-eval ".\GPXSee.exe D:\maps-bg\gmapsupp\gmapsupp.img \"geo:{lat},{lon};z={z}\"" ^
  --run-cmd-zoom 19
```

If you want every detected group to get a visible fallback tag by default:

```bash
python landmarks_stage2_configurable_v4.py analyze export-v7-00235051.csv ^
  --config-out stage2_config.json ^
  --default-postprocess-tag tourism=attraction
```

or while editing an existing config:

```bash
python landmarks_stage2_configurable_v4.py edit-config ^
  --config stage2_config.json ^
  --default-postprocess-tag tourism=attraction ^
  --run-cmd-before-eval ".\GPXSee.exe D:\maps-bg\gmapsupp\gmapsupp.img \"geo:{lat},{lon};z={z}\""
```

Then build as usual:

```bash
python landmarks_stage2_configurable_v4.py build export-v7-00235051.csv ^
  --config stage2_config.json ^
  --osm resolved.osm ^
  --gpx resolved.gpx ^
  --resolved-csv resolved.csv
```

I also verified the non-interactive path:

* `analyze` runs successfully
* default global postprocess tags are written into the generated config

One important detail:

* the global default postprocess is now stored under:

  * `defaults.postprocess.add_tags`
  * `defaults.postprocess.remove_tags`
* build applies those to **all groups**, then applies group-local `postprocess`

That gives you exactly the pattern you asked for:

* visualize example
* inspect the symbol in GPXSee
* decide naming / icon / tags
* move to next example in the same group
* keep everything in the same config file

The next strong upgrade would be adding a dedicated `--run-cmd-before-eval-on-enter/--no-auto-open` toggle, so you can choose whether each group auto-opens the first example or only opens when you press `o`.

Implemented it in stage 2.

Download the upgraded script here:

[landmarks_csv_to_osmand_google_earth.py](sandbox:/mnt/data/landmarks_csv_to_osmand_google_earth.py)

I added Google Earth output on top of the existing stage-2 config workflow. Stage 1 already exports the needed `point_group_key`, raw Garmin type, semantic JSON, image metadata, and coordinates into CSV, so stage 2 can reuse that directly.  The existing stage-2 logic already resolves records through the config, applying group assignment, naming, style, postprocess tags, and stable hashes, so I hooked Google Earth export after that same resolved-record stage. 

New outputs:

```bash
--kml output.kml
--kmz output.kmz
--kml-split-dir google-earth-kml-groups
--kmz-split-dir google-earth-kmz-groups
```

Each KML/KMZ contains:

* one Google Earth **Folder per configured group**
* toggleable components in the Google Earth sidebar
* per-group KML styles generated from your config color/icon
* point name from your stage-2 naming logic
* description table with Garmin/source/hash/config metadata
* `ExtendedData` for machine-readable properties

Example build:

```bash
python landmarks_csv_to_osmand_google_earth.py build parsed-landmarks/csv/*.csv --config stage2_config.json --kml bgmountains_landmarks.kml --kmz bgmountains_landmarks.kmz --resolved-csv resolved.csv --summary-json build_summary.json
```

For large datasets, use this instead:

```bash
python landmarks_csv_to_osmand_google_earth.py build parsed-landmarks/csv/*.csv  --config stage2_config.json  --kmz-split-dir google-earth-groups --kml-folder-visibility 0  --kml-label-scale 0
```

That creates one `.kmz` per group plus:

```text
manifest.json
```

This is better for Google Earth when you have tens of thousands of points, because you can load only the group you are inspecting.

Useful options added:

```bash
--kml-folder-visibility 0
```

Starts all folders hidden, so you enable groups manually in Google Earth.

```bash
--kml-folder-open 0
```

Keeps folders collapsed.

```bash
--kml-label-scale 0
```

Hides always-on labels. This is the default because 100k labels will destroy usability.

```bash
--kml-label-scale 0.7
```

Shows labels if you want them.

```bash
--kml-no-extended-data
```

Makes smaller KML/KMZ files by removing the full property dump.

The KML export uses the same config-controlled naming/postprocessing path as your existing OSM/GPX generation. The previous stage-2 build command already supported OSM, GPX, resolved CSV, and unmatched CSV outputs; I added KML/KMZ into that same build output branch.