USB ID

smartmontools の USB HDD 対応状況を調べている時に、 手持ちの HDD が Smartmontools USB Device SupportUSB ID Repository に 収録されていないことに気づいた。

折角なのでデータを送ろうかと思ったのだが、そうすると、 手持ちの USB機器を一通り調べて見たくなるのが凝り性の悪いところで、 すぐに出てくる場所にあった機器については下記の通り。 (他に、スキャナとプリンタが押入れにあるが、面倒なので調査対象から外した。 あとUSBメモリも除外)

種別 販売元・製品型番 USB ID USB デバイス名
HDD BUFFALO HD-LB2.0TU2 0411:01ba BUFFALO USB-SATA Bridge
HDD BUFFALO HDF-LB2.0TU2 0411:01ea BUFFALO USB-SATA Bridge
HDD BUFFALO HD-LC3.0U3-BKC 0411:027e BUFFALO HD-LCU3
HDD Logitec LHD-PBE40U2SV 0789:00cc Logitec LHD USB Device
DVD Panasonic LF-P968C 04da:0d14 Panasonic DVD-RAM MLT08
DVD BAFFALO DVSM-PL58U2 0411:00f9 BAFFALO USB2.0 External Mass Storage Device
SATA変換ケーブル GREEN HOUSE GH-USHD-SATA 152d:2339 JMicron JM20339 SATA Bridge
IDE変換ケーブル GREEN HOUSE GH-USHD-IDE 05e3:0702 Genesys Logic
有線LAN BUFFALO LUA3-U2-AGT 0411:006e BUFFALO
無線LAN PLANEX GW-US54GXS 2019:5303 PCI GW-US54GXS
キーボード SANWA Supply SKB-SL09BK 099a:6330 Zippy Technology Corp. USB Keyboard
有線マウス BUFFALO BSMOUK01 093a:2510  
無線マウス ELECOM M-LS14DL 25a7:2410 ARESON Laser mouse
無線マウス ELECOM M-BL2DB 056e:0092 ELECOM Wireless BlueLED Mouse
キーボード切替ケーブル BUFFALO BSKM201BK 2101:1402 ActionStar KM Switch
USBハブ ELECOM U2H-M4BWH 0409:005a (NEC Corp. High Speed Hub)
USBハブ ELECOM U2H-TAP3420SBK 0409:005a (NEC Corp. High Speed Hub)
カードリーダー ELECOM MR-GU2S04SV 0dda:2001 ICSI USB2.0 Card Reader
ヘッドホン BUFFALO 製品名不明 0c76:1607 JMTec, LLC. audio controller USB Headphone Set

販売ブランドと USB のベンダIDが違っているのは OEM 製品ということなのかな。

USB HDD (2)

過去に使用していた USB HDD についても smartctl の結果を記しておく。

BUFFALO HD-LB2.0TU2

テレビ用の1台目。2011年購入。

PC への接続時の dmesg は下記の通り。

ugen1.2: <BUFFALO USB-SATA Bridge> at usbus1
umass0: <BUFFALO USB-SATA Bridge, class 0/0, rev 2.00/1.12, addr 2> on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x8100
umass0:6:0:-1: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0: <BUFFALO External HDD 0000> Fixed Direct Access SCSI-3 device
da0: 40.000MB/s transfers
da0: 1907729MB (3907029168 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>

smartctl の -d オプションをいろいろ変えて試してみたが、 結局うまく行かなかった。ドライブ自体には SMART があると思うのだが、 機器側の USB ブリッジが SMART に対応していないのか、 smartctl がこのブリッジに対応していないのか、どちらかだと思うが、 どちらなのかは判らない。

USB ブリッジの USB ID は 0x0411:0x01ba。 中のドライブの型番が読み出せないので中身は不明。

BUFFALO HDF-LB2.0TU2

テレビ用の2台目。確か2012年購入。

PC への接続時の dmesg は下記の通り。

ugen1.2: <BUFFALO USB-SATA Bridge> at usbus1
umass0: <BUFFALO USB-SATA Bridge, class 0/0, rev 2.00/1.00, addr 2> on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0xc101
umass0:6:0:-1: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0: <BUFFALO External HDD 0000> Fixed Direct Access SCSI-3 device
da0: 40.000MB/s transfers
da0: 1907729MB (3907029168 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>

smartctl の自動推測がうまく働き、-d オプションの指定なしでもうまく行った。 内部的には -d sat を使用しているようだ。

# smartctl -i /dev/da0
=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Green
Device Model:     WDC WD20EARX-00PASB0
Serial Number:    WD-WCAZAE534488
LU WWN Device Id: 5 0014ee 25c684be6
Firmware Version: 51.0AB51
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 1.5 Gb/s)
Local Time is:    Tue May  8 15:24:43 2018 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

中身は WD の緑のようだ。

USB ブリッジの USB ID は 0x0411:0x01ea。

Logitec LHD-PBE40U2SV

ポータブルHDD。いつ頃の購入だったか覚えていないが、 容量 40GB なので、だいぶ昔だということは間違いない。 15年前くらいか?

PC への接続時の dmesg は下記の通り。

ugen1.2: <Logitec Corp. LHD USB Device> at usbus1
umass0: <Logitec Corp. LHD USB Device, class 0/0, rev 2.00/1.16, addr 2> on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x0000
umass0:6:0:-1: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0: <LOGITEC LHD-PBEU2 1.16> Fixed Direct Access SCSI device
da0: Serial Number 0406122020000689
da0: 40.000MB/s transfers
da0: 37954MB (77730300 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
cd1 at umass-sim0 bus 0 scbus6 target 0 lun 1
cd1: <LOGITEC VIRTUAL CD-ROM 1.16> Removable CD-ROM SCSI device
cd1: Serial Number 0406122020000689
cd1: 40.000MB/s transfers
cd1: 109MB (55983 2048 byte sectors)
cd1: quirks=0x10<10_BYTE_ONLY>

da の他に cd デバイスが認識されるのは、製品のマニュアルを 仮想CD-ROM として内部に格納しているからだ。

-d オプションを指定しても、smartctl からは内部が見えなかった。

USB ID は 0789:00cc。

GREEN HOUSE GH-USHD-SATA

これは HDD ではなく、SATA の生ドライブを PC に接続するための変換ケーブル。 購入時期はよく覚えていないが、IDE用のケーブルと一緒に買ったので、 HDD のインターフェイスが IDE から SATA に切り替わりつつある頃だろう。

試しに使い古しの生ドライブを接続すると、下記のような dmesg が出る。

ugen1.2: <JMicron USB to ATAATAPI Bridge> at usbus1
umass0: <MSC Bulk-Only Transfer> on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0xc100
umass0:6:0:-1: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0: <WDC WD80 0JD-08LSA0 > Fixed Direct Access SCSI-2 device
da0: Serial Number DA9A535973FF
da0: 40.000MB/s transfers
da0: 76324MB (156312576 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>

製品の中身は JMicron 製のようだ。 smartctl の自動推測が効いて、-d オブション無しで SMART が見られる。 内部的には -d usbjmicron が使用されているようだ。

USB ID は 152d:2339。

Tinkerer 1.7 と Python 2

新しく Tinkerer 1.7 をセットアップしたのはいいが、ビルドが失敗する。

$ tinker -b
Running Sphinx v1.7.4

Extension error:
Could not import extension tinkerer.ext.blog (exception: No module named builtins)

情報が足りないので、python 上で import を実行してみる。

$ python
Python 2.7.14 (default, Sep 27 2017, 12:15:00)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import tinkerer.ext.blog
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/maita/manuscript/webdocs/venv/lib/python2.7/site-packages/tinkerer/ext/blog.py", line 11, in <module>
    from tinkerer.ext import (aggregator, author, filing, html5, metadata, patch,
  File "/Users/maita/manuscript/webdocs/venv/lib/python2.7/site-packages/tinkerer/ext/aggregator.py", line 12, in <module>
    from tinkerer.ext.uistr import UIStr
  File "/Users/maita/manuscript/webdocs/venv/lib/python2.7/site-packages/tinkerer/ext/uistr.py", line 12, in <module>
    import builtins as __builtin__
ImportError: No module named builtins

エラーの真の出所は tinkerer.ext.uistr。Python のビルトインモジュールは、 Python 2 では __builtin__ という名前だが Python 3 で builtins に変わった。 該当のコードは Python 3 で実行した場合にその違いを吸収するためのものだろうが、 Python 2.7 で実行すると逆に builtins モジュールが無いので、ImportError が出るのは当然だ。

uistr.py を直接修正するのが一番簡単だろう。

#import builtins as __builtin__
import __builtin__

面倒だが、まぁ、未だに Python 2 を使い続けている自分が悪いのだ。

USB HDD の SMART を確認する

テレビの録画に使用していた USB HDD がエラーを出すようになった。 テレビ本体は 2011年購入の東芝REGZAなのだが、備忘のために症状を詳しく記すと、

  • 予約した録画が開始せず、クイックメニュー > お知らせ > 本機に関するお知らせに「録画機器の接続を確認できなかったため、録画予約を中止しました」というメッセージが追加される。
  • 録画実行中に録画が停止し、クイックメニュー > お知らせ > 本機に関するお知らせに「録画機器にエラーが発生したため、録画予約を中止しました」というメッセージが追加される。
  • 録画再生中に「この操作はできません」と一瞬表示されたあと、画面が真っ暗になる。

HDD のエラーと言うとまず不良セクタを疑う。 その場合は、録画再生で必ず同じ場所でエラーが出る筈だが、 今回の場合はそうではなく、エラーが出る場所がまちまちだったので、 その可能性は低いと思われた。

それよりも、電源や駆動系の劣化によってパフォーマンスが低下し、 スピンアップやヘッドシークが遅くなったりして、 リアルタイム処理に追いつかなくなってるような感じがした。

とは言え、こういう問題について「感じがした」なんていう 印象論を語っても意味はない。不良セクタの有無はディスクの SMART を確認すれば判るのだから、 HDD を PC に接続して実際に SMART を見てみることにした。

PC は FreeBSD 10.4R に pkg で smartmontools 6.6 をインストールしたもの。

HDD は BUFFALO DriveStation HD-LC3.0U3-BKC。確か2015年に購入。

まず、HDD の USB ケーブルを PC に挿した時にコンソールに表示されるメッセージは下記の通り。

ugen1.2: <BUFFALO HD-LCU3> at usbus1
umass0: <BUFFALO HD-LCU3, class 0/0, rev 2.10/1.00, addr 2> on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0xc101
umass0:6:0:-1: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0: <BUFFALO External HDD 0000> Fixed Direct Access SCSI-3 device
da0: 40.000MB/s transfers
da0: 2861588MB (5860533168 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>

smartctl はデバイスの種類を自動的に推測する機能があるが、 この製品ではうまく推測できないようで、以下のような結果になる。

# smartctl -i /dev/da0
smartctl 6.6 2017-11-05 r4594 [FreeBSD 10.4-RELEASE-p8 amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

/dev/da0: Unknown USB bridge [0x0411:0x027e (0x100)]
Please specify device type with the -d option.

USB HDD は中身に SATA ドライブを使用していることが多いようなので、 -d sat を指定してみると、やはり正常にアクセスできるようになった。 (以下、smartctl の出力のコピーライト部分は省略)

# smartctl -i -d sat /dev/da0
=== START OF INFORMATION SECTION ===
Model Family:     Toshiba 3.5" DT01ACA... Desktop HDD
Device Model:     TOSHIBA DT01ACA300
Serial Number:    25PHEW5GS
LU WWN Device Id: 5 000039 ff4f14c2b
Firmware Version: MX6OABB0
User Capacity:    3,000,592,982,016 bytes [3.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Tue May  8 09:12:06 2018 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

中身は東芝製ドライブのようだ。SMART をサポートしているようなので、 まずはエラーログを見てみる。

# smartctl -d sat -l error /dev/da0
SMART Error Log Version: 1
No Errors Logged

エラーは出ていない。次に -A オプションで attribute を確認する。

# smartctl -d sat -A /dev/da0
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   140   140   054    Pre-fail  Offline      -       67
  3 Spin_Up_Time            0x0007   134   134   024    Pre-fail  Always       -       413 (Average 439)
  4 Start_Stop_Count        0x0012   099   099   000    Old_age   Always       -       6336
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   124   124   020    Pre-fail  Offline      -       33
  9 Power_On_Hours          0x0012   099   099   000    Old_age   Always       -       7029
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       4844
192 Power-Off_Retract_Count 0x0032   095   095   000    Old_age   Always       -       6336
193 Load_Cycle_Count        0x0012   095   095   000    Old_age   Always       -       6336
194 Temperature_Celsius     0x0002   222   222   000    Old_age   Always       -       27 (Min/Max 3/62)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

ID 5 や ID 196 から明らかなように、セクタの代替処理がまったく発生していない。 その他の項目も、これと言って悪いところはなさそうに見える。 やはりディスク自体はまあまあ健全で、少なくともデータロストの危険はなさそうだ。

念のため、SMART の自己テストを実行してみる。short テストは 1,2分、long テストは 6時間ちょっと掛かった。

# smartctl -d sat -l selftest /dev/da0
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      7035         -
# 2  Short offline       Completed without error       00%      7029         -

やはりエラーなし。

となるとエラーの原因は、電源かUSBケーブルかインターフェイス部か、ということになるが、 これ以上の原因特定は難しそうなので(エラー自体の再現性が低いので)、 結局新しい USB HDD を購入して交換することにしたのであった。

QGISで表示できないshapefile

外部の人から受け取った SHAPE 形式のGISデータを、 QGISで見てみようとしたところ、データはちゃんと入っているっぽいのに 画面には何も表示されない、という状況になり、 原因調査にちょっと時間が掛かったのでメモしておく。

原因

先に結論を述べると、地物のジオメトリが緯度経度座標なのに、 bounding box (以下BBOX)がウェブメルカトル(EPSG3857)座標になっていたのが原因。

受け取ったデータはポリゴンデータだったのだが、 ポリゴンデータのような、複数の座標を持つジオメトリ型の場合、 SHAPEファイル内には、

  • レイヤ全体のBBOX
  • 個々のジオメトリごとのBBOX

が保持される。詳しくは ESRI の解説書 を見よ。

今回のケースでは、レイヤ全体のBBOXはジオメトリデータと同じく 緯度経度座標になっていたのだが、ジオメトリごとのBBOXは 何故か EPSG3857 になっていた。 おそらくQGISは、ジオメトリごとのBBOXを律儀に適用し、 地物の表示をマスクしてしまった、ということだと思われる。

症状

原因調査に時間が掛かったのは、SHAPEファイルを読み込ませた時に QGISが何もエラーを出さなかったからだ。

同様に、ogrinfo もエラーを出さなかった。 ogrinfo を実行すると Extent という表記でBBOXを表示するが、 これはSHAPEファイル内の「レイヤ全体のBBOX」の数値で、 ジオメトリごとのBBOXはまったく出力されない。

原因特定

ogr2ogr を使って SHAPE形式からSHAPE形式に変換したところ、 QGISで表示できるようになったので、バイナリ用diffを使って 変化した部分を特定し、ESRIの説明書と突き合わせて ジオメトリごとのBBOXが不適切であることを突き止めた。

HEX表記の浮動小数点データを10進表記にする作業には、 python の struct モジュールを使用した。

他の環境関係法令による政令市

指定都市等のリストは 総務省 を参照するのが確実かな。

さて、いろいろややこしい。

水質汚濁防止法

水質汚濁防止法施行令 第10条に、指定都市と中核市に加えて

  • 福島市
  • 市川市
  • 松戸市
  • 市原市
  • 町田市
  • 藤沢市
  • 徳島市

が挙げられている。

特例市については、かつては令第10条に記載されていたが、 地方自治法改正に合わせて条文から削除し、 H27.1.30付の附則で経過措置として施行時特例市に従来通りの事務委任を 続けるという規定が定められている。

だから実質的には、指定都市、中核市、施行時特例市、上記7市に 水質汚濁防止法の事務が委任されている。

騒音規制法

H23年度までは、(旧)騒音規制法施行令第4条第1項において、

  • 一関市
  • 日立市
  • 土浦市
  • ひたちなか市
  • 桐生市
  • 松戸市
  • 君津市
  • 上田市
  • 多治見市

に、自動車騒音常時監視の事務が委任されていた (H21年度版環境六法で確認)。

指定都市、中核市、特例市、特別区には自動車騒音常時監視に加えて 他の事務も委任されていた(旧令4-2)。

H24年度からは、地方自治の推進のため、すべての一般市にも 指定都市に対するものと同様の事務が委任されるようになった。 それに合わせて令第4条は削除された。

だから現在では、騒音規制法に定める政令市、というものはない。

振動規制法

H23年度までは、(旧)振動規制法施行令第5条において、 指定都市、中核市、特例市、特別区 に事務が委任されていた。

H24年度からは、地方自治の推進のため、すべての一般市にも 指定都市に対するものと同様の事務が委任されるようになった。 それに合わせて令第5条は削除された。

だから現在では、振動規制法に定める政令市、というものはない。

悪臭防止法

H23年度までは、(旧)悪臭防止法施行令第3条において、 指定都市、中核市、特例市、特別区 に事務が委任されていた。

H24年度からは、地方自治の推進のため、すべての一般市にも 指定都市に対するものと同様の事務が委任されるようになった。 それに合わせて令第3条は削除された。

だから現在では、悪臭防止法に定める政令市、というものはない。

ダイオキシン類対策特別措置法

ダイオキシン類対策特別措置法施行令 第8条に、指定都市と中核市に対する事務委任が規定されている。

特例市に関しては、もとから規定がなかったようだ (H21年度版環境六法で確認)。

大気汚染防止法に定める政令市

法律に疎いと何処に書いてあるのかわからんのよね。

大気汚染防止法施行令 第13条に規定。

  • 小樽市
  • 室蘭市
  • 苫小牧市
  • 川口市
  • 所沢市
  • 市川市
  • 松戸市
  • 市原市
  • 平塚市
  • 藤沢市
  • 四日市市
  • 吹田市
  • 八尾市
  • 明石市
  • 加古川市
  • 大牟田市

他に、指定都市、中核市、施行時特例市に事務の委譲がある。

川口市、所沢市、平塚市、四日市市、吹田市、八尾市、明石市、加古川市は 大気汚染防止法政令市かつ施行時特例市。

環境省・大気汚染防止法施行状況調査報告書 の末尾に政令市等の一覧がある。

いわゆる市区町村コード(2)

(承前)

データとしての使いやすさと情報量という点では、 統計LOD から公開されている「標準地域コード」で充分である。 ただ、実際に中身を見たところ、やや不十分なところがあった。

  • 自治体の分割に対応していない。山梨県上九一色村が2分割されて 甲府市と富士河口湖町に編入されたケースなどが正確に記述されていない。
  • 標準地域コード策定時点(1970年4月1日)時点で既に廃止されていた自治体の エンティティが混入していて紛らわしい。

これについては統計LODの問い合わせアドレスにメールで問い合わせたところ、 データを修正する方向で対応する、とのことであった。 そのうちデータがアップデートされるものと思われる。

さて LOD と言えば Sparql とかいう言語で検索したりするものらしいが、 私は当面は自発的にこれを学ぶつもりはない(だってめんどくさそうだし)。 この程度のデータ量だったらどんな方法でも大差はないのだから、 いつも通りに Python + rdflib で スクリプト を書いてみた。 各コードの有効期間と編入・合併先を抽出するスクリプトである。

実行結果は こんな感じ (ただし別途 sort してある)。 元データのライセンスが CC-BY 4.0 なので、このファイルを利用する場合は 元データの権利者を表示すること。 ただし標準地域コードの著作権者が誰になるのか、統計LODのサイトに 記載が無い…(追記・「政府統計の総合窓口(e-Stat)」で良いそうだ)。

いわゆる市区町村コードなるもの

これまで行政由来のデータを扱うことがほとんど無かったので 「市区町村コード」とかいうものをほとんど知らなかったのであるが、 業務上避けて通れなくなったので、これを機会に真面目に調べることにしたのである。

いわゆる市区町村コードには、実は3系統あって、初心者は混乱する。 というか混乱した。系統ごとに用語が微妙に違うので google で検索に 巧く引っかからなかったりするようだ。

系統間の関係について、調べた中では ここ が解りやすいか。

自治省系コード

正式には「全国地方公共団体コード」の「都道府県コード及び市区町村コード」。 旧自治省が地方自治体の事務処理のために作成したもので、作成時期は 3系統の中で一番古く、1968年。以下「市区町村コード」と呼ぶ。

「全国地方公共団体コード」は「市区町村コード」の他に 「一部事務組合等コード」が含まれている。この「一部事務組合等コード」が どういうものかと言うと、 たとえば「常総地方広域市町村圏事務組合」のような団体に 事務処理用コードを割り当てるためのものだ。 今回はこのような組合のことは関係ないので立ち入らないことにする。

「市区町村コード」のコードとしての特徴は、

  • 検査数字を含めた 6桁の数値
  • 都道府県、市町村、特別区(東京23区)、政令指定都市の行政区、を収録 (郡、支庁・振興局は除外)

現在は総務省地域力創造グループが管理しており、 総務省の電子自治体のページ から PDF と Excel がダウンロードできる。

過去の情報は、2005年4月1日以降の改正分が同じく PDF と Excel で入手できる。 それ以前の情報について、直接問い合わせところ、総務省地域力創造グループでは データを持っておらず、別途資料を当たられたい、とのことで、 例として 第一法規(という出版社)「全国都道府県・市区町村コード」 を紹介された。

行政管理庁系コード

正式には「統計に用いる標準地域コード」。 旧行政管理庁が 1970年に策定したもので、現在は総務省統計局が管理している。

コードの割り当て規則は、先行の自治省系コードのものを流用しているので、 実態としてはほとんど同じと言って良いが、細かいところで差異がある。

  • 検査数値なしの 5桁
  • 郡、支庁・振興局にもコードを割り当てている。
  • 策定の時点で「削除」扱いになっているコードがある。つまり、 1970年4月1日以前に存在し、先行の自治省系コードが割り当てられていた自治体が、 1970年4月1日までに廃止された場合、自治省系コードとの整合性のため、 そのコードを削除扱いにした、ということ。

電子情報としては、 総務省ウェブサイトの統計部門のページ から PDF, CSV で入手できるが、 2016年3月31日に LOD形式で公開された ので、現在はこれを使うのが良い。 1970年4月1日から現在までの変遷が追跡できる(ただし、一部に誤りがある。後述)。

このページ の一番下に turtle 形式のファイルが置いてある。

JIS コード

正式には JIS X401, JIS X402。 自治省系「市区町村コード」を流用して JIS 規格化したもの、のようだ。 これについて調べる前に、「標準地域コード」の LOD が見付かったので、 調べるのを止めてしまった。

(続く)

Python で MS Access データファイルを読む

mdbtools, pymdb を使えば Python 上から MS Access のデータファイルが 読めるらしい、と知った。こういうものがネットに転がっているとは 便利な時代になったものである。

Mac だと、MacPorts で glib2 と glib2-dev の切替が巧く行かず、 面倒だったので止めた。

従っていつも通り FreeBSD 上で実行した。10.3 Release。

mdbtools

mdbtools は MDB ファイルを CSV に変換したりするコマンド群とそのライブラリ。 PKG に収録されているので素直にそれをインストールする。

pkg install mdbtools

mdbtools のコマンドで MDB から CSV に変換できるので、 これだけで充分と言えば充分なのだが、やはり直接 Python 上で 扱えた方が便利なので(値にカンマが混じっていたりして クォーテーションされると面倒)、pymdb も入れる。

pymdb

pymdb は mdbtools の Python 用バインディング。PyPi にある。 pip でのインストールは、少なくとも FreeBSD 10.3R 上では不具合が発生した。

  • glibconfig.h が見つからず、ビルド失敗。

    FreeBSD 10 では glibconfig.h は

    /usr/local/lib/glib-2.0/include/glibconfig.h
    

    にあるが、これが pymdb のサーチパスに入っていない。 glibconfig.h 以外の glib 関係のヘッダファイルは

    /usr/local/include/glib-2.0
    

    にあるのに、何故か glibconfig.h だけ別のディレクトリに設置されている。 何故だろう。よく解らない。

    これを解決するだけだったら /usr/local/include とかに glibconfig.h を 無理矢理コピーすれば pip install が通るが、 次の不具合もあるので二度手間になる。

  • libiconv が無視される。

    pymdb の Cコード上で HAVE_ICONV というマクロが検査されるのだが、 pip install では OS 上に libiconv があるのにも関わらず HAVE_ICONV が セットされない。結果として MDB 内の日本語データが文字化けする。

    解決法は、pymdb の setup.py でマクロを定義して、直接ビルドする。

結論として、setup.py に以下の2行を追加する。

define_macros=[("HAVE_ICONV", "1"),],        # 追加
include_dirs=[
    "/usr/local/lib/glib-2.0/include",       # 追加

pymdb の使用感

pymdb の機能は極めて単純で、MDBファイルの中身を

{ table_name: { "headers": [header_list], "data": [[data_row], ...] }, ...}

という構造に変換するだけである。pythonic に利用するにはラッパクラスを作って __getitem__ 等を書くのが良い。例えば、

class MDBRow:
  def __init__(self, header, row, table_name=None, row_idx=None):
    self.headers = header
    self.data = row
    self.table_name = table_name
    self.index = row_idx
    self.extra_data = {}

  def __getitem__(self, col_name):
    try:
      return self.data[self.headers.index(col_name)]
    except ValueError:
      return self.extra_data[col_name]

  def __setitem__(self, col_name, col_data):
    try:
      self.data[self.headers.index(col_name)] = col_data
    except ValueError:
      self.extra_data[col_name] = col_data