C#版GeoCoreJPの設計 — 次期MAUIアプリ群の共通ライブラリ化

2026年7月15日

アマグラマー

C#版GeoCoreJPの設計 — 次期MAUIアプリ群の共通ライブラリ化

前回の記事で、座標変換エンジン「GeoCoreJP」をSwiftとC#で二重実装していると書きました。今回はそのC#版について、次期MAUIアプリ群（現在3本を計画中）で共有する共通ライブラリとしての設計を掘り下げます。

※本記事では、非公開の次期アプリ名・リポジトリ名は伏せ、それぞれ GeoC／GeoD／GeoF、TypeA／TypeB という仮称で表記しています。

共通化する範囲の決め方 — 変換エンジンのみ、UIは各アプリ

GeoDiveExa（GDE）を含む共有リポジトリ「TypeA」とは別に、次期アプリ3本（GeoC・GeoD・GeoF）は個人管理のリポジトリ「TypeB」で開発しています。3本とも現場向けRTK-GNSSアプリという性格は共通していますが、UIやアプリ固有の業務ロジック（杭打ちナビの誘導表示、写真のEXIF検証、DOP可視化など）まで共通化しようとすると、かえって密結合になり保守が難しくなります。

そこで共通化する範囲を「測地系・座標変換のロジックのみ」に絞りました。具体的には次の境界線です。

共通化する	共通化しない
測地系変換（緯度経度⇄平面直角座標系など）	画面のレイアウト・ナビゲーションUI
地殻変動補正・ジオイド補正の適用	アプリ固有の業務ロジック（誘導計算・写真処理など）
パラメータファイルの読み込み・保持	データの永続化方式（アプリごとのDB設計）

「変換エンジンだけを共通化し、それ以外は各アプリが自由に作る」という線引きにしたことで、3本それぞれの開発を独立して進めながら、変換ロジックの品質だけは一箇所で担保できる構成になっています。

名前空間・プロジェクト構成

C#版GeoCoreJPは、TypeBリポジトリ直下にクラスライブラリプロジェクトとして配置し、各アプリのMAUIプロジェクトからプロジェクト参照する構成です。

TypeB/
├─ GeoCore/                  ← クラスライブラリ（.NET Standard相当）
│   ├─ Datum/                ← 測地系定義（JGD2011・JGD2024ほか）
│   ├─ Correction/           ← 地殻変動補正・ジオイド補正
│   ├─ Projection/           ← 平面直角座標系・投影計算
│   └─ Parameters/           ← パラメータファイル読み込み
├─ GeoC/                     ← アプリ本体（MAUI）
├─ GeoD/                     ← アプリ本体（MAUI）
└─ GeoF/                     ← アプリ本体（MAUI）

名前空間はアプリ名を含めず GeoCoreJP.* に統一しています。将来アプリが増減しても名前空間を変更せずに済むようにするためで、Swift版のモジュール名（GeoCoreJP）とも呼び方を揃えています。

公開APIの設計 — 変換結果に根拠情報を必ず添える

API設計でもっとも意識したのは、「変換した数値だけを返さない」ことです。呼び出し側には、変換結果と一緒にどのパラメータ・どの測地系定義を使って計算したかという根拠情報を必ず返すようにしています。

public record ConversionResult(
    double Latitude,
    double Longitude,
    double? Height,
    string DatumUsed,          // 使用した測地系
    string ParameterFileUsed,  // 使用した補正パラメータファイル名
    DateTime ParameterEpoch    // パラメータの適用時点
);

public interface IGeoCoreConverter
{
    ConversionResult Convert(ConversionRequest request);
}

これは「変換の根拠をその場で残す」（GeoConverterPro）で紹介した思想をライブラリのAPIレベルまで落とし込んだものです。現場で「この座標はどのパラメータで補正したものか」が後から追えることは、測量成果として重要な要件だと考えています。

パラメータファイルの持ち方

地殻変動補正パラメータ（セミダイナミック補正・定常時地殻変動補正）は年度ごとに更新されるため、パラメータ本体をコードに埋め込まず、リソースファイルとしてGeoCore/Parameters/配下に配置し、バージョン番号付きで管理しています。

パラメータファイルはアプリ本体ではなくGeoCoreライブラリ側に同梱する（3アプリで二重に持たない）
新しい年度版が公開されたら、GeoCore側だけを更新し、参照している3アプリは次回ビルドで自動的に新パラメータを使う
旧バージョンのパラメータも一定期間残し、ParameterEpochを指定すれば過去のパラメータでの変換も再現できるようにしている

年1回程度のパラメータ更新を3アプリ分バラバラに反映する手間を避けるため、更新作業を「ライブラリ1箇所」に集約したのが狙いです。

アプリ側からの利用例

各アプリからは、DIコンテナにIGeoCoreConverterを登録して利用します。

// MauiProgram.cs
builder.Services.AddSingleton<IGeoCoreConverter, GeoCoreConverter>();

// 利用側
var result = converter.Convert(new ConversionRequest(
    latitude: 35.681236,
    longitude: 139.767125,
    sourceDatum: "JGD2011"
));
// result.DatumUsed, result.ParameterFileUsed で根拠を確認できる

アプリ側のコードには測地系の詳細ロジックを一切書かず、「変換リクエストを投げて結果を受け取る」だけに徹しています。この薄いインターフェースのおかげで、GeoCore側の内部実装（補正方式の追加・パラメータの差し替えなど）を変更しても、アプリ側のコード変更はほぼ発生しません。