Original Paper
An Agro-Meteorological Grid Square Data System Enabled Web Application for Agriculture and Its Web API
2019 Volume 2019 Issue 1 Pages 67-75
Details
2019 Volume 2019 Issue 1 Pages 67-75
近年，Web サービスが提供する Web API を組み合わせたマッシュアップと呼ばれる手法による Web アプリケーション開発が広く行われている．Web API を利用して新たな農業用アプリケーションを構築するときに，データと作物生育予測モデルや病害虫発生予察モデル等の農業モデルを結びつけられるようにするためには，データ表現形式の標準化や，理解しやすい Web API の設計が必要である．そのため，サービスを終了した気象データベース仲介サービス MetBroker の代わりとなる，メッシュ農業気象データやアメダスから気象データを取得する Web API 機能や，農業モデルを実行するための Web API 機能を実装した．
作物の生育予測モデルや病害虫発生予察モデル等の農業モデルや，気象データ，市況データや画像等のデータベースなどをコンポーネントとして扱い，それらをネットワーク経由で結び付けて新たなアプリケーションを構築する試みは，国内にインターネットが登場した頃から行われてきた．コンポーネント群を結び付けるためには，通信プロトコルや Application Programming Interface （API）の標準化が必要で，これに対応するための仕組みが分散オブジェクト技術である．
農業モデル・データベース分散協調システム（以降，協調システム）は，「増殖情報ベースによる生産支援システム開発のための基盤研究」（1997 ～ 2000 年度）や，「データベース・モデル協調システムの開発」（2001 ～2005 年度，農林水産省 2007）において研究，開発された，農業分野向けの分散オブジェクトシステムであった．
初期の協調システムでは，分散オブジェクト技術の標準仕様として策定された Common Object Request Broker Architecture（CORBA）の利用が進められていた．しかし，CORBA はプログラミングモデルの複雑さのため，筆者はプログラミング言語を Java に統一することにより簡単化して，農業モデル開発用フレームワーク（Java Agricultural Model Framework: JAMF，田中 2006） を開発し，それが提供する Java API を利用した協調システム（Agricultural Models and Databases with Distributed Cooperative System: AMADIS，田中 2013） を構築した．このシステムでは，気象データ取得機能はシステムを構成する分散オブジェクトの 1 つである，気象データベース仲介ソフトウェア MetBroker（Laurenson et al. 2002，二宮 2001）が担っていた．MetBroker はネットワーク上の気象データベースとアプリケーションを仲介するソフトウェアで，対応する気象データベースへのリクエストや，取得した気象データを扱うための統一的な手法を API として提供していた．2013 年にはアメダスや NOAA/WMO を含む国内外の 17 の気象データベースに対応し，世界中の 8.6 万（うち国内 2.5 千）カ所の気象観測地点にアクセスできた．そして，SIMRIW や JAPONICA 等の水稲生育予測モデルや，BLASTAM 等の病害虫発生予察モデルを含む 20 程度のモデルがクライアントサイドで実行される Java アプレットとして開発された．
その後，サーバサイドで処理を行う Web アプリケーションや Web サービスが主流となり，それらを利用するための Web API が公開されるようになった（水野 2014）．Web API（図 1）とは，Web サーバに送られた HTTP リクエストに対して，処理結果を Extensible Markup Language（XML） 形式や，JavaScript Object Notation（JSON）形式などのテキスト，または，画像データで返す機能を利用するための手順であり，処理結果は別のプログラムの入力データとして利用できる．有用なデータや視覚化ツールの Web API が公開されたことは，マッシュアップと呼ばれる複数の Web API を組み合わせる手法で，多くの有用な Web アプリケーションが誕生するきっかけとなった（Patel et al. 2010）．近年では，Society 5.0 の農業分野での実装として農業データ連携基盤 WAGRI（2017）が設立され，民間企業や官公庁等から提供された気象や土地情報等に関する様々なデータを，API を利用して参照できるようになっている．
このような技術開発の流れを受けて，AMADIS の成果も Java サーブレットによる Web アプリケーションとして再実装された．例えば，MetXML と名付けられた MetBroker 経由で気象データを取得するための Web アプリケーションや，作物生育予測モデルWeb アプリケーションである．再実装されたWeb アプリケーションでは Web API も公開した．この時点での目的はマッシュアップによる新たなアプリケーション構築を想定したものではなく，JAMF を利用したプログラム開発に不慣れなユーザのために，図 2 に示される URL クエリパラメータ値の文字列操作のみで，気象データを取得できるようにすることであった．また，作物生育予測モデル Web アプリケーションでの目的は，一度行ったシミュレーションの設定内容をクエリパラメータとして保存するためのものであった．
ところが，2017 年 3 月に気象データ取得元として長年利用してきた MetBroker が，ソースコードのメンテナンスやサーバを維持することが人的・資金的に困難になったため，サービスを終了した．JAMF の気象データ取得機能のデータは，すべて MetBroker 経由で取得していたため，AMADIS で開発した気象データが必須である農業用 Web アプリケーションを継続して利用可能とするためには，気象データ取得機能を JAMF に追加しなければならなかった．
本研究では，MetBroker に代わる気象データ取得機能として，アメダスやメッシュ農業気象データからの気象データ取得機能と，その関連機能を実装したことを報告し，Web API を利用した新たな農業用 Web アプリケーションの開発手法を提案する．
MetBroker は様々な気象データベースへのアクセス方法，リクエスト形式や出力形式の違いを吸収し，統一的な手法で利用可能にしていた．JAMF の新たな気象データ取得機能においても，以下の項で示すように同様な特徴を備えるようにした．気象データ取得機能が対象とする気象データベースは，国内での農業モデル実行を主な目的とするため，十分な数の地点と気象要素を扱っているアメダスとメッシュ農業気象データとした．表 1 はそれぞれの観測地点数，データ取得方法等の特徴や違いをまとめたものである．取得した気象データの利用は，取得元の気象データベースの利用条件に従うことになる．
1．アメダス
アメダス（気象庁 2002）は国内での農業モデル実行のための主要な気象データとして利用されていることから，必要な気象データベースである．また，病害虫予察モデルで利用される時別値も提供している．しかし，Web API が公開されておらず，図 3 の気象データ検索用 Web 画面で条件を設定すると，気象データが HTML の表で表示されるのみで，再利用可能なデータ形式となっていない．
そのため，リクエストされた気象データを表示させるための URL クエリパラメータ（図 4）を解析することにより，必要な気象データを取得するための URL 生成機能を作成した．取得する期間や気象要素の組み合わせによって，生成される URL の数は異なる．SIMRIW を実行する場合，終了条件までへの余裕を含めた移植日から 6 カ月分の日別気温と日射量を取得する．アメダスで日射量を観測している地点では，観測している気象要素数が多いため，気温と日射量が 2 ページに分かれて表示される．そのため，12 ～ 14 個（6 ～ 7 カ月分× 2 ページ）の URL が生成される．
生成された URL へのアクセスによって返されるのは，気象データが表として格納された HTML 文書であるため，HTML タグを手掛かりに気象データを切り出す必要がある．そのため，Web スクレイピングと呼ばれる手法で，HTML 文書内の表から，HTML 解析ライブラリを利用して気象データを抽出する機能を作成した．アメダスでのこのようなコンテンツの利用は，出典を記載することにより認められている（気象庁 2018）．しかし，URL の構造や HTML 文書の構造は公開されたものではないため，事前に通知されることなく変更されることがあり，その場合は，機能が正常に働かなくなるという問題がある．
2．メッシュ農業気象データ
メッシュ農業気象データ（大野 2014，2017）は，アメダスデータを空間補間した 1 km メッシュ値，26 日先までの予報値と，それ以降の平年値までをシームレスに取得できることから，アメダスよりモデル予測の精度を向上できるデータである．
メッシュ農業気象データは，年―気象要素の階層でデータが Open-Source Project for a Network Data Access Protocol（OpeNDAP）サーバに格納されている．必要な気象データは，OpeNDAP Server Dataset Access Form（図 5）に各変数の範囲を指定し，希望するデータ形式のボタンをクリックすることで取得できる．
メッシュ農業気象データから気象データを取得するための URL は，図 5 の DATA URL の欄に示される文字列で，URL のディレクトリ構造としてデータ領域，年，気象要素，データ形式が指定され，クエリパラメータとして期間，緯度，経度の範囲が指定されている（図 6）．
出力データ形式は 3 つあり，ASCII 形式（図 7），Network Common Data Form（netCDF） 形式と Data Access Protocol（DAP）形式である．同日時に観測されたデータが面的に列挙されて，時系列に積み重ねられるデータ構造となっている（図 8 右）．
メッシュ農業気象データを農業モデルで利用するためには，地点ごとの時系列データのセット（図 8 左）として扱えるようにデータ構造の変換が必要である．データ処理時間はデータのダウンロード時間と比べて無視できる程度なので，どの出力形式を利用するかは，文字列処理のみで行うか，netCDF や DAP 用プログラムライブラリを利用するかで選択することになる．メッシュ農業気象データを農業モデルで利用するために，図 6 のURL 構造を基に必要な気象データを取得するための URL 生成機能を作成した．アメダス同様に取得する期間や気象要素の組み合わせによって，生成される URL の数は異なる．SIMRIW を実行するために，移植日から 6 カ月分の日別気温（平均・最高）と日射量を取得する場合，3 個（3 気象要素）の URL が生成される．冬小麦の生育予測のように，年をまたぐような場合には，年ごとに別のアクセスが必要なため，気象要素数 × 2 年分の URL が生成される．
メッシュ農業気象データは，農業分野や他の分野における研究・開発・教育を目的とする場合に利用でき、利用者登録が必要である（大野 2014）．
3．時系列データ関連機能
MetBroker を利用するための Java ライブラリには，時系列データである気象データを格納する機能や期間を表現する機能など，農業モデル開発に必要な機能の多くが含まれ（Laurenson 2001），その多くを JAMF で利用していた．それらの機能のみ MetBroker のライブラリの利用を継続することも可能であったが，改良すべき点が多く，今後のメンテナンスもないことから，MetBroker に代わる気象データ取得機能に加え，時系列データ関連機能も実装することにした．
主な改良点の一つは，Java8 から導入された java.time パッケージの日時 API を利用するようにしたことである．MetBroker では日時の表現に java.util.Date クラスを利用していたため，日別値を扱う場合でも時刻の値を持っていたり，平年値を扱う場合でも年の値を持っていたりした．日別値の場合には時刻の値をクリアしていたが，その処理を忘れた日付との比較を行ってしまうと，予期せぬ不具合を引き起こすことがあった．平年値の場合は意味のない適当な年の値を設定することになり，年をまたいでの農業モデル実行時に面倒であった．JAMF では，日時 API の日付のみを表現する LocalDate や，月日を表現する MonthDay を利用することにより，以上の問題を解決した．
二つ目の改良点は，時系列データ関連の機能を拡張したことである．MetBroker の時系列データ保持のための StoreImpl クラスは，格納できるデータ期間を最初に設定しておかなければならず，期間を広げるためには別の処理が必要であった．また，観測値と平年値をつなげるようなマージ処理や，出力するために一部の期間のデータのみ取り出すような機能がなかった．さらに，ユーザ が利用できる形式での出力機能がなかった．そのため，データの追加，マージ，切り出し等の機能や，様々な形式（XML，JSON，CSV，Excel ブック，HTML の表，グラフ画像，KML ＜ Google アース上でのアニメーション表示＞など）で出力する機能を実装した．
JAMF の Java API，すなわち農業モデルを開発するためのプログラミング言語 API の利用は，農業モデル Web アプリケーション構築を容易にしてきた．例えば，農業モデルには多くの共通処理部分があり，JAMF を利用することで新規に開発する必要のあるモデル固有のプログラムのコード行数は，JAMF を利用しなかった場合に記述しなければいけないコード行数の 5.2％で済み（田中 2013 の表10），開発コストを低減できた．
しかし，気象データ取得から結果の出力までのすべての機能を必要とせず，気象データ取得機能のみ，あるいは，農業モデルの核であるモデルの計算部分のみを利用したいユーザもいる．そこで，JAMF を利用して開発した既存の農業モデルを気象データ取得，農業モデル実行，結果の視覚化の 3 つの Web サービスのコンポーネントに分割し，図 9 のように Web API 経由でそれらを結びつけるマッシュアップによる手法で農業モデルを再構築することを考える．気象データ取得や結果の視覚化のような機能は，それらに特化したサービスを利用したほうが，必要とするデータを取得できたり，最新の機能や優れたユーザインタフェースを利用できたりと，開発を効率化できる．さらに，コンポーネントの入れ替えが容易になれば，一部の機能を組み替えた特定ユーザ向けの農業モデルの開発も容易になる．
1．各コンポーネントのWeb API
気象データ取得 Web API として，JAMF を利用した気象データ取得サービス MetXML の Web API（田中 2007a，図 10）を利用できる．その他に，NASA POWER（1983），OpenWeatherMap（2012），World Weather Online（2015）などもあり，XML やJSON 形式などで気象データを取得できる．
農業モデル実行 Web API として，JAMF を利用して開発した作物生育予測モデル Web アプリケーション（田中 2007b，図 11）を利用できる．その他に，中部大学が開発した Decision Support System for Agrotechnology Transfer（DSSAT）を Web API 経由で実行するサービス等がある．
結果の視覚化には AMF の出力機能を利用できるが，Chart.js や C3.js 等のグラフ描画ライブラリや，DataTables や Handsontable 等の表生成ライブラリなど，データを出力するための様々なライブラリが公開されているので，それらを利用できる．
2．標準化
新たな農業用アプリケーションを構築するためには，データやモデルなどのコンポーネントを結びつけられるようにするため，データ表現形式（XML や JSON のスキーマ）や Web API の標準化（URL 構造，クエリパラメータ名，パラメータのデータ形式等）が必要である（水野 2014）．
JAMF では XML 形式を標準データとして，気象データ表現形式用 XML スキーマ metxml.xsd 等を提供してきた．しかし，データ量が少なく，処理時間が短い JSON 形式データが利用されることが多くなったため，コンポーネント間のデータ交換には JSON 形式を利用する．また，農業版クラウドオープンプラットフォーム（CLOP）では，様々な標準化作業が進められている．さらに，農業関係の Web サービス国際標準化のための W3C Agriculture Community Group（W3C 2014）が活動している．
3．各コンポーネントの接続
ここでは，JAMF を利用して開発した 3 つのコンポーネントを結び付けて，農業モデルアプリケーションを構築する例を示す．JAMF で開発されていないコンポーネントを利用することも可能であるが，コンポーネント間のデータ表現形式の変換処理が必要になる場合もある．各コンポーネントの接続は，図 9 の農業モデルアプリケーションが行う．データ表現形式の変換処理が不要な場合の最も単純な実装方法は，図 9 の説明の最後にある［2］［4］［6］の 3 つの処理を curl コマンド等で実行することである．
JAMF にメッシュ農業気象データやアメダスからの気象データ取得機能を扱えるようにしたため，MetBroker のサービス終了後も，既存の農業モデルを継続して利用できている．JAMF の気象データ取得機能は，ユーザのリクエストに応じて気象データを気象データベースから取得するだけの単純なものであるため，サーバやデータベースを利用していた MetBroker より効率の点で劣ることはあるが，維持の点では容易である．さらに，気象データのユーザは，JAMF の時系列出力機能により，XML，JSON，CSV，HTML 表，グラフ画像，KML による出力が行える．
アメダスには気象データを取得するための URL 構造やデータ構造が変更され，データ取得機能が正常に働かなくなるという問題がある．それに対し，Web API が公開され，出力データ形式が定まっているメッシュ農業気象データには，このような問題は生じにくい．変更されるとしても事前に通知されるか，旧バージョンとしてしばらく利用可能となることが多い．
気象データを農業モデルで利用する場合，基本的にメッシュ農業気象データを選択すればよい．理由の 1 点目は，メッシュ農業気象データでは 1 km 間隔のデータを利用できることである．特に作物収量予測モデルで利用される日射量は，アメダスでは国内で約 50 地点でしか提供されていない．2 点目は，26 日先までの予報値を利用できることから，平年値を利用するよりモデルの予測精度を向上できることである．しかし，メッシュ農業気象データは日別値のみ提供しているため，主に時別値を利用する病害虫発生予察モデルでは，三角法（坂神，是永 1981）のような推定手法を利用しないのであれば，アメダスを選択することになる．また，取得する気象要素数や期間の長さによっては，メッシュ農業気象データの応答時間が長くなることがあるため，気象データを利用するアプリケーションの性質によっては，アメダスが適している．
近年は，Web アプリケーションよりも，スマホアプリの躍進が著しい．Android 用のスマホアプリの開発言語は Java であるため，気象データを取得したり，農業モデルを実行したりするスマホアプリの開発に JAMF を利用することができる．ただし，Android OS のバージョンによって，利用可能な API レベルが決まっているため，レベルによっては，Java の新しい機能の一部がサポートされていない．2 年以内に購入されたスマホまでを対象にしたスマホアプリを開発する場合，2017 年 8 月にリリースされた Android 8.0 以上のシェアが 21.5％，2016 年 8 月にリリースされた Android 7.0 以上のシェアが 49.7 ％（2018 年 10 月時点，Android Developers 2018）であることを考慮すると，最低バージョンを Android 7.0 に設定することになる．しかし，Android 7.0 では Java8 から導入された java.time パッケージの日付 API を利用できず，初期から存在する java.util パッケージの Date や Calendar を利用するように書き換えなければならないという問題が生じる．Android 8.0 以上を対象とするなら問題ないが，対象スマホが少なくなってしまう．この場合，JAMF を利用して開発した気象データ取得や農業モデル実行の機能を Web API を経由で利用し，結果データとして JSON 形式のデータを取得し，スマホアプリのプログラムで利用すれば，問題を回避できる．さらに，Web API 経由での利用は，プログラミング言語を選ばなくなるため，Swift や Objective-C が開発言語である iPhone アプリ開発でも利用可能となる．
JAMF の気象データ取得機能については，気候変動研究のために農業モデルを国外の地点で実行するような場合（Tanaka and Kiura 2015）に対応するため，国外の気象データを扱う気象データベースに対応すべきだと考えている．例えば，MetBroker 経由で利用していた NASA POWER の全球 1 度グリッドのデータが候補である．
Web API による気象データ取得機能や，農業モデル実行機能を公開するためには，ネットワークに公開されたサーバ上で Web サービスを稼働させておかなければならないが，外部に公開されたサーバの維持コストは高い．データ連携基盤でサービスを動かすことが一つの解決法である．また，気象データ取得機能や，農業モデル実行機能は Java サーブレットとして開発されていて，WAR（Web Application Archive）ファイルとして配布可能となっている．WAR ファイルは，Apache Tomcat などの Java サーブレットコンテナの所定ディレクトリに配置するのみで利用可能となる．ユーザのローカルなサーバでユーザ専用の Web サービスとして稼働させることにより，気象データ取得機能や農業モデル実行機能 をWebAPI 経由で利用するのが，もう一つの解決法と考えている．
本研究成果である JAMF の気象データ取得機能は「農研機構メッシュ農業気象データ（The Agro-Meteorological Grid Square Data, NIAES）」を利用している．
