garmin-img-format-parsing/stage-1-read-garmin-img/readme.md

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)

I built a new revision here:

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
• water_sources_02335140.geojson
• landmark_types_02335140.csv
• 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:

python garmin_img_to_osmand_v4.py gmapsupp.img ^
  --mapset 02335140 ^
  --list-landmark-types

Export the landmark type summary in machine-readable form:

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:

python garmin_img_to_osmand_v4.py gmapsupp.img ^
  --mapset 02335140 ^
  --landmarks-csv points.csv ^
  --landmarks-geojson points.geojson

Export only water sources:

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:

python garmin_img_to_osmand_v4.py gmapsupp.img ^
  --filter-tag amenity=drinking_water ^
  --landmarks-csv drinking_water.csv

Filter by raw Garmin type:

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:

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:

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

or:

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)

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.