どうも〜おかむーです！今日はちょっとエンジニア寄りの、でも超実務的な話をしますよ〜

• 地理データはフォーマットと座標系の不一致で使い物にならないことが多い
• 行政コード（JIS）の連携とジオメトリ品質が鍵、APIで繋ぐと効率化できる
• 小さな技術改善（GeoJSON/JSON-LD、CI、スキーマ検証）が再利用を劇的に高める

結論

自治体のオープンデータで最も改善効果が高いのは「地理参照の一貫性」だと思うんです。エンジニア的に言うと、座標系・フォーマット・行政コードを規格化してパイプラインに組み込めば、可用性と利活用が一気に伸びます！

レポート本文

現状と問題点

これ見てくださいよ：各自治体が出す施設位置や境界データ、フォーマットばらばらでしょ？CSVに経度緯度を埋めてたり、Esri Shapefileだったり、GMLやPDFの図面に埋めてたり。しかも座標系がJGD2000/JGD2011/Tokyo座標（旧系）混在なんですよね。

参照ソースとして、デジタル庁や総務省の標準化方針（digital.go.jp, soumu.go.jp）、BODIKの取り組み（bodik.jp）を見ると、標準化の方向性はあるんですが、現場ではフォーマット運用まで落とし込めていないケースが多いです。intecの記事にも活用事例があるように（intec.co.jp）、使われるための整備は必須です。

問題を技術的に整理すると：

• 座標系ミスマッチ → 可視化と空間解析で誤差やズレ発生
• フォーマット多様性（CSV/Excel/GeoJSON/GML/Shapefile）→ パーサーの負荷
• 行政コード未連携 → 区分・集計で結合できない
• メタデータ不足 → 利用者が意味を誤解する

技術的な対処（実践レシピ）

1) 標準フォーマットを1つ（GeoJSON + JSON-LD推奨）にして、補助的にCSVを提供

2) 座標系はJGD2011（EPSG:6668 等）を基本に、変換履歴をメタデータで保持

3) 行政コード（JIS X 0401）をリソースに必須項目として付与。e-GovのAPI（e-gov.go.jp）で最新のコードを照合

4) CIでスキーマ検証（JSON Schema）とジオメトリ検証（GeoJSON Lint / Shapely）を回す

コード例（Python: 取得→標準化→検証）:

import requests
import geopandas as gpd
from shapely.geometry import Point

例: APIやファイルから読み込む
r = requests.get('https://example.local/gis/points.geojson')
src = r.json()

gdf = gpd.GeoDataFrame.from_features(src['features'])
座標系を確認してJGD2011(EPSG:6668)へ変換
if gdf.crs is None:
gdf.set_crs('EPSG:4326', inplace=True)  # 仮定
gdf = gdf.to_crs('EPSG:6668')

行政コード照合（e-GovのAPIで最新JISコードを取得してマージ）
schema validationをCIで行うイメージ

要するに、コード書く人ならわかると思うんですけど、パイプライン化すると再利用性が段違いなんですよ！

発展：境界データのトレーサビリティ

境界（行政界、施設ポリゴン）は頻繁に更新されます。変更履歴をGeoJSONのFeatureプロパティに入れて、変更時刻・元ソース・座標系を明記するだけで検証が楽になります。APIで配信する場合はETag/Last-Modifiedを実装して差分取得を容易にしましょう（digital.go.jpのガイドラインに沿って）。

データ公開の運用面提案

• データカタログに「座標系」「行政コード」「更新履歴」「サンプルクエリ」を明記
• CIで毎日スキーマとジオメトリチェックを走らせ、失敗は運用チケットと紐付け
• セマンティック層としてJSON-LDコンテキストを配備し、検索性を上げる

まとめ

地理データの利活用で手を動かすキーは「一貫した参照系」と「コードによる検証」です。フォーマットを標準化してAPIで行政コードを引ける状態にすれば、自治体データはすぐに使える資産になりますよ！

おかむーから一言

テクノロジーで行政をアップデートするって、こういう地味だけど確実に効く改善から始まるんです。小さな標準化で大きな利活用を生みましょう！