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

オープン
  • 何か問題がありますか？
#795 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
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
平均マージ
16時間 7分
マージ済み PR（30日）
128

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

OpenSAK-Org/OpenSAK のほかの issue

OpenSAK-Org/OpenSAK の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。