地名は人間が位置を言葉で指し示すとき自然に使う語彙でありながら、情報として扱うには座標と識別子の両方を持つ実体として定義し直す必要がある。この定義を明確にすることで、文書の中の記述と地図上の位置をつなぐ経路が開ける。
情報空間・地理空間・つなぐ空間
地理に関わる情報を整理する枠組みとして、情報空間・地理空間・つなぐ空間の三層が提示されている [UC-011 §3. 「どこ」を特定する——情報空間・地理空間・つなぐ空間]。情報空間はテキストや画像など「ある場所に関する資料・説明文」のデータ群であり、地理空間は点やポリゴン・ピクセルといった幾何学的な構造を持ち地球上の場所に対応する地図のデータ群である。この二つをつなぐ空間に立つのがトポニム(地名)で、座標(地図側)と識別子(資料側)を併せ持つことでつなぎ役を果たす [UC-011 §3. 「どこ」を特定する——情報空間・地理空間・つなぐ空間]。同じ枠組みをより端的に言えば、地名エンティティに識別子を付与すれば情報空間へ、座標を付与すれば地理空間へとつながる [UC-010 §情報・地理・つなぐ──三つの空間のモデル]。
日常では「東京にいる」という地名で位置を伝えれば通じるが、計算処理では緯度経度が必要になる [UC-009 §地理情報とは何か]。地名がその橋渡しをする、というのがこの三層モデルの核心である。
地名辞書(ガゼッティア)の構造と識別子
地名を機械処理で扱えるようにした辞書をガゼッティア(地名辞典)と呼ぶ。ガゼッティアの各エントリは地名の文字列と位置情報を持ち、それが指し示す実体(エンティティ)に識別子(ID)が付与されることで、異なるアプリケーションやデータセット間のデータ統合が可能になる [UC-010 §歴史的ジオコーダーとGeoLOD──地名をつなぐ基盤]。
GeoLOD はこの識別子付与を担うサービスの一例で、地名をアップロードして GeoLOD ID を割り当てると、その識別子を介して異なるアプリ間でデータを統合できる [UC-010 §歴史的ジオコーダーとGeoLOD──地名をつなぐ基盤]。識別子付与にあたっては「何を同じエンティティとみなすか」という基準が問題になる。たとえば「東京」というエンティティが指すものは、東京市15区・35区・現在の23区・東京府・東京都で異なり、どこを同一エンティティとみなすかは、あらかじめ基準を決める必要がある [UC-033 §地図・地誌・地名の枠組みと識別子付与の方針]。識別子の設計と引用の仕組み一般については「識別子とデータ引用」を参照。
属性の付与では位置情報が特に重要で、どこを代表点として選ぶかという判断を伴う。名称の表記揺れや粒度の相違を吸収し、よみや基本統計を付与することも、典拠データとしての地名辞書には求められる [UC-033 §地図・地誌・地名の枠組みと識別子付与の方針]。
『日本歴史地名大系』地名項目データセット
こうした典拠データの代表例が、『日本歴史地名大系』地名項目データセット(80,502件)である [UC-012 §江戸近世村データセット]。平凡社が刊行した『日本歴史地名大系』の地名項目に位置情報を加えて機械可読化したもので、江戸時代の村までさかのぼる地名をCC BYライセンスで公開している。出版社との協力のもとで、事実に関する書き手に依存しない情報をオープンデータとして公開し、解釈に関わる記述部分は引き続き有料サービス(ジャパンナレッジ)でクローズドに提供する、という構造をとっている [UC-012 §江戸近世村データセット]。
このデータセットは住所ジオコーディングにも活用されている。データ中の地名には平成の大合併以前の住所が記録されているため、そのまま現代のジオコーダーに入れても位置が特定できない。そこで大合併以前の住所に対応する現代住所の候補を jageocoder を用いて探したうえでジオコーディングし、地名の推定緯度経度として地図上にマッピングする手法が取られている [UC-031 §現代の住所を対象とした応用事例]。自動化できる部分もある一方、手動で対応しなければならない部分も多く残り、あくまで限定的な変換だという評価が示されている [UC-031 §現代の住所を対象とした応用事例]。
ジオコーディング——住所と地名を位置に変換する
住所や地名を緯度経度に変換する処理をジオコーディングと呼ぶ。一見単純だが、日本の住所はとにかく複雑でパターン化が困難であり、関係者の間で「住所の闇」「住所の沼」と語られる難しさがある [UC-031 §日本の住所が抱える課題]。
日本の住所には地番住所(法務局が土地ごとに定めた番号)と住居表示住所(市町村が建物につけた番号)の二体系が併存し、後者は日本の一部にしか対応していない [UC-031 §住所とジオコーディングとは]。さらに表記揺れ・異体字・複数の表記法・部分的な省略が重なり、日本全体を網羅した住所データベースも現時点では存在しない [UC-031 §日本の住所が抱える課題]。
jageocoder はこうした課題に対応するオープンソースのPython製ジオコーダーで、住所データベースを差し替えられるという構造上の特徴を持つ [UC-031 §jageocoder——現代日本の住所ジオコーダー]。この差し替え機能が、後述する歴史的住所への拡張を可能にする鍵になっている。
歴史的住所のジオコーディング——表記揺れ・異体字の扱い
現代の住所を対象とするジオコーダーを過去の住所に対応させる際、最も手間がかかる工程が表記揺れと異体字への対応である。
旧東京市15区住所データセット(56,089件)はその代表的な実践で、1907年(明治40年)の東京市15区を対象とする [UC-031 §公開したデータセットとマップ]。構築にあたっては、GeoJSON形式の地理データ・jageocoder用の住所データ・表記揺れ辞書データの三種を用意した [UC-031 §旧東京市15区住所データセットの構築]。表記揺れ・異表記辞書は、実際の住所データ(関東大震災死亡者データ)から典型的な表記揺れを収集して作成したもので、個々の現実の住所表記をデータベース中のエントリにマッピングする対応を一件ずつ記述している [UC-031 §表記揺れ・異表記辞書]。
典型的なパターンとして、区と町名の間に入る地域名の省略がある。小石川区には「小日向」「小石川」「関口」のような共通の接頭辞を持つ町名が多く、この地域名は日常の会話では省略されがちなため、地域名を補うルールが多く求められた [UC-031 §表記揺れ・異表記辞書]。異体字については、頻出するものは jageocoder が標準で持つ地名異体字辞書に登録し、利用例が多くない異体字は表記揺れ辞書のなかで個別に処理する。辞書を拡張するか元データを修正するかは、どれだけ例外的かという観点から判断する微妙なバランスの上に成り立っている [UC-031 §異体字への対応]。
この枠組みは別の実践でも検証されている。関東大震災(1923年)の死亡者住所約3万8千件をジオコーディングした事例では、まず変換率を確認しながら表記揺れのパターンを収集して辞書に登録し、次に一意に決まらない町名を文脈から判断し、さらに誤字・入力ミスを元データ側で修正するという段階的なワークフローをたどった [UC-032 §住所データ修正のワークフロー]。この一連の作業を経て、全体の87%(3万3,467件)を地番レベルで変換することができた [UC-032 §変換精度の結果]。
辞書を拡張するか元データを修正するかという判断は、例外の頻度と性質に依存するため、どちらが正解かを事前に定めることは難しい。こうした判断の記録・共有が、担当者による見落としやばらつきを減らし、作業品質を安定させると見込まれている [UC-031 §歴史的ジオコーダーの作成手順と今後の展開]。データを整える際の方針設計一般については「データを整える」を参照。
歴史地名に固有の問題——同名異地・異名同地
歴史地名を扱うとき、現代地名の対応づけとは質の異なる問題が現れる。時代や地域によって「同じ名が違う場所を指す」ことも、「違う名が同じ場所を指す」こともある。
「横川町」が本所横川町・中ノ郷横川町・柳島横川町のいずれかを区別できないような、一意に決まらない町名の問題はその典型で、文脈から判断してどれとみなすかを決める作業が必要になる [UC-032 §大正時代の住所をジオコーディングする課題]。「東京」というエンティティが東京市15区・35区・現在の23区・東京府・東京都で異なるように、何を同一エンティティとみなすかという基準は事前に明示する必要があり、どちらの立場も取りうるため一律に決まるものではない [UC-033 §地図・地誌・地名の枠組みと識別子付与の方針]。
また、1907年基準のデータセットを1923年の住所に適用した事例では、大正2年(1913年)に成立した芝区日出町のように、16年の差のあいだに生じた街区・住所の変化がエントリとして存在しない問題も見つかっている [UC-032 §変換の限界と今後の課題]。行政区域が時代とともに変わることとそのデータモデルについては「時間をもつ空間」を参照。