幾度か、「非IT屋の決めるコード体系は理解に苦しむ」ネタを掲げましたが、今回も。
郵便番号で遊んでいると、次のようなデータがありました。
0600063 北海道 札幌市中央区 南三条西（１～１８丁目）
0640803 北海道 札幌市中央区 南三条西（２０～２８丁目）
0600054 北海道 札幌市中央区 南四条東
0640804 北海道 札幌市中央区 南四条西
0600055 北海道 札幌市中央区 南五条東
0640805 北海道 札幌市中央区 南五条西
0600056 北海道 札幌市中央区 南六条東
0640806 北海道 札幌市中央区 南六条西
0600057 北海道 札幌市中央区 南七条東
0640807 北海道 札幌市中央区 南七条西
素直に、考えたら、郵便番号はキー項目にしたいし、順序採番して欲しいとろです。実際は、郵便番号は重複しているのがあるようです。
同じ「南三条西」でも丁目によって、3桁目が異なるのは、どうも落ち着きが悪い。
最初に採番したときは、札幌市中央区 060-xxxxの連番を振ったのでしょう、その後町域が広がって、丁目が増えたり、町を東西に分けたのでしょう。
その際、空き番がないから、064-xxxxをつかったものと、類推されます。
いかにもな採番に見えます。 町域が広がるのは容易に想像付く筈なのに、なぜコード化するときに考慮しなかったのかなぁ。
郵便番号のコード化のルールが存在するなら、知りたいものです。
"北都留郡小菅村","以下に掲載がない場合",
この分類は、仕方ないなぁと思います。
そうかと思うと、読み仮名の項目に ">" の文字が入っていたりします。
データをXML化して、XML処理の検証に使おうと加工すると、必ず、落ちるんですよ。追求していくと、
「ｵｵｴ(1ﾁｮｳﾒ､2ﾁｮｳﾒ<651､662､668ﾊﾞﾝﾁ>ｲｶﾞｲ､3ﾁｮｳﾒ5､1」のデータがあるではないですか。
"長野県","長野市","青木島町青木島乙（９５６番地以外）"こんな排他判断が必要なデータがあったり
"大阪府","大阪市中央区","城見松下ＩＭＰビル（地階・階層不明）" "不明"となっているのは、落ち着かない。
"京都市上京区","一町目（上長者町通堀川東入、東堀川通上長者町上る、東堀川通中" 京都の住所は例外扱いてす。
"北都留郡小菅村","小菅村（１～６６３）"
"北都留郡小菅村","小菅村（６６４以上）"
"大江（１丁目、２丁目「６５１、６６２、６６８番地」以外、３丁目５、１"
このあたりになると、プログラム処理は厳しくなります。し "（"があるのに閉じ")"がなかったり
"青森県","上北郡六戸町","四木、七百、下久保「１７４を除く」、下淋代、高森、通目木、坪毛沢「２"
"「"が閉じてなかったりします。
これから邪推すると、郵便会社のマスターデータはもっと長い住所項目があり、一定長でぶち切ったと感じます。
と思ったら、同一郵便番号のデータが複数件あり、次の例だと 4件で"03300071" を表すようです。
"0330071","上北郡六戸町","犬落瀬（内金矢、内山、岡沼、金沢、金矢、上淋代、木越、権現沢、"
"0330071","上北郡六戸町","四木、七百、下久保「１７４を除く」、下淋代、高森、通目木、坪毛沢「２"
"0330071","上北郡六戸町","５、６３７、６４１、６４３、６４７を除く」、中屋敷、沼久保、根古橋、堀切"
"0330071","上北郡六戸町","沢、南平、柳沢、大曲）"
無料で配るデータとはいえ、こんなレコードいやだなぁ。IT処理で不具合が発生しないような形にして欲しいなぁ
郵便番号の自動判定は無理なようですね。
逆にコード体系は、緻密でなくて、大雑派に決めて、桁不足になってから、継ぎ接ぎしてもシステムとして不具合なければ良いのかも知れませんね。