次期MM/Memoというか1470.netで、位置情報関連機能を強化しようと思って、まずは位置情報→住所、郵便番号→住所→位置情報とかが手軽に変換できるように、街区レベル位置参照情報と郵便番号を合成してみている。

主データとしては、街区レベル位置参照情報の方を利用する。というのは、郵便番号の方は位置情報ではなく、郵便の都合で区分けされているんで、より位置情報のキーとして使いやすそうなのは街区レベル位置参照情報の方だから。

街区レベル位置参照情報は「丁目」よりも細かい「街区符号・地番」レベルの情報も持っているけれども、そこまで扱うと

• 住所情報としてのセンシティブさが増しすぎる
• 郵便番号情報との粒度の違いも大きくなりすぎる
• AjaxとかでがんがんDBを叩くにはデータサイズが増えすぎるだろう

という理由で、データとしては「丁目」レベルまでを扱い、それ以下は切り捨てることにする。

で、まずは「都道府県」「市区町村」「町域（大字・町丁目）」「緯度」「経度」というデータを街区レベル位置参照情報からインポートして、位置情報テーブル（address）を作成する。

id

prefecture

city

cityarea

latitude

longitude

※実際にはprefecture、city、cityareaも別テーブルに切り出している

最初、上記の位置情報テーブルに、郵便番号カラムを追加してやればいいかと思っていたんだけど、郵便番号は町域レベル以内でダブって登録されていたりすることも多い（同じビルの階数ごとに別の郵便番号が振られていたり）んで、別に郵便番号テーブル（zip）を作ることになった。

id

zipcode

address_id

郵便番号データにも「都道府県」「市区町村」「町域」という情報があるので、それらが完全一致する場合は、その位置情報をセットすればいい。しかし、それで対応できるデータというのはかなり少ない。具体的には、

1. 一つの郵便番号で市区町村レベルまでの範囲を受け持っている
2. 一つの郵便番号で複数の町域（細かく指定）を受け持っている
3. 街区レベル位置参照情報には存在しない市区町村に関する郵便番号がある
4. 街区レベル位置参照情報には存在しない町域に関する郵便番号がある
5. 町域レベルとして地名ではなく建物名などがセットされた郵便番号がある

などの例外の割合が非常に多い。

1の場合、位置参照情報の方では、基本的に町域レベルまで指定された位置情報を持っているので、市区町村レベルまでしか指定されない場合、その市区町村に所属する複数の位置情報のどれを代表として使用するのが妥当なのかという判断が、機械的にはできない。けれども、ひとまずはデータ上最初に出てきたものをセットしてみた。つまり、このようにしてセットした行については、位置情報を調整する（市区町村レベルの中心に近い町域を指定する）必要があるかもしれない。

2の場合、郵便番号データの町域情報では、そのような複数の町域指定を「町域共通部(町域1、町域2)」のような形式で指定しているようなので、ひとまず「(」の前までの町域共通部を利用して、そこまでマッチする位置情報が存在した場合は、その位置情報として登録するようにした。これは1と同様の問題があり得る。

3に関しては想定外だったが、街区レベル位置情報では網羅されていない市区町村というものが思いのほかたくさんあった。これらは、

• 単に街区レベル位置参照情報データには、掲載されなかった市区町村
• 新しくできた・合併した・改名された市区町村

などだろうか。特に地方（北海道や沖縄など）で目立つようだ。これらのデータに関しては、本来addressテーブルレベルで何らかの対応をするべきだろう（既登録データの修正もしくは新規登録など）が、その際には郵便番号データにしか存在しない市区町村データに関して、一件ごとの具体的な対応の検討等も必要になるため、現在は未対応（zip.zipcodeは登録したがzip.addressはnull）である。

4に関しては、ひとまず街区レベルの情報は無視して、1と同様の対応を行った。これは1と同様の問題があると同時に、場合によっては3と同様にaddressテーブルレベルでの対応も行うべきだろう。新規にaddressテーブルに追加する場合は、独自に位置情報データ用意する必要がある。

5に関しては、2と同じような対応を行っているが、2よりもずれが大きい可能性が高い。というのは、基本的に文字列一致で処理を行っている都合上、街区レベル位置参照情報データと郵便番号データの二つで、町域レベルでの指定よりも建物レベルの指定の方が、その表記のずれが大きい可能性が高いからだ。これらも最終的にはデータ一つ一つに対しての検討が必要だ。

と、いろいろ問題はあるけれども、機械的に合成したデータでもそれなりに使えることは使えるようだ。このデータベースに対して、Wikiみたいに誰でも自由に位置情報の詳細を登録・修正できるインターフェースを用意してアップデートをかけていくと良さそうな気がするんだけど、それを実現するためにはいろいろ考えなければならないことがありそうなんで、ひとまずは機械的に作成したバージョンを公開しておく。

あと、それを使って作ってみたGoogle Mapsとの連動サンプルも。こちらはそのうち消える（というか1470.netのリニューアルバージョンの一部として再構成される）だろうけど。一応Firefoxでは一通り動くはず。Opera 8でも大丈夫っぽい。IEだと微妙に動作が怪しい（selectの自動生成周りの互換性が怪しい）けど、まあその辺は後々の課題ってことで。Google Mapsを使っているんでJavaScript必須ね。

4のパターンは

漢字表記が違うというのもあるらしい。「杉並区堀ノ内」が「杉並区堀之内」になっていたり。どっちが正しいんだろう？　っつーか地名表記漢字に「公式」ってのはあるのかな？

作ったとたんに

たたみラボ: GoogleがGeocodingAPIリリース!なんて話が……。