v.4.0.4
This commit is contained in:
+1
-1
@@ -2829,7 +2829,7 @@
|
|||||||
},
|
},
|
||||||
{
|
{
|
||||||
"cell_type": "code",
|
"cell_type": "code",
|
||||||
"execution_count": null,
|
"execution_count": 16,
|
||||||
"id": "1080c073",
|
"id": "1080c073",
|
||||||
"metadata": {},
|
"metadata": {},
|
||||||
"outputs": [
|
"outputs": [
|
||||||
|
|||||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
-9361
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,115 @@
|
|||||||
|
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"
|
||||||
@@ -0,0 +1,122 @@
|
|||||||
|
You have **two good OsmAnd targets** now.
|
||||||
|
|
||||||
|
The fast, practical one is **GPX waypoint overlay**. OsmAnd supports GPX import, waypoint icons/colors, and **waypoint grouping** through OsmAnd-specific GPX extensions, so this is the closest match to a toggleable landmark layer without fighting the full map compiler. Favorites are also stored/imported as GPX waypoints, which confirms GPX is a native path for point overlays. ([OsmAnd][1])
|
||||||
|
|
||||||
|
The more native/searchable one is **POI-only OBF**. OsmAndMapCreator officially supports `generate-poi` separately from `generate-obf`, and it accepts OSM-family input such as `.osm`, `.osm.gz`, `.osm.bz2`, and `.pbf`. That makes it the right target when you want searchable/filterable POIs but do **not** want the routing stage that is currently crashing. ([OsmAnd][2])
|
||||||
|
|
||||||
|
I packaged both paths into a converter:
|
||||||
|
|
||||||
|
[landmarks_csv_to_osmand.py](sandbox:/mnt/data/landmarks_csv_to_osmand.py)
|
||||||
|
|
||||||
|
Sample outputs:
|
||||||
|
|
||||||
|
* [sample GPX overlay](sandbox:/mnt/data/water_sources_02335140.gpx)
|
||||||
|
* [sample OSM for POI build](sandbox:/mnt/data/water_sources_02335140.osm)
|
||||||
|
|
||||||
|
### What I recommend
|
||||||
|
|
||||||
|
For a “BGMountains-like thing I can switch on and off,” use **GPX overlays** first.
|
||||||
|
For a “native searchable POI pack,” use **POI-only OBF** second.
|
||||||
|
|
||||||
|
### Path 1: GPX overlay layer
|
||||||
|
|
||||||
|
This is the quickest route.
|
||||||
|
|
||||||
|
It converts your landmark CSVs into a GPX file with:
|
||||||
|
|
||||||
|
* one waypoint per landmark
|
||||||
|
* grouped categories using `<type>`
|
||||||
|
* OsmAnd waypoint group styling via `osmand:points_groups`
|
||||||
|
* icons/colors per category
|
||||||
|
|
||||||
|
Build it like this:
|
||||||
|
|
||||||
|
```bash id="14483"
|
||||||
|
python landmarks_csv_to_osmand.py *.csv --gpx bg_landmarks.gpx --group-by category
|
||||||
|
```
|
||||||
|
|
||||||
|
For just water sources:
|
||||||
|
|
||||||
|
```bash id="52386"
|
||||||
|
python landmarks_csv_to_osmand.py *.csv --category water_sources --gpx bg_water_sources.gpx
|
||||||
|
```
|
||||||
|
|
||||||
|
Then import that GPX into OsmAnd. GPX waypoints and waypoint groups are supported officially, including icon/color/background customization. ([OsmAnd][1])
|
||||||
|
|
||||||
|
**Best practice for toggling:** make **one GPX file per theme**:
|
||||||
|
|
||||||
|
* `water_sources.gpx`
|
||||||
|
* `villages.gpx`
|
||||||
|
* `summits.gpx`
|
||||||
|
* `springs.gpx`
|
||||||
|
|
||||||
|
That gives you clean on/off control by file instead of stuffing everything into one blob.
|
||||||
|
|
||||||
|
### Path 2: native POI pack for OsmAnd
|
||||||
|
|
||||||
|
This is better when you want it to behave more like a built-in searchable POI dataset.
|
||||||
|
|
||||||
|
First convert CSVs to OSM XML:
|
||||||
|
|
||||||
|
```bash id="51512"
|
||||||
|
python landmarks_csv_to_osmand.py *.csv --category water_sources --osm water_sources.osm
|
||||||
|
```
|
||||||
|
|
||||||
|
Then build a POI-only OBF:
|
||||||
|
|
||||||
|
```bash id="68855"
|
||||||
|
java.exe -Xms256M -Xmx4096M -cp "OsmAndMapCreator.jar;lib/*" ^
|
||||||
|
net.osmand.MainUtilities generate-poi C:\path\to\water_sources.osm
|
||||||
|
```
|
||||||
|
|
||||||
|
That uses OsmAndMapCreator’s documented `generate-poi` mode and avoids the routing stage entirely. ([OsmAnd][2])
|
||||||
|
|
||||||
|
### Which one should you choose?
|
||||||
|
|
||||||
|
Use **GPX** when you want:
|
||||||
|
|
||||||
|
* fast import
|
||||||
|
* easy toggle on/off
|
||||||
|
* visual overlay behavior
|
||||||
|
* category grouping with custom icons/colors
|
||||||
|
|
||||||
|
Use **POI-only OBF** when you want:
|
||||||
|
|
||||||
|
* more native OsmAnd integration
|
||||||
|
* better POI-style searching/indexing
|
||||||
|
* a cleaner long-term pack
|
||||||
|
|
||||||
|
### Important limitation
|
||||||
|
|
||||||
|
For now, your landmark CSV path is strongest for **exact-coordinate point features**. That is why it works well for springs, drinking water, villages, summits, and similar point landmarks. It is not the same as a full vector map overlay with arbitrary line/polygon filtering.
|
||||||
|
|
||||||
|
### Ready-to-use commands
|
||||||
|
|
||||||
|
All CSVs into one grouped GPX:
|
||||||
|
|
||||||
|
```bash id="40684"
|
||||||
|
python landmarks_csv_to_osmand.py *.csv --gpx all_landmarks.gpx --group-by category --summary-json all_landmarks_summary.json
|
||||||
|
```
|
||||||
|
|
||||||
|
Only water sources into GPX:
|
||||||
|
|
||||||
|
```bash id="33043"
|
||||||
|
python landmarks_csv_to_osmand.py *.csv --category water_sources --gpx water_sources.gpx
|
||||||
|
```
|
||||||
|
|
||||||
|
Only water sources into OSM for POI build:
|
||||||
|
|
||||||
|
```bash id="57957"
|
||||||
|
python landmarks_csv_to_osmand.py *.csv --category water_sources --osm water_sources.osm
|
||||||
|
```
|
||||||
|
|
||||||
|
Only named villages into GPX:
|
||||||
|
|
||||||
|
```bash id="12262"
|
||||||
|
python landmarks_csv_to_osmand.py *.csv --filter-tag place=village --named-only --gpx villages.gpx
|
||||||
|
```
|
||||||
|
|
||||||
|
The cleanest deployment pattern is: **one GPX per category for toggles, plus one POI-only OBF per high-value category for native search**.
|
||||||
|
|
||||||
|
[1]: https://osmand.net/docs/technical/osmand-file-formats/osmand-gpx/?utm_source=chatgpt.com "OsmAnd GPX | OsmAnd"
|
||||||
|
[2]: https://osmand.net/docs/technical/map-creation/create-offline-maps-yourself/?utm_source=chatgpt.com "Create Offline Raster & Vector Maps | OsmAnd"
|
||||||
-110056
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user