« 明日もう一度のお伺い(結果報告) | トップページ | 進捗なし »

2014年11月 8日 (土)

住所データの扱いは難しい-3

先日、郵便番号データを更新したら、カナ版とローマ字版の差異が33件に増えていました。

ローマ字版では、
・データの更新タイミングがカナ版よりも遅れるようで、カナ版とデータ数の差異が発生する
・市 区、郡 町村、大字 字がスペースを開けて表記されている。
・町域の文字データが欠落していますが、カナ版で15文字以上のデータが、規則性なく、15文字、16文字、17文字以降がカットされている

郵便番号データそのものに
同じ漢字表記で読み方の違う町域が同じ郵便番号で存在する。

ということが判りました。

市と区の分離、郡情報の削除、字(あざ)情報の抽出、町域のアルファベット表記など、カナ版とローマ字版で共通した一意のデータを作って連結クエリーで更新しようと思ったのですが無理でした。

それぞれの変換テーブルを作って対処します。

まず、カナ版とローマ字版の共通項を作る為に、ローマ字版のテーブルに、市と区、郡と町村の間のスペースを除いたデータを作ります。

町域については、ローマ字版のデータから、町域と字(字)の間のスペースを除き、15文字以下のデータに揃えます。
カナ版についても、町域のデータを15文字以下に揃えたデータを作ります。

ここまである程度、作業もしながら方針を決めて来たのですが、町域データの記載方法に規則性が見いだせなくなりました。
特に()内の記載が意味不明です。
現状では使いようが無いので、()内のデータは複数行に分割されたデータをマージ後に消去します。

郵便番号データの複数レコードに分割されたデータの復元(マージ)はこんなスクリプトで行いました。

カナデータは、M_住所というテーブルに取り込んでいます。
町域の項目は、テキストのフィールドサイズ255でも入りきらず、メモ型に設定しました。
*11/09訂正 勘違いをしていたようです。マージ後のデータを調べなおしたところ、最大で252文字でした。フィールドサイズ255でマージ処理は完了できました。

IDフィールドは、オートナンバーでIDを振っています。

拙い、出来だとは思いますが、郵便番号データを触られる方の参考になればと思います。
使ってみての不具合などお知らせ頂ければ、対処を検討いたします。

郵便番号データの落とし穴
日本郵便の郵便番号データを解析してみる 第1回~住所のマージ編~
を参考にさせて頂きました。有意義な情報を有難うございました。

 

 

« 明日もう一度のお伺い(結果報告) | トップページ | 進捗なし »

VB.net 業務管理」カテゴリの記事

郵便番号データの住所入力データ化」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック


この記事へのトラックバック一覧です: 住所データの扱いは難しい-3:

« 明日もう一度のお伺い(結果報告) | トップページ | 進捗なし »

今日の体温(下は昨日)

  • 36.4℃
    36.4℃

スライムパンク防止剤被害低減プロジェクト

川越市周辺の自転車屋MAP

埼玉県内出張修理店情報

「パンク防止剤のスライムって知ってます?ママチャリに使うものらしいですが。」を読まれた方へ

自転車出張修理のブログ

自転車修理法の疑問はこちらへ

ブログランキング

カテゴリー

無料ブログはココログ