Investigate GPSBabel integration for import/export (GDB support and Garmin device-recognition fixes)

未关闭
  • 哪里不对？
#795 4 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
25/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
python
领域
data

调研方向

This is an investigation into wrapping the GPSBabel CLI as a subprocess for importing GDB files, so start with the existing GPX/LOC importer and check whether it can accept a converted GPX file unchanged. Confirm how the subprocess call, installation detection and missing-tool message would fit the current import flow. Done means a written recommendation on the approach, plus a decision on whether the optional export path is in scope, agreed in the comment thread.

由索引模型根据 Issue 内容生成。

描述

area: gps-export area: import improvement
Current State

OpenSAK has its own native GPX/GGZ import and export implementation, covering two distinct areas:

Export: Garmin device-recognition issues (caches showing as plain waypoints instead of geocaches) were tracked in #656 and are now fully fixed in stable v1.16.0 — GPX format now matches GSAK's exactly (GPX 1.0, correct namespace/element order), and previously missing attributes/description/full log history are now exported correctly across GPSMAP 64s/66s/66sr and Montana 700.
Import: OpenSAK still cannot import GDB files (Garmin's legacy binary database format) or other formats GSAK supports, since we only parse GPX/LOC ourselves.

GSAK avoids reimplementing format-specific logic by shelling out to GPSBabel (gpsbabel.org, GPL-licensed CLI tool) for both import and export.

Proposed Improvement

Add optional GPSBabel integration:

Import (primary motivation): support GDB and potentially other legacy/proprietary formats by converting to GPX via GPSBabel as a pre-processing step, then feeding the result into our existing GPX importer unchanged. GDB in particular is a poorly-documented binary format — GPSBabel already carries years of reverse-engineered edge-case handling for it that would be costly to redo ourselves.
Export (secondary/optional): since our native export now matches GSAK's format and passes device-recognition testing across multiple models (#656), a GPSBabel export path is no longer needed as a bug fix. It could still be offered as an alternative path for any device/firmware combination that turns out to be pickier than what we've tested — worth keeping in scope but not the priority.

Implementation approach: call gpsbabel as a subprocess (not linked against its code — same GPL-compatible model GSAK and tools like ffmpeg-wrappers use). Detect whether GPSBabel is installed on the system and show a clear message/instructions if not, rather than bundling the ~3 platform binaries in our PyInstaller builds from day one.

Expected Benefits

Opens up GDB and other legacy/proprietary format imports "for free"
Low implementation complexity (one subprocess wrapper + format detection) for a meaningful format coverage gain
Optional safety net for export edge cases beyond what #656 already tested and fixed
References
#656 (Garmin GPX export not recognized — closed/fixed in v1.16.0)
Forum feedback on geocaching.com (GDB support request, referencing prior GDB/WinGDB3 reverse-engineering experience)

主要语言
Python
星标
37
派生
17
平均合并
21 小时 5 分钟
30 天内合并 PR
131

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

OpenSAK-Org/OpenSAK 的其他 Issue

查看 OpenSAK-Org/OpenSAK 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。