株式会社estieでは、建物の住所や緯度経度を管理しています。建物の住所と緯度経度は一対一で対応するものではないため、頑張って正しい状態を維持していますが、様々な原因からどうしても間違いは生まれます。今回は、住所と緯度経度からその間違いを見つける話をします。
住所とその範囲はオープンデータで提供されています。そのため、例えばestieのオフィスのある東京都港区赤坂の範囲は下図のように可視化できます。
そしてestie マーケット調査で「赤坂（港区）」で検索すると、840件の建物がヒットします。大体正しそうです。でも、大体正しそう…としかわかりません。
全ての地区で建物の場所と住所が正しいかを確認するのは難しいです。新しい建物データを登録する度に各種APIや入力者の注意力を使って99.9%は正しい状態を維持できていると思いますが、プログラムも人間も間違えることはあります*1。
ということで、不整合を検出する仕組みをまた一つ追加しました。具体的には、建物の緯度経度と各自治体のポリゴンを使い、建物が所属している自治体の名称を特定し、建物が持つ住所との一致を確認しました。例えばestieが入居しているミッドタウン・イーストは、東京都・港区・赤坂・9丁目の4つのポリゴンに属しており、住所の「東京都港区赤坂9丁目7-2」と合致しています。
一方で、以下のような緯度経度のズレも見つかりました。下の例では建物が道路上に存在してしまっています*2。
幸いにも解体済の建物のデータだったためサービスには影響がありませんでしたが、このような緯度と経度のズレを検出できます。他にも、緯度と経度がなぜか1 km以上ズレた建物も西早稲田にありました。また、東京都台東区上野にあるのに住所が「東京都台東区台東…」となっていた建物もありました。札幌市北区にあるのに札幌市中央区の自治体に紐付いていた建物もありました。これらはブログを書きながら修正したので、皆さんがこの文章を読んでいるころには直っています。
ところで、全てのデータが正しいのに検知してしまう例もあります。例えば住友不動産御茶ノ水ビルは、東京都千代田区と東京都文京区との境界をまたぐように建てられています。そのため、住所は入口のある東京都千代田区を採用し、代表点は建物の中央付近の文京区を採用した結果、ポリゴンとの整合性チェックでは不整合だと判別されてしまいます。
知ってはいましたが、このような建物が抽出されることで住所や自治体への理解が深まります（自分が住んでいる文京区より千代田区ブランドを選ばれているのは少し悔しい気もしますが千代田区なら仕方ありません）。
他にも「都心三区」や「大手町・丸の内・有楽町エリア（大丸有）」など、不動産特有のエリアの区分もあります。これらを正しく簡単に管理できるようにデータの構造を工夫すると共に、そこに生じる誤りを防ぐ取り組みを進めています。
オープンデータも完璧ではない
今回使用したオープンデータは質・量ともに優れており、特に大量の自治体データが使いやすい形式で提供されていることはありがたいです。しかし、完璧ではありません。
例えば、オープンデータには東京都台東区に東京都文京区湯島を含んでしまうなど、境界付近ではどうしても不整合がありました。estieが使用しているSnowflakeではST_DISTANCE関数を使っているため10 m以上間違っている場合などと抽出条件は工夫できますが、間違えやすく気がつきにくいのもまた境界付近でもあり、もどかしくもあります。
そのためestieでは、より精度の高い確認を可能とし、さらに高速にプロダクトを動かせるデータの管理方法・紐付け方法を採用しています。気になった方は応募して社員になってください！
