JP2021026499A - 情報処理装置及びその制御方法及びプログラム - Google Patents

Abstract

【課題】より適切で、意義のある農作物の状況を把握するための情報を提供する情報処理装置及びその制御方法及びプログラムを提供する。【解決手段】圃場における農作物に関する情報の管理および集計する情報処理装置において、管理部は、圃場調査装置から圃場における農作物の観察データを受信し管理する。フィルタリング部は、管理部により管理している観察データから、集計対象の観察データをフィルタリングする。判定部は、管理部による管理に基づき、集計タイミングとなったか否かを判定する。集計部は、判定部により集計タイミングとなったと判定された場合、外部からの観察データの問い合わせに対する最新の応答のために観察データの集計処理を実行する。【選択図】図３

Description

本発明は農業における調査データの管理、集計技術に関するものである。

高級なワインを製造するためには、ぶどうの品質が重要な要素の１つとなる。また、複数品種をブレンドして、ワインを製造する場合は、収穫前に収穫量の予測、製造計画をたてることが重要である。このため、ワイン用ぶどう栽培においては、病害虫調査、成育度調査、成熟度調査、収穫量予測調査など、様々な調査を実施する必要がある。

大規模なワイナリーにおいては、圃場における栽培管理とワインの製造管理が分業になっている。また、複数の圃場で収穫したぶどうを使ってワインを製造することもある。このため、ワイン製造責任者にとっては、圃場における調査の進捗状況の詳細を知らない状況で、リモートから圃場の調査結果を参照する必要がある。

圃場の情報をリモートから参照する従来技術として、特許文献１が知られている。特許文献１の従来技術では、圃場にＩｏＴセンサを設置し、情報処理装置は一定時間ごとに、そのIoTセンサから圃場の観察データを取得し、集計処理する。農家のＰＣでは、リモートから情報処理装置の集計結果を参照することができる。

一方、ワイン用ぶどう栽培における各種調査は、天候や成育状況といった外部要因により、調査計画が変更になることがある。また、大規模な圃場では、ある調査目的の調査を複数日かけて実施したり、複数の調査員が調査したりすることがある。このため、ある調査目的の観察データが、不定期に複数回にわたって情報処理装置にアップロードされることになる。

また、ワイン用ぶどう栽培においては、同時並行で複数の調査を計画し実施することもある。また、大規模圃場では複数の調査員が、同一の調査を分担して行い、調査員はそれぞれのタイミングで調査結果を報告することも行われている。このような状況では、調査の進捗管理と調査結果の集計に係る作業は煩雑であり、その作業を行う者の負担は大きい。

特開２００８−２４７４４９号公報

このような状況において、従来技術は、一定時間ごとに集計処理を実施していた。この場合、ある調査目的の観察データが全て情報処理装置にアップロードされる前に集計処理が実行されることがある。すると、全ての観察データを用いて集計した場合と異なる集計結果を情報処理装置が公開してしまうことになる。結果、不十分な観察データをもとに集計された集計結果を参照してしまい、誤った判断をしてしまう可能性がある。

また、この課題を解決しようために集計間隔を長くとりすぎると、ある目的の調査が全て完了してから、集計処理までのタイムラグが長くなってしまう。つまり、集計間隔を長くすると、今度は判断およびその対応が遅れてしまうことになる。

この課題を解決するため、例えば本発明の情報処理装置は以下の構成を備える。すなわち、
圃場における農作物に関する情報の管理および集計する情報処理装置であって、
圃場調査装置から圃場における農作物の観察データを受信し、管理する管理手段と、
該管理手段により管理している観察データから、集計対象の観察データをフィルタリングするフィルタリング手段と、
前記管理手段による管理に基づき、集計タイミングとなったか否かを判定する判定手段と、
該判定手段により集計タイミングとなったと判定された場合、外部からの観察データの問い合わせに対する最新の応答のために前記観察データの集計処理を実行する集計手段とを有する。

本発明によれば、従来技術とくらべて、より適切で、意義のある農作物の状況を把握するための情報を提供できるようになる。

実施形態における圃場調査システムの構成図。 情報処理装置のハードウェア構成図。 第１の実施形態の情報処理装置の処理手順を示すフローチャート。 図３におけるフィルタリング処理を示すフローチャート。 図３における判定処理を示すフローチャート。 実施形態における調査カテゴリのテーブルを示す図。 実施形態における観察データのテーブルを示す図。 実施形態における調査計画と調査実施のテーブルを示す図。 他の実施形態における調査カテゴリと調査計画のテーブルを示す図。 他の実施形態における観察データ受信管理と集計管理のテーブルを示す図。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものでない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

［第１の実施形態］
図１は、実施形態における圃場調査システムのブロック構成図である。

調査員は、圃場において観察データを圃場調査装置102に入力する。入力された観察データは、ネットワーク104を介して情報処理装置101にアップロードされる。なお、圃場調査装置102は、通信手段とデータ入力手段を有する装置であり、典型的にはスマートフォンなどの端末でよい。

情報処理装置101は、ネットワーク104を介して観察データを受信し、受信した観察データを集計処理し、集計処理結果を公開する。

ワイン製造責任者や圃場管理者は、生育管理装置103を使い、ネットワーク104を介して情報処理装置101の集計結果を参照する。

図２は、図１のシステムにおける情報処理装置101のハードウェア構成を示す図である。情報処理装置101は、ＣＰＵ201、ＲＯＭ202、ＲＡＭ203、HDD204、通信インタフェース205、システムバス206を有している。

ＣＰＵ201は、中央演算装置(Central Processing Unit)であり、各種処理のための演算や論理判断等を行い、システムバス206に接続された各構成要素を制御する。ＲＯＭ(Read-Only Memory)202は、プログラムメモリであって、後述する各種処理手順を含むＣＰＵ201による制御のためのプログラムを格納する。ＲＡＭ(Random Access Memory)203は、ＣＰＵ201の主メモリ、ワークエリア等の一時記憶領域として用いられる。HDD204は、本実施形態に係る電子データやプログラムを記憶しておくための記憶デバイスである。

ＣＰＵ201は、ＲＯＭ202に格納されたプログラムを読み込んで実行することで、後述する各フローチャートに従った処理を実現する。そして、ＣＰＵ201は、各処理の実行結果をＲＡＭ202やHDD204に保存する。なお、ＲＯＭ202に格納されたプログラムをＲＡＭ202にロードすることで、プログラムメモリを実現しても構わない。補助記憶デバイス204に格納されたプログラムをＲＡＭ202にロードすることで、プログラムメモリを実現しても構わない。

通信インタフェース205は、公知の通信技術により、他の情報処理装置や通信機器、外部記憶装置等との間で双方向通信を行うインタフェースであり、有線、無線の種別は問わない。

図３は、ある調査における情報処理装置101のＣＰＵ201が実行する、観察データの集計処理を行うアプリケーションの処理手順を示すフローチャートである。このフローチャートでは、図６乃至図８に示すテーブルのデータを扱う。

図６は、実施形態における調査カテゴリのテーブルである。このテーブルは、予めHDD204またはROM202に登録、保持されており、必要に応じてRAM203やCPU201に読み込まれる。調査カテゴリのテーブルは、調査カテゴリID、調査目的、調査項目、集計タイミング判定条件、集計処理の計算方法のフィールドで構成されている。調査カテゴリIDは、調査の種別を特定するためのコードであり、他のフィールドはこのコードとの関係で定義されている。ここで、調査目的とは、成育度調査、収穫量予測調査、成熟度調査、病害虫調査といった、調査の目的を表す情報である。また、調査項目とは、植物の生育段階を判定する成育度調査や、成熟度調査の糖度、酸度や、病害虫調査の病気の種類、虫の種類といった調査対象の項目を表す情報である。さらに、集計タイミング判定条件とは、情報処理装置200が、圃場の面積に対してどの程度の面積に相当する観察データを受信したら集計処理を実行するのかを判定するための条件である。そして、集計処理の計算方法とは、調査目的や調査項目に応じて実施する集計処理の計算方法のことである。例えば、成育度調査であれば観察データの最頻値を算出する式のことである。収穫量予測調査であれば、各調査項目に応じた収穫量予測計算式のことである。成熟度のスポット調査であれば、各調査項目に対する平均値を算出する式のことである。病害虫の分布調査であれば、調査区画をメッシュ分割し、各メッシュに対する病害虫の状況を数値化する式のことである。例えば、各メッシュの最頻値を算出する。

図７は、観察データのテーブルである。 観察データは、観察データのID、調査項目、値、観察した位置（緯度、経度）、観察した時刻の情報からなる。ここで、調査項目とは、図６の調査項目のことである。

図８（ａ）は、調査計画のテーブルである。調査ごとに、調査単位を識別するための調査IDと、調査目的や調査項目を表す調査カテゴリIDを登録する。ここで、調査カテゴリIDは、図６の調査カテゴリIDのことである。完熟ぶどうを使うと、高級ワインを製造することができる。そこで、ワイン用ぶどう栽培では、収穫タイミングを見極めるために、成熟度調査を繰り返し行う。調査IDは、同一の調査カテゴリを複数回、繰り返し調査する場合に利用する。

図８（ｂ）は、調査実績のテーブルである。調査ごとに、調査IDと、調査を実施した調査日を管理する。ここで、調査IDは、図８（ａ）の調査IDのことである。

続いて、図３のフローチャートを参集して、情報処理装置101における観察データの集計処理を説明する。このフローチャートでは、上記の図６乃至図８に示すテーブルのデータを扱うことになる。

S3101にて、ＣＰＵ201は、図８（ａ）の調査計画データを受信し、HDD204に記憶する。

S3102にて、ＣＰＵ201は、図７の観察データまたは図８（ｂ）の調査実績データの受信を待つ。

S3103にて、ＣＰＵ201は、図７の観察データまたは図８（ｂ）調査実績データを受信し、HDD204に記憶する。

圃場調査装置102から情報処理装置101へは、任意のタイミングで、観察データや調査実績データをアップロードすることが可能である。そのため、情報処理装置101は、ある調査に対して複数回、データを受信することがある。ＣＰＵ201は、図８（ｂ）の調査実績データにおける同一の調査IDに対して、既に記録している調査日以外の調査日を追記する。図８（ｂ）の調査ＩＤ“T002”は、8/31（８月３１日）と9/1（９月１日）の二日間にわたって調査していることを示している。調査実績データは、それぞれの調査日ごとに２回に分けて受信する場合や、二日間の調査実績データを１回で受信する場合などがある。同一の調査日に、２台の圃場調査装置102で調査を実施している場合は、それぞれの圃場調査装置102から重複する調査日の調査実績データを受信することになるが、圃場調査装置102の調査日には、重複した調査日を排除して記録する。

ここで、観察データは、複数件をバッチで受信してもよいし、さらに、複数件の観察データと調査実績データをセットで受信する方式でもよい。データをバッチで受信したり、セットで受信したりすることにより、後述のＣＰＵ201による処理の実行回数を減らせるため、ＣＰＵ201の負荷を減らすことができる。

S3104にて、ＣＰＵ201はフィルタリング処理を行う。このフィルタリング処理では、前記調査カテゴリテーブル、前記調査計画テーブル、前記調査実績テーブルを用いて、集計処理に使う観察データのデータセットを取得する。

ここで、図４のフローチャートを用いて、S3104のフィルタリング処理の詳細を説明する。同図におけるS3201〜S3205のループを、ＣＰＵ201が、HDD204に記憶している観察データに対して実行することになる。

なお、観察データは数が多いため、図４の処理の前にフィルタリングする観察データの範囲を限定する処理を行い、フィルタリングをより効率的に実施してもよい。

例えば、ワイン用ぶどう栽培用のシステムでは、ビンテージごとに観察データの管理領域を分ける。また、ビンテージの期間を定義する。これらのビンテージ情報を用いた管理をすることで調査実績の調査日をもとに、観察データの管理領域を特定し、図４のフローチャートで対象とする観察データの範囲を限定する。

また、例えば、調査項目が独立になるように調査の大分類（収穫量予測調査、病害虫調査、成熟度調査、etc.）を定義し、調査カテゴリと調査の大分類を関連づけて管理する。そして、調査の大分類ごとに観察データの管理領域を分けて管理する。これらにより、図４のフローチャートで対象とする観察データの範囲を限定することが可能になる。

さらに、ビンテージと調査の大分類の両方を使って観察データの管理領域を分割管理して、図４のフローチャートで対象とする観察データの範囲を限定してもよい。

また、数が多い観察データに対するループを減らすために、調査実績がない場合は、フィルタリング処理のループを行わずに、フィルタリングした結果の観察データのデータセットを空のデータセットとしてもよい。

S3202にて、ＣＰＵ201は、観察データの観察時刻が、調査実績の調査日に含まれるかどうかを判定する。含まれると判定した場合、ＣＰＵ201はS3203に処理を進め、含まれないと判定した場合は終端のS3205に処理を進める。

S3203にて、ＣＰＵ201は、観察データの観察項目が調査計画における調査項目に含まれるかどうかを判定する。含まれると判定した場合、ＣＰＵ201は処理をS3204に進め、含まれないと判定した場合はループ終端のS3205に処理を進める。

S3204にて、ＣＰＵ201は、観察データを集計対象のデータセットに追加する。

ループ終端では、ＣＰＵ201は、HDD204に記憶している観察データに対してのループ処理が完了したかどうかを判定する。未処理の観察データが有る場合は、ループ開始S3201に戻り、同様の判定および処理を繰り返す。観察データに対するループ処理が完了した場合は、図４に示すサブフローを抜ける。なお、観察データをリレーショナルデータベースに格納している場合は、ループ処理ではなく、ＳＱＬを用いて集計処理に使うデータセットを１度に取得することが可能である。

図３のフローチャートの説明に戻る。S3105にて、ＣＰＵ201は、図６の集計タイミング判定条件と、S3104でフィルタリング処理した集計対象のデータセットを用いて、集計処理を実行するかどうかを判定する。集計タイミング判定条件は、調査カテゴリＩＤごとにあり、調査カテゴリＩＤは、S3101で受信した調査計画データの調査カテゴリＩＤにより特定される。ＣＰＵ201は、集計処理を実行するタイミングであると判定した場合は処理をS3106に進める。また、ＣＰＵ201は、集計処理を実行するタイミングではないと判定した場合は処理をS3102に戻し、観察データまたは調査実績データの受信を待つ。

ここで、図６の調査カテゴリID：C009の成熟度の分布調査を例に、図３のS3105の判定処理を、図５のフローチャートを参照して説明する。

S3301にて、ＣＰＵ201は、調査区画をメッシュに分割する。メッシュの縦の長さと横の長さは、畝の間隔、ぶどうの木の剪定方法、調査をどの程度の密度で行う必要があるのかを考慮して調整されたパラメータで、HDD204に予め記憶されている。また、調査区画の輪郭は、GeoJSON形式（JavaScript Object Notation (JSON) を基とした、GIS（Geographic Information System）データを記述するためのフォーマット）などの、緯度、経度の配列でHDD204に記憶されている。メッシュの縦の長さと横の長さに従って調査区画をメッシュ領域に分割し、各メッシュの頂点情報をGeoJSON形式などの、緯度、経度の配列でHDD204に保存する。

S3302からS3306のループは、S3301でメッシュ分割した各メッシュに対する処理である。S3303にて、ＣＰＵ201は、S3104でフィルタリングした観察データに対して、メッシュの中にあるのか、メッシュの外にあるのかを判定し、メッシュの中にある場合は、メッシュごとに用意したカウンタをカウントアップする。内外判定は、Crossing Number AlgorithmやWinding Number Algorithmなどを用いる。

S3304にて、ＣＰＵ201は、式（１）で、各メッシュの観察データのカウンタ値と、各メッシュに必要とする観察データの閾値を比較し、閾値以上の観察データ数があるかどうかを計算する。図６の例では、集計タイミング判定条件に従い、調査カテゴリIDの閾値は３である。

S3305にて、ＣＰＵ201は、判定結果をRAM203に保存する。ＣＰＵ201は、S3302からS3306のループを、調査区画の全メッシュに対して繰り返し実行することになる。

ステップS3307にて、ＣＰＵ201は、式（２）に従い、全メッシュ数に対して、S3304の判定で、観察データのカウント値の閾値以上であったメッシュの割合を算出する。

S3308にて、ＣＰＵ201は、式（３）で、カウント値が閾値以上のメッシュの割合がメッシュ割合の閾値以上かどうかを算出する。閾値以上の場合はtrue、閾値を下回る場合はfalseを応答する。図６の調査カテゴリＩＤ：Ｃ００９の例では、メッシュ割合の閾値は0.9である。図５の処理の応答がtrueの場合は、図３のS3105の判定はYESとなり、ＣＰＵ201は処理をS3106へ進める。一方、図５の処理の応答がfalseの場合は、図３のS3105の判定がNOとなり、ＣＰＵ201は処理をS3102に戻す。

S3106の集計処理は、S3104でフィルタリングした観察データのセットを、図６の各調査カテゴリに応じた集計処理の計算方法に従い処理する。集計処理の計算方法は、最頻値、平均値、収穫量予測式などがある。

S3107にてＣＰＵ201は、集計処理の計算結果をHDD204に保存する。

生育管理装置103からのネットワーク104を介した問い合わせがあった場合、情報処理装置101はHDD204に保存した最新の集計結果で応答することになる。同じ調査IDに対して集計処理を複数回実施した場合は、最後の集計結果を応答する。また、ある調査ＩＤに対する集計処理が一度も実施されていない場合に、問い合わせがあった場合は、未集計であることを応答する。

ここで、情報処理装置101が集計処理を実施し、その処理が完了した場合に、情報処理装置101から成育管理装置103に集計結果を通知する方式を用いてもよい。

ワイン用ぶどう栽培の調査は人手でなされることが多い。それ故、調査対象の圃場が広い場合は、複数人で分担して調査することになる。そして、各調査員は、それぞれの調査が完了すると観察データを情報処理装置にアップロードする。このような状況において、あるタイミングにおいては、情報処理装置が管理している観察データが不十分なデータセットの状態が生じてしまう。一方、ぶどうの生育状況や病害虫の被害状況には偏りがあり、不十分なデータセットをもとに集計すると、観察データに基づく集計結果と、実際の圃場の状況に乖離が生じてしまう。

第１の実施形態で説明した方法を用いることにより、観察データが、ぶどう栽培における調査カテゴリに応じたデータセットとして十分である状況において集計されるため、情報処理装置が管理している集計結果が誤った情報になることを防ぐことができるようになる。

また、従来手法では、誤った情報になることを防ぐためには、集計間隔を長くとる必要があった。これに対して、第１の実施形態では、データを受信するタイミングで集計タイミングを判定する。このため、従来手法とくらべて、情報処理装置がデータを受信してから、集計結果を公開するまでのタイムラグが短くなる。

また、第１の実施形態においては、観察データの位置情報を集計タイミングという時間情報に変換する手段を示した。ワイン用ぶどうは、圃場内で生育状況や病害虫の被害状況に位置的な偏りが生じることがある。このような、位置的な偏りが生じる農作物の調査において、位置情報を考慮して集計タイミングを決める方法は、従来手法の時間情報のみで集計タイミングを決める方法よりも、観察データのデータセットが十分であるかどうかを判定するのに有効である。

また、ワイン用ぶどう栽培においては、複数の調査を同時並行で計画、実施したり、１つの調査を複数の調査員で分担したりするため、圃場における調査の進捗管理が大変であった。これに対して、第１の実施形態で説明した方法を用いることにより、情報処理装置が自動で集計タイミングを判定し、判定結果に応じて集計処理するため、従来よりも圃場における調査の進捗管理が容易になる。

［第２の実施形態］
上記第１の実施形態では、各調査カテゴリＩＤに集計タイミング判定条件が１つある場合について説明した。しかし、図９（ａ）のように１つの調査カテゴリＩＤに対して複数の集計タイミング判定条件や集計処理の計算方法があってもよい。この場合、図３のS3105の判定処理、S3106及びS3107の処理は、各集計タイミング判定条件および対応する集計処理ごとに実施する。

これにより、１つの調査に対して複数の集計処理を行う場合、それぞれ異なる集計タイミングであった場合に、それぞれの集計処理に適したタイミングで集計処理が実施され、集計処理が完了した集計結果から順に参照できるようになる。

［第３の実施形態］
上記第１の実施形態では、各調査ＩＤに調査カテゴリＩＤが１つある場合について説明したが、ある調査で得た観察データを複数の調査目的のために利用する場合は、図９（ｂ）のように、１つの調査IDに対して複数の調査カテゴリIDを登録し管理する。ある調査を実施した場合、図９（ｂ）の調査に対応する調査カテゴリそれぞれに対して、図３のS3104のフィルタリング処理、S3105の集計タイミング判定処理、S3106の集計処理、S3107の集計結果の保存処理を行う。本実施形態の場合、日々の状況の分析という目的と、複数日にわたる大規模な調査という目的があった場合に、日々の状況がその日のうちに参照できるようになり、一方、大規模な調査は、調査が完了した段階で集計され参照できるようにすることができるようになる。

このうち、日々の状況の分析を目的とする集計は、上記各種テーブルに明示的に登録されることなく、常に行われるものとして運用されてもよい。すなわち、第1の実施形態に示した調査カテゴリに応じたタイミングで実行される集計と並行して、圃場調査装置１０２が情報処理装置１０１から観察データを受信するごとに日付単位の集計を実施し、集計結果を生育管理装置１０３に公開してもよい。

［第４の実施形態］
第１の実施形態では、集計タイミング判定条件に観察データの数を用いる方法について説明したが、本第４の実施形態では、圃場調査装置から観察データを受信したかどうかを判定条件に用いる方法について説明する。

図１０（ａ）は、圃場調査装置102から情報処理装置101への観察データの送信状況を管理するテーブルである。管理テーブルは、調査ID、圃場調査装置ID、データ受信状況で構成される。圃場調査装置102には、識別情報として圃場調査装置IDが割り当てられていて、調査の計画時に調査IDと圃場調査装置IDを登録する。この時点で、観察データは未受信のため、データ受信状況は、未受信を登録する。

図３のS3103にて観察データを受信すると、情報処理装置101のＣＰＵ201は、受信したデータの調査ID、圃場調査装置IDを参照し、対応するデータ受信状況の欄を“受信済”に更新する。S3105にて、ＣＰＵ201は、ある調査に対して、その全圃場調査装置のデータ受信状況が“受信済”であるかを判定する。ある調査における全てのデータ受信状況が“受信済”であれば、YESとなり、“未受信”が１つ以上あればNOに進む。YESの場合、NOの場合の処理は、第１の実施形態で述べた方法と同様である。

なお、第４の実施形態において、情報処理装置101の計算処理を効率的に行うため、S3104のフィルタリングとS3105の判定処理のタイミングの順序を入れ替えてもよい。第４の実施形態では、圃場調査装置102から情報処理装置101への観察データの送信状況を管理するテーブルを用いるため、S3105の判定処理を、１の実施形態よりも少ない計算量で行うことができる。順序を入れ替えた場合、S3105でNOと判定した場合は、S3104のフィルタリング処理を実施しないため、その分の計算量を削減することができる。

［第５の実施形態］
第５の実施形態では、圃場を複数の区画に分けて管理し、それぞれの区画に対して集計処理のタイミング判定する形態について説明する。

図１０（ｂ）は、各調査における情報処理装置101の集計状況を区画ごとに管理するためのテーブルである。調査ID、区画ID、集計状況で構成され、調査計画時に、調査IDとその調査が対象とする区画IDをテーブルに登録する。計画時点の集計状況は“未完”である。

図３のS3104、S3105、S3106、S3107を区画ごとに実施する。S3103にて、ＣＰＵ201は観察データを受信した際に、観察データが属する区画に対して、図１０（ｂ）の集計状況を“完了”に更新する。第５の実施形態では、S3107のあとに、図１０（ｂ）において対象とする調査IDに属する全ての区画IDの集計状況が“完了”になったかを判定する。対象の調査IDに属する全ての区画IDの集計状況が“完了”になった場合は終了へ進み、“未完”があれば、ＣＰＵ201は処理をS3102に戻し、“未完”の区画に対する観察データの受信を待つ。

第５の実施形態のように区画ごとに並列に集計を実施する方法は、各区画の収穫日を決定するための成熟度調査で効果がある。なぜなら、収穫日は、区画ごとに成熟度の時系列の変化を分析して決定する。そのため、区画に対して観察データが十分そろったタイミングで、区画単位で集計すると、全ての区画の観察データがそろってから集計するよりも、一部の区画で早く集計結果を参照することができるようになる。

以上説明したように本実施形態の技術を用いることで、ある調査目的の観察データを、不定期に複数回にわたって情報処理装置が受信する場合において、従来技術とくらべて、より適切な観察データのデータセットに対して、より適切なタイミングで自動的に集計処理できるようになる。

また、情報処理装置による集計タイミングの判定は、自動で行われるため、手動で集計タイミングを指示する方法にくらべて、圃場における調査の進捗管理や調査結果の集計が容易になる。

＜その他の実施形態＞
なお、図６の集計タイミング判定条件は、その代わりとして、機械学習された学習済みモデルを代わりに用いて判定しても良い。その場合には、例えば、その判定部への入力データと判定結果の組合せを学習データとして複数個準備し、それらの学習データから機械学習によって知識を獲得し、獲得した知識に基づいて入力データに対する判定結果を出力する学習済みモデルを生成する。学習済みモデルは、例えばニューラルネットワークモデルで構成可能である。そして、その学習済みモデルは、前記処理部と同等の処理をするためのプログラムとして、ＣＰＵあるいはＧＰＵなどと協働で動作することにより、前記処理部の処理を行う。なお、上記学習済みモデルは、必要に応じて一定の処理後に更新しても良い。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

101…情報処理装置、102…圃場調査装置、103…生育管理装置、104…ネットワーク

Claims (8)

1. 圃場における農作物に関する情報の管理および集計する情報処理装置であって、
   圃場調査装置から圃場における農作物の観察データを受信し、管理する管理手段と、
   該管理手段により管理している観察データから、集計対象の観察データをフィルタリングするフィルタリング手段と、
   前記管理手段による管理に基づき、集計タイミングとなったか否かを判定する判定手段と、
   該判定手段により集計タイミングとなったと判定された場合、外部からの観察データの問い合わせに対する最新の応答のために前記観察データの集計処理を実行する集計手段と
   を有することを特徴とする情報処理装置。
2. 前記圃場調査装置からのデータ受信状況を管理する第２の管理手段を更に有し、
   前記判定手段は、調査を実施するため圃場調査装置からのデータ受信状況に基づき集計タイミングを判定する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 農作物に対する観察すべき項目と、当該観察すべき項目の観察データが示す圃場の面積の閾値との関係を示すテーブルを保持する保持手段を更に有し、
   前記判定手段は、前記閾値以上の圃場の面積の観察データが前記管理手段に管理されている場合に、当該閾値以上となった観察すべき項目についての集計タイミングになったと判定する
   ことを特徴とする請求項１に記載の情報処理装置。
4. １つの調査に対して複数の集計処理を実施し、それぞれの集計処理に対して集計タイミング判定条件を有し、それぞれの集計タイミング判定条件の判定結果に応じて、それぞれの集計処理を実施することを特徴とする請求項１に記載の情報処理装置。
5. 圃場を複数の区画に分けて管理する第３の管理手段を更に有し、
   前記判定手段は、前記区画ごとに集計タイミングを判定し、
   前記集計手段は、区画ごとに集計処理を実行する
   ことを特徴とする請求項１に記載の情報処理装置。
6. 前記観察データは、位置情報を有し、
   前記判定手段は、観察データの位置情報に応じて、集計タイミングを判定する
   ことを特徴とする請求項１に記載の情報処理装置。
7. 圃場における農作物に関する情報の管理および集計する情報処理装置の制御方法であって、
   圃場調査装置から圃場における農作物の観察データを受信し、管理する管理工程と、
   該管理工程により管理している観察データから、集計対象の観察データをフィルタリングするフィルタリング工程と、
   前記管理工程による管理に基づき、集計タイミングとなったか否かを判定する判定工程と、
   該判定工程により集計タイミングとなったと判定された場合、外部からの観察データの問い合わせに対する最新の応答のために前記観察データの集計処理を実行する集計工程と
   を有することを特徴とする情報処理装置の制御方法。
8. コンピュータが読み込み実行することで、前記コンピュータに、請求項１乃至６のいずれか１項に記載の装置が有する手段として機能させるためのプログラム。

Images