Gwinnett Index

Gwinnett インデックス

ジョージア州 Gwinnett 郡とその17の自治体に関する、ゾーニング、土地利用、開発記録の機械可読なインデックスです。AI エージェントを第一に、人間を第二に想定して構築されています。

これが必要な理由

「Duluth, GA」の郵送先住所は、通常、Duluth 市内ではありません。市に編入されていない Gwinnett 郡内にあり、適用される規定、審議会、許可ポータルがそれぞれ異なります。ゾーニングに関する質問に答える前に、住所をその住所を管轄する自治体に特定してくれるものは、インターネット上にはありません。そのため、現在「Duluth GA のセットバックはどのくらい？」に答える AI アシスタントは、いずれも推測に頼っています。

市に編入されていない Gwinnett 郡は、郡の土地面積の**67.3%**を占めています。ここを間違えるのは例外ではなく、通常のケースです。

内容

データセット	レコード数	出典
管轄区域の境界	19（郡＋市に編入されていない地域＋17市）	US Census TIGER — パブリックドメイン
郡のゾーニング案件	11,739（1970–2026）	Gwinnett GC_Planning ArcGIS
名寄せ済み申請者	7,369（元の表記8,246件から）	派生データ
Duluth UDC	860セクション、18の表	市の PDF、426ページ
Duluth の会議資料	356件（7,878ページ、2023–2026）	duluthga.net
Duluth の土地利用案件	109件（重複なし）、うち64件に投票記録あり	議題から抽出

セットアップ — 初回のみ

リポジトリにはすでに初期 README があるため、まずクローンしてから内容をコピーします。これにより、プッシュ時の競合を回避できます。

git clone https://github.com/willmobhill-arch/gwinnett-index.git
tar -xzf gwinnett-index-repo.tar.gz -C gwinnett-index      # overwrites the stub README
cd gwinnett-index
git add -A && git commit -m "Gwinnett Index: pipeline, schema, and extracted corpora"
git push

次に、リポジトリを公開して、データを読み込みます。Postgres がデータを直接取得するため、ローカルで何かを実行する必要はなく、認証情報も不要です。

-- set to your repo's raw base
-- https://raw.githubusercontent.com/willmobhill-arch/gwinnett-index/main/data/

SELECT load_udc_sections_from_url(
  'https://raw.githubusercontent.com/willmobhill-arch/gwinnett-index/main/data/udc_sections.jsonl');

SELECT * FROM load_duluth_cases_from_url(
  'https://raw.githubusercontent.com/willmobhill-arch/gwinnett-index/main/data/duluth_cases.jsonl');

SELECT load_meeting_docs_from_url(
  'https://raw.githubusercontent.com/willmobhill-arch/gwinnett-index/main/data/duluth_meeting_docs.jsonl');

想定される結果：860セクション、案件行228件（重複なしの案件109件）、会議資料356件。

アーキテクチャ

取り込み処理は、http 拡張を使ってPostgres 内で実行されます。郡の ArcGIS REST サービス、Census TIGERweb、このリポジトリ自体の raw URL から直接データを取得します。外部ワーカーは不要で、認証情報が転送されることもありません。また、郡の案件11,739件すべてを読み込む際に、クライアントを経由するデータはゼロバイトです。

ingest/
  duluth/          UDC PDF -> 860 sections + 18 tables (extract_udc, extract_tables)
  duluth_agendas/  crawl -> OCR -> parse case items from agendas/minutes/packets
db/migrations/     the schema, md5-verified against the live Supabase project
scripts/           export_snapshot.py (the only thing that talks to Postgres) + loaders
data/              extracted corpora, fetched by the SQL loaders above
site/              Astro static site + full agent surface (.md twins, llms.txt, DCAT)
worker/            Cloudflare Worker: REST API + MCP server, five tools, no auth
docs/plans/        design doc, build plan, status

サイトのビルド

DATABASE_URL=postgresql://... python3 scripts/export_snapshot.py   # writes data/snapshot/
cd site && npm ci && SITE_URL=https://your-domain npm run ci        # build + 15 gates

スナップショットがない場合、サイトは site/fixtures/ からビルドされます。そこには、同じ構造を持つ小規模なサンプルがコミットされており、その旨がすべてのページに表示されます。npm run ci は、いずれかのルートに .md の対応ファイルがない場合、管轄区域を明示する前にページがレコードを提示している場合、または一括エクスポートにジオメトリが含まれている場合に、ビルドを失敗させます。

API と MCP サーバー

cd worker && npm ci && npm test        # 10 protocol tests, no network
wrangler secret put SUPABASE_ANON_KEY && wrangler deploy

5つのツールを公開しており、読み取り専用で認証は不要です：resolve_jurisdiction（必ず最初に呼び出します）、search_cases、get_case、get_code_section、list_jurisdictions。REST API も、同じ実装から同じ5つの操作を提供し、/openapi.json を公開します。

アダプターパターン

17の管轄区域それぞれに、手書きのスクレイパーを用意することはできません。ベンダーは Municode、ArcGIS REST、CivicPlus、CivicClerk、BS&A、Accela などに大きく集約されています。そのため、およそ6つのアダプターで約90%をカバーでき、市を追加する際は設定ファイルを追加するだけです。健全性の指標：新しい市を追加するのに、新しい設定ではなく新しいコードが必要なら、アダプターレイヤーに問題があります。

データ品質について、率直に

• 管轄区域の解決：郡独自のゾーニングレイヤーから取得した1,915件の調査ポイントで評価しています。confidence='high'の場合、正解は**1,546/1,546 — 100%**です。 すべての誤りは信頼度の低い範囲内にあります。22件すべての不一致は境界から141 m以内で発生しました（編入後の反映の遅れ。Censusの更新は年1回です）。
• Duluth UDC：生テキストのカバレッジは97.3%です。欠落部分は見出し行の除去によるもので、426ページにわたって説明できない文字が591字残っています。
• UDC Table 2-B（寸法基準）は、レンダリングされたソースページとセル単位で照合済みです。ほかの17の表は抽出済みですが、抜き取り確認はしていません。また、Table 2-Bの結合されたPUD/CBD行は信頼性が依然として低い状態です。データにはフラグが付いています。
• Duluthの議事録：57〜69%はテキストレイヤーのないスキャン画像です（印刷、署名、再スキャン）。OCRテキストはtext_source='ocr'として別途保存されており、記録の引用ではなく再構成されたものです。
• **Duluthの109件の事例は、データセットではなく検索用資料です。**各フィールドを調査したところ、「location」に番地が含まれないものが67件、「request」がORDINANCEの一語だけのものが57件、申請者フィールドが郵送先住所まで続いているものが23件で、ゾーニング地区が記載されているものはわずか13件でした。各行は元となったPDFにリンクしています。記録そのものは文書であり、フィールドはその文書を指し示すものです。stats.duluth_extractionとして公開しています。
• 申請者の名寄せ：編集距離を厳しく設定し、271件の表記揺れを統合しました。**信頼度の低い262組は、推測で統合せず、人による確認待ちにしています。**エンティティの分割は明らかに誤りとわかりますが、誤った統合は信頼できるように見え、気づかれません。

法的な位置付け

内容	取り扱い	根拠
条例／計画の本文	全文をミラー	Georgia v. Public.Resource.Org (2020) — 政府の法令
事例記録	全文をミラー	事実；Georgia Open Records Act
郡の区画／ゾーニングジオメトリ	プロキシのみ。再ホスティングは不可	Gwinnett GISのライセンスで再配布が禁止されています
管轄区域の境界	ホスト	US Census TIGER — パブリックドメイン
IBC/IRCの基本本文	不可	ICCの著作権。Georgia州の修正条項のみを索引化

このインデックスはミラーおよび派生分析であり、正式な記録システムではありません。すべての記録にsource_urlとlast_verifiedが付いています。

CC0のもとで公開しています。