KEN_ALL.csv のどこがだめなのかまとめてみる
KEN_ALL.csv はだめだとよく言われます。では何がだめなのでしょうか。 Blogや Twitterなどでよく語られているので、その内容を紹介してみたいと思います。
Blog 「ぐるぐる〜 」
まず、かなり網羅的にまとまっていたのが、下記の ブログ「ぐるぐる〜 」のエントリです。
項目としては、下記のようなものが上げられています。あるあるですね…
- 単一レコードの複数行分割
- 「以下に記載がない場合」、「次のビルを除く」を含むレコード
- 「〜」で範囲を示すレコード
- 「〜」や「以上」、「以下」を含むレコード
- 「以外」「を除く」を含むレコード
- 「その他」を含むレコード
- 「全域」を含むレコード
- 「（丁目）」、「（郡）」、「（番地）」などを含むレコード
- 「を含む」を含むレコード
- 「地階・階層不明」を含むレコード
- 複雑な、としか言い表せないレコード
- その他
一番くそだと思うのが、 1. 単一レコードの複数行分割 これに尽きます。 CSVの概念を覆してきます。固定長 CSVかよ。 これがある時点で、CSVを1行ずつ処理して… というのができなくなります。
Blog 「my-hobby」
こちらは、実際に zipnavi というサービスを作るにあたって直面した問題についてまとめられてます。
- 日本郵便の郵便番号データを解析してみる 第１回～住所のマージ編～ | my-hobby
- 単一レコードの複数行分割
- フラグ4の信頼性について
- 単一レコードの複数行分割
- 日本郵便の郵便番号データを解析してみる 第２回～括弧の意味編～ | my-hobby
- 町域にある「（）」括弧 の扱い、（）内データの展開について
- 日本郵便の郵便番号データを解析してみる 第３回～カンマなどの区切り文字編～ | my-hobby
- 区切り文字「、」「及び」「・」について
- 日本郵便の郵便番号データを解析してみる 第４回～範囲の指定編～ | my-hobby
- 範囲指定文字「～」「以上」「以下」の扱いについて
- 日本郵便の郵便番号データを解析してみる 第５回～「その他」編～ | my-hobby
- 「その他」の扱いについて
- 郵便番号データの廃止データを解析してみた | my-hobby
- 住所の廃止について
- 市町村合併によって住所が廃止されたケース
- 住所自体が廃止となったケース
- 住所の呼び方が変わったケース
- 住所の表記が変わったケース
- 住所の廃止について
Blog「Studio JamPack」
郵便番号データについて思ったこと – Studio JamPack
大口事業所はまた別データになってるんですよね（JIGYOSYO.CSV）
- 住所の郵便番号と大口事業所個別番号が別データとなっている
- 全国地方公共団体コードが規格に沿っていない件
- 郵便番号データでは5ケタしかなく、チェックデジットが省略されてる
郵便番号DBを利用するときに考慮すると幸せになれること – Studio JamPack
- 1つのクエリに2つ以上のレコードが返ってくる
- 町域がやたら長い（括弧表記されている）
- 廃止レコードが複数ある
- 8191131 福岡県
- 同じ町域でも郵便番号が異なる
- 8190166 福岡県 福岡市西区 横浜（１～２丁目）
- 8190366 福岡県 福岡市西区 横浜（３丁目）
- やたら大量の件数を返す
- 4520961 愛知県 清須市
サイト 「Qiita」
エンジニアのノウハウがつまったサイト Qiita でも時々話題になっています。
感想
本当につらいですね。日本郵便さん、元データ、なんとかならないものでしょうか。
世の中には同じような苦労をしてきている方がたくさんいらっしゃいます。その方々の先人の成果がOSSソフトウェアや、サービスとして存在していますので、次にはそのあたりも紹介してみたいと思います。
また、そもそもこの KEN_ALL.csvを使わなければこのような苦労はないわけで、KEN_ALL.csv 以外に、信頼できるデータがないものか、調査してみたいと思います。
