21世紀になってから20年近くも経つと言うのに、私たちは未だに 文字化けに取り憑かれている。滑稽である。

MS-DOS時代(だいたい1990年代後半)のMOディスクの中身を取り出そうと思い、 FreeBSD機に繋げて mount_msdosfs を使用したところ、ファイル名に関連して エラーが出た。カーネルハックして原因が判ったので、対策を記録しておく。

OS のバージョンは FreeBSD 11.2R 。

直面したエラーには 2種類あった。 チルダ記号(0x7e)に関するものと、「最」の字に関するもの。

REPORT?1.TXT: No such file or directory

SJIS:   52 45 50 4f 52 54   7e 31 2e 54 58 54
UCS2:   52 45 50 4f 52 54 203e 31 2e 54 58 54
EUC-JP: 52 45 50 4f 52 54 aea2 31 2e 54 58 54

EUC-JP: 52 45 50 4f 52 54 aea2 31 2e 54 58 54
UCS2:   52 45 50 4f 52 54 3013 31 2e 54 58 54
SJIS:   52 45 50 4f 52 54 ac81 31 2e 54 58 54

52 45 50 4f 52 54 81 ac 2e 54 58 54

/usr/src/share/i18n/esdb/MISC/Shift_JIS.src
/usr/src/share/i18n/esdb/MISC/Shift_JIS-2004.src
/usr/src/lib/libkiconv/quirks.c

/usr/share/i18n/esdb/MISC/Shift_JIS.esdb
/usr/share/i18n/esdb/MISC/Shift_JIS-2004.esdb
/lib/libkiconv.so.4

最初.TXT: No such file or directory.

static int
iconv_xlat16_toupper(void *d2p, int c)
{
        struct iconv_xlat16 *dp = (struct iconv_xlat16*)d2p;
        int c1, c2, out;

        if (c < 0x100) {
                c1 = C2I1(c << 8);
                c2 = C2I2(c << 8);
        } else if (c < 0x10000) {
                c1 = C2I1(c);
                c2 = C2I2(c);
        } else
                return (c);

        if (dp->d_table[c1] && dp->d_table[c1][c2] & XLAT16_HAS_UPPER_CASE) {
                out = dp->d_table[c1][c2] & 0xffff;
                if ((out & 0xff) == 0)
                        out = (out >> 8) & 0xff;
                return (out);
        } else
                return (c);
}

--- iconv_xlat16.c.orig     2018-06-22 08:02:52.000000000 +0900
+++ iconv_xlat16.c  2019-09-22 21:08:40.097838000 +0900
@@ -334,6 +334,8 @@
    } else if (c < 0x10000) {
                 c1 = C2I1(c);
                 c2 = C2I2(c);
+                if (c1 == 0)
+                        return (c);
    } else
            return (c);

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

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

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

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

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>

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 -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

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>

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>

新しく 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 がエラーを出すようになった。 テレビ本体は 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 を購入して交換することにしたのであった。

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

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

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

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

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

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

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

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

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

（承前）

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

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

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

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

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

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

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

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

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

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

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

pkg install mdbtools

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

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

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

（承前）

ogr2ogr で保存した GMLファイルを R 上に読み込んでみよう。 それには readOGR を用いる。

R の GIS データ用クラスはジオメトリ型ごとに異なっているらしい。 型ごとに別のオブジェクトに格納する。

> library(gdalUtils)
> library(rgdal)
> pnt <- readOGR("test.gml", "mylayer", require_geomType="wkbPoint")
> lines <- readOGR("test.gml", "mylayer", require_geomType="wkbLineString")
> poly <- readOGR("test.gml", "mylayer", require_geomType="wkbPolygon")
> plot(pnt)

R オブジェクトのクラス名はそれぞれ SpatialPointsDataFrame, SpatialLinesDataFrame, SpatialPolygonsDataFrame のようだ。 plot() に渡すと点や線が表示される。

> mypoints <- readOGR("WFS:http://hogehoge/wfs?version=1.0.0&request=getfeature&typename=mylayer&srsname=EPSG:4326", "mylayer", require_geomType="wkbPoint")
> plot(mypoint)

R で地理データを扱う時に、WFS から直接取り込むことができたら便利に違いない。 幾つか方法があるのかも知れないが、google でまず GDAL を使う方法が ヒットしたので試してみる。

gdalUtils と rgdal というパッケージを使うのだが、実態は、GDAL のコマンドを 呼び出すラッパーのようなので、先に直接コマンドを実行してみる。

さて、まず判り難かったのが、GDAL で WFS ドライバをビルドするには configure で curl オプションを有効にしなければならないということ。 OSX の macports、および FreeBSD の pkg で素直にインストールすると curl は有効になっていないので WFS が使えない。 macports では次のようにする。

$ sudo port install gdal +curl

FreeBSD では ports でリビルドしなければならないので少々面倒臭い。

curl オプション付きで GDAL をインストールすると、ogrinfo で WFS のメタデータを取得できるようになる。以下で利用可能なレイヤの一覧が出力される。

$ ogrinfo "WFS:http://hogehoge/wfs?service=wfs&version=1.0.0&request=GetCapabilities&srsname=EPSG:4326"

ogr2ogr で WFS から取得した GIS データをローカルファイルに保存できる。 TypeName に欲しいレイヤ名を、 request は GetFeature にする。 なお、元データにマルチバイト文字があるとエンコードエラーが出るのと、 線とポリゴンが含まれているとジオメトリ変換エラーが出る。 どちらも、デフォルトの出力フォーマットが shp であることが原因のようだ。 前者は -lco オプションでエンコードを指定して回避する。 後者は、shp がそもそも複数のジオメトリ型をひとつのファイルに 共存させられないから回避できない（処理するジオメトリ型を明示的に指定して 複数回実行するしかない）。出力フォーマットはオプションで 変更可能だが、まずはエラーを無視するように -skipfailures を指定してみる。

$ ogr2ogr test.shp "WFS:http://hogehoge/wfs?service=wfs&version=1.0.0&request=GetFeature&typename=mylayer&srsname=EPSG:4326" -lco "encoding=utf-8" -skipfailures

出力フォーマットは -f オプション で指定する。GML だとエンコーディング問題も 複数型共存問題も生じない。

$ ogr2ogr test.gml "WFS:http://hogehoge/wfs?service=wfs&version=1.0.0&request=GetFeature&typename=PlotNet:plots&srsname=EPSG:4326" -f gml

OSX 10.9.5 に QGIS を入れてみようとして、 まずは MacPorts を試してみたが、ビルドに失敗する。 ログを見ると、system というコマンドを実行しようとして失敗しているようだが、 そのような名前のコマンドは、ユーザランドにも bash built-in にも （libclang にも？）見当たらない。どういうことだ？ なお FreeBSD には system(3) がある。

さくらインターネットの個人サーバ(FreeBSD)に pkg で入れて、 X11 Forwarding で使おうかと思って試してみたが、やはり反応が遅くて気が滅入る。 仕方ないので http://www.kyngchaos.com/software/qgis からビルド済み dmg を 落として入れることにした。こういう時にはいつも何故か何かに負けたような 気分になる。

さて入れてはみたが、QGIS の使い方を全然知らないんだよな。 取り敢えず本買うか。

環境省・水環境総合情報サイト、というものがある。 Google で検索した時、 http://www.env.go.jp/water/mizu_site/ が 先頭に出てくるのだが、このサイトに行ってメニューをクリックすると、 Network Error という画面が出てくる。 始めのうちは、何だよメンテでもしてんのか、と思ったが、それらしい 素振りもないし、どうも変だなー、と頭を悩ませていた。

実はこのサイトは古いサイトで、現在ではリニューアルされて https://www2.env.go.jp/water-pub/mizu-site/ で公開されている、 ということに気付くのに半日くらい掛かった。 うーん。自動転送するように設定しておいてくれないものか。

まぁそれはそれとして、このサイトでは、水質調査のデータを ダウンロードすることができる。のだが、Safari だとダウンロードが途中終了する。 サイトのヘルプを見ると、IE のバージョン 8 以上が推奨だそうで、 うへぇ、と思いつつ試しに Firefox 31.0 でやってみると、 無事にダウンロードすることができた。

さて、この ダウンロードページ では、（底質データ以外は）ファイル形式として CSV, SHP, GML を選ぶことができる。 GML についてあまり知識が無かったので、GML って KML の親戚だっけ？ などと考えつつググり、OGC 発で ISO 19100 シリーズに取り込まれたことや、 国土地理院が JPGIS という国内規格に取り込んだことなどを勉強した。 ISO 19115/19139 や JMP のことは以前に勉強したことがあって知ってたんだけど、 ISO 19136, JPGIS は聞いた記憶が無いな。なんでだろう。

話を戻して、水質データの中身だが、まず面食らうのが項目名の表記法で、 安直なローマ字表記が妙に笑える。例えば （ 公共用水域水質データファイル利用説明書 より引用）

と、中々のセンスである。

まぁカラム名はただのラベルなので本質的にはどうでもいい。

ダウンロードした GML ファイルの中身を見て判ったのは、どうもこのファイルは ツールを使って自動的に生成したものらしい、 ということ。GML ファイル内に http://www.safe.com/gml/fme という URI が 指定されていたので調べたところ、 Safe Software という会社が FME というデータフォーマット変換ツールを売っているようだ。 おそらく環境省から業務を受託した業者が FME を導入したのだろう。 ファイルダウンロード時に十数秒待たされる挙動から、どうも、ダウンロード用ファイルは 事前に用意されているのではなく、その都度マスターDBから生成している 雰囲気がある。

GML は主題情報用のタグなどを別途定義しなければならないため、 この GML形式水質データにも XML スキーマファイルが同梱されている。 しかしこれが如何にも自動生成されましたという顔をしており、 annotation や description が一切無く、maxLength や minOccurs などの 形式面の定義だけが羅列されているという物。 また GML ファイルの方には gml:featureMember というタグが使われているが、 これは GML 3.2.1 では deprecated とされていて、使うべきではない。

という訳で、このサイトの GML形式データは総じてやっつけ感が隠せない仕上がりであった。

参考までに、国交省・国土数値情報のサイトから GML 形式データをひとつ ダウンロードして中身を見てみたが、さすがにこちらは出来が良い。 思いがけず、環境省と国交省の差を見せつけられた一日となった。

昨日は NIMS で開催された「オープンサイエンスと著作権」というセミナーに 行ってきた。もちろん会場から質問する機会はあったのだが、その時には 思いつかず、自宅に帰ってきてから何時間も経ってから訊くべきことに 気付く、というよくある事態に。

データは、法的には著作物ではない。 一方で、研究データを CC ライセンスの下で公開する事例が出始めている。 そこで、著作物を前提にして設計されている CC ライセンスを、 著作物ではない研究データに適用することは適切なのか？ という疑問が生じる。

• 法的枠組みとして妥当なのか？
• 実際問題としてこれは上手いやり方になっているのか？

という点について、弁護士としての見解をお尋ねしたい。

IPCC Data Distribution Centre

というサイトに GCM データの利用規約が記載されている。

今の時代、公開データの利用規約で共著を要求するのは時代遅れだぜ、 ということを説得するための資料収集中。

ICSU-WDS Data Sharing Principles 第3項

All who produce, share, and use data and metadata are stewards of those data, and have responsibility for ensuring that the authenticity, quality, and integrity of the data are preserved, and respect for the data source is maintained by ensuring privacy where appropriate, and encouraging appropriate citation of the dataset and original work and acknowledgement of the data repository.

データとメタデータを生産・共有・利用する人は、すべて、 これらのデータの管理人である。 従ってこれらの人は、以下のことについて責任がある。

• データの信頼性、品質、完全性が保全されるように保証すること。
• プライバシー保護が必要な場合は、それを確実にすること。
• データセットやその元となった作業の適切な引用、 及びデータリポジトリへの謝辞を奨励することによって、 データの出典への配慮が守られるようにすること。

citation, acknowledgement を推奨する一方で co-authorship への言及無し。 典型かな。

（承前）

さてこの L^-1 の単位を定義しなければならないのだが、実に悩ましい。 STMML 形式では普通 xxxPerYyy という書き方をするが、perYyy という書き方は しないようだ。

参考までに、 T^-1 （周波数）には Hz という固有単位が与えられているので、 これを使って定義している。

<unit id="hertz" name="hertz"
      unitType="frequency" multiplierToSI="1"
      abbreviation="Hz">
  <description>hertz</description>
</unit>

波数には SI の固有単位はないようだ。CGS単位系ではカイザー(K)という単位名が 与えられているらしい。 では波数の定義がどうなっているかと言うと、

<!--waveNumber-->
<unit id="waveNumber" name="waveNumber"
      unitType="lengthReciprocal" multiplierToSI="1">
  <description>1/meters</description>
</unit>

つまり、単位名に物理量の名称を当ててしまっている。これは本当はおかしなことで、 それは SI接頭辞を付けた kiloWaveNumber とか megaWaveNumber という語が 何を言っているのか判らないことから明らかだ。 苦し紛れであることは論を俟たないが、他に記法が無いような気も、確かにする。 kiloParMeter 等とするのもやはりおかしい。

そう言う訳で、結論としては以下のような custom unit を定義した。

<!-- attenuation coefficient (m^-1) -->
<unit id="attenuationCoefficient"
          name="attenuationCoefficient" unitType="lengthReciprocal"
      multiplierToSI="1" abbreviation="1/m">
  <description>Coefficient of exponential attenuation</description>
</unit>

釈然としないところがあるが、どうにもならん。

指数関数的減衰における減衰係数の単位は対象とする物理現象によって異なるが、 ここではある物質中を電磁波（光線）が通過することを考える。 すると電磁波は物質中を進む距離に応じて減衰するので、この場合は 減衰係数の単位は L^-1 の次元になる。

まぁ要するに日射光の減衰である。

この L^-1 の次元の物理量は珍しいようで、EML標準の単位定義には 波数しか無い。

<unitType id="lengthReciprocal" name="lengthReciprocal"> <!--waveNumber-->
  <dimension name="length" power="-1"/>
</unitType>

しかも単位の型名として「距離の逆数(length reciprocal)」などという こなれない語句を当てていて、いかにも苦し紛れな感じがする。 そう言われてみると確かに L^-1 次元の物理量はにわかには 思いつかない。不思議な感じがする。

ともあれ係数は扱いが難しく、EML標準定義にはほとんど無い。 少ない中のひとつが transmissivity で、 L² T^-1 の次元である。

<unitType id="transmissivity" name="transmissivity"> <!--metersSquaredPerSecond-->
  <dimension name="length" power="2"/>
  <dimension name="time" power="-1"/>
</unitType>

　Transmissivity は地質学では透水量係数を意味するようだが、 生態学にはあまり関係がないように思うので、 拡散係数を表現しているのではないかと思われるが、どうだろう。 分野を限定しないと用語の意味が確定しないのは科学の難点のひとつである。

（承前）

ところで意外なことに EML標準にはエネルギーのフラックスを表す単位が 定義されていない。いや、別に意外ではないのか？ よく判らないが、日射フラックスなどを表すのに MJ m^-2 h^-1 とか W m^-2 を使う。 次元を計算してみると M T^-3 という不思議な次元になる。

<!-- energy flux -->
<unitType id="energyFlux" name="energyFlux">
  <dimension name="mass" power="1"/>
  <dimension name="time" power="-3"/>
</unitType>
<unit id="joulesPerSquareMeterPerSecond"
  name="joulesPerSquareMeterPerSecond"
  unitType="energyFlux"
  multiplierToSI="1"
  abbreviation="J/㎡/s">
  <description>flux of radiation</description>
</unit>
<unit id="megajoulesPerSquareMeterPerHour"
  name="megajoulesPerSquareMeterPerHour"
  unitType="energyFlux"
  parentSI="joulesPerSquareMeterPerSecond"
  multiplierToSI="277.7778"
  abbreviation="MJ/㎡/h">
  <description>flux of radiation</description>
</unit>
<unit id="megajoulesPerSquareMeterPerDay"
  name="megajoulesPerSquareMeterPerDay"
  unitType="energyFlux"
  parentSI="joulesPerSquareMeterPerSecond"
  multiplierToSI="11.5741"
  abbreviation="MJ/㎡/d">
  <description>flux of radiation</description>
</unit>

今日は一日、高校物理の復習をして過ごしたような気がする。

（承前）

とは言え、他人の仕事の粗探しをしても自分の仕事が進む訳ではないのだ。 自分なりに考えて実装してみると、以下のようになった。

<!-- amount of photons -->
<unitType id="amountOfPhotonFlux" name="amountOfPhotonFlux">
  <dimension name="amount" power="1"/>
  <dimension name="length" power="-2"/>
  <dimension name="time" power="-1"/>
</unitType>
<unit id="einsteinsPerSquareMeterPerSecond"
  name="einsteinsPerSquareMeterPerSecond"
  unitType="amountOfPhotonFlux"
  multiplierToSI="1"
  abbreviation="E/㎡/s">
  <description>Einsteins (mols of photons) per square meter per secound</description>
</unit>
<unit id="microeinsteinsPerSquareMeterPerSecond"
  name="microeinsteinsPerSquareMeterPerSecond"
  unitType="amountOfPhotonFlux"
  parentSI="einsteinsPerSquareMeterPerSecond"
  multiplierToSI="0.000001"
  abbreviation="μE/㎡/s">
  <description>micro Einsteins (10^-6 mols of photons) per square meter per secound</description>
</unit>

molesOfPhoton のように Of を使う用例は EML 標準には少ないので、 素直に einstein を使うようにした。

ところで flux という用語は、 EML標準の単位定義では T^-1 の次元に 使われているのだが、私の業界では L^-2 T^-1 を意味する。 一般にフラックスは「単位時間、単位面積あたりの流量」のことだから、 EML標準の用法がおかしいように思う。 一方で EML標準では rate という用語も T^-1 の次元を意味するらしく、 混乱する。 これらの用法は一体どこから来ているのだろうか。よく判らない。

EML(Ecological Metadata Language) は 生態学データに特化した規格であるとされているが、 色々と不足がある。中でも、標準で用意されている数値データの物理量の単位が 網羅的でなく、使いたい単位が無い場合も多い。 そういう場合は custom unit を定義して、その定義を EML メタデータに 個々に追加する必要がある。

今回問題となったのは、光合成の研究で使われる光子量の単位で、 例えば μmol photons m^-2 s^-1 である。 光合成量は光子のエネルギー量ではなくて光子の個数によって決まるため、 ジュール(J)等ではなくて物質量(mol) の単位を使う。 なお、光子 の mol 数を表す単位としてアインシュタイン(E)がある （ということを今回初めて知った）。 従って μmol photons m^-2 s^-1 は μE m^-2 s^-1 でもほぼ等価である。

さて、光合成の研究などは世界各地でうんざりするほど実施されている訳で、 そのデータ用の EML メタデータも既に作成されている筈である。 Google で検索してみたところ、早速 2,3 個ヒットした。

Harvard Forest Research の knb-lter-hfr.140.9

<stmml:unit
    name="micromolePerMeterSquaredPerSecond"
    unitType="arealMassDensityRate"
    id="micromolePerMeterSquaredPerSecond"
    parentSI="molePerMeterSquaredPerSecond"
    multiplierToSI="0.000001"
    constantToSI="0.0"
    />

シカゴ大 Marine Biological Lab. の knb-lter-pie.92.3

<unit
    name="microEinsteinPerMeterSquaredPerSecond"
    unitType="illuminance"
    id="microEinsteinPerMeterSquaredPerSecond"
    parentSI="" multiplierToSI="1">

ミネソタ州立大 McMurdo Dry Valleys の knb-lter-mcm.3001.34

<stmml:unit
    id="umolphotons/m2/second"
    name="umolphotons/m2/second"
    abbreviation=""
    unitType="">

フロリダ国際大 FCE サイトの 単位リスト

microEinsteinsPerSquareMeterPerSecond
illuminance
µE/m^2/s
Einsteins (1E-06 moles of photons) per square meter per second (radiant flux density)

定義が 4者4様で興味深いが、どれも間違いがあるのは頂けない。

HFR と MBL はそれぞれ “micromole…” “microEinstein…” としているが、 s を入れて “micromoles…” “microEinsteins…” とするべきだ。

MCM の “umolphotons/m2/second” は STMML 書式ですらない （<stmml:unit> というタグを使用しているのに）。

MCM と FCE は単位のカテゴリを illuminance としているが、 illuminance（照度）は心理物理量で、人間の視覚システムが感じる明るさ、 を意味しており、光子の物理学的なエネルギーや個数とは一意な関係には無い。 また HFR はカテゴリを arealMassDensityRate としているが、 mass は質量（kg, ton など）のことであり、 mol 数は 物質量(amount of substance)である。

EML は custom unit という名目で自由に単位を追加することができるが、 反面、それを正しく使うのにはそれなりの知識が必要で、 正確に記述できるかどうかは担当者の力量に強く依存する。 人間がメタデータを読む分には問題は生じないだろうが、 将来的に機械で自動処理させる段になったら困りそうだ。

故あって CCライセンスを調べている時に、クリエイティブコモンズジャパンの FAQ に、 CCライセンスはソフトウェアには使わない方がよい、ということが書いてあるのを見つけた。 どういう理由でそう主張しているのか知りたかったのだが、詳しいことが書いていない。 CCジャパンの FAQ は古いもののようで、本家の FAQ に明らかに追随していないので、 本家FAQ を読んだついでに、備忘のために和訳しておく。

元テキスト

時々思い出したように tex を使うが、その度に色々変わっていて 戸惑っているような気がする。

Mac 附属のヒラギノフォントを PDF に埋め込むための手順を調べた。 基本的に ここ と ここ を参考にしたが、後で混乱しないようにメモしておく。

# mkdir -p /opt/local/share/texmf-local/fonts/opentype/public/hiragino
# cd !$
# ln -s "/Library/Fonts/ヒラギノ明朝 Pro W3.otf" HiraMinPro-W3.otf
# ln -s "/Library/Fonts/ヒラギノ角ゴ Pro W6.otf" HiraKakuPro-W6.otf
# mktexlsr
# updmap-sys --setoption kanjiEmbed hiragino
# kanji-config-updmap hiragino

その上で、dvipdfmx に -f オプションでフォントを指示する。

$ dvipdfmx -f ptex-hiragino.map hogehoge.dvi

ちなみに -f オプションを指定しないとヒラギノではなくて IPAフォントが埋め込まれた。

前記事を書いた後で CiNii で検索したところ、 船守「デジタル空間に移行する大学教育」情報の科学と技術 65: 258-263, 2015 という文献が見つかった。これには MOOC について興味深いことが記述されており、

• MOOC の開発費用（教材作成費用？）は1コースあたり 1000-3000万円と高額
• これに対して学生からは、学費を負担している正規の学生への教育でなく、学外の 不特定多数に無料の講義を提供することに多額の資金を費やす大学側の姿勢に 批判が出ている
• 大学当局は、MOOC を学内教育にも流用することでこの批判を躱そうとしている （いわゆる反転授業）

そうである。

開発費が 1000-3000万円というのは、想像していたよりも文字通り一桁大きいので 単純に驚いた。既存の講義資料を流用すれば安上がりにできるだろうと思っていたが、 そうではなくて新規に製作しているのか。ならば金も掛かるし、 学生が怒るのも無理はない。

gacoo の教材はどのくらいの予算で作ってんでしょうね。

基本的に時勢に疎い人間なので、 新しい流行について私が初めて見聞きした時には既に その流行は廃れかけていた、ということがよくある。

MOOC (Massive Open Online Course) という言葉を目にしたのは昨日が最初で、 JST の STI Updates に 総務省、データサイエンス・オンライン講座「社会人のためのデータサイエンス入門」を再開講 という記事があったので、そのオンライン講座とやらの内容にちょっと興味が湧いて gacoo のサイト に行ってみた訳である。 レジュメ を見ると、 内容自体はおおよそ初歩的な統計ネタで（平均値の見方、とか）、 私の期待とは違ったのだが、最後の方に「e-Stat の使い方」という項目があって、 私は e-Stat を使ったことがないのでちょっと見てみたい、と思った。

それで、どうやったら中身を見られるのか知るために、 gacoo のシステムや運営 についてサイト内を調べて回ったのであるが、 「開講期間」とか「修了証」とか「相互採点」とか、 意味が理解できない用語が幾つも出てくるので混乱してしまった。 どうも、講義資料が PDF や slideshare みたいな感じで置いてあって、 興味があるところだけ見られる、というようにはなっていないらしい。 中身を見るには、受講手続きして、開講するのを待って、 週一で課題を解いて提出して、最終試験を受けたりしないといけないらしい。

なにこれめんどくさい。と心の底から思った。

gacoo の元締めの JMOOC のサイト に MOOC について解説があって、 そこには「今、世界中で MOOC が流行ってます」といったようなことが 書かれていたが、私にはこんな面倒なものが流行るとは思えず、 不可解な気分になった。

こういう場合は、自分が間違っているのか、それとも世界が間違っているのか、 きちんと調べて理解しなければならない。 自分は正気であると信じている人間は、常に、自分の知性が正常に機能しているか 否かを点検し続ける義務があるからである。

“MOOC” でググったところ、割と上位に TechCrunch の オンライン講義のMOOCが大学に取って代わることができない理由 という記事が出てきて、やはり私の直観通り、MOOC の流行は既に終わっているようだ。

この記事は 2015年5月のものだが、その約1年前、日本国内でも その事実は認識されており、しかもそれが JMOOC の関係筋（放送大学の人） から語られている。 山田恒夫「MOOCとは何か　ポストMOOCを見据えた次世代プラットフォームの課題」 情報管理 57(6): 367-375, 2014. DOI: 10.1241/johokanri.57.367 （2014年7月受理、とある）

別の文書によると、2013年後半には既に「MOOC は Hype（誇大宣伝）だ」と 言われ始めたそうである。MOOC が出現したのは 2012年らしいので、 1年くらいは幻想が保ったようだ。 堀真寿美「ポストMOOCと日本の大学経営」ViewPoint 14: 50-52, 2014.

一方で JMOOC 関係者は、MOOC は今でも世界的に拡大していると主張している （2015年5月の記事）。 MOOCの広がりと登録者12万人のgaccoの取り組み これが本心からの言葉か、立場上の発言なのかは判別できない。

MOOC の対極に SPOC (Small Private Online Course) があるが、 MOOC よりも SPOC の方に注目している人も出てきている。 荒木博行「オンライン教育でリーダーは育つか？」 マネタイズや学習効果という点では確かに SPOC の方が有利だろう。

上記荒木氏によると、MOOC の関係者ももはや Massive や Open に あまり拘らずにサービスを変容させて行き詰まりを乗り越えようと しているそうである。 荒木博行「MOOCは儲かるのか？」 「「MOOC」という呼び名が過去のものになるのも時間の問題かもしれません。」 と書かれているが、私もそんな気がする。

さて、私の MOOC に対するイメージは gacoo サイトを見た印象から得たものだが、 gacoo/JMOOC と本場の MOOC は質的にまったく異なるという意見もあるようだ。 tkyon「MOOCを利用し始めて1年が経過した」 これを読むと、gacoo を見ただけで MOOC について解ったような気になっては いけないらしいことが理解できる。少なくとも本場の MOOC には 高等教育に対する高い理想があるんだな。

何ヶ月も前から、試しに ORCID ID を取得しなければ、とは思ってはいたが、 目先の仕事以外のことはしたくない、という生来の面倒臭がりのために放置していた。 PlotNet のデータ入力に飽きたので気分転換に ORCID のサイトに アクセスしてみた。登録自体は簡単で、確かに5分もあれば済む。 認証メールは一応送られては来るが、 メール認証しなくても先に進むことができるので、逆にそれで 大丈夫かと心配になるくらいだ。 メール認証を放置すると後で取り消しになったりするのかしら。

ひとつ感心したのが、パスワード入力欄のヘルプに、パスワード文字列で 使用可能な記号文字をきちんと明記してあるところだ。

私は普段、パスワード用文字列を乱数生成するのに apg というツールを使っている。

mac:~$ apg -h

apg   Automated Password Generator
        Copyright (c) Adel I. Mirzazhanov
(snip)
mac:~$ apg -a 1
>~B"Av~qJ1
$xphcK~qO/
kbUX8Kp`Ke
\hX?,LQ$
nlZ#2'pQ6
z"~1TtF(M

apg は ‘” とか <> とかの記号を遠慮なく混ぜてきて、パスワードの強度としてはいいのだが、 これをそのまま入力フォームにコピーすると、時々、エラーを吐くサイトがあって、 面倒臭い。使用可能文字に制限があるなら先に書いておくべきであろう。 こちらとしては、なるべく強度の高い文字列を選んで使おうとしているのに、 それがエラーとなると、恩を仇で返されたような気分になるのである。

私の ID は 0000-0002-3987-2098 になった。

勤務先情報の入力などもあっと言う間に終わってしまい、拍子抜けしたので、 遊びで自分の姓を検索してみた。

結果は 7件。大半がラテン系と思われる人名だが、中にひとり、「まいたひろし」という いかにも日本人っぽい名前の人物が居た。名前以外の情報は未入力か非表示にしているようで、 どこの誰だかは ORCID 上では判らない。

CiNii で検索すると、米田宏（バイオ系）と米田広（流体工学）という人物が出てきた。 「米田」を「よねだ」ではなく「まいた」と読ませる姓が存在することは前から知ってはいたが、 ふたりも出てくるとは思わなかった。 おそらくこのうちのどちらかが ORCID に登録したのであろう。どちらなのかは 情報不足で判らない。おそらく、私がそれを知る機会は無いだろう。

ここしばらくの間ずっとデータ入力に掛かり切りで、世間の動向に無関心で過ごした。 今日あたり東京で IDF の会議があるはずだが、申し込みとかすっかり忘れていて、 まぁいいか別に俺は行かなくて、と思うことにした。

EML ソフトウェアがバージョンアップされてないか、と思い、 久しぶりに KNB のサイトに行ってみた。 数ヶ月前は、確か、証明書関係のエラーが出て接続できなかったような気がするが、 今日行ってみたところ、普通に表示された。直ったのか、記憶違いか。

ソフトウェアの新バージョンは無かったが、 データベースの中に日本のデータセットが3件あるのに気付いた。 漁業情報サービスセンターのエチゼンクラゲのデータのようで、 3件とも中身は同じようだが何故かメタデータは 3件登録されている。 よく解らない。

どういう経緯で登録されたのか。 メタデータの中に “Usage restricted to Global Jellies Working Group members.” と書いてあって、ググってみると NCEAS かどこかがクラゲのデータベースを作ってるらしく、 その関係で日本が取っている日本周辺のデータを提供したもののようだ。

しかしいつの間にか KNB のデータベースに DOI が導入されているね。 このクラゲデータセットにも DOI 付いてるし。 金があるところは色々出来ていいなぁ。

先週の JaLTER DB 講習会で発覚したのだが、 IE 11 では JDC のファイルアップロード機能が上手く動作しない。 同じ PC 上で Chrome で操作すると動作するので、OS ではなく ブラウザが原因なのだろう。

手元に IE 11 が動作する PC が無く、原因究明ができないため、 差し当たり他のブラウザを使用して頂きたい。

JaLTER DB に格納されているデータセットの一部について、 そのメタデータをトムソンロイター社の Data Citation Index に提供するという件、 結局メタデータは ftp で送るということになり、6月に送信してあった。

その後、向こうでどのような作業が進んでいるのかまったく音沙汰が無かったのだが、 先日、TR DCI の “Master Data Repository List” を検索してみたら、 JaLTER DB が登録されているのを発見した。

9月頭に調べた時には発見できず、9/14 に調べた時にはヒットしたので、 その間の約 2週間の間に登録されたようだ。6月にメタデータを送ってから 9月まで、一体何に時間が掛かっていたのか、よく解らないが、 ともかく向こうの作業が進んでいるようなので安心した。

本来なら DCI そのものを検索して、JaLTER DB のレコードが登録されているか どうか確かめたいのだが、以前に記述したように、NIES では DCI を契約していない ので私が直接確かめる方法が無い。伝手を辿ってみるか…

しかしそれにしても、JaLTER DB の Responsible Organization として 日本生態学会が記載されているのはどうしたものか。向こうとしては、 JaLTER のような、永続性に不安がある組織よりも、学会のような 社会的・財政的に確立された組織の方が好ましい、ということなのだろうか。 この点は後で検討した方がいいかも知れない。

JDC に投入したデータを遡って調査したところ、壊れたファイルが見つかったので 再投入した。

調査の過程で解ったことは、2014年4月まではファイル破損がなく、 2015年4月から破損が生じていることである。このことから、 2014年4月後半に端末の MacBook を買い替えたことがエラー顕在化の 原因と推定される。

以前に使用していた MacBook は 2009年に購入したもので、性格が貧乏性のため 2014年まで使っていた。OS も Leopard のまま、アップグレードせず。 おそらく、Leopard の Safari には FileAPI が実装されていなかったのだろう。 ネットで拾った JavaScript コードは、 FileReader が実装されていればそれを使い、 実装されていなければファイルを直接読む、というようなロジックが組まれていたので、 前の MacBook で開発している時には FileReader.readAsBinaryString() が 実行されていなかったのだと思われる。そのため開発中ずっとこのバグに 気がつかなかった、ということなのだろう。

盲点だった。古い環境を使い続けるのも考えものだな。

これで少なくとも、私が JDC 開発中にバグに気付かなかった原因は解った。 しかし他の人々が FileReader.readAsBinaryString() の挙動を誤解していた （している？）原因はやはり不明である。

JDC にバグが見つかった。zip ファイルをサーバにアップロードすると、 ファイルが壊れるというものだ。テスト用インスタンスを立ち上げて 挙動を見てみると、サーバ側ではなくクライアント側でファイルが壊されているようだった。 具体的には、ファイルサイズが何故か 1.5 倍に増加しており、しかも、データが ランダムなバイト列ではなく UTF-8 にエンコードされているのであった。

ファイルのアップロードにはネットで拾ったパプリックドメインの JavaScript コードを 利用していて、これがファイルの読み込みとサーバへの送信を実行している。 読み込みから送信までの間に何かが起こっているのだろう、とはすぐに見当がついた。 処理を追いかけて調べた結果、FileReader.readAsBinaryString() が読み込んだ ファイル内容を破壊していることがわかった。 これを FileReader.readAsArrayBuffer() に変更することでバグ自体は 修正できたのだが、これについて調べた結果がやや興味深かったので記録しておく。

さてこの FileReader.readAsBinaryString() 、字面からは、バイナリファイルを 読み込んで中身のバイナリデータをメモリ上に保持する函数であるかのように見える。 ネット上の記事でもそのように解説されているものが多いようだ。 たとえば これ とか これ とか これ とか。

ところが、実はそうではない。 FileReader.readAsBinaryString() は仕様上 DOMString オブジェクトにデータを 格納することになっており、そして DOMString は UTF-8 しか受け付けない。 だから、少なくとも仕様上は、 FileReader.readAsBinaryString() は ランダムなバイト列を読み込むことはできないのである。 （ 参考 ）

そのため、たとえば Safari のエンジンである WebKit ではどうなっているかと言うと、

Source/WebCore/fileapi/FileReaderLoader.cpp:295
    switch (m_readType) {
    case ReadAsArrayBuffer:
        // No conversion is needed.
        break;
    case ReadAsBinaryString:
        m_stringResult = String(static_cast<const char*>(m_rawData->data()), m_bytesLoaded);
        break;

ReadAsArrayBuffer ではデータに何も加工しないのに対して ReadAsBinaryString では String クラスに渡す。この String には コンストラクタが数種類定義されているが、この場合に呼ばれるのは、

Source/WTF/wtf/text/WTFString.h:84-
    class String {
    ..snip..
    // Construct a string with latin1 data.
    WTF_EXPORT_STRING_API String(const LChar* characters, unsigned length);
    WTF_EXPORT_STRING_API String(const char* characters, unsigned length);

の下の方である。コメントに書かれているように、入力データを latin1 として 強制的に解釈する。そして target.result に結果を格納する際に UTF-8 に変換する のであろう。

実際、サーバに送信された壊れたデータを取り出して、元のファイルと比較してみると、

iconv -f L1 -t UTF-8

と変換した場合にファイルサイズも内容も一致した。

この FileReader.readAsBinaryString() 、実は 2012年に W3C の仕様から 削除されている。 2011年の仕様 では、 代わりに readAsArrayBuffer() を使うようにと書かれている。 その理由は、 readAsBinaryString() が、readAsBinaryString という名称でありながら DOMString の制限のためにバイナリを返せないという中途半端な函数だったからだろう。

それにしてもよく解らないことがある。

まず、多くの人が、readAsBinaryString() はバイナリファイルの内容をそのまま 保持する函数だと思っていたことである。 ざっとググった限りでは、そうではないと書いてある日本語ページは ここ くらいである。

もしかしたら、以前のブラウザの実装は、W3Cの仕様に反して、内容を加工しない ようになっていたのかも知れない。何しろわたしも JDC の開発中にこのことに 気がつかなかった。しかし WebKit のリポジトリから 2011年頭頃のコードを 取り出してみたが、今現在と変わらないように見える。 他の webエンジンではどうなのだろうか。

FormAlchemy には PostgreSQL の範囲型や配列に対応する renderer が 用意されていない。しかしコードを読んだらカスタマイズはそれほど 難しくはなさそうだったので書いてみた。

要点は、 formalchemy.fields.FieldRenderer をベースにして render(), render_readonly(), deserialize() 等をオーバーライドする。 フォーム出力用に formalchemy.helpers.text_field() というヘルパー函数が 用意されているため、これを利用すれば手間が省ける。 deserialize() はフォームの入力内容をパースする時に呼ばれるメソッドで、 入力内容を解釈して適切な Python オブジェクトに変換する機能を持たせる。

init4range と array 用のコードは以下のようになる。 これを forms.py に追加する。

from formalchemy import FieldSet
from formalchemy.helpers import text_field
from sqlalchemy.dialects.postgresql import INT4RANGE, ARRAY
from formalchemy.fields import FieldRenderer
from psycopg2.extras import NumericRange

class Int4RangeRenderer(FieldRenderer):
  def _range_string(self):
    # self.value は u"NumericRange(115, 889, '[)')" という文字列になっている
    # self.raw_value に NumericRange インスタンスがあるのでそれを利用
    # PostgreSQL 内には "[lower, upper+1)" という形式で格納されるようだが
    # 解り難いので "[lower, upper]" という形式で入出力する
    if isinstance(self.raw_value, NumericRange):
      value = "[{},{}]".format(self.raw_value.lower, self.raw_value.upper-1)
    else:
      value = ""
    return value

  def render(self, **kwargs):
    return text_field(self.name, value=self._range_string(), **kwargs)

  def render_readonly(self, **kwargs):
    return self._range_string()

FieldSet.default_renderers[INT4RANGE] = Int4RangeRenderer


class ArrayRenderer(FieldRenderer):
  def render(self, **kwargs):
    value = " ".join(self.raw_value)
    return text_field(self.name, value=value, **kwargs)

  def deserialize(self):
    # スペース区切りの文字列として受け取る
    data = self.params.getone(self.name)
    data = data.split()
    return data

FieldSet.default_renderers[ARRAY] = ArrayRenderer

FormAlchemy の設計では配列型の中身のデータ型に応じて default_renderer を切り替えるようにはできないので、上記コードでは 配列型を一緒くたに扱っている。

（承前）

次に、GeoAlchemy2 を使ってジオメトリデータを PostGIS に投入する方法を確認する。 簡単のため、Pyramid + GeoFormAlchemy2 は使用せずにロジックだけ追う。

モデルは以下とする。

class Plot(Base):
    __tablename__ = 'plots'
    id = Column(Integer, primary_key=True)
    name = Column(Text)
    geom = Column(Geometry('geometry', 4612))

作成するジオメトリは、複数の POINT を含むコレクションで、 以下をサンプルデータとする。

dat = [ [6,8], [8,1], [9,44] ]

ジオメトリのオブジェクトは shapely のものを利用する。

from shapely.geometry.point import Point
from shapely.geometry.collection import GeometryCollection
points = []
for i in dat:
  points.append(Point(i))
gc = GeometryCollection(points)

この時点で、例えば gc.to_wkt() とすると

GEOMETRYCOLLECTION (POINT (6.0000000000000000 8.0000000000000000), POINT (8.0000000000000000 1.0000000000000000), POINT (9.0000000000000000 44.0000000000000000))

が得られ、PostGIS に投入可能のように見えるが、残念ながらそうではなく、 SRID が指定されていない、とエラーが出る。

そこで、 GeoAlchemy2 の from_shape() を使用する。これは shapely オブジェクトを GeoAlchemy2 のオブジェクトに変換する函数だが、 SRID 情報を付加することができる。

from geoalchemy2.shape import from_shape
geo = from_shape(gc, srid=4612)

これでジオメトリオブジェクトが作成できたので、Plot インスタンスを生成して PostGIS に投入する。

plot = Plot()
plot.name = "test1"
plot.geom = geo

session.add(plot)
session.commit()

サンプルコードの完全版は以下の通り。

from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker
from sqlalchemy import Column, Integer, Text
from geoalchemy2 import Geometry
from geoalchemy2.shape import from_shape
from shapely.geometry.point import Point
from shapely.geometry.collection import GeometryCollection

from sqlalchemy.ext.declarative import declarative_base
Base = declarative_base()

db_url = "postgresql://gis:gis@localhost/gistest"
dat = [ [6,8], [8,1], [9,44] ]

db_engine = create_engine(db_url)
DBSession = sessionmaker(bind=db_engine)
session = DBSession()

class Plot(Base):
    __tablename__ = 'plots'
    id = Column(Integer, primary_key=True)
    name = Column(Text)
    geom = Column(Geometry('geometry', 4612))

points = []
for i in dat:
  points.append(Point(i))

gc = GeometryCollection(points)
geo = from_shape(gc, srid=4612)

plot = Plot()
plot.name = "test1"
plot.geom = geo

session.add(plot)
session.commit()

これで、GeoAlchemy2 の使い方はだいたい解った。

（承前）

Python コード内で GeoAlchemy2 を使う

サンプルとして下図のようなデータを作成した。

PostGIS 上で見ると、

gistest=> select * from plots;
 id |  name  |                                                                                                                                                               geom
----+--------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  1 | points | 010700002004120000070000000101000000F2FFFFFF23932140DDFFFFFFF9364A400101000000E4FFFFFF47941E40DDFFFFFFF90C47400101000000E4FFFFFF47D81640DDFFFFFFF96647400101000000BAFFFFFF23C52B40DDFFFFFF797D47400101000000DDFFFFFF916B3B40DDFFFFFFB9B547400101000000DDFFFFFF91DC3340DDFFFFFF393449400101000000DDFFFFFF91553340DDFFFFFF79614540
(1 行)

一方、Pyramid 上でビュー函数を定義し、そこにデバッグ用 print 文を仕込んでみる。

@view_config(route_name='item', renderer='templates/plot.pt')
def item_view(request):
  item_id = request.matchdict['id']
  item = DBSession.query(Plot).filter(Plot.id == item_id).first()
  print item.geom

すると、pserve を実行したコンソール上に同じ文字列が出力される。

0107000000070000000101000000f2ffffff23932140ddfffffff9364a400101000000e4ffffff47941e40ddfffffff90c47400101000000e4ffffff47d81640ddfffffff96647400101000000baffffff23c52b40ddffffff797d47400101000000ddffffff916b3b40ddffffffb9b547400101000000ddffffff91dc3340ddffffff393449400101000000ddffffff91553340ddffffff79614540

これは OpenGIS の WKB (Well-Known Binary) フォーマットのデータを hex 表現したもので、PostGIS に格納されている元々のデータは バイナリである（と思われる）。 item.geom オブジェクトは geoalchemy2.elements.WKBElement クラスの インスタンスで、このクラスは data と desc の属性を持つ。 data 属性はバイナリ表現のデータを保持し、desc は data の内容を hex 化して 返す、@property でデコレーションされたメソッドである。

WKB を WKT (Well-Known Text) 形式に変換するには主にふたつの方法がある。 PostGIS サーバに変換させる方法と、ローカルマシンで処理する方法である。

PostGIS サーバに変換させるには、geom カラムに ST_AsText() 函数を適用すれば良い。 ビュー函数のデバッグ文を以下のように変更する。

print DBSession.scalar(item.geom.ST_AsText())

すると出力は、

GEOMETRYCOLLECTION(POINT(8.7873840332031 52.429504394531),POINT(7.6448059082031 46.101379394531),POINT(5.7112121582031 46.804504394531),POINT(13.885040283203 46.980285644531),POINT(27.420196533203 47.419738769531),POINT(19.861602783203 50.408020019531),POINT(19.334259033203 42.761535644531))

コレクションの中身を分割させるには ST_Dump() 函数を使う。

a = DBSession.execute(item.geom.ST_Dump().geom.ST_AsText())
for i in  a.fetchall():
  print i

出力は、

(u'POINT(8.7873840332031 52.429504394531)',)
(u'POINT(7.6448059082031 46.101379394531)',)
(u'POINT(5.7112121582031 46.804504394531)',)
(u'POINT(13.885040283203 46.980285644531)',)
(u'POINT(27.420196533203 47.419738769531)',)
(u'POINT(19.861602783203 50.408020019531)',)
(u'POINT(19.334259033203 42.761535644531)',)

各行がタプルになっている点に注意が必要だ。

ローカルマシンに変換させる場合は geoalchemy2.shape.to_shape() を使う。 ビュー函数を修正してアプリケーション再起動。

from geoalchemy2.shape import to_shape
@view_config(route_name='item', renderer='templates/plot.pt')
def item_view(request):
  item_id = request.matchdict['id']
  item = DBSession.query(Plot).filter(Plot.id == item_id).first()
  print to_shape(item.geom)

コンソール出力は以下のようになる。

GEOMETRYCOLLECTION (POINT (8.7873840332031 52.429504394531), POINT (7.6448059082031 46.101379394531), POINT (5.7112121582031 46.804504394531), POINT (13.885040283203 46.980285644531), POINT (27.420196533203 47.419738769531), POINT (19.861602783203 50.408020019531), POINT (19.334259033203 42.761535644531))

geoalchemy2.shape.to_shape() は shapely というパッケージを利用しており、 shapely は OS の libgeos を呼び出しているようだ。

to_shape() の返り値はオブジェクトで、この場合は <class ‘shapely.geometry.collection.GeometryCollection’> になる。このクラスはリストとして動作するのでスライス操作で要素を取り出すことが できる。 個々の要素は、この場合は <class ‘shapely.geometry.point.Point’> で、 POINT データの内容を更に操作することができる。たとえば X座標値だけを取り出すには

for i in shape.to_shape(item.geom):
    print i.x

などとすれば良い。

Python コードとの相性は geoalchemy2.shape の方が良さそうだ。 ただ、PostGIS と libgeos がトポロジー計算などでまったく同じ精度の 計算を行うのかどうかは確かめないといけない。

（承前）

ジオメトリの種類を変える

models.py の point を multipoint に変えてみる。

class Plot(Base):
    __tablename__ = 'plots'
    id = Column(Integer, primary_key=True)
    name = Column(Text)
    geom_point = Column(Geometry('multipoint', 4612))

テーブルを作り直してアプリケーション再起動。 すると下図のように、OpenLayers インターフェイス上で 多点指定ができるようになった。

linestring と multilinestring、 polygon と multipolygon も同様の関係になる。

さて汎用の geometry を指定した場合にどうなるか、だが、

geom = Column(Geometry('geometry', 4612))

point, linestring, polygon を自由に指定できる。

geometry は geometrycollection でも良いようだ。

geom = Column(Geometry('geometrycollection', 4612))

複数カラム

ひとつのテーブルに複数のジオメトリカラムを作成した場合にどうなるか、 見てみる。models.py を以下のように修正してテーブルを作り直す。

class Plot(Base):
    __tablename__ = 'plots'
    id = Column(Integer, primary_key=True)
    name = Column(Text)
    geom_geometry = Column(Geometry('geometry', 4612))
    geom_point = Column(Geometry('multipoint', 4612))
    geom_line = Column(Geometry('multilinestring', 4612))
    geom_polygon = Column(Geometry('multipolygon', 4612))

アプリケーションを再起動すると下図のようになる。 注意するべきは、2段目、3段目に表示されるべきデータが 4段目に表示されているところである。

これは、GeoFormAlchemy の renderer が、OpenLayers 用に、 まったく同一の JavaScript コードを 4回出力しているからだと思われる。 OpenLayers インスタンスへの参照を保持する変数名を使い回すことになるため、 4個目のインスタンスだけが変数に格納され、 1-3個目のインスタンスは、メモリ上には存在するが JavaScpript コードからはアクセスできないようになる。 結果的に、すべての入力内容が 4個目のインスタンスに渡されることになる、 ということなのだろう。 ただ、上図では 1個目のインスタンスだけは正常に動作しているようで、 それが何故なのか、この理屈ではよく解らない。

ちなみにこのまま save しようとするとエラーが出る。4個目のカラムは multipolygon 用であり、point や linestring を格納しようとするとエラーが 出るのである。

GeoFormAlchemy のこの挙動をバグと捉えるかどうかは悩ましいところである。 何故なら、OpenGIS では基本的に、ひとつのテーブルに対して ジオメトリカラムはひとつであることを措定しているからだ。 GIS は地物を扱う。地物には様々な属性が附属しており、ジオメトリも 属性のひとつである。ひとつの地物が複数のジオメトリを持つことはありえない。 何故なら地物はひとまとまりの物理的実体であり、従ってひとまとまりの ジオメトリしか持ち得ないからである。

よって、そもそも上記の models.py のような、ジオメトリタイプごとに カラムを分けるようなテーブル設計は OpenGIS の流儀から外れている、 ということだ。複雑なジオメトリデータを格納する場合は geometrycollection を 使うべきである。

なお、私は昨日まで PostGIS 等を使用したことがなく、OpenGIS に関する 上記の記述も、ついさっき小一時間調べただけに過ぎない。 私の理解が間違っているかも知れないので直ちに真に受けてはいけない。

（続く）

SQLAlchemy を空間データに拡張した GeoAlchemy2 という パッケージがあるのを見つけた。 同様に FormAlchemy にも GeoFormAlchemy2 があるらしい。 早速試してみる。

$ cd /usr/local/share/postgresql/contrib/postgis-2.1/
$ su pgsql
# psql postgres
postgres=# create database gistest;
postgres=# create role gis with unencrypted password 'gis' login;
postgres=# \c gistest
gistest=# \i postgis.sql
gistest=# \i spatial_ref_sys.sql
gistest=# \i topology.sql
gistest=# \q

$ pip install GeoAlchemy2

from geoalchemy2 import Geometry
class Plot(Base):
    __tablename__ = 'plots'
    id = Column(Integer, primary_key=True)
    name = Column(Text)
    geom_point = Column(Geometry('point', 4612))

$ pip install GeoFormAlchemy2

誤) options['openlayers_lib'] = 'http://openlayers.org/dev/OpenLayers.js'
正) options['openlayers_lib'] = 'http://openlayers.org/api/OpenLayers.js'

from formalchemy import FieldSet, Grid
from geoformalchemy import GeometryFieldRenderer
from geoalchemy2 import Geometry
FieldSet.default_renderers[Geometry] = GeometryFieldRenderer

動作テスト

この状態で Pyramid を起動し、 pyramid_formalchemy の admin UI で表示させてみる。

__init__.main() に pyramid_formalchemy の admin UI 設定が残っていることを確認。

config.include('pyramid_formalchemy')
config.formalchemy_admin('admin', package="alc")

テーブルを作成してアプリケーションを起動し、ブラウザで http://hogehoge/admin/Plot にアクセスすると以下のようになる。

‘new plot’ ボタンを押すと、 OpenLayers のインターフェイスが現れ、 地図上で空間データが入力できる。今回は models.py で point を 指定したため、点がひとつしか指定できない（新しい点を指定すると 既存の指定点が消されてしまう）。point ではなく multipoint を 指定するとどうなるか、後で確認してみよう。

‘save’ ボタンを押すとデータがテーブルに insert される。

Geom 欄の背景に何も表示されていないように見えるのはズームのせいで、 ズームを調整すると背景にちゃんと地図があることが解る。

（続く）

（承前）

pyramid_formalchemy のビュー機能

pyramid_formalchemy には管理インターフェイスが附属しているので それを試してみる。

まず必要なパッケージをインストールする。

$ pip install webhelpers
$ pip install couchdbkit

alc/forms.py を作成する。 pyramid_formalchemy のマニュアル には空ファイルで良いとあるが、実際にはそんなことは無かった。 以下の行を記述する。

from formalchemy import FieldSet, Grid

__init__.main() に以下を追加する。

config.include('pyramid_formalchemy')
config.formalchemy_admin('admin', package="alc")

アプリケーションを再起動して http://hogehoge/alc/admin/ にアクセスすると 以下のように表示される。

例えば Order をクリックすると Order クラスのレコードが表示される。 新規作成や編集もこの画面から可能である。

構造が単純なデータベースを自分だけで使う場合は これで充分という気がする。

（承前）

リレーション

テーブル間のリレーションの設定には 2種類が必要で、

• RDBMS 上のテーブル定義での外部キー制約の設定
• Python コード上でリレーションを扱うための設定

を別々に指定する。これらはモデルに指定する。

alc/models.py に以下を追加する。

class Order(Base):
  __tablename__ = 'orders'
  id = Column(Integer, primary_key=True)
  fruit_id = Column(Integer, ForeignKey('fruits.id'))
  amount = Column(Integer)

  fruit = relation(Fruit, backref=backref('orders', order_by=id))

ここで、fruit_id が RDBMS 上での外部キーを指示しており、 fruit がリレーション先の Fruit オブジェクトを格納する変数である。 Python コード上で fruit 変数にアクセスすると自動的にデータベースに クエリが発行されて対応する Fruit オブジェクトが fruit 変数に 格納されるという動作をする。

backref 云々というのはリレーション先の Fruit クラス上に 逆方向のリレーションを自動的に作成するように指示するコードで、 Fruit.orders に関連する Order オブジェクトが自動的に格納されるようになる。

モデルを追加したのでテーブルを作成する。

$ initialize_alc_db development.ini#truemain

Order 用に URL パターンを追加する。__init__.main() に

config.add_route('order', '/order')

そしてビューも追加する。views.py に

@view_config(route_name='order', renderer='templates/fruit.pt')
def order_view(request):
  num = DBSession.query(Order).count()
  action_url = request.route_url('order')

  if 'form.submitted' in request.params:
    up = FieldSet(Order, DBSession, data=request.POST)
    if up.validate():
      up.sync()
      DBSession.add(up.model)

  fs = FieldSet(Order, DBSession) # notice
  return {'number': num, 'form': fs.render(), 'action_url': action_url,
      'submit_label': 'Add New Order'}

ここで注意が必要なのは # notice の部分で、リレーションが無い場合は

fs = FieldSet(Order)

でも動作するのだが、リレーションを設定していると、リレーション先の テーブル内容を取得するために自動的にクエリが発行される場合があるため、 DBへのセッションを与えておく必要がある。上記の場合では return 文にある fs.render() を実行する時にリレーションを解決しようとするため、 セッションを指定しないと例外が出る。

Exception: No session found.  Either bind a session explicitly, or specify relation options manually so FormAlchemy doesn't try to autoload them.

さてアプリケーションを再起動して http://hogehoge/alc/order にアクセスすると TypeError が出る。

TypeError: lists/tuples are no longer allowed as elements in the 'options' arg: (u'', u'None')

これは WebHelpers2 の仕様変更に FormAlchemy が追従していないために 発生する例外である。PyPI 上にある最新の FormAlchemy は Ver 1.5.5 であるが、 GitHub には開発版の 1.6-dev があり、そちらのコードは WebHelpers2 の 仕様変更に追従している。変更点は 1行だけであるので、ローカルのファイルを 手作業で変更した方が早い。

修正が必要なファイルは formalchemy/helpers.py で、 diff は

@@ -173,7 +173,7 @@ def select(name, selected, select_options, **attrs):
     """
     if 'options' in attrs:
         del attrs['options']
-    select_options = _sanitize_select_options(select_options)
+    select_options = (tags.Option(*reversed(o)) for o in _sanitize_select_options(select_options))
     _update_fa(attrs, name)
     if six.PY3 and isinstance(selected,map): # this test fails with py2
         selected = tuple(selected)

アプリケーションを再起動して http://hogehoge/alc/order にアクセスすると このような画面が表示される。

Fruit 欄にインスタンスのメタ情報が表示されてしまっているが、 これは Fruit クラスの __repr__() をオーバーライドしていないために デフォルトの __repr__() 函数が使用されているためである。 従って Fruit クラスの定義に __repr__() を追加する。

def __repr__(self):
  return self.name

アプリケーションを再起動するとドロップダウンメニューの表示が変わる。

（続く）

（承前）

次に、モデル作成からフォーム処理までの作業の概略を確認しよう。

class Fruit(Base):
    __tablename__ = 'fruits'
    id = Column(Integer, primary_key=True)
    name = Column(Text)
    price = Column(Integer)

from ..models import (
    Fruit,
    )

$ initialize_alc_db development.ini#truemain

config.add_route('home', '/')
config.add_route('item', '/{id}')

from pyramid.view import view_config
from formalchemy import FieldSet

from .models import (
    DBSession,
    Fruit,
    )

@view_config(route_name='home', renderer='templates/fruit.pt')
def home_view(request):
  num = DBSession.query(Fruit).count()
  action_url = request.route_url('home')

  if 'form.submitted' in request.params:
    up = FieldSet(Fruit, DBSession, data=request.POST)
    if up.validate():
      up.sync()
      DBSession.add(up.model)

  fs = FieldSet(Fruit)
  return {'number': num, 'form': fs.render(), 'action_url': action_url,
      'submit_label': 'Add New Item'}

@view_config(route_name='item', renderer='templates/fruit.pt')
def item_view(request):
  item_id = request.matchdict['id']
  item = DBSession.query(Fruit).filter(Fruit.id == item_id).first()

  if 'form.submitted' in request.params:
    up = FieldSet(item, data=request.POST)
    if up.validate():
      up.sync()
      DBSession.add(up.model)

  action_url = request.route_url('item', id=item_id)
  fs = FieldSet(item)
  fs_ro = FieldSet(item)
  fs_ro.readonly = True
  return {'tgt': item, 'info': fs_ro.render(),
      'form': fs.render(), 'action_url': action_url,
      'submit_label': 'Update'}

TypeError: No renderer found for field text_list. Type TEXT[] has no default renderer

テンプレート

Pyramid は Mako と Chameleon と2種類のテンプレートが使えるが、 このうち Chameleon は ZPT からの派生で、 TAL や METAL が使えるというので、 Chameleon を使う。

<!DOCTYPE html>
<html lang="${request.locale_name}">
  <head>
    <meta charset="utf-8">
    <title>Friut Database</title>
  </head>
  <body>
    <div tal:condition="number | nothing">
      Number of items: ${number}
    </div>
    <div tal:condition="tgt | nothing">
      ID: ${tgt.id}
      <table>
        ${info}
      </table>
    </div>
    <div>
      <form action="${action_url}" method="post">
        ${form}
        <input type="submit" name="form.submitted" value="${submit_label}"/>
      </form>
    </div>
  </body>
</html>

ZPT は ${} 構文が使えず、 tal:content や tal:attributes を使わなければ ならないところが煩雑だったが、 ${} が使えるだけで随分簡便になるものだ。

ブラウザ上の表示は、’home’ ビューが

‘item’ ビューが

のようになる。試験のため見栄えが良くないが、 METAL が使えるということはマクロが使えるということなので、 ページレイアウトをマクロ化したりすれば多少はマシなものが作れるだろう。

あと確認が必要なのは、

• 外部キーを使ったリレーションに対する FormAlchemy の振る舞い
• METAL
• pyramid_formalchemy のビュー機能

あたりか。

（続く）

PostgreSQL 上のデータベースに対する UI が欲しいと思い、 表題のような組み合わせを検討したので記録しておく。

PostgreSQL 上で create database, create role, grant の作業は 済んでいるという前提。

インストール。

$ pip install pyramid
$ pip install sqlalchemy
$ pip install pyramid-sqlalchemy
$ pip install psycopg2
$ pip install FormAlchemy
$ pip install pyramid_formalchemy
$ pip install pyramid-chameleon

プロジェクト作成。

$ pcreate -s alchemy alc
$ cd alc
$ python setup.py develop

設定ファイル development.ini 修正。

[app:truemain]  <- [app:main] から変更
..snip..
sqlalchemy.url = postgresql://alc_admin:alc_pass@localhost/alc

[composite:main]    <- URL調整のために追加
use = egg:Paste#urlmap
/alc = truemain

初期化と起動。

$ initialize_alc_db development.ini#truemain
    （#section を指定しないと [composite:main] に sqlalchemy.url が
        あるものだと仮定して処理するようで、エラーが出てしまう。）

$ pserve development.ini

ブラウザで http://hogehoge/alc/ にアクセスすると Pyramid のトップページが表示されるはず。

（続く）

きっかけは単なる思いつきで、職場で発行しているニュースレターの記事を CiNii Articles で検索可能にできたらいいな、と。

CiNii Articles での学術出版物の判別基準がどうなっているのか知らないが、 ニュースレターは学術出版物と認められるらしい。たとえば 日本地球惑星科学連合 JpGU のニュースレター JGL は記事の書誌情報が CiNii Articles に 収録されており、たとえば http://ci.nii.ac.jp/naid/40020474066 のようである。 右隅に表示されているように、情報の出所は国会図書館(NDL)らしい。 つまり JpGU は JGL の冊子体を NDL に納本しており、NDL は JGL を雑誌記事索引の 収録対象にしている、ということだ。実際に NDL の採録誌一覧に JGL が 載っている （ ここ ）。

CiNii Articles は基本的に既存のデータベースを統合しているだけで、 自力でゼロから収集している訳ではない。そこで、CiNii Articles に書誌情報を 載せるにはその情報源となっているデータベースに情報を流すことになる。

最初に検討したのは JaLC で、その理由は、そもそもこれらのことを考え始めたのは JaLC の 「研究データへのDOI登録実験プロジェクト」 に参加するようになって、どうせならついでに出版物にも DOI を振ったらいいじゃん、と 考えたからだ。JaLC に DOI を登録する際には JaLC メタデータと呼ばれる情報を 提出するので、その情報をそのまま JaLC から CiNii に流して貰えれば楽ちんだな、 と思ったのである。

しかしこの案は駄目だと判った。JaLC は2,3 年前から論文情報の DOI 登録を扱っているが、 CiNii Articles には JaLC のデータベースは収録されていない。それには理由があって、 JaLC の会員はほとんどが NII の JAIRO か JST の J-Stage を利用している 大学または学協会で、JAIRO と J-Stage は元から CiNii Articles の情報源になっているため、 JaLC からメタデータを CiNii に流すことは基本的に二度手間にしかならないのである。

次に考えたのは、CiNii Articles が CrossRef を情報源にしていることから、 JaLC 経由で CrossRef に DOI 登録し、CrossRef 経由で書誌情報を CiNii Articles に 流す、という方法である。この方法の欠点は、CiNii Articles に収録させるためだけに CrossRef を利用することの妥当性に疑問があること（CrossRef に登録すると JaLC 会費とは別に 費用がかかる）で、現実的な選択肢ではないと思われる。

他に良い方法が無いかと考えてみたところ、NII の 学術機関リポジトリデータベース IRDB 経由で流す方法があることに気付いた。IRDB は国内の学術機関リポジトリに格納されている 書誌情報等を収集して蓄積しているデータベースで、 CiNii Articles の情報源のひとつに なっている。IRDB は基本的には大学や大学共同利用機関を対象にしているようだが、 運用規程 によると、特に大学に限定している訳ではないようだ。つまり国環研も、 条件を満たせば IRDB に書誌情報等を格納してもらえる筈である。

その条件は、提供リポジトリのシステムが、

• OAI-PMH を喋れる
• junii2 形式のメタデータを吐ける

ことである（ 詳細 ）。 このうち OAI-PMH は世界的な標準プロトコルなのでいいとして、 NII 独自の junii2 フォーマットに対応できるかどうかが要点となる。

ところで junii2 には DOI 用の項目が 2種類あり(selfDOI, doi)、用途が異なる。 selfDOI は、情報提供機関が NII 傘下の JaLC 準会員となり、NII 経由で JaLC に DOI を登録する際に利用する項目で、一方の doi は NII とは無関係に情報提供機関が独自に DOI を取得した場合に利用する項目である。両方の選択肢が用意されている点は 評価して良いだろう。

さて junii2 への対応であるが、技術的には OAI-PMH + junii2 など大して高度なものではないが、 自分でリポジトリシステムを作るとなると大変面倒くさい。 出来合いのソフトウェアとして NII のウェブサイト には DSpace や WEKO が挙げられている。 DSpace は広く使われているリポジトリシステムで、CGER でも7,8年前に導入が 検討されたことがある。junii2 用のプラグインを導入すれば junii2 が吐けるようになる ようなことがウェブページに書いてあるが、詳しいことは判らない。 WEKO は NII が自ら作成したソフトで、NetCommons のモジュールとして動作し、 JAIRO クラウドの基盤として使用されている。 他に理研制作の XooNIps が挙げられているが、フレームワークが Xoops Cube で、 今から導入するシステムに Xoops Cube を使うのはどうなのかという気がするので 個人的には避けたい。

機能やデザインに拘らないのであれば、WEKO を使うのが一番手っ取り早い。 という結論を得て、ちょっと WEKO を試用してみようとしたのだが、 公式サイト にまともなドキュメントが無く、一通り動かすのに苦労した。 試行錯誤したため必要十分な手順が判らなくなってしまったので、 後で再検証するか。時間があれば。

CiNii に続いて NDL から書誌情報を取得する方法を検討する。 以下、調査結果を記す。

最初に注意しなければならないのは、API を提供しているのは 国立国会図書館サーチ（NDLサーチ）であり、NDL-OPAC ではない、 ということだ。なぜこれが重要かと言うと、両者は検索する データベースの範囲が異なり、そのため ID の体系が異なるからである。

<dcndl:materialType rdf:resource="http://ndl.go.jp/ndltype/Book" rdfs:label= "図書"/>

（承前）

実用上の問題としては、ライブラリがないことが一番の障害だ。 CiNii の公式サイトに見当たらないし、利用者の「試してみた」記事にも無い。 まぁちょっと試してみる程度の動機ではそれなりのコードを書く気にも ならんだろう。しかし NII は過去にアプリコンテストなどを開催しているが、 そんなコンテストするよりは主要言語用のライブラリを整備した方が よっぽど利用者が増えると思うのだが、本末を間違えてるんじゃないのかそれ。

まぁいい。

さて python で書くとすると requests が便利だが、requests.Response に json() という JSON パーサがあるようなので、これを使うことにした。 つまり、書誌情報を CiNii Web API から JSON-LD 形式で取得し、これを requests の JSON パーサで python オブジェクト化してから取り出す。

JSON データを解析したりしながら約 2日、出来たのが これ 。元々の JSON-LD 形式というのが 妙に煩雑なせいか、不格好なコードになってしまった。

>>> import ciniiwebapi
>>> cwapi = ciniiwebapi.CWAPI("your developer_id")
>>> cite = cwapi.query("110009810897")
>>> cite.title
「研究データ公開」における人材と体制の問題 : 研究図書館の可能性(学術情報)

>>> dir(cite)
['authors', 'authors_en', 'authors_num', 'pages', 'publication', 'publication_en', 'publisher', 'publisher_en', 'title', 'title_en', 'volume', 'year']

>>> for i in dir(cite):
...  data = getattr(cite, i)
...  if isinstance(data, list):
...    data = u", ".join(data)
...  if isinstance(data, unicode):
...    data = data.encode("utf-8")
...  print "{}: {}".format(i, data)
...
authors: 真板 英一
authors_en: Maita Eiichi
authors_num: 1
pages: 81-86
publication: 日本生態学会誌
publication_en: Japanese Journal of Ecology
publisher: 日本生態学会
publisher_en: The Ecological Society of Japan
title: 「研究データ公開」における人材と体制の問題 : 研究図書館の可能性(学術情報)
title_en: Professions and facilities for the research data publication : the potential of research libraries(News)
volume: 64
year: 2014

PlotNet のサイトを作っていて、文献情報をいちいちコピペするのが 面倒なので、外部DBから取って来れないものかと思い、まずは CiNii の API サービスを調べてみた。

まず “CiNii API” 等でググってみると、検索上位には CiNii の公式サイトが並び、 その他は「試しにちょっと使ってみた」程度のページが数える程度出てくるだけで、 世間ではあまり流行っていない、という印象を持った。 この API サービスが始まったのは 2009年頃のようで、その当時は NII が API を使用したアプリ開発のコンテスト を開催したようだが、2009, 2010年に 1回ずつ開催しただけで終わったようだ。 一方で API の開発は継続されており、 2013年に JSON-LD 形式に対応するなど 機能拡張が進められている。内部事情はよく知らないが、限られた人員・予算で 細々と継続しているのであろう。

さて、この API を利用するにはデベロッパー登録というものを しなければならないことになっている。実際には無登録でも、 少なくとも書誌情報を RDF または JSON-LD 形式で取り出すことは可能で、 たとえば http://ci.nii.ac.jp/naid/110009810897.rdf などと URL の末尾に .rdf 等を付加すれば良い。おそらくこの登録というものは CiNii の側で API の利用状況を把握するために利用するのであろう。 有料という訳でもないし、素直に登録することとした。

ところで、 API 登録者は API 利用に関して 学術コンテンツサービス利用規程 なるものを遵守せよ、と要求されるのであるが、この規程というのが なかなか曲者である。たとえば第4条に、

(利用目的)
第4条 何人も自己の学術研究に利用するため,本サービスを利用するものとし,それ以
外の目的のために使用しないことに同意する。

とあるが、API を使用するアプリを作って第三者に提供した場合、 （自己ではなく）その第三者の学術研究のために API を利用したことになってしまうため、 通常の意味でのアプリ開発は不可能ということになってしまう。 アプリを開発者自身しか使わない場合は問題ないが、先述の通り、 NII 自体が過去にアプリコンテストなるものを開催して第三者使用を奨励しており、 明らかに矛盾している。

他には第5条2項の一、

一 複製,改変,翻訳及び編集等を行ってはならない。ただし,自己の学術研究に利用
するためダウンロードし又は印刷することができる。

アプリというものは適宜、 API で得た情報を編集加工してアプリ利用者に提示するものであって、 編集するべからずという要求は理解に苦しむ。

つまりこの条文は公開 API の提供を想定していない ものであって、API 登録者に遵守を求めることが無理なのである。 この点を CiNii の担当者は認識しているのだろうか。 この規程を修正するか、または API利用者用に別に規程を策定するか、 どちらかの対応が必要と思われる。 CiNii Web API が世間で利用されている形跡が少ないのは この規程の不備も原因のひとつなのだろうか。

まあ良い。規程の問題は当面無視する。

Python では公式にはインデント幅は 4 にすることになっているようだが、 個人的には 4文字幅は深過ぎると思っている。 真面目な（書き捨てでない）コードの場合、主要な部分はだいたいインデントの 3-4段目に来ることになる。つまり、

class CLASS:
  def __init__(self):
    if a:
      hogehoge（3段目）
      for i in b:
        hogehoge（4段目）

さてそうすると、4文字幅の場合、4段目のインデントでは無条件に 16文字分の領域が消費されてしまうことになる。 一行の文字数が約70文字しか無いのに、その 2割強があらかじめ使えないとなると、 コード記述の自由度が低く、窮屈である。 私はこの窮屈さが嫌いで、インデント幅を 2文字に減らして python コードを 書いてきた。別に書いたコードを PyPI に登録したりする訳でもないので、 個人の勝手の範囲である。

さて、さっき、 FreeBSD 上の vim で python コードを書こうとしたら、 自動インデントの幅がいつの間にか 4 になってしまっていて戸惑った。 色々調べてみたところ、先日、サーバ上で何かをアップデートした時に pkg の vim にアップグレードが掛かってしまい、 filetype 関係の 定義ファイルが書き変わってしまったようだ、と考えられた。 /usr/local/share/vim/vim74/ftplugin/python.vim に

" As suggested by PEP8.
setlocal expandtab shiftwidth=4 softtabstop=4 tabstop=8

という行があり、おそらくこれがアップグレード時に追加されたのだろう。

この設定は ~/.vimrc の指定を上書きするらしく、~/.vimrc の中での 記述順を変えたりしても無駄であった。

ググってみたところ、~/.vim/indent/ にインデントに関する個人設定が 置けるようだったので、試しに ~/.vim/indent/python.vim に

setlocal shiftwidth=2

と指定したら、以前の通り、自動インデントが 2文字に戻ったのであった。

PostgreSQL のバージョンアップを他人任せにしたら、 PostGIS 用のテンプレート上にリストアされてしまって、 pg_dump に余計なものが混じるようになってしまった。

取り敢えず、PostGIS 用のビューとテーブルを削除したものの、 他にデータタイプと函数が大量に登録されていて、気が遠くなる。 幸いなことに、今まではデータタイプも函数も使用していなかったので、 これらをまとめて全部無視すれば良いということが判った。

調べてみると、pg_dump には –table オプションがあり、これは テーブル、ビュー、シーケンスのみをダンプする機能であった。 試しに使ってみると、テーブル作成からインデクス、外部キー制約まで 一通り出力してくれるようだ。

他に –data-only というオプションもあるが、こちらは 外部キー制約が上手く出力できないようで、 notice が出力された。 これは使わない方が良いだろう。

結論としては以下のようになる。PostGIS は topology という スキーマを作成するので public.* と指定した方が間違いがない。

# pg_dump -h host -U user -c --table="public.*" database

なお、PostgreSQL のスキーマには 2重の意味があって、最初は混乱した。 実際に pg_dump の man にもそう書いてある。:

--schema-only
     .. snip ..
    (Do not confuse this with the --schema option, which uses the word
    "schema" in a different meaning.)

–schema の方は名前空間の方の意味で、 –schema-only の方は テーブル定義の方の意味である。

生半可だった知識を整理する機会にはなった。

NASA Ames Format for Data Exchange というデータ形式があって、 地球科学関係の分野でよく使われている。

このフォーマットを扱える Python パッケージはないものかと PyPI を 探したところ、 2つ見つかった。

という訳でまず NAStools から試す。

$ pip install numpy
$ pip install pandas
$ pip install NAStools

$ curl -O http://badc.nerc.ac.uk/help/formats/NASA-Ames/example-1001-a.na
$ python
>>> import nastools
>>> ex = nastools.Naspy("example-1001-a.na")
>>> ex
NAS Data File (FFI = 1001)
example-1001-a.na

>>> dir(ex.header)
['COLUMN_VARIABLES', 'DATA_DESCRIPTION', 'DATA_INTERVAL',
'DEPENDENT_VARIABLE', 'FFI', 'FILENAME', 'FILE_VOL_NO', 'HEADER_LINES',
'INDEPENDENT_VARIABLE', 'MISSING_DATA_FLAGS', 'MISSION', 'NORMAL_COMMENTS',
'NORMAL_COMMENT_LINES', 'NO_VOL', 'ORGANIZATION', 'PI', 'REV_UTC',
'SCALE_FACTORS', 'SPECIAL_COMMENTS', 'SPECIAL_COMMENT_LINES', 'START_UTC',
'TOTAL_NUM_VARIABLES', '__class__', '__delattr__', '__dict__', '__doc__',
'__format__', '__getattribute__', '__hash__', '__init__', '__module__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
'__sizeof__', '__str__', '__subclasshook__', '__weakref__',
'_fileAbsPath_', '_fileObj_', 'contact_info', 'data_description',
'parse_header']

>>> ex.header.DATA_DESCRIPTION
'Meteorological sensors'

>>> print ex.header.COLUMN_VARIABLES
['t', 'T', 'p', 'RH']

>>> print ex.get_column_names()
['T', 'T', 'P', 'RH']

>>> ex.make_numpy()
array([(38927.0, 10.0, 99.0, 0.6), (38927.020833, 10.1, 98.9, 0.591),
       (38927.041667, 9.5, 99.3, 0.62), (38927.0625, 9.2, 99.5, 0.632),
       (38927.083333, 9.3, 99.4, 9.999), (38927.104167, 8.9, 99.9, 9.999),
       (38927.125, 8.5, 100.1, 0.632), (38927.145833, 8.9, 99.8, 0.622),
       (38927.166667, 9.4, 99.7, 0.61), (38927.1875, 10.1, 99.5, 0.604),
       (38927.208333, 10.2, 99.3, 0.595), (38927.229167, 10.4, 99.0, 0.58),
       (38927.245, 10.3, 99.2, 0.587)],
      dtype=[('T', '<f8'), ('T_1', '<f8'), ('P', '<f8'), ('RH', '<f8')])

EML エディタ Morpho の新バージョン 1.11.0 がリリースされたとのこと。 インストーラ付きバイナリは KNB からダウンロードできる。

リリースノートによると、新バージョンでは Java 6 のサポートを打ち切った模様。 手元の Macbook OS X 10.9 では Java 8、FreeBSD 10.1R では Java 7 が デフォルトになっているようなので、まったく実害はない （Windows は知らないし、興味もない）。 と言うか、リリースノートにはそれしか書いてないのだが、他に変更点はないのだろうか。 新機能の追加などはせず、古いコードを削ることに注力したのかしら。 Java なんぞ普段書かないから事情が解らん。

実は Morpho 1.10 系列をちゃんとフォローしていなかったので Morpho の change log を読むのは久しぶりなのだが、読んでみると 面白いことが書いてある。 ひとつはメタデータを PDF で出力できる機能で、「ファイル -> エクスポート」で 出力してみると、確かに PDF が現れる。

中身はこんな感じ。

正直、見易いんだか見難いんだかよく判らない。

もうひとつは、キーワードの入力に IMS VDEX という技術を導入して、 出来合いのシソーラスから定義済みのキーワードを選択できるようになったこと。 入力画面はこんな感じ。

IMS VDEX (Vocabulary Definition Exchange) というのは学習支援やナレッジベース関係の用途で作られた仕様で、 ボキャブラリ情報をやり取りするためのもの、らしい。 ググってもあまり情報が出てこないので、流行らなかったのかも知れない。 日本語だと IBM の技術情報のページ が出てきた。正確な経緯はともかく、大体の文脈はこれで解る。

調べると PyPI にも、 VDEX で書かれたボキャブラリ情報を Zope vocabulary オブジェクトに変換するパッケージが登録されている。そのパッケージの 説明には、ツリー構造のボキャブラリを自動処理できるところが売りだ、と 書かれているが、確かにそのような複雑な構造の情報だとこういうツールが欲しくなる かもな。

新バージョンをインストールしてみたが、EML エディタの機能としては ほとんど進化はないようだ。

文書作成ツールの利便性のひとつは参照関係を自動解決してくれるところにあり、 sphinx だと :ref: などがそれに当たる。

この機能を表の中でも使いたいと思い、 csv-table で :ref: を含んだデータを 読み込ませたのだが、sphinx が :ref: を解釈してくれず、そのまま出力されてしまった。 この時、実は、:ref: の記述をミスしていて、そのために参照が解決されなかったのだが、 普段 csv-table をあまり使わないせいで、「csv-table だと :ref: を解釈してくれない」と 思い込んでしまい、csv を grid table に整形するスクリプトを自作しようと 思ったのが発端である。

大きな csv（精確にはssv）データを手作業で grid table 化するのは面倒なので、 自動変換スクリプトを書こうと思うのは当然だが、書き始めてすぐに、 文字列長に関して疑問が生じた。grid table は罫線を精確に揃えて記述しなければ ならない形式であり、文字列長を厳密に計算する必要があるが、 マルチバイト文字列が含まれている場合に 文字列長をどのように計算しているのか、ということだ。

私は普段 ターミナル + Vim で作業しており、grid table を書く場合には 画面の見た目通りに書く。すなわち、Ascii文字は 1文字分、全角文字は 2文字分として 計算すれば sphinx のビルドが通る。しかしこれは不思議なことで、 UTF-8 だと日本語文字は 3バイト以上になるし、unicode オブジェクトに len() を 取ると1文字扱いだし、UTF-16 にすると逆に Ascii 文字が 2バイトに計算され、 全角／半角概念とは綺麗には整合しない。

不思議に思って sphinx のコードを追ってみたら、 docutils の方で、 unicodedata.east_asian_width() を呼んでいることが判った (docutils/statemachine.py)。 これは Unicode Standard Annex #11 に基づくもので、文字の表示幅を返す函数らしい。 docutils ではこれを利用して、画面上の見た目に合うように内部データを 修正している。

こんな便利な函数があるとは知らなかった。と言うか unicodedata ライブラリ自体 知らなかった。”unicodedata.east_asian_width” でググっても 1500件くらいしか ヒットしないので、世間でもあまり知られていないのかも知れない。

なお、:ref: の記述ミスに気付いたのはスクリプトが完成してからで、 完全な時間の無駄だった。馬鹿馬鹿しいが、勉強にはなった。

何気なく地理院地図のサイトを開いてツールをいじっていた時、 作図ツールの中に円があることに初めて気付いた。これ、前から あったっけか。それとも最近追加されたのか。

大雑把に範囲指示したい時にポリゴンよりも楽ちんかなと思い、 ちょっと作図してみたが、保存する時、KML と geojson でコードが違った。 KML だとポリゴン扱いで、円弧上の30個くらいの点を繋いで疑似円を 描画するようなコードだったのに対し、 geojson だと CircleMarker という 円図形の扱いで、中心座標と半径から円を描画するようなコードが出た。

これを見て、短絡的に、geojson には円が定義されているのかと思ったが、 調べてみるとそうではなく、geojson の規格にはKMLと同様に点・線・ポリゴンしか 定義されていない。じゃあ CircleMarker というのは何かと言うと、 Leaflet という JavaScript ライブラリで定義されているマーカだった。

以前調べた時には、地理院地図ではKMLかgeojsonでレイヤを記述できるが、 geojsonの方はまだ仕様が詰められていなくて、変更の可能性がある、という ことだったので、自作 Sphinx 拡張では KML を生成するようにしたのだった。 でも円が使えると便利だなーと思い、geojson を出力するように書き直した。

geojson形式だと、アイコンにアンカー点を指定できるので、Google Map で よく見られるピン／バルーン型のマーカアイコンも精確な位置に表示できる。 これも書き直す動機のひとつではあったが、改めて表示させたいデータを見ると、 特定の地域では点が密集していて、バルーン型のアイコンは明らかに邪魔すぎる と思い、従来の小ボタン型アイコンを使い続けることにした。

細かな点では、KML形式では色指定がなぜか #bbggrr というフォーマットで あったが、geojson では普通に #rrggbb で、混乱が少なくて良い。 あと半径の指定は、Leaflet のドキュメントにはピクセル単位と書かれているが、 地理院地図ではメートル単位のようだ。単位変換してから Leaflet に流している んだろう。

物は試しで起動するところまで。

virtualenv でテスト環境を作るところは省略。

(pyramid)$ pip install pyramid

(pyramid)$ pcreate -l
Available scaffolds:
  alchemy:  Pyramid SQLAlchemy project using url dispatch
  starter:  Pyramid starter project
  zodb:     Pyramid ZODB project using traversal

(pyramid)$ pcreate -s zodb testproj

(pyramid)$ cd testproj/
(pyramid)$ python setup.py develop

<VirtualHost *:80>
  ServerName pyramid.myserver.jp

  ProxyPreserveHost On
  ProxyPass /testproj http://localhost:6543/testproj
  ProxyPassReverse /testproj http://localhost:6543/testproj
</virtualHost>

[composite:main]      <- 追加
use = egg:Paste#urlmap
/testproj = truemain

[app:truemain]        <- [app:main] から変更

(pyramid)$ pip install Paste

起動

(pyramid)$ pserve development.ini

ブラウザで http://pyramid.myserver.jp/testproj/ にアクセスして 以下の画面が表示されたら正常。

全体的な状況はこんな感じらしい。

• 2014年 Webアプリケーションフレームワークトレンド

Django, Flask がやはり人気があるようだが、 これらは URLルーティング + ORマッピングなデザインだから 個人的には興味がない。

ただし、Django には GeoDjango というものがあるようで、 これは DB に PostGIS などを用いて空間情報を扱えるようにした 拡張らしい。暇で暇で仕方が無いような時があったら調べてみよう。

オブジェクト指向（的）のフレームワークとしては

• CherryPy
• Grok, Dolmen
• Pyramid, Substance D

が見つかった。

MS-WORD で保存したという mht ファイルを受け取ったのだが、 手元の Word for Mac 2011 で開けない。

中身を less で覗いても、壊れているようには見えなかったので、 ソフトウェアの問題なのであろう。WORD に拘る必要も無いし、 簡単に使える分解ツールは無いものかとググっても、めぼしいものが見つからず、 自分で書いた方が早そうだったので、そうした。

#!/usr/bin/python
# encoding: utf-8

import os
import sys
import errno
import email

# ファイル名が格納されているフィールド
TOJ = 'Content-Location'

# 抽出するべきデータ型
TYPES = {"text/html", "image/jpeg"}

# 出力先
OUTDIR = "mht_contents"

# 出力先作成
try:
  os.mkdir(OUTDIR)
except OSError, e:
  if e.errno != errno.EEXIST:
    raise RuntimeError

# ファイル読み込み
with open(sys.argv[1], "r") as fin:
  msg = email.message_from_file(fin)

# マルチパート解析
for mpart in msg.get_payload():

  # content type で選別
  if mpart.get_content_type() not in TYPES:
    continue

  # 出力ファイル名を抽出
  fn = mpart[TOJ].split("/")[-1]

  # ファイル出力
  with open(OUTDIR + "/" + fn, "wb") as fout:
    fout.write(mpart.get_payload(decode=True))

ファイルで欲しければ ここ から持っていくと良い。 第一引数で mht ファイル名を与えるようになっている。 まぁ、見れば解るか。Python 3 で動くかどうかは知らない。

pretty でない（改行を含まない）XML ファイルを less （と言うか lv ） で表示させたら、 行の途中で勝手に改行されているように表示されて、なんじゃこりゃとびっくりした。 最初はファイルが壊れているのかと思ったが、wc で見るとそんなことはなく、 オリジナル less と lv の表示を比較してみて、lv がおかしいことが判った。

おかしいと言うか、 仕様 なのだなこれは。 多言語化less として結構長いこと lv を常用してきた筈だが、 今まで気付かなかった。どうしてだろう、不思議だ。

トムソンロイター社に DCI 用の情報をメールで送ることになったので、 メール送信用のスクリプトを書く一日。昨日の午後に仕様を考え始めたが、 よくよく考えると結構複雑な動作が必要で、普段あまり使わないモジュールを 調べたりして、結局今日一日をコーディングに費やしてしまった。 200行くらいではあるが、 argparse でコマンド的な動作をするようにしたり、 頭の体操になった。

定期的にコードを書いてる訳ではなく、必要に応じて必要な分だけ書く、という 状況なので、それなりのものを作ろうと思うと最初にリハビリが必要になる。 昨日、仕様を考えながら、python っぽい書き方を思い出すのに苦労した。 まぁ、多分またすぐに忘れるだろうが。

正常系は完成したので、一晩寝かせてから異常系のテストをしよう。

研究データベースとか研究データ管理に数年間携わってきて、その結果、 これは 9割方は金の問題だ、と思うようになった。しかし私は世間知らず なので金の話がピンと来ない。

積ん読の「学術の動向」の続きを読んでいたら金の話が出てきたので ちょっとメモしておく。

文科省・学術情報基盤実態調査 によると、国内の大学における平成25年度の総計で、

国研等の分も含めると日本全体でジャーナルに 400~500億円くらい支払っていて、 全世界だと数千億円規模の産業ということなのか。なるほど誰も彼もが シリアルズ・クライシスとぼやく訳だ。

理研・玉尾氏の、日本発国際誌の育成に関する記事 は興味深かった。 学術誌に対する費用に関して国家収支を考えると、日本から海外に流出する一方であり、 早急に評価の高い国際誌を育成して少しでも収支を改善しないといけない、という 分析。 仮に日本からの発表論文がすべて掲載料著者負担式だったとすると掲載料は 年間 110億円程度となり、これが外国に流出するか国内に還流されるかは 国家戦略上無視できない、ということらしい。 なるほど。そういうことは考えたことがなかったな。

データペーパーを 1件片付けたと思ったら別のリクエストが飛んできた金曜日。 1年前のことなんかすぐには思い出せないょぅ… うむ、よろしい、来週にしよう。

現実逃避に積ん読の「学術の動向オープンサイエンス特集号」を読み始める。

JST 中村理事長の記事に、2014年度中に「科学技術情報委員会」から データシェアリングの在り方について提言を出す、とあるが、 JST のウェブサイトに行ってもそれらしきページが見当たらないのだが、 これはスケジュールが遅れているのか？ 12月2日の時点ではまだ検討中のようだが。 NDL 第5回科学技術情報整備審議会議事録 ググってもこれ以上の情報は出てこないなぁ。

NISTEP 林氏の記事に「自分社会系」という用語が出てきて、 何だこりゃ聞いたこと無いけど何か凄そうな用語だなぁ、 サブカル分野の新概念か？ と一瞬思ってググってしまったが、単に「人文社会系」の typo のようだ。 がっかりだ。と言うか、一瞬でも「何か凄そう」と思ってしまった自分の サブカル脳を批判しなければならない。

dwc_occurrence.xml の記述を JDC に取り込むコードを書いた。 そして実際に取り込んでみて、 データペーパーのデータファイルと項目数が一致しないことに気付いた。 dwc_occurrence.xml の方が項目が多い。具体的には以下の項目。

• materialSampleID
• infraspecificEpithet
• taxonRank
• verbatimTaxonRank

ファイル生成に使用したソフトウェアが古いバージョンだったのか。 まぁ4カラム程度だったら手作業で調整すればいいが、データファイルと定義が 一致するかどうかは毎回確認しないといけないな。

dwc_occurence.xml の内容を JDC用に整理・加工している間に、 Darwin Core が随分複雑になっていることに驚いた。 地質年代の項目があるのは化石標本を扱うためか。こんな項目があるなんて 今まで知らなかったが、確かに化石も扱えないといけないよな。 DwC はシンプルなメタデータ標準だ、という風に 思い込んでいたが、いつの間にか、あるいは実は前から？　私の想像以上に 複雑な内容になっていたようだ。 まぁその大半が optional ではあるが、アプリケーションを組む側は optinal を含めて全ての項目を扱えるようにしなければならない訳で、 IPT の開発者とかは大変そうだな、とも思うが、今のところ他人事なので どうでもいい。

ちょっと時間が掛かりそうだなこれ、と思ったのでしばらく放置していた データペーパーの処理を始める。

機械的に生成したデータファイルっぽい、というところまでは解る。 おそらく IPT が吐き出したんだろう。メタデータの先頭部分に http://rs.tdwg.org/dwc/terms/Occurrence とあるので、おそらく 観察データ用のフォーマットなのだろうと推測するが、なかなか定義を 見つけられなかった。生物多様性関係は情報量が多いから門外漢は難儀する。

データファイルを見ると、全部で 159カラムのうち、データが入っているのは 18カラムだけで、あとはひたすら空欄になっている。随分ムダなことをする。 optional な空カラムも律儀に出力するのは機械生成だからか、それとも GBIF の流儀なのか。多分、meta.xml や、データファイルのヘッダ行が 無くても困らないようにフォーマットを固定しているんだろうなぁ。

meta.xml を処理する方法は無いものかと色々ググってみたら PyPI に python-dwca-reader なるものを発見！　これはいいものを見つけたぞ、 と思ってちょっと使ってみたが、動作が遅い。まぁいきなり 10万行の データを読み込ませたらメモリスワップするよな。機能的にもほとんど パーサ程度の機能しか無さそうだったので、今回の作業には使えないと 結論づけた。

その後、 http://rs.gbif.org/core/dwc_occurrence.xml を探し当てる。 TDWG じゃくて GBIF の方にあったのね。これを元にして EML の <attribute> を生成するスクリプトを組めば良い。 流用できそうなのは definition だけだろうが、何も無いよりはましだ。 それ以外は EML の仕様上ほとんど一意に定まる筈だし。

内閣府・国際的動向を踏まえたオープンサイエンスに関する検討会では、 昨年末から、世界的なオープンサイエンスの潮流に対して日本はどう 対応するべきかに関して議論が進められていたが、3月30日付けで 報告書が公表された。 （内閣府）

軽く目を通したので要点を幾つか。

• 論文の根拠データは原則公開、それ以外のデータの公開は努力目標。
• 競争的及び公募型研究資金による研究が対象。サマリでは言及されていないが、 報告書全文では全額運営費交付金による研究も対象とすべきとされている。
• 大学・研究機関等は研究データの管理保存に関し、規則を定めて具体的施策を 実施すること。

他に気になった点は、

• 「研究データは原著論文と同等又はそれ以上の研究開発成果として位置づけられ」 (p.15)

  データ公表が論文以上の成果になる文化っていうのは俄には信じがたい。 それは「科学とは知の集積である」という科学観が変更されるという ことを意味するだろう。更に敷衍すれば、論文よりもデータが評価されるなら、 データよりもそのデータを生み出す観測機器の開発の方がより評価される べきで、科学者よりも測器会社の技術者の方がより評価されるべきである、 ということになる（これは個人的に以前から疑念に思っていたことである。 現代の自然科学において観測機器の発展が占める比重があまりにも大きすぎる）。

• 「データサイエンティスト等の育成と活用」(p.22)

  これは「育成と雇用」とするべきである。

  この手の分析では一般にデータ専門家の人材「育成」が課題として 挙げられることが多いが、私見では、人材育成は大した問題ではない。 問題はその後、専門職としての雇用があるかどうかで、日本でかつて 大学院重点化で院生を増やした後に何が起こったかはこの業界に居る 人間ならば誰でも知っていることであろう。

  この次の行に「人材の確保」という文面があるが、これも 「人材を雇用するための予算の確保」とする方が正しかろう。 「人材の確保」という表現では、予算はあるけど適当な人材が見つからない、 つまり人材の方が希少財のような感じを受けるが、実際は逆で、 求職者は掃いて捨てる程居るのに雇用する予算が無い、という状況の方が 支配的なはずである。

  人材育成は雇用とキャリアパスが伴わなければ効果が無い。 そして、雇用の維持とキャリアパスの確立の方が明らかに難しい問題なのである。

所内から Web of science に接続してあちこち探したものの、 Data Citation Index の影も形も見当たらない。

あれ、もしかして、DCI って別途契約しないとアクセスできないのでは？ と思って所の図書室に問い合わせてみたら、やはりそうで、 弊所では DCI を契約しておらず、当面はその予定もない、と返事が来た。

それ自体はまあ仕方が無い。無い袖は振れん。

問題なのは、では一体 DCI の利用者はどのくらい居るのか、というところで、 もし DCI の利用者が少ないんであれば、DCI に登録するメリットがあんまりない、 ということになる。 どの研究機関も学術出版に対する出費を少しでも減らそうとしている このご時世に、追加で DCI を契約する余裕のあるところがどれだけあるのか、 という疑念が湧かざるを得ない。DCI の料金が具体的にどれだけなのかは 知らないので判断できないが、少なくともどこでも気軽に買えるほど 安くはないのだろう。

DCI に登録すれば劇的にアクセスが増える、というような代物ではない、 ということは間違いなさそうだ。 そう考えるとやる気が萎むなぁ。

DataCite のメタデータには必須項目が全部で 5つあって、

• Identifier
• Creator
• Title
• Publisher
• PublicationYear

その必須項目を

Creator (PublicationYear): Title. Publisher. Identifier

という書式で並べることを DataCite は好ましいとしており、 この書式を DataCite citation standard と呼んでいる、という、 単にそれだけのことであるらしい。

参考— DataCite Metadata Schema Version 3.1

MASTER DATA REPOSITORY LIST で DCI に収録されているリポジトリが検索できるようだ。 試してみる。

あと KNB や台湾林業試験所も入っているっぽい。 今のところ生態学／生物多様性関係の収録数は少なそうだ。

日本から参加しているのは現状この 3つだけのようだ。 JBIFとかはどうなってるんだろう。何か対応を考えているのか、 それとも話が行ってないのか。

続き。

今日から本気出す、と毎日のように決意を新たにしております。

さて棚上げしてあった DCI 事案であるが、まずは情勢を精確に把握するために 資料を集めることに。 ウェブにTR社の資料があるのでまずそれを読む。

REPOSITORY EVALUATION, SELECTION, AND COVERAGE POLICIES に目を通していたら、幾つか興味深いことが書いてあった。 今後、DCI について他人に説明するよう命じられるかも知れないので、 メモを残しておく。

まず TR社としては、データであれば何でもいいという訳ではなく、 DCI に収録するべきリポジトリを選別しているようだ。 向こうからの最初のメールに “JaLTER has been selected as a potential resource…” って書いてあって、まるで詐欺メールの「当選おめでとうございます！！！！！！」 みたいな文面だな、と胡散臭く思ったが、TR社としては真面目に選別しているようだ。 その評価基準が幾つか挙げられている。英語苦手なので和訳する。

年度末だから、という訳でもないが、DNS を変更してサーバ切り替え。 事前の準備は抜かりないように色々考えるが、事後の作業はだいたい 忘れる。よくあるのは ssh の known_hosts の変更で、スクリプトが エラーを出すまで気付かないことが多々ある。まぁいつものことだ。

変更後のホスト構成。

• www.emaita.jp
• blog.emaita.jp
• dosc.emaita.jp
• jdc.emaita.jp
• jdcdoc.emaita.jp
• jdc-trial.emaita.jp
• metacat-trial.emaita.jp

枯れ木も山の賑わいって感じだな。

さくらインターネットにおける、 「会員メニューのドメイン設定」と「レンタルサーバのドメイン設定」の 関係についてのメモ。

これまで個人サーバとしてさくらのVPSを使用してきたが、 VPSだとシステムの入れ替えなどで長時間停止したり 引っ越ししたりしなければならず、ウェブページのような システム非依存のコンテンツは別にした方が楽かもなぁ、と思ったことが きっかけで、レンタルサーバを借りてみた。最安価の月額129円プラン。 ftps の設定がやや解り辛かったがググって解決。 えーと、一応張っておくか。ftp クライアントは lftp を使用。

set ftp:ssl-auth TLS
set ftp:ssl-force true
set ftp:ssl-allow yes
set ftp:ssl-protect-list yes
set ftp:ssl-protect-data yes
set ftp:ssl-protect-fxp yes
set ssl:verify-certificate no

さてそれはともかく、DNS の設定も変更しなければならない訳だが、 VPS の場合は「会員メニュー」のドメイン設定で、 レンタルサーバのマルチドメイン（バーチャルホスト）設定は レンタルサーバの「サーバコントロールパネル」のドメイン設定で 変更することになっており、両者の関係がよく解らなかった。

ちょっと試した結果、例えば blog.emaita.jp は、

• 両方に設定しても、さくらのユーザインターフェイス上でエラー等は出ない。
• 片方の操作は他方に影響しない。
• 両方に設定するとレンタルサーバの設定の方が優先される。
• 会員メニューの方は、 emaita.jp ゾーンの blog.emaita.jp エントリで、 レンタルサーバの方は、 blog.emaita.jp ゾーン の blog.emaita.jp エントリで、 別ゾーンということのようだ。
• レンタルサーバの方に全く同じ emaita.jp ゾーンを作成するテストはしていない。 その場合はエラーになるのかも知れない。

ちょっとすっきりしない気がするが、会員メニューのドメイン設定には エントリ数上限がある（契約台数あたり5エントリ）ので、 レンタルサーバ側で処理できると余裕ができる。 レンタルサーバのマルチドメイン（バーチャルホスト）に上限があるのか どうかは判らない。ヘルプに書いてないから無限にできるのか？

同じ仕事を何年もしていると、過去の出来事の時系列が不確かに なってくる。時々整理しておく方がいざという時に慌てなくて良い。

過去のノートを引っ張り出せば細かい日付も判るはずだが、 そこまでする程のことではあるまい。

昔の資料を整理しているのだが、Morpho のメッセージ日本語化について ちゃんと記録していなかったので、思い出しながらまとめておく。

そもそもの事情は、Morpho が多言語メッセージ化された時、 開発チームは当初 Google か何かの自動翻訳で日本語メッセージを作成したものの、 その翻訳が正しいのかどうなのか皆目判らないので、私の知り合いに 校閲を依頼してきたのだが、その知り合いは JAVA とか開発関係のことが まったく解らない人だっので、私が手伝うことになったのである。 ファイルのタイムスタンプを見ると 2010年夏になっているので、 たぶん Morpho 1.8.0 から 1.9.0 のあたりのことだろう。 手元に残っているメッセージファイルの行数は 633行で、 最新リビジョンだと 727行だから、数年間でだいぶ増えているな。 現在では個人的にも JaLTER としても Morpho から JDC に移行したので、 最新リビジョンのファイルを修正して開発チームに送るような 気力は湧かない。

以下、手順。

ソースコードをリポジトリから取り出す。

$ svn co https://code.ecoinformatics.org/code/morpho/trunk morpho_src

メッセージファイルは morpho_src/lib/language/ に配置されている。

$ ls morpho_src/lib/language/
Messages.properties         Messages_ja.properties
Messages_es.properties      Messages_pt.properties
Messages_fr.properties      Messages_zh_TW.properties

言うまでもなく、Messages_ja.properties が日本語用ファイルである。 ファイルのフォーマットは JAVA プロパティで、 エンコードはユニコードエスケープでなければならない。

世間ではユニコードエスケープを直接扱える「プロパティエディタ」なるものが あるらしいが、ここでは別にそんなものを使うまでもないので、 一旦 UTF-8 に変換して常用のエディタを使うこととする。 エンコード変換には native2ascii を使用する。 MacOS X の場合、もしかしたら X Code をインストールしないと使えないかも 知れない。

$ native2ascii -encoding UTF-8 -reverse morpho_src/lib/language/Messages_ja.properties > msg_ja.utf8

UTF-8 化したメッセージファイルを編集する。 編集が終わったらエンコードを元に戻す。

$ native2ascii -encoding UTF-8  msg_ja.utf8 > morpho_src/lib/language/Messages_ja.properties

Morpho のビルドには Apache Ant が必要だが、 Mac OS 10.9 からは Ant がベースシステムから除外されたらしい。そのため手動でインストールする。 野良でも brew でも Mac Port でもいいが、私は Mac Port を使っているので 以下のようにする。

$ sudo port install apache-ant

Morpho をビルドする。

$ cd morpho_src; ant macjarbundler

なお Windows 版をビルドするには

$ ant buildwinexe

とする。

ビルドされた Morpho を起動して修正したメッセージが適切かどうか確認し、 必要に応じて再修正を繰り返す。

サーバ引っ越しメモの続き。 JDC 試用版用にメールとキャプチャと Metacat が要る。

include_dirs = ["/usr/include/freetype2"],

include_dirs = ["/usr/local/include/freetype2"],

# python setup.py build
# python setup.py install

# pkg install postgresql94-server
# service postgresql initdb
# service postgresql start
# su pgsql
$ psql postgres
postgres=# create user metacat with unencripted password 'パスワード';
postgres=# create database metacat with owner metacat;
postgres=# grant all on database metacat to metacat;

# mkdir /var/metacat
# chown www:www /var/metacat

玉突き的にサーバ引っ越し中。空き家になったサーバに FreeBSD 10.1 を 改めてクリーンインストールして、ウェブアプリ系を移動させる。

JDC が動かないと始まらないのでまずそれから。

最大の難点は distribute/setuptools の開発状況の混乱で、 ネットの状況によると現在は setuptools に統合されているらしい。 そこで setuptools を使うことにしたのだが、生憎 ports/pkg に 収録されているバージョンが 5.5.1 とかなり古く、 これを使用すると buildout かなんかのバージョンチェックに通らなかった。 ports/pkg の setuptools は libxml2 などと依存関係にあるので setuptools だけ最新版を入れるというのも混乱の元になるから避けることとし、 一方 virtualenv では比較的新しいバージョン 12 がインストールされることから、

• bluebream 環境の構築は virtualenv 環境下で実施
• JDC は直にサーバ環境で実行

することに。

# pkg install py27-setuptools
# pkg install py27-virtualenv

# pkg install ca_root_nss-3.17.3_1
# ln -s /usr/local/share/certs/ca-root-nss.crt /etc/ssl/cert.pem

$ virtualenv venv
$ source venv/activate

(venv)$ easy_install bluebream
(venv)$ paster create -t bluebream test
(venv)$ cd test
(venv)$ python bootstrap.py --setuptools
(venv)$ ./bin/buildout
(venv)$ ./bin/paster serve debug.ini
(Ctl-C)

(venv)$ svn export file:///svn/.../trunk jdc
(venv)$ cd jdc

(venv)$ python bootstrap.py --setuptools
(venv)$ ./bin/buildout

(venv)$ deactivate

#!/usr/local/bin/python     <- 修正
..snip..
  '/.../venv/lib/python2.7/site-packages/Paste-1.7.5.1-py2.7.egg',  <- トル

# pkg install py27-Paste
# pkg install py27-PasteDeploy
# pkg install py27-PasteScript

# pkg install py27-libxml2
# pkg install py27-libxslt
# pkg install py27-imaging
# pkg install py27-dateutil
# pkg install py27-xlrd
# pkg install py27-openpyxl

# ./bin/paster serve debug.ini
(Ctl-C)

ProxyPass /jdc/ http://localhost:8081/++vh++http:svr2.emaita.jp:80/jdc/++/
ProxyPassReverse /jdc/ http://localhost:8081/

基本的にクリーンインストール派なのでアップグレードはあまり使わないのだが、 後学のため、空き家になった旧サーバで最新のアップグレード手順の確認をした。

まず一応、パッチレベルを最新にする(10.0-p17)。

# freebsd-update fetch
# freebsd-update install
# reboot

その後、 10.1 にアップグレードする。

# freebsd-update upgrade -r 10.1-RELEASE
# freebsd-update install
# reboot
# freebsd-update install
# pkg upgrade
# freebsd-update install
# reboot

自動的に最新パッチがインストールされるらしく、 10.1-p6 になった。 install の実行数が2回から3回に増えているのは、

• ユーザランドインストール
• 不要ファイル削除

のプロセスを分離するためのようだ。3回目では古い *.so が削除されるため、 その前に ports のリビルドとかをしろということらしい。

ZFS 関係が改良されているためzfsストレージのアップグレードも必要だが、 省略。

ZFS に bookmarks という機能が追加されたらしい。これはスナップショットの メタデータだけを保存するという機能のようで、スナップショット自体を消した 後でもメタデータだけは残すように使うらしい。 つまり、データブロックは残ってないのでロールバックはできないが、 どのデータブロックが更新されたかは検出できるので zfs send で同期させる時の目印には使える、ということのようだ。

新サーバ上で Sphinx の挙動がおかしいことに気付いて、 よくよく考えたら自作拡張を作った時に Sphinx 本体のコードに 手を加えたことを思い出した。

virtualenv で隔離環境を作ることにしよう。

# pkg install py27-virtualenv
# pip install sphinx

旧サーバと新サーバで Sphinx のバージョンが異なる (1.2.3 -> 1.3) ので 自作拡張用パッチが一部 rej された。マニュアルで修正。

libxml2 が pip でも easy_install でも入らないので、実環境のファイルを 隔離環境に無理矢理持ってくることにした。

# ln -s /usr/local/lib/python2.7/site-packages/libxml2mod.s
# ln -s /usr/local/lib/python2.7/site-packages/libxml2.py

これで以前と同じ挙動になった。

なお、easy_install で SSL 関係のエラーが出て中断する問題は、

# pkg install ca_root_nss-3.17.3_1
# ln -s /usr/local/share/certs/ca-root-nss.crt /etc/ssl/cert.pem

で回避できるようだ。 https://nixbsd.wordpress.com/2015/01/02/freebsd-ssl-certificate_verify_failed/

いろいろ資料を集めるのは楽しいんだけど、読むのがね。 主に気力的な面で。

湯本貴和・松田裕之編『世界遺産をシカが喰う　シカと森の生態学』文一総合出版。 約10年前の本だが、今現在でもシカの食害が全国的に大問題であることは、例えば CiNii で「シカ　食害」と検索してみれば理解できる。 シカが人の手に負えないほど増えた理由は現時点で科学的には未解明であり、 解明される気配もなさそうに見えるんだが、実のところはどうなんだろう。 個人的には「天敵（オオカミ）が絶滅したからだ」という説を信じており、 オオカミを（トキのように）中華大陸から持ってくればいいんじゃないの、 と思ってはいるものの、真剣に検討した結果の意見ではないので 他人に強く主張するつもりはない。

武村政春『巨大ウイルスと第4のドメイン　生命進化論のパラダイムシフト』 講談社ブルーバックス、 面白そうなので買ってみたが、面白いようなそうでないような。 近年、巨大ウイルスなるものが発見されて話題になっているということは まったく知らなかったので勉強になった。それはそれとして後半の生命進化に 関する部分はちょっと空想的すぎて説得力を感じないなぁ。 細胞核の出現はウイルスの影響とかではなくて 有糸分裂の確立との関連の方が重要なのではないか。 と、この前読んだ高木由臣『有性生殖論』に強い感銘を受けたせいで そう思うのであります。 ちなみに生命・非生命の分別については池田清彦の影響で構造主義的生物学的な 立場に説得力を感じております。

ずっと先延ばしにしていた OS バージョンアップを断行するのであります。 そうしないと Tinkerer の置き場が決まらない。

FreeBSD のリリーススケジュールは、

• 10.2 — 2015年11月
• 11.0 — 2015年7月

11.0 に手を出すつもりはないので 10.2 に着目すると、半年以上先の予定だから 今 10.1 にバージョンアップしてもそれほど悪いタイミングという訳ではない。 よろしい。

まずは気楽に作業できる開発機から。

クリーンインストール主義者なので、さくらVPS で新インスタンスを契約、 10.1 の ISO でブートさせて手なりのインストール。さくらVPS 側で カスタムOSを準備してくれると sftp put する手間が省けて楽なのだが、 未だに9系しか用意されていないというのは怠慢ではないのかね。 FreeBSD ユーザってそんなに少ないのか。まぁ少ないよね。

これまで pf を使っていたけど、これを期に ipfw に変えてみる。 初めて使うツールはやはり細かい所で躓くな。

• ループバックと ip6 mandatory の設定は rc.firewall が勝手に設定するので ユーザは書かなくていい。
• rc.firewall の自動設定にルール番号1000番まで消費されるので、ユーザは 1001番以降を使うと良い。
• DNS, NTP は UDP を使うことを思い出せ。何で忘れるんだろうかねぇこういうこと。
• udp 設定に keep-state オプションを付けると tcp established っぽい挙動になって便利。

Tinkerer は、

• easy_install だと not found
• pip だと lxml のコンパイルでコケるので、別途 pkg install py27-lxml すると通る

あとは概ねいつも通り。

昨日は学術会議でデータジャーナルに関する講演会。 10人くらいが現状報告・情報提供して、現状認識を一致させて 問題意識を共有しましょう、という会だった。 議論の時間はほとんどなく、戦略的・建設的な話はなかった。 もしかしたらオフレコでやってたのかも知れないが。 でもまあ面白かった。現状把握という意味では有用だった。 あとで講演資料を学術会議のウェブサイトに載せるそうなので、 しばらくしたら見てみよう。

学術会議のロビーに学術の動向のバックナンバーが置いてあったので 暇つぶしに見てみたら、2014年11月号でオープンサイエンスが特集されているのを 見つけた。しばらくしたら J-Stage で無料閲覧できるようになるはずだが、 ページ数が多いので冊子を買ってもいい。あとでアマゾンでポチるか。 紀伊国屋が取り扱ってないのは何でだ。

今日は Concrete5 を試してみた。ウェブ上に転がっていたチュートリアルを 真似して Nifty C4SA というクラウド上で動かしてみた。 クリック一発でインスタンスができちゃうなんて、クラウド環境は楽ちんだなぁ。 まぁその分高いが。

• ページ上の規定の位置（エリア）に各種コンポーネント（ブロック）を配置していって ページを作るというやり方。確かに初心者に優しい。
• ブロックの種類は実用に充分なだけ揃っているようにみえる。
• エリアの配置はテーマによって固定化されている。 エリアを調整するにはテーマファイルを改造しないといけない。 テーマは PHP で書かれているので、改造するには PHP をハックしないといけない。
• 最新バージョン 5.7 に対応しているフリーのテーマはほとんどない。 5.6 用はいっぱいあるようだが。

テーマの問題さえ解決できればツールとして悪くないように思える。 今すぐ何かをしないといけない訳ではないので、しばらく様子を見よう。

昨日から色々調べているが、何で調べ始めたんだったかな。 まぁいいや。

• Concrete5 という CMS が楽しそう。あとで試す。 使えそうだったら JaLTER ウェブサイトの改装時に導入することを検討する。

• Plone は ver. 5 が開発中、アルファ状態。 検索すると「2014年中にリリースか」という記事が出てくるが、 現時点でまだアルファ版ということは、 開発スケジュールが順調に遅れているということなのだろう。 たぶんあと半年は出ないな。

• Zope の開発状況はよく判らなかった。 Zope 2 をベースにして Zope 4 を開発中という記事があった一方、 Grok や Pyramid も並行しているし、どうなってんだか。 相変わらず情報を探し難い。 https://zope.readthedocs.org/en/latest/WHATSNEW.html

  Plone の開発陣は将来的なフレームワークの選択に悩んでいるようだ。 https://plone5.veit-schiele.de/news/plone-2020

  どちらにせよ、 Zope 4 が Zope 2 の後継なら Zope 3 ベースの JDC には 関係ない話だ。Zope3(BlueBream) に関しては特に新しい情報はなかった。

• Python ベースのブログ生成ツールとして tinkerer, pelican が 有力らしい。試しに Sphinx ベースの tinkerer を使ってみた。 というのがこのブログの動機。しばらく使ってみよう。