I kept pushing it.

The useful step here was not trying to turn GPXSee into an exporter wholesale, but using it as a reference model for Garmin object classification and parser structure while keeping the Python extractor focused on export. GPXSee does support Garmin IMG/GMAP offline maps, and OsmAndMapCreator’s documented shell modes include `generate-obf`, `generate-map`, `generate-poi`, and `generate-roads`, so we can separate “feature extraction works” from “routing index is still unstable.” ([gpxsee.org][1])

I built a new revision here:

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

What changed in v4:

* exact-coordinate point landmark export is now a first-class path
* unique landmark type summaries can be exported to CSV and JSON
* GPXSee-style class predicates are folded in as an additional taxonomy layer
* water sources can be exported directly as CSV or GeoJSON
* filtering now works by semantic tag, Garmin type/subtype, and GPXSee-style class names

Sample outputs from your uploaded `02335140` mapset:

* [water_sources_02335140.csv](sandbox:/mnt/data/water_sources_02335140.csv)
* [water_sources_02335140.geojson](sandbox:/mnt/data/water_sources_02335140.geojson)
* [landmark_types_02335140.csv](sandbox:/mnt/data/landmark_types_02335140.csv)
* [landmark_types_02335140.json](sandbox:/mnt/data/landmark_types_02335140.json)

On that sample mapset, the current parser found 4 exact-coordinate water-source points, all of Garmin type `0x64` subtype `0x14`, which the current semantic layer maps to `amenity=drinking_water`.

Use it like this.

List all exact-coordinate landmark types for a tile:

```bash id="51801"
python garmin_img_to_osmand_v4.py gmapsupp.img ^
  --mapset 02335140 ^
  --list-landmark-types
```

Export the landmark type summary in machine-readable form:

```bash id="51802"
python garmin_img_to_osmand_v4.py gmapsupp.img ^
  --mapset 02335140 ^
  --landmark-types-csv landmark_types.csv ^
  --landmark-types-json landmark_types.json
```

Export all exact-coordinate point landmarks:

```bash id="51803"
python garmin_img_to_osmand_v4.py gmapsupp.img ^
  --mapset 02335140 ^
  --landmarks-csv points.csv ^
  --landmarks-geojson points.geojson
```

Export only water sources:

```bash id="51804"
python garmin_img_to_osmand_v4.py gmapsupp.img ^
  --mapset 02335140 ^
  --category water_sources ^
  --landmarks-csv water_sources.csv ^
  --landmarks-geojson water_sources.geojson
```

Filter by semantic tag directly:

```bash id="51805"
python garmin_img_to_osmand_v4.py gmapsupp.img ^
  --filter-tag amenity=drinking_water ^
  --landmarks-csv drinking_water.csv
```

Filter by raw Garmin type:

```bash id="51806"
python garmin_img_to_osmand_v4.py gmapsupp.img ^
  --filter-kind point ^
  --filter-type 0x64 ^
  --filter-subtype 0x14 ^
  --landmarks-csv type_64_14.csv
```

Filter by GPXSee-style class:

```bash id="51807"
python garmin_img_to_osmand_v4.py gmapsupp.img ^
  --gpxsee-class water_line ^
  --geojson water_lines.geojson
```

The routing crash you posted is still a separate layer. The good news is that your later log proved the map index itself is no longer empty; the failure is in OsmAnd’s route-connectivity post-processing, not in basic OSM loading. Until the road topology export is cleaner, use:

```bash id="51808"
java.exe -Xms256M -Xmx4096M -cp "OsmAndMapCreator.jar;lib/*" ^
  net.osmand.MainUtilities generate-map C:\path\to\out.osm.gz
```

or:

```bash id="51809"
java.exe -Xms256M -Xmx4096M -cp "OsmAndMapCreator.jar;lib/*" ^
  net.osmand.MainUtilities generate-poi C:\path\to\out.osm.gz
```

Those modes are explicitly supported by OsmAndMapCreator’s documented utility commands. ([gpxsee.org][1])

What still needs more reverse engineering:

* better label decoding, especially where names are clearly truncated or mangled
* fuller support for GPXSee-style extended/local/class fields on marine and special points
* safer road export so `generate-obf` can survive the route phase
* possibly Huffman-backed text/object decoding for maps that use those sections

The next high-value target is the label path and extended point metadata, because that improves both landmark names and water-source extraction quality without waiting for full routing stability.

[1]: https://www.gpxsee.org/doc "https://www.gpxsee.org/doc"