top of page

データとしての「住所」のユニーク性(またはGoogleジオコーディングAPIで結果が得られないのはなぜか?)


たとえば「住所はユニークではない」と言ったとします。 何言ってんのこの人、という反応が返ってくるでしょう。 ユニークでなかったら郵便が届かない、と言われると思うのですね。

しかしそもそも「住所のユニーク性」とは、ということを考えた場合に、似て非なる2つの概念があると思われます。

1)日本全国の住所リストの中でユニークである 2)特定の住所文字列と特定の地点が1対1のユニークな関係である

「住所がユニークでなければ郵便が届かないじゃん」というのは、 このうち、1)について指していることになるわけです。 ただしこれも厳密に言えば、 ・同一市区町村内に同町名を持たない というルールに基づいて各市区町村が町名を設定している点がユニーク性の担保になっているわけですから、「フルネームである場合」という条件付きのユニーク性ですよね。 (たとえば「千葉県船橋市船橋」と「東京都世田谷区船橋」など)

さて問題は2)です。日常生活の中ではこの問題を想定するような場面が無いので、意識されづらいのではないかと思います。 (後述しますがこの認識は出身地によっても左右される可能性があります)

そもそも、我々が「住所」と呼んでいるものは何でしょうか?

狭い意味で言う場合には、「住居表示法」の指すところのそれなのでしょうが、広い意味では、次のものを無意識にふわっと包含した概念であったりするのではないかと思うのです。

・総務省(旧郵政省)が作成した住所(=郵便番号基準) ・総務省(旧自治省)が作成した「住居表示 ・法務省が不動産登記として管理している「地番 ・国土交通省が作成した「位置情報(測量情報)」

「いや普段『住所』って聞いて郵便番号とか測量とか考えないから!」 という話ではなく、それぞれの意図するものと概念が、「住所」という言葉に含まれている、という意味です。

たとえば住所の「正しさ」という面から考えた場合に、 ・郵便にとっては、間違えず宛名に届くことが「正しい」 ・不動産登記としては、土地の所有者と範囲がわかることが「正しい」 ・位置情報としては測量結果に誤りが無いことが「正しい」 と、それぞれ異なるものの、 ・文字列として ・経路として ・場所として という言い方をすると、確かに通常「住所」という言葉を使う際に、それら複数の概念を無意識に含めていることに気付かされます。

では先ほど挙げた項目のうち「住居表示」においては何が正しいのか、というと、これはもう、長らく論争が続いてきたのであります。 ざっくりまとめると ・住所がグダグダで困る ・実証実験したら無理だわこれ ・とりあえず実行は市区町村にまかせようか ・土地の歴史を無視するのか!という運動が出る ・歴史と伝統を残そう ・じゃあ市区町村はそのへんも考えてよろしく という具合な歴史をたどっています。

結果としてどうなったかというと、 ・必要な人たち(郵便や電力会社等)は各自で必要な情報を管理することにした ・住居表示が整備された地方もされていない地方も存在する ・もちろん地番=住所という場所もある ・その間(埋め立てなどで)新たに生まれた土地もある という、全体としてカオス度が増す、という惨事になりました。 しかも、局所局所では最適化されているため、全体としては話が終わってしまっているようです。

そして21世紀も十数年過ぎた現在ですが、個別のデータ塊があるというだけでは困るよ、というご時世になっておるわけです。

具体的にはたとえば、GPSやらGoogleマップやらなんやらある中で、「特定の緯度経度が何県何市の何丁目何番なのか」ということがわからないのはどうなんだ、ということです。 地図会社はこの点、国土地理院の測量結果に自分たちで調べた建物名などを結びつける、という手段で地図を作ってきました。 Googleなどの場合は、Web上の住所情報なども加味して結びつけをしていますね。 確かに検索する人間の行動と意図からするとこれもまた「正しい」ことになると思われます。

さてここからが本題のようなものなのですが…

GoogleマップのAPIに、「Google Geocoding API」というものがあります。 つまり「住所」から「緯度経度」(またはその逆)を入手するためのAPIです。

これで検索してみるとわかるのですが、「緯度経度の得られない」住所が、意外と多く存在します。 真面目な開発者なら「使い方が間違っているんじゃないか?」と思って悩んでしまうと思うのですが、間違っているのは住所の方なのです。

#おそらく、出身地によってはここまでの説明で「あぁ」となる人もいそうですね

「いや、この住所は絶対に存在する」という反論が出るかもしれません。 確かに存在するのかもしれませんが、この記事の前段のダラダラした部分を既にお読みくださった方には、なんとなく嫌な予感がしているのではないかと推察します。 お察しの通り、いくつかの理由で、「対応する緯度経度の無い住所」が存在するのです。 と同時に、それが多発する地域があります。 いくつかありますが、まず京都市から話を始めます。

京都以外の人にとっても有名な話ではありますが、京都市内の住所は伝統的に「烏丸通高辻上る」というように表現されています。この場合は「烏丸通りと高辻通りの交差点を御所方面へ向かった地点」ということになりますね。 まず、これが昔から成立しているので、これ以外の「住所」の必要が無いということになります。

と、ごちゃごちゃ言っていてもまわりくどいので、例として「下京警察署」を挙げます。

住所は「〒600-8413 京都市下京区烏丸通高辻上る大政所町682番地」とされています。

郵便番号から検索してみましょう。 600-8413 「京都市下京区大政所町」の住所とされています。つまり郵便局は「町名+番地」でこの住所を認識しているわけです。

「京都市下京区烏丸通高辻上る大政所町682番地」をGoogleジオコーディングAPIで緯度経度に変換してみます。 京都市下京区烏丸通高辻上る大政所町682番地 これは、結果はありますが、「烏丸駅」であると見なされています。 つまり、およそのエリアとしては認識されたものの、そのものズバリはわからなかったため、最も近いランドマークの緯度経度が返ってきた、という状態です。

では次に、「京都市下京区烏丸通高辻上る」「京都市下京区烏丸通高辻上る682番地」をGoogleジオコーディングAPIで見てみます。 京都市下京区烏丸通高辻上る 京都市下京区烏丸通高辻上る682番地 該当なし、という結果が返ってきます。 これは、指定された住所が認識できなかったことを意味します。 たとえば、「京都市下京区」と指定した場合でも認識はされますので、上記では「京都市下京区」の住所としても認識できなかったことになります。

最後に、「京都市下京区大政所町682番地」をGoogleジオコーディングAPIで見てみます。 京都市下京区大政所町 住所は認識され、緯度経度が取得できます。

長々と書いてきましたが、つまりどういうことかと言いますと、「京都の人が認識している住所と、郵便その他が認識できる住所は異なる」ということです。 客観的に見ると、「で?」というように見えますが、実際にそこに住んでいる人からすると、困惑する結果ではあると思うのです。 「正しい住所は何?」と聞かれてもわからないですからね。

同じことが、札幌や旭川などでもあります。 ここでも例を挙げてみます。

住所は「〒070-8521 北海道旭川市6条通10丁目左10号」とされています。

まず「北海道旭川市6条通10丁目左10号」をGoogleジオコーディングAPIで見てみます。 北海道旭川市6条通10丁目左10号 一応結果が返ってはくるのですが、2条通の別のランドマークの結果になってしまっています。

次に「北海道旭川市6条通10丁目10号」をGoogleジオコーディングAPIで見てみます。 北海道旭川市6条通10丁目10号 座標が返ってきました。が、この座標43.7696078,142.3664716を確認してみると、隣のブロックになってしまいます…。この座標では、「6条通10丁目」は正しいのですが、「右10番」になってしまうはずです。

道路としての「7条通」は、9丁目から12丁目まで存在しませんが、住所としての「7条通」は、道路があった場合の位置に沿って存在します。同じブロック内でも、旭川市第三庁舎は7条通で旭川中央警察署は6条通ですね。

では、旭川中央警察署の「正しい」住所はどうなるのか、というと、「旭川自動車安全運転センター」の所在地が「旭川市6条通10-2231-1」となっていることから見ると、おそらくこれに近い地番が存在するのでしょう。 GoogleジオコーディングAPIで「旭川市6条通10丁目2231」を見てみると、緯度経度は「43.7707494,142.3670573」と返ってきます。 これをGoogleマップで見ると、旭川中央警察署とは微妙にズレた位置にピンが立っているので、やはり「旭川市6条通10丁目2231」としては認識されていないようです。

ともあれ、旭川中央警察署に「正しい住所は何番ですか?」と聞いても、「北海道旭川市6条通10丁目左10号」という答えしか返ってこないだろうと思います。 人が認識している住所とのズレがある、というのはこういう点です。

上記のようなパターンは、京都・旭川の他にも札幌などいくつかの都市に存在しています。

また、碁盤の目状の都市だけではなく、再開発によって似たような現象が発生する場合もあります。

たとえば次のような例がありました。

とある駅前の角地にタバコ屋があり、それをとりかこむように家電量販店が建っていました。 地番は、タバコ屋が「1丁目1番」、家電量販店が「1丁目2番」でした。 しかしある時、タバコ屋の一角は取り壊され、家電量販店が改築して旧タバコ屋の土地部分に建屋を増やしました。 その後、家電量販店はチラシ等へ掲載する所在地を「1丁目1番」としました。

しかし正式な地番ではないので、「1丁目1番」の緯度経度を求めると、旧タバコ屋の位置であって家電量販店の緯度経度ではないのです。 微妙に数十メートルほどズレているわけです…。

次のような例もありました。

ある郊外の埋め立て地にショッピングセンターができたのですが、やはりその住所から緯度経度情報が得られないのです。 調べてみると、そのショッピングセンターがオープンしたのは数ヶ月前で、住所の「丁目」は1年前に新設されたものであることが判明しました。 国土地理院のデータは2年更新だったので、これはデータが追いついていないことが原因であると判明しました。

さて、ここまで読んでいただける方がいらっしゃるかどうか…とは思うのですが、締めに入りますと: 「住居表示」は人間の活動にあわせられているものなので、データとしての正規化やユニーク性の担保を期待すべきではない、というのが結論です。

しかしながら、では野放しなのか、と言うと、国土地理院は仕事をしてくれています!

2010年から「住居表示住所」というデータを公開しています。 http://www.gsi.go.jp/kihonjohochousa/jukyo_jusho.html 現時点でもまだ全てを網羅しているもののようではないようですが、そう遠くない将来、全ての住所はユニークな座標点とオフィシャルに相互変換可能になるのでしょう。

#仕事の方向性と地道さは本当にすばらしいと思うのですが、 #なんか形的に、つじつま合わせが技術者に押し付けられる、という #デスマパターンを思い出してちょっと嫌な気持ちになるんですよね…

最新記事

すべて表示

SQLite(sqlite3)で “no such table”

小ネタです。 SQLiteを使っていて "no such table" とエラーが出た場合、 DBファイル名の指定が空になっている、という凡ミスを起こしていないかを確認してみましょう。 ・・・ そういう凡ミスをしてしばし悩んだので… ファイル名の指定が空になっている場合、一時的なインメモリDBとして保存されます(※1)。 つまりDB接続を切断すると中身は消えます。 なので接続

アプリケーションサーバにポートを指定せずに起動すると?

最近、 Goで書かれたアプリケーションサーバが起動しない! ->原因: .env ファイルが欠けていた というドタバタがありました。 結局Goと関係ないですが、この時、 「あまりGoに慣れてないのでGoの問題かと…」「DockerまだよくわかってなくてDockerの問題かと…」 というような声があったのて、あえてGoで検証してみようと思ったわけです。 さて、Goでサーバサイドのシステムを作

GitLab 9.1.2 (MySQL) を 11.4.0 (PostgreSQL) にアップグレード

弊社ではかなり前からGitLab(CE)を自社環境で運用しているのですが、ふと気付くと、バージョンがだいぶ先に行ってしまっていました。 とくに最近のバージョンでは Auto DevOps なども使えるようになっていたりするので、さすがにそろそろキャッチアップしたいと考えたわけです。 現行の環境は次の通りです: GitLab 9.1.2 sameersbn/gitlab 使用 MySQL 5.6

bottom of page