0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

素案どおりの GeoPackage を実データで作ってみたら、埋まったのは 29% だった — 国総研「下水道管路データ交換標準仕様書(素案)」×半田市オープンデータ

0
Last updated at Posted at 2026-08-14

はじめに

前回の記事で、国総研の「地震対応における下水道管路データ交換標準仕様書(素案)」を読みました。読み終えて、当然の疑問が残りました。

うちの台帳のデータ、これに変換したらどこまで埋まるのか?

仕様書は読むだけでは分かりません。今回は半田市のオープンデータ(下水道管路)を素案の応用スキーマに実際に変換し、どこが機械的に埋まり、どこで人の判断が要り、どこに情報の行き場が無いかを差分レポートにしました。素案は現在意見照会中(民間企業向けの提出期限は 2026 年 8 月 26 日 17 時)なので、提出する立場の方の論点整理の材料になれば幸いです。

結論から言うと、管きょは素案 24 属性のうち 7 つ(29%)しか埋まりませんでした。ただしこの数字自体は悪い話ではありません。面白いのは「何が・なぜ埋まらないか」の内訳です。

作ったもの

変換パイプライン一式はリポジトリの work5-exchange-standard/ にあります。

  1. スキーマの転記 — 素案の応用スキーマ(印刷 pp.20-23)とコードリスト全 11 種(pp.24-29)を、出典ページ付きの JSON に書き起こしました。マンホール 19 属性、管きょ 24 属性+関連役割 2、公共ます 2 属性、取付け管は形状のみ。
  2. 対応表 — 半田市側の属性(第 3 回で復元した属性辞書)と素案の属性の対応を、mapped(機械変換可)/judgment(人の判断が要る)/missing(台帳に無い)/no_home(素案に受け皿が無い)の 4 区分で定義。
  3. 変換器 — 設計原則はひとつ、黙って推測しない。機械的に決められない箇所はすべて判断ログに残し、必須違反・異常値は品質レポートに出します。

出力は素案の指定どおりの GeoPackage(.gpkg・UTF-8)で、レイヤ名も列名も応用スキーマの日本語名そのままです。前回紹介した国総研 FAQ の「仕様書で定められたレイヤ名、項目名、型、属性定義等に統一します」(No.2)を、そのまま実装した形になります。

結果: 何がどこまで埋まったか

レイヤ 件数 素案の属性数 埋まった数 充足
管きょ 21,223 24(+関連役割 2) 7 29%
マンホール 20,689 19 8 42%
公共ます 39,391 2 2 100%
取付け管 39,443 0(形状のみ) — 定義どおり

mapping_matrix.png

先に断っておくと、これは公開データの話です。市の庁内台帳には公開版に含まれない属性があるはずで、この充足率は「半田市の台帳の充足率」ではありません。それでも、公開されている範囲の台帳から機械的に作れる交換データの上限がこの数字だ、ということは言えます。

発見①: 「どちらか必須」が満たせない

素案の下水道管路パッケージで必須(多重度 [1])なのは位置・形状と施設番号だけ — 前回は「くらい」とぼかして書きましたが、今回は管路パッケージの全ての表(印刷 pp.21-23)を数えて「だけ」であることを確認しました(なお調査パッケージ側には調査 ID・対応種別フラグ・調査日の必須 3 属性があります — 印刷 p.30)。それに次ぐ強い要求として、 排水区域名称と処理区域名称は「どちらか必ず入力すること」 という注記があります(印刷 pp.21-22)。

これが埋まりません。管きょレイヤには両方とも存在せず、全 21,223 本が注記を満たせない。マンホールには排水区名称がありますが記入は 15.1% で、84.9% は両方空です。

素案の立場からは「災害時に区域単位で被害を集計する最低限のキー」という意図が読めます。台帳の立場からは「区域名は別レイヤ(区域ポリゴン)で持っていて、施設属性としては持たない」設計が普通にあり得ます。空間結合すれば機械生成できるので絶望的なギャップではありませんが、「変換ボタンひとつ」では埋まらない、事前準備が要る項目だと分かります。

発見②: 施設番号の一意性が、平時の台帳では守られていない

素案が唯一必須にした施設番号。その源になる半田市の人孔キーは、欠損 1,726 基・重複 2,507 基でした(全 20,689 基中)。

これは半田市が悪いという話ではありません。平時の台帳運用では、人孔キーは図面や帳票と照合できれば十分で、データベース的な一意性制約がなくても業務は回ります。「施設を一意に特定できること」が本当に必要になるのは、外部とデータを交換する瞬間です。素案の意見照会が施設番号の桁数・文字種をわざわざ聞いているのは、国総研がここを急所と見ているからでしょう。前回、台帳データの整備・品質がそのまま災害対応力になる構図だと書きましたが、その最も具体的な実例がこれです。

発見③: 変換の本体はプログラムではなく「判断の表」

変換の過程で、機械的に決められず人の判断を挟んだ箇所が 15 件出ました。代表例を挙げます。

  • 「塩ビマンホール」4,458 基(半角カナは台帳の原文ママ) — 台帳は人孔を材質で呼んでいますが、素案のマンホール種別コードは寸法の軸(Y号〜7号 = 内径・内のり)です。軸が違うので対応が存在しません。その他人孔(17)に落とすと材質情報が消えます。
  • 「シールド」9 本 — 台帳は工法で呼び、素案の管材質コードはセグメント材質(コンクリート系/鋼製)を要求します。台帳からはどちらか判別できず、不明(99)に落とすしかありません。
  • 塩ビ系 13,625 本 — 素案は薄肉(VU=08)と厚肉(VP=09)を分けますが、台帳の「硬質塩ビ管」「塩ビ管」は肉厚を区別しません。今回は自然流下の本管に一般的な VU(08)を仮置きしましたが、これは変換ではなく判断です。
  • 「建設省」285 基 — 道路管理者名に、2001 年の省庁再編で消えた名前が残っています。01(国)に読み替えるのは人間には自明でも、変換表に書かない限り機械には自明ではありません。
  • 「2015年」 — 竣工年度の値が単位語付きの文字列でした。Integer に入れるには「年」を剥がす前処理が要ります。

国総研 FAQ は変換機能をベンダーの開発に期待する競争領域と整理していますが(No.16。No.20 では台帳からの出力機能は「各自治体側で」実装とも)、この判断表だけはベンダーには書けません。台帳の語彙(管種名称 15 種、人孔種別、道路管理者名…)がそれぞれ何を意味するかを知っているのは自治体(とその台帳を長年触ってきた受託者)だけだからです。交換標準対応の見積りで本当に工数を食うのはコードではなくここだと思います。

発見④: 交換で「失われるもの」リスト

逆方向の差分 — 台帳にはあるのに素案に受け皿が無い情報 — も出ました。

  • 地盤高(標高) — 素案の管路パッケージの属性は地表からの相対値(深さ・管底深・土被り)だけで、標高の属性を持ちません。半田市の台帳ではマンホールの地盤高(m)は基本項目として入っているので意外でしたが、大地震後は地盤自体が変動して標高成果が使えなくなることを考えると、属性としては相対深さだけで完結させたのは意図的な設計とも読めます(なお素案の空間参照系は T.P. 基準の標高も規定しているので — 印刷 p.68 — 高さの受け皿は属性ではなく座標側、という整理なのかもしれません)。
  • 人孔内径の実測値 — 素案では種別コード(1号=内径90cm 等)に寸法情報が畳み込まれており、実測の内径 2 値の行き場がありません。
  • マンホールの施工年度 — 素案の管きょは竣工年度を持ちますが、マンホールは持ちません。耐震性能の推定(設計指針の適用年代)に効く情報なので、これは意見照会で聞いてみる価値のある論点だと思います。
  • 「・推進管」サフィックス — 台帳の管種名称に含まれる施工法の情報。素案の管きょに施工法属性が無いため落ちます。
  • ほかに資産番号、マンホールポンプ区分、副管有無、備考など。

「必須最小限」の割り切りは前回見たとおり素案の思想なので、落ちること自体は設計どおりです。ただ、何が落ちるかのリストを事前に持っておくことは、交換データを受け取った側が「この情報は元の台帳に問い合わせないと無い」と判断する材料になります。

発見⑤: 「日本測地系2024」を名乗る手段が、まだ流通していない

素案は空間参照系に「日本測地系2024における緯度経度座標系」を指定しています(印刷 p.68)。ここで手が止まりました。

  • JGD2024 の EPSG 登録は 2026 年 4 月(EPSG Dataset v12.055)。素案の公表(2026 年 3 月)の翌月です。つまり素案が出た時点では、指定された測地系を名乗るための EPSG コードが存在しませんでした。
  • 手元の pyproj 3.7.2(同梱 EPSG データベース v11.022)では、登録後の今もまだ JGD2024 を参照できません。

幸い、測地成果 2024 では水平座標の数値は JGD2011 から引き継がれるため、値そのものの変換は不要です。今回は EPSG:6668(JGD2011 地理座標系)ラベルで出力しました。値は正しく、名前が旧称という状態です。運用開始(令和 9 年度以降)までにはツール側が追いつくはずですが、2026 年夏時点で「素案どおりの CRS 表記」を汎用ツールで作るのは案外難しい、というのは変換してみて初めて分かったことでした。

実務でどう使えるか

  • 事前準備の TODO が定量化されます。 「排水区域名称を区域ポリゴンから空間結合で付与する」「人孔キーの重複を解消する」— どの作業で充足率が何ポイント上がるかが数字で見えるので、発災前にやる価値の高い順に並べられます。
  • 意見照会の論点材料になります。 肉厚不明の塩ビを表すコードが無い、工法(シールド・推進)の受け皿が無い、マンホールに竣工年度が無い、寸法軸のマンホール種別コードに材質系の台帳語彙が載らない — いずれも実データで具体的に示せる論点です(民間企業向けの提出期限は 2026 年 8 月 26 日 17 時)。
  • 受け取る側の期待値調整に使えます。 交換データの充足率は元台帳の公開範囲と品質で決まります。「gpkg で来る=全部入っている」ではない、という感覚を持って受け取るのが安全です。

まとめ

  • 半田市の公開データを素案スキーマの GeoPackage に変換しました。管きょ 24 属性中 7(29%)、マンホール 19 属性中 8(42%)。コードはリポジトリにあります。
  • 「排水区域名称/処理区域名称はどちらか必須」が公開台帳からは満たせず、施設番号の源(人孔キー)は欠損 1,726・重複 2,507 でした。平時の台帳品質=災害対応力の実例です。
  • 変換の本体はプログラムではなく判断の表でした。台帳の語彙(材質・工法・旧省庁名)と素案のコード(寸法・セグメント材質)の軸のずれは、その台帳を知る人にしか埋められません。
  • 素案に受け皿の無い情報(地盤高・実測内径・マンホールの年度・施工法)のリストも取れました。
  • 素案指定の日本測地系 2024 は、EPSG 登録が素案公表の翌月(2026 年 4 月・v12.055)で、汎用ツールの対応はまだこれからです。

次回は、第 1 回の予告をようやく回収します — TV カメラ調査の結果を入れると緊急度判定を整理してくれるツールを作りました。

追記: 重複 2,507 の正体と実用コアに対する充足率(2026-08-15)

公開後、実務者の方から「人孔キーの重複 2,507 は内訳を分解すべき(ダミー値の集中なら対処が全く変わる)」というご指摘をいただき、追加分析を行いました。結果は予想より面白いものでした。

  • ダミー値(0・ハイフン・999 など)は 0 件。同一座標の二重登録も 0 組でした。
  • 重複キー 2,505 種はすべて「汚水系の人孔」と「雨水系の人孔」にまたがっていました(組内距離の中央値 167m)。つまり半田市の人孔キーは排水系統の中でだけ一意になる採番で、別系統の別施設が同じ番号を持ちます。
  • したがって「排除区分をキーに前置する」前処理 1 本でほぼ解消し、残る系統内の真の重複は 2 キーだけです。事前準備の見積りは「2,507 基の個別修正」ではなく「採番規則の変換 1 件+個別対応 2 件+空欄 1,726 基の付番」になります。

あわせて、災害対応の実用コア 10 項目(形状/施設番号/管径/管種/管底深×2/土被り×2/上下流マンホールとの関連/施工法)に対する充足も算出しました。10 項目中 6 項目(60%) が埋まり、埋まる項目の充足率は 90〜100% 台です。本文の 29% は「Null 許容の仕様全体に対する参考値」、この 60% が「実用度」に近い読みになります。

分析スクリプトと詳細はリポジトリの work5-exchange-standard/supplement_analysis.py および output/supplement_key_and_core.md を参照してください。

免責・出典

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?