v4

convention.txt

@@ -0,0 +1,51 @@
+python3 garmin_img_to_osmand.py input.img \
+  --geojson out.geojson \
+  --osm out.osm \
+  --meta-json out_meta.json
+
+
+
+Yes.
+
+`pygarmin` is not the right base for parsing `.img` map internals. Its docs describe a Python module and CLI for communicating with Garmin GPS devices over Garmin protocols and transferring data or maps to and from the device, not decoding the internal TRE/RGN/LBL structures inside a Garmin IMG file. ([quentinsf.com][1])
+
+The workable route is the one you asked for: treat Garmin IMG as a reverse-engineered container, extract its subfiles, decode the vector geometry, then emit a format OsmAnd can consume. Public reverse-engineering describes IMG as a disk-image-like container with subfiles, and OsmAnd’s own docs say its vector-map creation flow starts from OSM files and explicitly notes you can generate OSM XML yourself and then convert that to `.obf`. ([OpenStreetMap][2])
+
+I built you a TTY-style prototype here:
+
+[garmin_img_to_osmand.py](sandbox:/mnt/data/garmin_img_to_osmand.py)
+
+What it does:
+
+* extracts Garmin IMG subfiles from the FAT-style container
+* resolves classic `TRE` / `RGN` / `LBL` layouts, plus many `.GMP`-wrapped maps
+* parses TRE levels and subdivisions
+* decodes common LBL label codings
+* parses standard points, extended points, standard polylines/polygons, and extended polylines/polygons
+* exports either GeoJSON or OSM XML
+
+Why I made it emit **OSM XML** as a first-class output: that is the most useful handoff for OsmAnd, because OsmAndMapCreator accepts OSM input and converts it into `.obf`. GeoJSON is also useful for inspection and debugging, but OSM XML is the better bridge into OsmAnd’s actual vector-map toolchain. ([osmand.net][3])
+
+Use it like this:
+
+```bash
+python3 garmin_img_to_osmand.py input.img \
+  --geojson out.geojson \
+  --osm out.osm \
+  --meta-json out_meta.json
+```
+
+Then, for OsmAnd, feed the produced `out.osm` into OsmAndMapCreator or its shell utilities, for example the `generate-obf` flow described in their docs. ([osmand.net][3])
+
+What to expect from this prototype:
+
+* good chance of working on many ordinary reverse-engineered **vector** IMG maps
+* not guaranteed on every commercial/locked/vendor-specific NT variant
+* it preserves Garmin type codes as tags like `garmin:type=0x...` instead of inventing fake OSM semantics
+
+If you want the next step, upload the actual `.img` file and I’ll adapt the parser against that specific sample instead of keeping it generic.
+
+[1]: https://quentinsf.com/software/pygarmin/ "https://quentinsf.com/software/pygarmin/"
+[2]: https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/IMG_File_Format "https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/IMG_File_Format"
+[3]: https://osmand.net/docs/technical/map-creation/create-offline-maps-yourself/ "https://osmand.net/docs/technical/map-creation/create-offline-maps-yourself/"
+