クリエイティブWeb - オープンデータ

市区町村コード表（履歴付）を作成する .NET Core アプリを公開しました

2017-02-20T12:17:00+09:00

国勢調査等の市区町村別の統計データを過去から集計して比較しようとすると、平成の大合併により過去のデータは合併前の市町村のデータを集計する必要があり、普通に手作業ですると非常に手間のかかる作業になります。

政府統計の総合窓口（e-stat）の統計LODで、1970年以降の標標準地域コードのデータが公開されているので、それを利用して、任意の時点での市区町村コード表の作成や対応表が作成できるデータベースを作成するコンソールアプリケーションを作成しました。

.NET Core で作成したので、Windows だけでなく、Mac や Linux でも動作するし、.NET Core はインストールも手軽で簡単に動作させられるようになったので GitHub で公開してみました。URL は、以下のとおりです。

NAreaCode

このアプリを作っていて気がついた点を2点メモしておきます。

コマンドラインの解析

コマンドラインの解析には、Microsoft.Extensions.CommandLineUtils を使いました。CommandLineUtils は、.NET Core になってやっと組み込まれた機能です。

以前の Microsoft はエンタープライズ向けのことには熱心なのですがシンプルに処理をするということにはあまり力が入っていなかったように思っていましたが、.NET Core、ASP.NET Core になって、シンプルに作りたい場合にも使いやすくなったと思います。コマンドラインの解析は、簡単そうですが実際に自分で作るとなると結構手間がかかるので、.NET Core になって改善された典型的な例だと思います。

コード表の処理速度

作成した市区町村コードのデータは、json形式にしています。例えば、期間付き市区町村コードは以下のような形式になっていて、4588件のレコードがあります。

public class StandardAreaCode
{
    [JsonProperty("id")]
    public int Id { get; set; }
    public string 名称 { get; set; }
    public string ふりがな { get; set; }
    public string 英語名 { get; set; }
    public 自治体種別 種別 { get; set;}
    //北海道、東京都島嶼部、長崎県対馬（旧）は支庁・振興局、その他の町村は郡、区は政令指定都市のコード
    public int 所属 { get; set; }
    //北海道及び旧長崎県対馬支庁の町村のみ
    public string 郡名称 { get; set; }
    public string 郡ふりがな { get; set; }
    public DateTime 施行年月日 { get; set; }
    public DateTime 廃止年月日 { get; set; }
    public List<int> 施行データ { get; set; }
    public List<int> 廃止データ { get; set; }
}

これらのデータを Web アプリケーションの中で使う時に、RDB にインポートするのは面倒なので、メモリーベースで処理をするということで、処理時間を計測してみました。都道府県毎に市区町村コードの一覧を計算する処理で、画面の例は「北海道の市区町村コード一覧」です。また、一覧を計算するコードのメインは以下のようになっていて、LINQ を使うのであれば、リストや配列の場合でも SQL Server を使うのとほぼ同じコードで書くことができます。

public IEnumerable<(int id, string 名称, string ふりがな)> GetAreaCode(int pref, DateTime date) =>
    AreaCodeList
    .Where(x => x.Id / 1000 == pref && x.施行年月日 <= date && x.廃止年月日 > date && x.所属 != 99)
    .Select(x => (id: x.Id, 名称: x.名称, ふりがな: x.ふりがな))
    .OrderBy(x => x.id);

Google Compute Engine の n1-standard-2 （AWS の m4.large とほぼ同性能）を使って処理時間を計測すると以下のようになりました。

ファイルサイズ 1126KB
データの読み込み時間 45ms
計算時間 0.4～0.008ms

結果としては、SQL Server Express を使うよりも遙かに早いです。計算時間の 0.4ミリ秒は初回の計算の時で計算ルーティンやデータが CPU のキャッシュメモリーに入っていない場合の処理時間です。計算の必要なコードとデータが CPU のキャッシュメモリにキャッシュされてしまえば 0.008ms という圧倒的な速さで処理がなされます。こういう処理ではデータのやりとりにばっかり時間を食っていて、本当の計算時間なんてごく僅かのものだなと感じます。

そういうことで、データー量がそれほど大きくないコード関係は RDB を使うのをやめてメモリーに乗せていこうと思っています。管理も、RDB で管理するよりも、テキストベースにして git で管理した方が遙かに管理しやすいし、入力もデータベース用の入力画面を使うよりも、テキストエディターや Excel で編集できた方が楽です。RDB をやめることの欠点ってといえば、コードを修正する毎にアプリをデプロイしなければいけないので、その手間が増えるのですが、昔と違って今はデプロイが楽になっているのでデータの更新の頻度ににもよりますがそれほどの負担にはならないと思います。

統計LODのバグから見える沖縄の歴史

2017-01-18T13:15:00+09:00

統計LODの「統計に用いる標準地域コード」を使っていて面白いバグを見つけたのでメモしておきます。

沖縄県では、北部が本土に近いので国頭（くにがみ）郡で、南部はシマの尻となるので島尻郡です。それにもかかわらず、沖縄県の最も北に位置し東シナ海上に浮かぶ伊平屋村及び伊是名村は国頭郡ではなくて島尻郡に属しています。

伊平屋島は、琉球王朝の第一尚氏縁の地であり、伊是名島は、第二尚氏縁の地です。そのため琉球王朝の時代には直轄地だったという歴史があり、その後の経過を経て島尻郡に属するようになったようです。

具体的な統計 LOD のバグの内容ですが検索用画面で以下の Query を実行してみてください。

PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
PREFIX org:<http://www.w3.org/ns/org#>
PREFIX dcterms:<http://purl.org/dc/terms/>
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX sac:<http://data.e-stat.go.jp/lod/sac/>
PREFIX sace:<http://data.e-stat.go.jp/lod/sace/>
PREFIX sacr:<http://data.e-stat.go.jp/lod/sacr/>

SELECT ?p ?o WHERE { 
  sace:C394 ?p ?o .  
}

Output を Text にすると次のように検索結果が返されます。

-------------------------------------------------------------------------------------------------
| p                         | o                                                                 |
=============================================================================
| rdf:type                  | sacs:CodeChangeEvent                                              |
| org:resultingOrganization | sac:C47361-20020401                                               |
| org:resultingOrganization | sac:C47352-20020401                                               |
| org:resultingOrganization | sac:C47351-20020401                                               |
| dcterms:description       | "Nakazato-son(47351) and Gushikawa-son(47352) are merged, and Kumejima-cho(47361) in Shimajiri-gun is newly established."@en |
| dcterms:description       | "仲里村(47351)、具志川村(47352)が合併し、久米島町(47361)を新設"@ja|
| org:originalOrganization  | sac:C47352-20001222                                               |
| org:originalOrganization  | sac:C47361-19720607                                               |
| org:originalOrganization  | sac:C47351-20001222                                               |
| dcterms:identifier        | "394"                                                             |
| sacs:reasonForChange      | sacr:establishmentOfNewMunicipalityByMmerging                |
| dcterms:date              | "2002-04-01"^^<http://www.w3.org/2001/XMLSchema#date>       |
-------------------------------------------------------------------------------------------------

org:originalOrganization（変更前の期間つき標準地域コードのリソース）に、sac:C47361-19720607 があります。確かに 47361 は現在の久米島町の市町村コードではありますが、1972年には久米島町はなかったはずです。実は C47361-19720607 は、宮古郡城辺町（現宮古市）の昔の市町村コードです。47361 という市町村コードは使い回しされていたのです。

市町村コードは廃止されたコードは欠番とされ、新たなコードとして別の自治体に交付しないという原則に例外があったのです。恐らくそのことを知らないエンジニアが間違ったプログラムを書いたのですが、影響はあまりないのでそのままになっていると思います。

なぜこういうことが発生したのか、まず、1965年（昭和40年）の沖縄県の国勢調査の結果をみてみると、以下の図のように琉球政府の時代には郡は使わずに北部地区という名称を使っていたようです。

1970年（昭和45年）の沖縄県の国勢調査の結果をみると、復帰前ですが本土と同じように市町村コードが振られて郡が復活しています。その際に北部地区をそのまま国頭郡にしてしまったようです。

本土復帰後になって、伊平屋村及び伊是名村が島尻郡に属していることがわかり修正しようとしたのですが、運悪く島尻郡に属する町村が多すぎて伊是名村が47360というコードになり宮古郡のコードと衝突してしまったのです。それで宮古郡のコードを47370に変更し、宮古郡に属する町村のコードも変更せざるを得なくなったようです。そして、合併で久米島町ができたときに 47361 になり城辺町の昔のコードを使い回してしまったということのようです。

統計LODから取得した標準地域コードを利用して、統計メモ帳のページを追加中なので、完成したらそのページの方も紹介したいと思います。

5374 徳島市版を作ってわかった地域アプリの厳しさ

2015-09-01T23:12:47+09:00

今日から9月です。約3ヶ月このWebサイトを更新するのに時間がかかっていたのでブログの更新ができていませんでした。最初に 5374 徳島市版のアクセス状況を書いてみます。

8月分のページビュー数は、73PVでした。うち5374 の本来の使い方である Direct が約半数の36PVで1日で1PVという感じで、アクセスは本当に少ない状況です。

自分でも5374徳島市版は使っていません。「ごみの日」を知る必要があるのは後片付けの時なので、手がぬれている場合が多いのでスマートフォンは使う気がしません。台所にごみカレンダーを貼っておいた方が便利だと思います。

金沢の成功事例である5374の本家版の利用者は、月間で4000人だそうです（出典：TheWave の「強い想いが仲間と流れをよびよせた／Code for Kanazawa（前編）【鈴木まなみ】」）。

ecitizen.jp 全体だと8月のユーザー数は31000人なので、5374の本家版よりも8倍も多くなっています。

それで、ecitizen.jp の方が 5374の本家版より優れているというつもりはありません、5374の本家版は金沢市が対象なので46万人が対象になりますが、ecitizen.jp だと全国の市町村の人口のグラフを作っているので日本全国が対象になるので、対象人口が大きく違います。

Code for Kanazawa のように地域で活動するのも一つの方法ですが、それでうまくいかない場合に、あきらめずにもう少しグローバルに考えるという方法もあると言いたかったのです。

自作のAPIをオープンデータで公開しました

2015-05-27T14:49:00+09:00

Xingle 氏が、ブログ「オープンデータ先進県「福井」の残念なデータに思う」で、次のようなことを書いていました。

2 年前このデータを見たとき、ついカッとなって上記のデータを良い感じの形式に変換する API を作ったりしました。が、公開を目前にして「どう考えても元々のデータを直すべきで、万が一にも自分の API を使ってアプリを作るような人が出ても困る」と我に返り、踏み留まりました。

「万が一にも自分の API を使ってアプリを作るような人が出ても困る」ということですが、なぜ困るのか疑問に感じていました。そもそもアプリを作る人がいないのであれば、県や市町村としてオープンデータとして公開するのは無駄な作業になるし、まして手間をかけて「元々のデータを直す」ことは税金の無駄遣いだと思います。

最近公開された徳島県のオープンデータポータルサイト(Our Open Data)では、個人でもデータカタログに登録できるようになっています。そこで、APIを作ってデータカタログに登録して公開することにしてみました。公開しているAPIは、徳島県県土防災情報システムの道路気象、雨量、水位のデータを加工したもので、以下の２種類の API です。

徳島の気温、雨量、水位 GeoJSON

徳島の気温、風速、風向、雨量の10分データ

下の図がそのAPIを使って作成したサンプルです。

このAPIの作成に要した日数は6日間です。時系列データを作ったり時間雨量の計算をしたりする方に時間がかかっているので、APIの作成だけであれば3日でできると思います。今後、このAPIを使ったアプリを作ろうと思っているのですが、アプリの作成には10日以上かかると思います。それで今すぐに作るのは、かなり負担になるので将来 d3.js でグラフを描く機会に作成しようと思っています。

今回のAPIの作成の開発費がどうなるかというと、人件費を考慮すると日当5万円で30万円です。でも、自分でやっているので、自分の人件費を除いて計算すると電気代とパソコンの消耗費ぐらいでほぼゼロに近いと思います。

今後の運営経費に関して計算してみると、今回の公開には Amazon の S3 を使っています。単価は、1000回のGETのリクエスト使用料が$0.0037、ネットワークの下り側の使用料金が1GBで$0.14となっています。APIのファイルサイズで一番大きいのは雨量データで32KBです。1000PV当たりで計算すると、リクエスト使用料が$0.0037、ネットワークの使用量が32MBなので料金が$0.0045になります、合計で$0.0082で1ドルを120円とすれば約1円です。S3ではなく普通のサーバーを使っても同じようなものだと思います。公開以外に、データの処理コストが必要になります。今回のAPIの処理は10分毎の処理で処理時間は2.5秒なので、サーバーに少し負荷がかかるので無料ということはないですが月何百円の単位だと思います。こうして計算してみると運営経費は本当に僅かな額です。

次に収益の方ですが、現状では収益は見込めないです。もし、Webアプリを作った場合どうなるかというと、広告収入は可能だと思います。イケダハヤト氏がブログで収入を公開していますが、今年の４月分だと129万PVで、バナー、記事広告アフィリエイトで59万円なので、1000PV当たり457円ということになります。自分のWebサイトの場合は Google アドセンスしか貼っていないのでそれよりは低いですがそれでも半分以上の単価になっています。地域限定で日常的に使うアプリの場合、スポンサーは結構取りやすいと思うので457円の単価は難しくないと思います。

しかし、地域対象のアプリで問題なのはアクセス数を稼ぐのが非常に難しいということです。徳島県の場合人口が76万人しかいないので100万PVというのは夢のまた夢です。それに、アプリを作るのに10日とか書ましたが一人で作ってかつ業務の内容も分かっているからできる話であって、普通に開発会社が開発するのであればフロントエンドのエンジニア、サーバー側エンジニア、Webデザイナー等３～4人でチームを組んで、ヒアリング等も必要になってくると思います。そうなれば数百万円のコストが必要になってくるので、自治体から委託料をもらわずに自社開発するのは無理だと思います。

それだったらなぜ「オープンデータ」という話になるかというと、stackoverflowの調査だと、開発者の70%が週に2時間以上趣味やオープンソースの開発でプログラミングをしており、週10時間以上している人も20%います。そういう開発者の力を活用しようというのがオープンデータです。確かに、今回のAPIの作成はテストにも使っているので、自分としてもさほど負担には感じていないです。また、オープンデータはアプリのプロトタイプをテストするのには便利だと思っています。

海外ではソフトウェア開発者は比較的給料もよくて恵まれている職種なのでOSSの開発をする余裕がある人が多いと思います。日本では、そういう開発者の層は薄いので、オープンデータの活用が本当に進むかどうか不透明な部分がありますが、日本でもOSSの開発経験がエンジニアの採用時に実績として重視されたり、GitHub がポートフォリオになるような時代になっていくと思うので、将来的には海外と同じようになると思います。

また、日本ではXingle氏のように行政がきちんとしたデータを提供すべきだと考える人が多いと思います。確かに、XMLやRDF等で提供されていれば形式を勝手に変更されることがないだろうという安心感があります。一方Excelで作ったデータであれば、自治体の職員がすぐに様式を変更できるので、その対応を考えておかないといけないのが結構煩わしいと思います。

でも逆にいえば、XMLやRDFの場合、修正の必要が生じたときに自治体としてすぐに対応できるのかということがあります。また、経費や手間をかけてXMLやRDFで提供している場合、利用者が少ない場合でも提供を継続してくれるのかという不安もあります。現実に日本のオープンデータで最も規模の大きいものの一つである「政府統計のAPI機能」で、総務省以外の省庁の統計データは更新がほとんどされていません。恐らく各省庁は別のシステムで統計を作っていて、政府統計のシステムにデータを手入力するのはあまりにも手間がかかるし、一方でシステム化をするにはコストが必要ですがそのコストの説明ができないため、従来通りExcel形式での公開ということになっているのではないかと思います。

そういうことを考えれば、自治体ではできるだけ手間をかけずに内部で使っているデータをそのまま公開した方がいいと思います。そして、エンジニアの方が便利なAPIを作ったら、「万が一にも」とか言わずにどんどん公開したらいいと思います。公開するための経費はほとんど必要ないし、オープンデータを使ってアプリを作るということは自己責任で作るということなので、APIの提供者は運用についてあまり気にする必要はないと思います。それに、個人が開発したAPIを使うことに対するアプリ開発者側の不安は、APIの作成ルーチンをOSSで公開することではかなり緩和されると思います。そういうことで今回のAPIを作成するプログラムは、GitHubで公開しています。長くなったのでAPIの作成の話は次回にします。

5374 徳島市版を作成してみました

2015-05-17T10:51:00+09:00

Windows 10 Insider Preview と Visual Studio 2015 RC のテストを兼ねて、Code for Kanazawa が作った「いつ、どのゴミが収集されているのか」をわかるWebアプリ 5374.jp の徳島市版を作ってみました。

Windows 10 も VS 2015 も自分の使った限りでは、エラーが発生することなく使えています。今年の夏に発売予定ですが、準備の方は順調に進んでいるようです。VS 2015 で、ASP.NET 5 については、あまり使っていませんが、ASP.NET 4.6 では製品版といってもいい状況で、実際の運用環境で使ってもいいという "Go-Live" ライセンスになっているというのもうなづけます。

5374.jp については、徳島市の場合は隔週及び4週毎のごみの収集があるのに、それに対応していないため、カスタマイズをしてみました。詳しくは、GitHub の方に記載しています。

徳島市版を作成した理由の一つには、JavaScript をどこまで使うのがいいのかということに対するテストという意味合いもあります。結局は、JavaScriptにどれぐらい慣れているのかということが一番大きな要素になると思いますが、自分の場合はロジックについてはC#で書いた方が楽です。JavaScript は一般的には手軽なのですが、Date を使うのは結構ややこしいです。自分の場合は、メンテナンスまで考えると今までどおり JavaScript は、UI 部分だけで使った方がいいと思いました。

5374.jp の場合、収集日を通知してくれる機能が欲しいと思うので、Cordova で作るのがいいのか、Xamarin で作るのがいいのか試してみたいと思っています。1月にアプリを作りかけたときは、表示の項目数が多かったので、Xamarin.Forms ではレイアウトの処理に時間が掛かりすぎました。5374.jp の場合は、それと比較するとかなり簡素なので Xamarin.Forms でも余り問題がないと思うので、比較するのには丁度いいと思っています。

オープンデータ先進国イギリスの主要都市のオープンデータの状況を調べてみた

2015-02-16T23:53:00+09:00

最近、地方自治体でもオープンデータの利活用に力を入れるところが増加してきたようです。じんぐる氏がブログに「オープンデータ先進県「福井」の残念なデータに思う」という記事を書いていたので、オープンデータの公開をどうしたらいいのかを少し調べてみました。

まず、オープンデータの先進国であるイギリスの主要都市のオープンデータの状況をしらべてみました。都市については、ロンドンとそれに続く「Second city of the United Kingdom」の8都市をまず選択しました。残り３都市は人口の多いところを選びました。

調べてみると、カーディフ以外の11都市は、オープンデータのホームページを持っていました。公開しているデータとして「500ポンド以上の支出」が目につきましたが、「Local Government Transparency Code 2014」で、地方自治体が公開すべきデータになっているのが影響しているのかもしれません。

都市名	リンク	専用サイト	主な公開形式
ロンドン（London）	リンク	CMS	xls, csv, pdf, html
ベルファスト（Belfast）	リンク		xml, rss
バーミンガム（Birmingham）	リンク		csv, xlsx
カーディフ（Cardiff）	-
エディンバラ（Edinburgh）	リンク	GitHub	csv
グラスゴー（Glasgow）	リンク	CKAN	csv, xlsx, geojson
リーズ（Leeds）	リンク		xls, csv
リバプール（Liverpool）	リンク		xlsx
マンチェスター（Manchester）	リンク	CMS	csv
ブリストル（Bristol)	リンク		csv, pdf, html
シェフィールド（Sheffield）	リンク		準備中
ブラッドフォード（Bradford）	リンク		準備中

xml を中心にして公開しているのは、ベルファストだけです。ベルファストはデータセットが6つ公開し、その内の4つがXmlです。xml はメタデータを作るのが大変なので、地方自治体では多くのデータセットを公開するのは難しいようです。また、csv で公開するのがいいのか、xls, xlsx で公開するのがいいのかというのは、イギリスでも微妙な問題のようで、都市によって分かれています。

公開方法については、都市のWebページの中で公開しているところが多いですが、専用のサイトを作っている所もあるという状況です。また、data.gov.uk で地方自治体もオープンデータを公開できるようになっていて、ブリストルはそれを利用しています。こう見てくると、イギリスにおいてもオープンデータについては課題が多いように思います。

じんぐる氏が残念だといっている坂井市のケースでは、珍しくxlmでデータを公開していると思ったら、既に「坂井市WebMap」というものがあってそのデータを使っているためのようです。坂井市WebMapは、坂井市のさまざまな位置情報を電子地図にて提供するWEBシステムだそうで、そのデータは KMLです。例えば、津波避難場所情報については、以下のようになっています。

http://www.city.fukui-sakai.lg.jp/map/data/hazard/hinan_tsunami.kml

自分の疑問は、なぜKMLで公開しないの？どうしてわざわざXMLにするの？ということです。KMLの方だと KML のスキーマがあるのでデータの構造は理解しやすいです。また、KMLということであれば、<description>タグの中を構造的なタグにしない理由もわかります。それに、順次公開予定となっているデータもすぐに公開できます。

地方自治体がオープンデータを公開する場合は、最初はできるだけ既存のデータを使った方がいいと思います。市町村にはITエンジニアは殆どいないのでエンジニアフレンドリーなデータを最初から公開できるということは期待しない方がいいでしょう。また、改善を要求する時には、コストのことは考えた方がいいでしょう。xml をきれいな形で公開しようと思えば、「利用者側にこんな不毛な苦労が必要なのか」という下のようなコードを、市町村側で作成しメンテナンスしていく必要がある場合が多いと思います。それでは、市町村側もこんな苦労するんだったらデータなんか公開しない方がいいと思うのではないかと思います。坂井市のこのデータであれば、空間データなので今は既存の KMLで公開しておいて、将来的には協力して坂井市WebMap と共通で GeoJSON に持って行くのがいいように思います。

var data = attribute.Value
         .Split(',')
         .Select(x => x.Split('='))
         .Select(x => new
         {
             Key = x[0],
             Value = x[1]
         })
         .ToArray();

オープンデータは、オープンソースと同じで協力して育てていくことが重要だと思います。それに、坂井市のレベルは、決して絶句するレベルではないと思います。

C#で経済指標巡回プログラムを作成しました

2014-12-30T19:35:00+09:00

「Rubyで経済指標自動巡回プログラム作成しました。 - 人生、徒然なるままに。」というブログをみて、このブログの筆者は、.Net や Java を使えるのに、なぜ、新たに勉強してまで Ruby を使ったのかということに興味があったので、同じようなものを C# で作り、GitHubで公開(https://github.com/awoni/GetMarketCalendar)してみました。

今回のプログラムでは、データの取得には HTTPClient を使って直接 Url をたたいて該当ページのHTMLを取得しています。一方で、Ruby の方では、「フレームワークとしてCapybara、レンダリングドライバー・javascriptドライバーとして poltergeist, PhantomJS」を選択しているそうで、プログラムでボタンをクリックして取得したデータをもとに解析しています。今回のデータの場合は、HTML のみで必要なデータが取得できましたが、JavaScriptを使ったインターラクティブな Webページが増加しているので、Javascriptが動作する環境でブラウジングしてデータを取得する必要がある場合も多くなってくると思います。

Html のパースには、Html Agility Pack を使っています。LINQ を使って記述していますが、意外と簡単にパースすることができます。

データの保存については、データベースではなくて、そのままで API として使いやすい Json で保存するようにしてみました。 Newtonsoft の Json.NET でシリアライズしています。設定ファイルについても、Json にしてみました。

その他に NuGetのパッケージとしては、NLog を使っています。Html のパースルーティンでは、どの程度までエラー処理をすべきかが問題になりますが、画面の変更に対応しようと思うとプログラムがどんどん複雑になってくるので、自分としては、プログラムは余り複雑にせずに、画面の変更によるエラーに早く気づくようにした方がいいのではないかと思っています。NLog をログのメール送信にも対応しているので、こういう点に関しては便利だと思います。ただ、今回公開しているプログラムでは、時間の関係でとりあえずの状況なのですが、実際にアプリケーションを作る場合は、ログをどうとるかは結構重要だと思っています。

C#で実際に同じようなプログラムを書いてみて、実務的にいえば C# は十分優秀だと思います。LINQ や今回は使っていませんが await async による非同期処理は便利です。ではどこが Ruby より劣るのかということを考えてみると、ブログの筆者のいう「rubyは面白いらしい」ということに尽きるのではないかと思います。それに、日本では情報量の差も大きいと思っています。

C#がどうすれば面白くなるかはよくわかりませんが、ブログの作者が巡回プログラムを作る動機になった「Rubyによるクローラー開発技法巡回・解析機能の実装と21の運用例」という本は、amazon.co.jp の「ソフトウェア・開発言語」で7位にランクされています。クローラーは意外と興味がある人が多いようなので、自分もクローラーであれば結構ネタはあるので、時々ブログに書いてみようと思っています。

統計API が本格運用を開始し、提供データが増加しています

2014-11-04T13:18:00+09:00

総務省統計局及び独立行政法人統計センターが次世代統計利用システムで試行運用を行なっていた統計のAPI機能が、2014年10月30日から、政府統計の総合窓口(e-Stat)の API 機能として本格運用になりAPIＩ機能で利用可能な統計データが統計局が所管する国勢調査などの23統計から、34統計が追加されたという報道がありました。

そこで、統計データ API エクスプローラの API の URL を新しいものに変更してやると、問題なく追加された統計データが表示されました。追加された統計では、労働関係の「民間給与実態統計調査」、「毎月勤労統計調査」、「賃金構造基本統計調査」、医療関係の「医療施設調査」、「患者調査」、教育関係の「学校基本調査」、「学校教員統計調査」、「地方教育費統計調査」等があり、「統計データ API エクスプローラ」で表の内容を見てみると結構面白いことができそうに思います。

「統計データ API エクスプローラ」に関しては、自分が統計のAPIを使って開発するときに便利なツールという方向で開発していこうと思っています。

統計メモ帳のサイトが月3万PVを超えました

2014-11-02T14:36:00+09:00

「統計メモ帳」のサイトが、今月はページビューが前月より81%増加して、やっと月間で3万PVを超えることができました。

アクセスが増加した要因は、掲載順位が10以内に入るキーワードが増加して、検索での表示回数が84%増加したことです。

このサイトは、政府統計APIを中心に使っている「オープンデータ」のサイトなのですが、「オープンデータ」で食べていけるかというのが課題です。ちょっとした収入にするためにはアクセス数を現在の10倍ぐらいに増やす必要があります。また、このサイトだけで食べていこうと思えば最低でも月100万PVぐらいは必要になります。かなり厳しい道だと思います。

ただし、パソコンがあれば始められて必要経費はほぼゼロなので、チャレンジする価値はあると思います。今まで個人が「e-Stat」のようなページを作ることは不可能でしたが、データが公開されているので、これからは、個人で作ることも不可能ではありません。

これまでの経験からいえば、「0から3万PV」にするのと、「3万PVから30万PV」にするのと、どちらが難しいかといえば、「0から3万PV」にすることです。Google の検索に認識してもらうのにはかなりの期間が必要です。今回もどういうわけかこの時期になって掲載順位が上がりました。Webサイトの場合は粘り強く改善していくことが重要だと思っています。

Mashup Awards に応募してみました

2014-10-25T15:24:00+09:00

統計メモ帳の「人口を可視化してみました」を Mashup Awards に応募してみました。昨日、Mashup Awards にオープンデータ部門があることを知って応募の作品リストをみると、オープンデータ部門の応募者が少なく、特に次世代統計利用システムのAPIを使っている作品は1点しかありませんでした。オープンデータについては、話題になることが多く、最近は各地でハッカソン等の催しが行われているので、かなり応募があるのかと思っていました。

自分は、次世代統計利用システムのAPIをよく使っているので、1点だけの応募では寂しいと思って応募することにしました。このページ自体は既に作っていたものなので、応募は簡単にできました。

「統計メモ帳」のサイトのアクセス数は、最近やっと月3万PVを超えたところで、その大半が「人口の可視化」の部分です。

このサイトをビジネス的にみたらかなり厳しいと思っています。オープンデータのデータを処理して、それをアプリに仕上げるのは、かなりの技術力と手間が必要です。「人口の可視化」の部分の制作で半月ぐらい時間をかけているし、これだけではビジネスにはならないので、どうやって収益化していくかを考えていく必要があります。これらの人件費のことを考えると採算をとるのは本当に厳しいです。応募者が少ないというのはアイデアだけでは無理で手間もかかるという所に原因があるのではと思っています。

でも、趣味的にやるというのであれば、経費は全くいらないです。特に、IT関係の人であれば、自分の技術力をステップアップさせるのにいいテーマだと思います。

Excel の xls ファイルは機械判読不可能？

2014-05-08T00:05:00+09:00

前回のブログでも書いたように、最近、都道府県別・市町村別等の1980～2040年の5歳年齢階級別人口の推移のページを作成しました。その時に利用した日本のデータは、過去の分は国勢調査のデータを、将来の分は国立社会保障・人口問題研究所の将来推計を使用しています。

過去の国勢調査のデータを使用する場合に、特に市町村で問題になるのが市町村合併をどう処理するかです。人口の推移ではやはり市町村合併を考慮すべきだと思うので、過去の分では旧市町村の分を集計する必要があります。これに関しては、次世代統計利用システムの方で都道府県・市区町村コード情報がLOD（Linked Open Data）で提供されているので、それを利用することで市町村合併を機械で取得できるのでそれほど手間をかけずに処理をすることができました。また、国勢調査のデータは、今回は SDMX の API を使って取得しました。今後、Eurostat 等でも同じような処理でデータを取得できるというメリットがあると思っています。

一方、将来推計人口の方は、Excel ファイルでデータを公開しています。自分の場合は、Excel のファイルを C# で Excel Data Reader という OSS のライブラリーを使って処理しているので特に問題なく処理できました。むしろ、心配したのはデータの著作権の方でした。数字だけなので著作権の問題はないだろうと思って使いましたが、やはり気になるところです。

最近は、日本でもオープンデータの取り組みが始まり、統計データも API で公開されるようになって便利になりました。ただ、オープンデータの取り組みの中でどうも Excel の xls ファイルは機械判読ができない取り扱いになっているようなので気になって少し調べてみました。

首相官邸の「電子行政オープンデータ実務者会議」のページの「電子行政オープンデータに関連する決定」をみると「機械判読に適したデータ形式での公開の拡大」が結構大きな目標になっています。それで、「機械判読に適したデータ形式」とはどういう形式なのかを調べてみました。結論はよく分かりませんでしたが、第１回データWGの配布資料７の「データ形式・構造、データカタログに関する技術について」（小池データＷＧ主査代理提出資料）という資料があり、機械判読可能なデータ形式の資料がありました。そこには「オープンデータの５つの段階」という話があって、Excel の xls ファイルは、「公開文書（編集可）」という位置づけで、「機械判読可能な公開データ」という位置づけにはなっていないようです。

自分の C# の Excel Data Reader を使った Excel ファイルの判読ルーティンのサンプルは以下のようなものです。

using System;
using System.Collections.Generic;
using System.Data;
using System.IO;
using System.Net.Http;
using Excel;

    public void GetExcel(string url, string cachePath)
    {
        //毎回Excelのファイルをダウンロードするのは無駄なのでキャッシュしている
        if (!File.Exists(cachePath))
        {
            //Webサイト（アドレス url）からのファイルの読み込み
            using (var client = new HttpClient())
            {
                var sr = client.GetStreamAsync(url).Result;                    
                var sw = File.Create(cachePath);
                sr.CopyTo(sw);
                sw.Close();
            }
        }
        FileStream stream = File.OpenRead(cachePath);
        IExcelDataReader excelReader = ExcelReaderFactory.CreateBinaryReader(stream);
        //Excel Data Readerを使って、Excel のデータを DataSet クラスに読み込む。
        DataSet result = excelReader.AsDataSet();
        stream.Close();

        int sheet = 2; 
        int column = 3;
        int row = 8;
        string s = result.Tables[sheet].Rows[row][column].ToString();
    }

また、SMDX を使った国勢調査のデータの判読ルーティンのサンプルは以下のようなものです。

using System;
using System.Collections.Generic;
using System.Xml.Linq;

    public void GetSmdx(string url)
    {
        //使用している名前空間を定義
        XNamespace generic = "http://www.sdmx.org/resources/sdmxml/schemas/v2_1/data/generic";

        //APIからXElementに読み込み
        var xe = XElement.Load(url);

        //LinqToXmlで各データの値を取得
        var obsList = from q in xe.Descendants(generic + "Obs")
            select q;
        foreach (var obs in obsList)
        {
            string cat01 = "";
            string cat02 = "";
            string cat03 = "";
            string area = "";
            string time = "";
            foreach (var obsKey in obs.Descendants(generic + "ObsKey").Descendants())
            {
                switch (obsKey.Attribute("id").Value)
                {
                    case "cat01":
                        cat01 = obsKey.Attribute("value").Value;
                        break;
                    case "cat02":
                        cat02 = obsKey.Attribute("value").Value;
                        break;
                    case "cat03":
                        cat03 = obsKey.Attribute("value").Value;
                        break;
                    case "area":
                        area = obsKey.Attribute("value").Value;
                        break;
                    case "time":
                        time = obsKey.Attribute("value").Value;
                        break;
                }
            }
            string value = obs.Descendants(generic + "ObsValue").First().Attribute("value").Value;

            //以下で取得したデータを処理する
            処理(cat01, cat02, cat03, area, time, value);
        }
    }

ほぼ SDMX と同じような処理で、公開された Excel データを自動処理することが可能です。違いといえば、SDMX の場合は定義された名前空間を使ってデータにアクセスできますが、xls ファイルの場合は、自分でシート番号とセルの位置を計算して指定してやる必要があるということです。確かに SDMX が名前空間が定義されているのでいつでもデータが取得できる確実性が高いのに対して、xls ファイルの場合は誰でもがすぐに表の形式を変更できるため次回も同じ方法でデータを取得できるという保証がないのが大きな欠点です。

しかし、データを作成する側から言えば、名前空間を定義してやらないといけないので、XML ファイルでデータを提供するのは結構大変だと思います。一方、xls ファイルでの公開は簡単だし、多くの人が簡単に利用できます。

Excel のファイルを扱うことができるフリーソフトとしては、Java では Apache POI、Ruby では Spreadsheet、PHP では PHPExcel、Python では Python Excel、JavaScript でも Sheet JS というソフトがあります。現在では、メジャーな言語であればExcel を扱うことのできる OSS のソフトが存在して、Excel を持っていなくても Excel のファイルを扱うことが可能になっています。

確かに数年前はExcel のファイルを Excel を使わずに扱うことは難しいことでした。でも、上の図は Seet JS のホームページですが、Excel がなくてもそのデータを使えるようにしようというエンジニアの努力によって、今では xls ファイルも商用のソフトを使用しなくても機械判読可能です。

資料を作った小池博氏は、「株式会社日立コンサルティングテクニカルディレクター」でデータ・ワーキンググループのワーキンググループ主査代理です。なぜ、xls ファイルを機械判読可能としなかったのでしょうか。確かに XML ファイルで提供される方がAPIとして利用する人にはベターなのですが、普通のユーザーには使い方が難くなるし、提供側でも作成に関してもそれなりに追加コストが必要です。そういう点を考えれば xls ファイルの機械判読がどの程度困難なのかで、XML 化する範囲やスピードについて結論は変わってくると思うのです。こういう資料を見ていると、LoD とか RDF というのは理想ですが、まだまだ一般の人が使えるような物ではありません。だから、Sheet JS のメンバーのような現実的な解決案を提供するという視点も重要です。そういう視点が欠けていることが日本のソフトウェアの高コスト体質を生んでいるように思います。

三好市の人口の推移のグラフを作ってみた - 極点社会～新たな人口減少クライシス～

2014-05-06T13:36:00+09:00

5月1日のNHKのクローズアップ現代「極点社会～新たな人口減少クライシス～」で、高齢者が減少し“消滅”の危機にある代表として徳島県の三好市が取り上げられていた。そこで、三好市の1980年から2040年までの年齢階級別の人口の推移のグラフを作成してみた。

データについては、2010年までは国勢調査で、それ以降は国立社会保障・人口問題研究所の『日本の地域別将来推計人口（平成25年3月推計）』を使用しています。

このグラフを見ると三好市では、1980年には、池田町、三野町、山城町、井川町、東祖谷山村、西祖谷山村の6町村で47,057人の人口だっだのが、2010年には29,951人にまで減少し、2040年には13,745人にまで減少することが推計されています。非常に厳しい状況にあることが理解できると思います。もう少し詳しく数字をみると、もう一段と厳しい状態があることがわかります。以下が、0～34歳までの5歳階級別の人口の表です。

1980年に0～4歳だった人は2,643人ですが、30年後の2010年に30～34歳の人は1,184人です。正確ではないですが簡単にいえば、三好市で1976～1980年に生まれた人では、45%の人が地元に残り、それ以外の他の市町村に転出してしまっているということになります。1986～1990年に生まれた人だと地元に残る若者はわずかに36%です。1991～1995年に生まれた人は46%が地元に残ると推計されそれ以降も割合が増えていますが、それは純移動率の計算方法に原因があります。国立社会保障・人口問題研究所の地域別将来推計人口の「純移動率」の推計については以下のようになっています。

市区町村別・男女年齢別の純移動率は、一時的な要因によって大きく変化することがあるため、一定の規則性をみいだすことが難しい。そこで最終的に「日本の将来推計人口（平成 24 年 1 月推計）」（出生中位・死亡中位仮定）による推計値と一致させることを考慮し、全域的な傾向を一律に反映させることとした。「住民基本台帳人口移動報告」（総務省統計局）から平成 12（2000）年以降の動きをみると、転入超過数の地域差は平成 19（2007）年をピークとして縮小傾向にある。したがって、原則として、平成 17（2005）～22（2010）年に観察された市区町村別・男女年齢別純移動率を平成 27（2015）～32（2020）年にかけて定率で縮小させ、平成 27（2015）～32（2020）年以降の期間については縮小させた値を一定とする仮定を置いた。

確かに2008年のリーマンショックの影響によって東京圏への人口流入は減少し、地方でも人口の流出は抑えられています。しかし、2015年～2020年にかけてもこの傾向が続くかどうかは不明です。クローズアップ現代の「極点社会～新たな人口減少クライシス～」では、「地方の介護産業が高齢者を求め東京に進出し」、そこで働く若年女性も、「地方から東京へ移動し始めています」という問題を取り上げています。もし、今後地方からの若者の人口流出が増加するようなことになれば、地方の人口の減少は更に加速し、「極点社会」になってしまうのも近いと思います。

三好市は典型的な例ですが、県庁所在地の徳島市でも2010年の264,548人が2040年には206,368人と22%減少する推計になっています。東京圏への人口集中が進めばそれ以上に減少する可能性もあります。地方では県庁所在地でさえ大きく人口が減る時代になっています。地方は危機感を持って若者がどうしたら地域でいい生活を送れるのかを真剣に考えていかないといけないと思います。

統計データを取得するために SDMX を使ってみた

2014-04-30T22:55:00+09:00

年齢別人口のデータを取得するために SDMX を使ってみました。SDMX は、Statistics Data and Metadata eXchage の略で日本語でいえば統計データ及びメタデータ交換仕様といったところでしょうか。世界開発銀行、ヨーロッパ中央銀行、ヨーロッパ統計局、IMF、OECD、国連、世界銀行によって支援されています。

そういうことで、今後統計データを入手しようと思えば、SDMX を使うのがいいだろうと思って使い始めました。取りあえず今回はヨーロッパ統計局の人口関係のデータを取得して、下の図のようなグラフを描くところまでできました。各国の年齢階級別人口の推移のページで公開しています。

SDMXについては、初心者の段階なので、もう少し理解できるようになったら詳しい内容をブログに書きたいと思っています。

ヨーロッパは少子化が進んでいるというようなイメージがあったのですが、図をみればわかるようにヨーロッパ全体では人口は安定した動きになっています。少子化対策の優等生といわれるフランス（フランスの5歳年齢階級別人口の推移）やいち早く少子化が社会問題となったスウェーデン（スウェーデンの5歳年齢階級別人口の推移｝では、リンクをクリックして見ていただければわかるのですが少子化対策が成功しているように思われます。

日本の全国及び各都道府県の年齢階級別人口の推移のページも作成しました。グラフをみると日本の少子化の深刻さがわかります。このままにしておけば百年もすれば日本の地方から人がいなくなるといってもいいような状態だと思います。日本も子供を育てやすい国になることを真剣に考えないといけないと思います。

気象庁防災情報XMLを使ってみた

2014-04-26T01:37:00+09:00

気象庁の防災情報XMLフォーマット形式電文を実際に使ってみました。現在は、天気予報を表示するページを作ってみてテスト運用をしています。これで安定して運用が出来るようになれば Web アプリに組み込みたいと思っています。

PubSubHubbub の subscriber ですべてを処理させるのは、機能追加の時に問題が出そうなので、subscriber は更新情報を受信したら Amazon SQS にメッセージを送るだけの機能にして、XML電文の処理の方は別のコンソールアプリケーションにさせるようにしています。

テストをしてみて、C# の非同期処理 async / await は便利だということを実感しました。XML データを取ってきたり、Amazon の SQS やデータの保存に S3 を使う場合には、どうしても一件当たり100ミリ秒単位の時間がかかるので同期処理をすると100件ぐらいで分単位の処理時間がかかるようになってしまいます。async / await を使うとそれを簡単に非同期処理ができるので処理時間を数分の1に短縮することができます。

実際に防災情報XMLを使ってみて感じたのは、今更なのですが天気予報を以下の例のように言葉で表現したものは簡潔でわかりやすいなと思いました。日本の伝統的な洗練されたものがあるように感じました。

南の風２３区西部でははじめ南の風やや強く晴れ
夜くもり所により雨で雷を伴う
波１メートル後０．５メートル

一方で、XMLの方は使いずらいと思いました。以下に、日本、アメリカ、イギリス、ノルウェーのXMLのサンプルを表示しましたが、日本だけが間延びして階層が異常に深くなっていることがわかると思います。技術的な評価はよく分かりませんが、少なくとも利用する側としては、日本のXMLは４つの中で最低です。階層が深くかつデータがばらばらとあるので、データを取得するプログラムの行数は増えていきます。7階層までいかないとどの項目か判断できないような設計はせずに、外国のように4階層ぐらいでデータを取得できるようにしてほしかったと思います。日本が後発で外国の例を参考にできる立場だっただけに残念です。

日本

アメリカ

イギリス

ノルウェー

それから、今回プログラムを作成していて、かなり時間がかかったのが、WetherCode のコード表の件です。WetherCode のコードについての説明がないので、どのアイコンを使えばいいのかがはっきりしないのです。自分が見落としているかもしれませんが、アメリカの場合は、XML の中に画像のURL が記載されているし、イギリス、ノルウェーの場合でも、得意でない英語の文章でも探すことができました。

天気予報APIのFAQに、「天気の種類は何種類ありますか？」という問いに対して、「天気の種類は現在のところ121種類ございます。尚、121種類の詳細につきましては、開発ドキュメントにてご確認いただけます。」という回答になっていて、秘密保持契約をまかないと開発ドキュメントは手に入れられないので、天気の種類という基本的なことが公開されていないようなのです。drk7氏が独自にしている「気象庁の天気予報情報を XML で配信」のページに、天気情報と画像ファイルの対応表を公開していたので、それを参考にして対応表を作りました。実際に運用してみてチェックしていこうと思っています。

XMLを洗練したものにできない理由を考えてみると、言葉による天気予報では、長年かけて予報官が自ら改善していったものだと思います。しかし、システムのことになると日本の予報官は分からないから、SI業者に丸投げに近い状態になっていて、その SI業者はというと、現状をそのままシステム化しただけになっていると思います。日本では、SI業者に依存しすぎるので、システムのことになると現場の改善力がうまく発揮できないようです。その上に気象会社からの圧力があって、改善すると民業圧迫といわれるので余計に改善の意欲がわかない状態になっていると思います。

問題点は書きましたが、やっと実現した天気予報の無料XMLなので、大いに活用しましょう。気象庁防災情報XMLを使いたい人は、http://ecitizen.jp/weatherのページのリンクから各府県のXMLが取得できるので、月3000PVまでであれば自由に使ってもらっても構いません。事前準備をしなくでもすぐにXMLの取得ができます。商用利用も可能ですが、気象庁の利用上の留意事項については遵守してください。

気象庁 XML と他国の気象庁の天気 API との比較

2014-02-24T00:56:00+09:00

気象庁が防災情報XMLフォーマット形式電文の公開を始めて1年以上になりますが、日本の天気予報を自分の Web ページに載せたいと思って、気象庁XMLを使い始めています。それで、今まで使ったことがある他国の気象庁が公開している天気 API と比較してみました。

自分が使ったことのあるのは、アメリカ、イギリス、ノルウェーの気象庁のAPIです。まず、大きな違いは、気象庁 XML が、それを取得するために PubSubHubbub の subscriber を構築しないといけないということです。アメリカとノルウェーは、誰でもがRESTで簡単に取れます。下のリンクをクリックすると現時点での天気予報のXMLが表示されます。イギリスは、ユーザー登録が必要ですが、オンラインでキーが発行されます。

アメリカニューヨークセントラルパーク

http://graphical.weather.gov/xml/sample_products/browser_interface/ndfdXMLclient.php?lat=40.78&lon=-73.97&product=glance

http://forecast.weather.gov/MapClick.php?lat=40.78&lon=-73.97&unit=1&lg=english&FcstType=dwml
こちらだと現在の気温等の観測データも入っています。

イギリスシティオブロンドン

http://datapoint.metoffice.gov.uk/public/data/val/wxfcs/all/xml/350929?res=3hourly&key=(key)

ノルウェーオスロ

http://api.met.no/weatherapi/locationforecast/1.8/?lat=59.9127;lon=10.7461

気象庁が、無料で天気予報のXMLを公開するのは画期的なことだと思います。ただ、subscriber を構築しないと受信できないのは、ハードルの上げすぎではないかと思っています。初心者にとってはサーバー側のプログラムを組むというのは厳しいです。

それに、subscriber は、警報のように何時発表されるか分からない情報だと確かに便利だと思うのですが、天気予報のように定期的に発表されているものでは必要ないと思います。逆に、サーバーがダウンしたりして通知を取りこぼすと次に新しい通知があるまで復旧できないのが大きな欠点です。できれば、試行から本番に移行するときには他国のように単純に REST で XML を取得できるようにして、subscriber の方は追加の通知機能ということにして欲しいと思います。

ところで、先端IT活用推進コンソーシアム（AITC）の「気象庁防災情報XML」を活用するためのAPIが公開されているのを知りました。先端IT活用推進コンソーシアムには、日本の代表的な SIer が会員になっているし、鶴保会長も日本の SIer の代表者だと思います。こういう組織が作る利用規約だと先進的な利用規約を作るものと思っていましたが、10年以上遅れた利用規約で、明らかに気象庁の利用規約の方が上です。

具体的に言うと、利用規約に「新しい技術やデータセットの評価をおこなうためのものであるため、商用利用を固くお断りします。」、「定期的なクローリング、プログラムからの大量アクセスはご遠慮ください。」という条項があることです。

オープンデータでは、基本的に利用目的については問いません。だから、気象庁も商用利用を認めているし、イギリスの気象庁は Q&A で以下のように商用利用を積極的に認めています。今回の場合でも、商用利用といってもテスト的な利用はあるえると思うし、共同で開発していこうという姿勢を持つことが必要だと思います。それで、普通に書くとしたら「新しい技術やデータセットの評価をおこなうためのものであるため、予告なしにAPI等を変更することがあります。その結果生じたいかなる損失・損害についても、責任を負いません。」ぐらいの書き方がベターでないかと思います。

Can I use the DataPoint web services on a commercial website?

Yes, we actively encourage the use of the DataPoint web services on commercial websites, subject to the conditions set out in the detailed terms and conditions

次に「大量アクセスはご遠慮ください。」というのは、プログラムをする側からすれば意味不明です。きちんと定義すべきです。

アメリカの場合は、基本的に無制限で詳細に書いてあるのは免責条項です。サービスの説明の方にデータの更新は1時間に1回以上はしないから、アクセスの方も同一地点については1時間に1回だけにしてねと書いてあるだけです。

イギリスの利用規約では、1日5000リクエスト、1分100リクエスト以上になるとフェアーユースの範囲を超えるとして、有料になります。

For the purposes of this DataPoint Fair Use Policy, the Fair Use Limits shall be defined as follows:

You may make no more than 5000 data requests per day; and
You may make no more than 100 data requests per minute.

ノルウェーの利用規約では、毎秒20リクエスト以上を大量アクセスと定義しています。

You should save the information on your own server if you have heavy traffic. Heavy traffic means more than 20 requests from the api per second.

このサービスに多大なコストがかかるのであれば、今のような利用規約になっても仕方がないと思うのですが、最近は運用コストが低下して費用はそれほどかからないと思います。個人で天気予報 XML を公開している人もいるぐらいです。それに、先端IT活用推進コンソーシアムの会員にはクラウドコンピューティングを提供している企業もあるのでスポンサーになってもらえばいいのではないかと思います。日本の SIer も、OSS とかの活動にもう少し積極的になって欲しいと思います。

自分も希望があれば天気予報や週間天気予報の XML を他の国のようにRESTですぐに取れるように公開してもいいと思っています。もし、希望があればコメントに書いてください。

気象庁 XML を取得するサンプルを PHP から C# にしてみた

2014-02-21T20:55:00+09:00

自分は、2008年の後半から2009年の前半にかけて、Web を作成するのに、PHP を使うのか ASP.NET で C# を使うべきなのか、それとも Java を使うのか迷った時期がありました。ASP.NET MVC がリリースされ、また、CMS も Umbraco が使えるということで最終的には C# を使うということにしました。

気象庁が提供する天気予報、気象警報、地震、津波情報などの気象庁 XML の取得については、PubSubHubbub の受信サーバーを用意する必要があります。自分でも受信サーバーをたてていて、最近C#で天気予報を取得するプログラムを書き始めています。気象庁の資料をみていると PHP のサンプルコードが、平成25年3月に開催された気象庁XML利活用セミナーの気象庁XMLを入手しようにあったので、そのサンプルコードを C# を使って書いてみました。

資料のサンプルコードでシンプルな例は以下のとおりです。

<?php 
$method = $_SERVER['REQUEST_METHOD'];

// subscribe (or unsubscribe) a feed from the HUB 
if ($method == 'GET') { 
  $hubmode = $_REQUEST['hub_mode']; 
  $hubchallenge = $_REQUEST['hub_challenge']; 
  if ($hubmode == 'subscribe' || $hubmode == 'unsubscribe')
    // response a challenge code to the HUB
    header('HTTP/1.1 200 "OK"', null, 200);
    header('Content-Type:text/plain');
    echo $hubchallenge;
  }else{
    header('HTTP/1.1 404 "Not Found"', null, 404)
  }
}

// receive a feed from the HUB
if ($method == 'POST') {
  // feed Receive
  $string = file_get_contents("php://input");
  // feed save
  $fp = fopen(dateDateTime.UtcNow.ToString('YmdHis') . "_atom" . ".xml", "w");
  fwrite($fp, $string);
  fclose($fp);
?>

これと同じものを、ASP.NET MVC の C#で書いた例です。

using System;
using System.IO;
using System.Web.Mvc;
using System.Xml;

namespace PuSH.Controllers
{
  public class SubscriberController : Controller
  {
    // subscribe (or unsubscribe) a feed from the HUB
    [HttpGet]
    public ActionResult Index()
    {
      string hubMode = Request.QueryString["hub.mode"];
      string hubchallenge = Request.QueryString["hub.challenge"];
      if (hubMode == "subscribe" || hubMode == "unsubscribe")
        // response a challenge code to the HUB
        return Content(Request.QueryString["hub.challenge"]);
      else
        return NotFound();
    }

    // receive a feed from the HUB
    [HttpPost]
    [ActionName("Index")]
    public ActionResult IndexPost()
    {
      // feed Receive
      var reader = new StreamReader(Request.InputStream);
      string str = reader.ReadToEnd();
      // feed save
      using(var sw = new StreamWriter(DateTime.Now.ToString("yyyyMMddHHmmss) + "_atom.xml"))
      {
        sw.Write(str);
      }
      return Content("");
    }
  }
}

このプログラムだとは、PHP も C#はよく似たものだと思います。C#の方が型の宣言をしないといけないのと、関数名やプロパティ名が長いので、記述量が多くなるように見えますが、型宣言に var が使えてコンパイラーが自動で型を決めてくれるし、関数名等で名前が長いのはVSが補間してくれるので、入力が特に面倒だということはありません。

次に POST処理の部分を、変更したサンプルが紹介されています。コードは以下のとおりです。

// receive a feed from the HUB
if ($method == 'POST') {
  // feed Receive
  $string = file_get_contents("php://input");
  //feed Parse & XML GET
  if(FALSE === ($feed = simplexml_load_string($string)))
  {
    exit("feed Parse ERROR");
  }
  foreach($feed->entry as $entry)
  {
    $url = $entry->link['href'];
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_TIMEOUT, 60);
    curl_setopt($ch, CURLOPT_HEADER, 0);
    $fp = fopen(basename($url), "w");
    curl_setopt($ch, CURLOPT_FILE, $fp);
    curl_exec($ch);
    curl_close($ch);
    fclose($fp);
  }
}
?>

これを単純に ASP.NET MVC の C# に変更するだけだったら面白くないので、自分が現在使っているルーチンを紹介したいと思います。

追加と変更部分のみ
using System.ServiceModel.Syndication;
using Nlog;

    private static Logger logger = LogManager.GetCurrentClassLogger();

    [HttpPost]
    [ActionName("Index")]
    public ActionResult IndexPost()
    {
      using (XmlReader xmlReader = new XmlTextReader(Request.InputStream))
      {
        try
        {
          var feed = SyndicationFeed.Load(xmlReader);
          if (feed != null)
          {
            string feedtype = "e"; //定時:regular、随時:extra、地震火山:eqvol、その他:other
            foreach (var link in feed.Links)
            {
              if (link.RelationshipType == "self")
              {
                var uris = link.Uri.Segments;
                feedtype = uris[uris.Length - 1].Split('.')[0]; 
              }
            }
            var xmlWriter = XmlWriter.Create(
              Server.MapPath("~/App_Data/feed/") + feedtype + DateTime.UtcNow.ToString("yyyyMMddHHmmssfff") + ".xml");
            feed.SaveAsRss20(xmlWriter);
            xmlWriter.Close();
                    
            logger.Info("ID:{0} Update:{1} Type:{2}", feed.Id, feed.LastUpdatedTime, feedtype);
            foreach (var item in feed.Items)
            {
              string title = item.Title.Text;
              string name = item.Authors[0].Name;
              string updatetime = item.LastUpdatedTime.ToString();
              foreach (var link in item.Links)
              {
                logger.Info("{0} {1} Update:{2} uri:{3}", title, name, updatetime, link.Uri);
                switch (title)
                {
                  case "府県週間天気予報":
                    処理
                    break;
                  case "府県天気予報":
                    処理
                    break;
                }
              }
            }
          }
        }
        catch(Exception e1)
        {
       　　 logger.Error("Feed Error:" + e1.Message);
        }
      }
      return Content("");
    }

ログの記録には、NLog を使っています。まだプログラムを始めたばかりなので、ログを取ったり、RSSをファイルに保存したりしていますが、最終的には、ログやファイルへの保存は最低限にしていこうと思っています。ログを取ってみると、気象庁 XML は、1分間に1回処理が動いてフィードが飛んでくることがわかります。ここで最大で約1分間の遅延があること、また、たまにフィードの送信が遅延することがあるので数分間程度のタイムラグがあると思った方がいいということが分かります。

実際にはプログラムができたら、気象庁への登録申請が必要になりますが、登録申請の前にきちんとテストをしておきましょう。Google のハブを使ったテストの方法は、気象庁の電文公開の仕組みのページの情報提供に係る仕様とSubscriberの構築についてというPDFファイルに記載があります。

この例からわかるように Web だけの話だったら、PHP はとてもいい言語だと思います。でも、PHP は Web以外で動かそうと思ったら結構大変です。Web 用のオープンソースのアプリケーションは非常に多いのですが、自分は Web 以外でもプログラムをしたかったので PHP は捨てました。C#は Web の世界でも、PHP に決して劣っているわけではありません。そして、多くのデバイスで動作することが魅力です。Android/iPhone のネイティブアプリが作れる Xamarin に期待しているので、時間ができれば Xamarin も使ってみたいと思います。

Linked Open Data を使って自治体コード表を作ってみた

2014-01-28T00:05:00+09:00

前回のブログでは、次世代統計利用システムで都道府県・市区町村コード情報が LOD（Linked Open Data）で提供されるようになったので、実際に使ってみてその使い方をメモした。今回は、その LOD を使って、実際に自治体コード表（地方公共団体コード表）を作ってみた。（公開している場所 http://ecitizen.jp/sac）

自治体コード表をLODを使って作ってみて感じたことは、LODはプログラマーにとっては確かに便利だと思う。でも、現在の政府統計窓口では、市町村コード表や廃置分合等情報がダウンロードできるようになっている。それを使ってプログラムする場合とLODを使ってプログラムをする場合の差はあまりないと思う。結局は、LODを使ってもデータの内容を把握しないとプログラムはつくれない。オープンデータの５つ星がいわれているが、自分の経験からいえば、星が０と１の間はものすごく大きいが、星1つと星5つの差はそれと比べるとかなり小さく、星5つというよりは星1.5だというのが正直な感想である。

以下は具体的にどうしたかをメモしておく。まず、自治体コード表を作るため、前回作成した埼玉県の市町村一覧を選択するクエリーを変更して、SELECT に「ふりがな表記」と「自治体コードの6桁目であるチェックディジットコード」を追加し、FILTERに「特別区」及び「政令指定都市の区」を追加して表示されるようにした。変更後のクエリーは以下のとおりである。

SELECT ?s ?name ?kana ?cd WHERE { 
  GRAPH ?g { ?s ?p ?o .
    ?s rdf:type sacs:CurrentStandardAreaCode.
    {{
      ?o dcterms:isPartOf sac:C11000-19700401.
    }UNION{
      ?o dcterms:isPartOf ?district.
      ?district dcterms:isPartOf sac:C11000-19700401.
    }}
    ?o sacs:administrativeClass ?ad.
    ?o rdfs:label ?name.
    ?o rdfs:label ?kana.
    ?o sacs:checkDigit ?cd.
  }
  FILTER( lang(?name) = "ja")
  FILTER( lang(?kana) = "ja-hrkt")
  FILTER(?ad = sacs:DesignatedCity || ?ad = sacs:CoreCity ||
   ?ad = sacs:SpecialCity || ?ad = sacs:SpecialWard || ?ad = sacs:Ward ||
   ?ad = sacs:City || ?ad = sacs:Town || ?ad = sacs:Village)
}

そのクエリーをベースにして、JavaScript を使ってWebブラウザーで自治体コードが表示されるようにしてみた。期限付きの都道府県コードは、CXX000-19700401で調べた範囲ではすべての都道府県が大丈夫のようだ。沖縄県の場合は1970年4月1日現在では琉球政府の時代で日本復帰は1972年5月15日であるが、C47000-19700401 となっていた。なお、沖縄県にある市町村の方の期限付き標準地域コードは1972年5月15日以降の分しかない。

このクエリーを処理する JavaScript のルーティンを書くことはそれほど難しいことはない。注意する点は、ブラウザーでの処理には、クロスドメインの制限があるということである。そのため、使うプロトコルは JSONP になるので、データとして jsonp/callback を送信する必要がある。また、その値がコールバックルーティンの名前なので、jQuery の場合であれば jsonpCallback にその名前を設定してやる必要がある。

なお、ソートは本来はクエリー側ですべきで、ORDER BY ?s をクエリーの最後につけてやればコード順のソートが出来るはずなのだが、理由はよくわからないが動作させられなかったので、JavaScript 側の方でソートをしている。

function makeTable(sacQuery){
  $.ajax({  
        url: http://statdb.nstac.go.jp/lod/sparql?,
        data: {
            query: sacQuery,
            output: "json",
            jsonp: "sacsac"
        },  
        jsonpCallback: 'sacsac',
        dataType: "jsonp"  
    })
    .done(function (data) {  
        var mn = data.results.bindings;
        mn.sort(function (a, b) {  
            if (a.s.value < b.s.value)
                return -1  
            else
                return 1;  
        });

        var html = "<table class=\"sactable\">";  
        html += "<tr><th>団体コード</th><th>団体名</th><th>ふりがな</th></tr>";
        for (var n = 0; n < mn.length; n++) {  
            html += "<tr><td>" + mn[n].s.value.substring(mn[n].s.value.length - 5) + mn[n].cd.value + "</td><td>" +
              mn[n].name.value + "</td><td>" + mn[n].kana.value + "</td></tr>";
        }  
        html += "</table>";
        return html;
    });  
}

これで動作させてみると、下の図のように政令指定都市の区が二重になった。なぜか調べると、政令指定都市の区は dcterms:isPartOf で複数の期限付きの政令指定都市のコードを持つ場合があるということのためのようだ。

それで、期限付きの政令指定都市コードのうち現在の政令指定都市コードを選択してやらないといけないということで、ここでは、少し処理を簡単にするため、廃止年月日のない政令指定都市コードを選択することにした。

SPARQL 1.1 だと、dcterms:valid 値がないレコードを取得するののは NOT EXISTS を使えば簡単に記述できるが、NOT EXISTS は動作しなかった。それで、以下のように SPARQL 1.0 で記述してみると動作した。

SELECT ?s ?name ?kana ?cd WHERE { 
  GRAPH ?g { ?s ?p ?o .
    ?s rdf:type sacs:CurrentStandardAreaCode.
    {{
      ?o dcterms:isPartOf sac:C11000-19700401.
    }UNION{
      ?o dcterms:isPartOf ?district.
      ?district dcterms:isPartOf sac:C11000-19700401.
      OPTIONAL {?district dcterms:valid ?valid.}
    }}
    ?o sacs:administrativeClass ?ad.
    ?o rdfs:label ?name.
    ?o rdfs:label ?kana.
    ?o sacs:checkDigit ?cd.
  }
  FILTER( lang(?name) = "ja")
  FILTER( lang(?kana) = "ja-hrkt")
  FILTER(?ad = sacs:DesignatedCity || ?ad = sacs:CoreCity ||
   ?ad = sacs:SpecialCity || ?ad = sacs:SpecialWard || ?ad = sacs:Ward ||
   ?ad = sacs:City || ?ad = sacs:Town || ?ad = sacs:Village)
  FILTER (!BOUND(?valid))
}

次世代統計利用システムの都道府県・市区町村コード情報は、SPARQL 1.0 で動作しているように思われる。これから使うシステムなので、NOT EXISTS や MINUS が使える SPARQL 1.1 で動作させて欲しいと思う。

今回作った Webページは、統計メモ帳の以下にアドレスに公開しておきます。

http://ecitizen.jp/sac

もう少し手間をかければ、e-stat の「標準地域コードを探す」というページに近いものが作れると思っている。しかし、レスポンスや次世代統計利用システムのサーバー側の負荷を考えると、SPARQL を直接使うのはどうかなと思っていて、自分のサーバーで、データのキャッシュ等をして負荷の軽減をすべきだと思っている。それで、次はサーバー側での SPARQL の処理を試してみようと思っている。C#には、dotNetRDF というオープンスースの RDF 関連のライブラリーもあるので、そのライブラリーも試してみたいと思っている。

市区町村コード情報がLODで公開されたので使ってみた

2014-01-25T22:54:00+09:00

次世代統計利用システムで、都道府県・市区町村コード情報が LOD（Linked Open Data）で提供されるようになったので使ってみた。使い方を少しメモしておく。

まず、SPARQLエンドポイントが用意されているので、そのページに行くと下の図のように画面でも検索できるようになっているので、この画面でSPARQLを試してみた。

?s ?p ?o というのは、?s（Subject 主語）、?p（Property 述語）、?o（Object 目的語）で、tuple ステートメントというようです。そのままで、Show results inline: にチェックをして、「Send Query」ボタンをクリックすると以下のように情報が表示される。

次に市区町村コードから市町村名等が表示されるか試してみた。?s を埼玉県川越市の市区町村コード11201に以下のように置き換えてクエリーしてみた。なお、sac:C11201は、<http://statdb.nstac.go.jp/lod/sac/C11201>の省略形であり、Prefex が登録されているので簡単に記述可能である。sac:C11201 の代わりに、<http://statdb.nstac.go.jp/lod/sac/C11201>と入力しても同じ結果になる。

SELECT * WHERE { 
  GRAPH ?g { sac:C11201 ?p ?o . } 
}

クエリーの結果は、プロパティとしては、rdf:type と owl:sameAs のみを持つていて、owl:sameAs プロパティの結果として期間付き標準地域コード sac:C11201-20030401 が返されるだけで、市町村名等は取得できない。ここで取得した期間付き標準地域コードのプロパティを取得する必要がある。そこでクエリーを次のように変更して実行してみた。

SELECT * WHERE { 
  GRAPH ?g { sac:C11201 ?p ?o .
    ?o ?a ?b.
  } 
}

こうするとマニュアルにある期限付き標準地域コード・クラスのプリパティの一覧が表示され、その中に川越市という名前も表示される。プロパティのうち、dcterms:valid は廃止年月日のプロパティなので、現時点では値がない。その場合には、RDBのようにNULLとかが表示されるのではなく、プロパティには何も表示されない。それでは市町村名だけを表示するのはどうしたらいいかというとプロパティを以下のように市町村の日本語表記である rdfs:label@js 等に指定すればよい。

SELECT ?b WHERE { 
  GRAPH ?g { sac:C11201 owl:sameAs ?o .
    ?o rdfs:label ?b.
  }
  FILTER( lang(?b) = "ja") 
}

なお、マニュアルでは、日本語表記のプロパティは、rdfs:label@ja となっているが、そのままでは動作せずFILTER を使う必要があるようだ。

次に、埼玉県川越市の市区町村コードを取得してみる。一番簡単なクエリーは以下になる。

SELECT * WHERE { 
  GRAPH ?g { ?s ?p "川越市" . } 
}

これで、?s に川越市の期間付き標準地域コードの一覧が表示されるので、一応 11201 ということがわかる。もう少し厳密に現在の川越市の市区町村コードをクエリーで得る例は以下のとおり。

SELECT * WHERE { 
  GRAPH ?g { ?s ?p ?o .
    ?s rdf:type sacs:CurrentStandardAreaCode.
    ?o rdfs:label "川越市".
  } 
}

次に埼玉県の現在の市町村の一覧を取得してみる。そのコード例は以下のとおり。

SELECT ?s ?name WHERE { 
  GRAPH ?g { ?s ?p ?o .
    ?s rdf:type sacs:CurrentStandardAreaCode.
    {{
      ?o dcterms:isPartOf sac:C11000-19700401.
    }UNION{
      ?o dcterms:isPartOf ?district.
      ?district dcterms:isPartOf sac:C11000-19700401.
    }}
    ?o sacs:administrativeClass ?ad.
    ?o rdfs:label ?name.
  }
  FILTER( lang(?name) = "ja")
  FILTER( ?ad = sacs:DesignatedCity || ?ad = sacs:CoreCity || ?ad = sacs:SpecialCity ||
    ?ad = sacs:City || ?ad = sacs:Town || ?ad = sacs:Village )
}

埼玉県の1970年4月1日以降のどの日の市町村一覧とか市町村がどのように合併をしてきたか等をSPARQLを使えば取得可能である。そういう点では、LODは非常に便利である。自分の場合は、市町村の合併等を考慮して統計数字を比較したいと思っているので、都道府県・市区町村コード情報の LODを使いたいと思っている。

しかし、普通の人がSPARQLを使うのは、はっきりいって難しすぎるし、少し複雑なことをしようと思えばSPARQLがどんどん複雑になってしまう。今のSPARQLだとオープンデータの専門家のおもちゃにすぎないと思う。オープンデータでLODの評価が非常に高くなっているが、それは一部の専門家の評価であって、普通の人が使えるようなソフトウェアを作らなければLODの評価は過大評価だと思う。

政府統計データ API で公開されている統計表のリストを作ってみた

2013-06-28T10:10:00+09:00

総務省統計局と統計センターによって、次世代統計利用システム（API機能）の試行運用が6月10日から開始されました。自分も統計データAPIを使ってアプリケーションを作ろうと思っています。

ところで、統計APIの関係では「統計くん」というWebサービスがメディアに取り上げられています。例えばITmedia ニュースによると「個人開発者の矢野さとるさんは6月12日、10日に公開された「次世代統計利用システム」のAPIを活用し、国勢調査などの政府が持つ統計データをCSV形式でダウンロードできるWebサービス「統計くん」を公開した。」というような記事が掲載されています。

その「統計くん」を使ってみると、データの一覧には自分の欲しいデータがありませんでした。そのため今回のAPIの公開がかなり暫定的なものなのかと思ってしまいました。でも実際に調べていくと「統計くん」では統計APIで公開されている統計表のごく一部しか扱っていないことがわかりました。

自分で使うためにも、どういう統計データが公開されているかを知りたかったので、APIで公開されている統計表の一覧表を作成してみました。まだまだ未完成ですが、統計APIを使ってみようと思っている人には役に立つと思うので ecitizen.jp の方に「政府統計データAPI エクスプローラ」として公開してみました。