"コンピュータに、前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第1の位置を認識し、前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な1台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識し、前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得し、前記1台以上の端末のうち少なくとも1台の端末について、当該端末の存在する第2の位置を認識し、前記第1の位置と前記第2の位置の間の距離を計算し、前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第1の指示を当該端末のユーザに対して与えるよう、第2の指示を与えることを含む処理を実行させるプログラム。前記データ記憶装置は、前記1台以上の端末それぞれのユーザのうち少なくとも1人が作業を行う領域に設置されており、前記プログラムが前記コンピュータに実行させる前記処理が、さらに、前記領域における前記作業のスケジュールを認識し、前記端末に前記第1の指示を与えさせる日または日時を、前記スケジュールに応じて決定し、前記第2の指示の与え方を制御することで、前記端末に、決定された前記日または前記日時に前記第1の指示を前記ユーザに与えさせる、ことを含むことを特徴とする請求項1に記載のプログラム。前記日または前記日時を決定する処理は、所定の基準よりも前記経過時間が長ければ、前記日または前記日時を決定する前記処理が行われる当日を、前記端末に前記第1の指示を与えさせる日として決定し、前記基準よりも前記経過時間が短ければ、前記スケジュールによって前記作業が計画されている日と計画されていない日の分布に基づいて、前記端末に前記第1の指示を与えさせる前記日または前記日時の延長期限を決定することを含むことを特徴とする請求項2に記載のプログラム。前記プログラムが前記コンピュータに実行させる前記処理が、さらに、前記作業の休憩時間に応じて決まる時刻に、前記端末に前記第1の指示を与えさせるように、前記第2の指示の与え方を制御することを含むことを特徴とする請求項3に記載のプログラム。情報処理装置であって、前記情報処理装置が収集する対象のデータを記憶しているデータ記憶装置が設置されている第1の位置を示す位置情報を記憶する記憶手段と、前記データ記憶装置と通信可能な1台以上の端末の各々との通信を行う通信手段と、前記データ記憶装置に記憶されていたデータを、前記1台以上の端末のいずれかと前記通信手段を介して過去に前記情報処理装置が収集した収集時点からの経過時間を認識し、前記経過時間が長いほど大きくなるように定義された閾値を、認識した前記経過時間に基づいて取得する取得手段と、前記1台以上の端末のうち少なくとも1台の端末について、当該端末の存在する第2の位置を認識する位置認識手段と、前記記憶手段から前記位置情報を読み出し、前記位置情報が示す前記第1の位置と、前記位置認識手段が認識した前記第2の位置との間の距離を計算する計算手段と、前記計算手段が計算した前記距離が、前記取得手段が取得した前記閾値未満のとき、前記計算手段が前記距離の計算に用いた前記第2の位置に存在すると前記位置認識手段により認識された当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第1の指示を当該端末のユーザに対して与えるよう、第2の指示を与える指示手段を備える情報処理装置。コンピュータが、前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第1の位置を認識し、前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な1台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識し、前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得し、前記1台以上の端末のうち少なくとも1台の端末について、当該端末の存在する第2の位置を認識し、前記第1の位置と前記第2の位置の間の距離を計算し、前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第1の指示を当該端末のユーザに対して与えるよう、第2の指示を与えることを特徴とする方法。ところで、ある種のデータ収集システムは、端末のユーザの関与を伴う。例えば、データ収集システムは、データを収集するコンピュータと、当該コンピュータが収集する対象のデータを記憶しているデータ記憶装置を含んでもよい。しかし、コンピュータとデータ記憶装置が通信することができるとは限らない。そこで、データ記憶装置およびコンピュータの双方と通信可能な端末が用いられてもよい。つまり、データ記憶装置からデータを一旦端末に転送し、その後、端末からデータをコンピュータに転送することで、データ記憶装置からコンピュータへのデータの収集が実現されてもよい。そして、端末を介した上記のようなデータ収集は、何らかの意味でのユーザの関与を伴う。例えば、ユーザは、端末に対する操作を行うことで、データ収集に関与するかもしれない。また、仮にデータ記憶装置から端末へのデータ転送や、端末からコンピュータへのデータ転送自体は自動的に行われるとしても、ユーザの関与は無ではない。例えば、端末をデータ記憶装置と通信可能な状態にするために、ユーザは端末を携帯してデータ記憶装置に接近するなどの行為を行うことで、データ収集に関与するかもしれない。つまり、端末を介した上記のようなデータ収集では、ユーザに何らかの手間が発生する。そして、データ収集に関与するための行為をユーザが自発的または偶発的に行うという可能性はあるが、ユーザが当該行為を適時に必ず行うという保証はない。そこで、端末は、データ収集に関与するための行為を行うように、ユーザに指示を与えてもよい。換言すれば、端末は、データ記憶装置に記憶されているデータの端末への転送のための指示をユーザに与えてもよい。ここで、上記に例示したような、目標物の位置と現在位置に応じた制御を利用して、目標物としてのデータ記憶装置の位置と端末の現在位置に応じて、端末がユーザに対して上記指示を与えることが考えられる。しかし、上記指示は、手間をかけることをユーザに要求する指示である。よって、上記指示を端末が濫発することは、ユーザに必要以上の負担をかけるおそれがあり、望ましくない。例えば、ある端末を介してデータ記憶装置からデータがコンピュータに収集された後、しばらくの間は、次の収集対象のデータがまだないまたは、少量しかデータ記憶装置に蓄積されていないかもしれない。そして、ユーザに対して上記指示を出すか否かという判断が、データ記憶装置と端末との間の距離に関する固定的な閾値に基づいてなされると仮定すると、結果的には指示が濫発されることになりかねない。例えば次の収集対象のデータがないという状況など、収集の緊急度が低い状況下では、固定的な閾値に基づく制御は、端末が不急の指示を必要以上に出してしまうという結果を招くおそれがある。他方、仮に上記のような指示の濫発を防ぐために、収集の緊急度の低い状況に合わせて固定的な閾値を定めると、別の問題が生じかねない。すなわち、たまたま、固定的な閾値で示される範囲内には1台も端末が存在しないという場合は、たとえ収集の緊急度が高くても、結果的には端末を介したデータ収集がすぐには行えないという事態に陥るおそれがある。そこで本発明の課題は、データ収集が端末のユーザの関与を伴う場合に、データの収集の緊急度とユーザの手間のバランスをとることである。一態様において提供されるプログラムは、コンピュータに以下の処理を実行させる。当該処理は、前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第1の位置を認識することを含む。また、当該処理は、前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な1台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識することを含む。さらに、当該処理は、前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得することを含む。また、当該処理は、前記1台以上の端末のうち少なくとも1台の端末について、当該端末の存在する第2の位置を認識し、前記第1の位置と前記第2の位置の間の距離を計算し、前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第1の指示を当該端末のユーザに対して与えるよう、第2の指示を与えることを含む。データ記憶装置からのデータの収集の緊急度は、過去にコンピュータがいずれかの端末を介してデータ記憶装置からデータを収集してからの経過時間が長いほど、高いと考えられる。なぜなら、経過時間が長ければ、コンピュータは最近のデータをまだ収集しておらず、したがって、最近のデータが表す最近の状況をコンピュータは把握していないからである。つまり、経過時間は、収集の緊急度の指標である。他方、第1の指示をユーザに与えることは、手間をかけることをユーザに要求することである。よって、第1の指示の濫発は好ましくない。換言すれば、第1の指示をユーザに対して与えるように端末に求める第2の指示の濫発は、好ましくない。しかし、上記プログラムによれば、経過時間が短ければ、データ記憶装置から近い端末にしか第2の指示が与えられず、経過時間が長いほど、データ記憶装置からより遠い端末に対しても第2の指示が与えられるようになる。つまり、経過時間が短ければ、データ記憶装置から近い端末のユーザにしか第1の指示が与えられず、経過時間が長いほど、データ記憶装置からより遠い端末のユーザも、第1の指示を与えられることになる。よって、上記プログラムによれば、収集の緊急度が低い場合つまり経過時間が短い場合は、収集の緊急度が高い場合つまり経過時間が長い場合と比べて、手間をかけることをユーザに要求する第1の指示が抑制される。すなわち、上記プログラムによれば、データの収集の緊急度と、ユーザの手間の間で、バランスをとることができる。以下、実施形態について、図面を参照しながら詳細に説明する。具体的には、まず、図1~12を参照して第1実施形態について説明する。次に、図13~20を参照して第2実施形態について、第1実施形態との違いを中心に説明する。最後に、その他の変形例についても説明する。図1は、第1実施形態の概要を説明する図である。図1のデータ収集システム100は、コンピュータ101とデータ記憶装置102と1台以上の端末を含む。図1では具体的には2台の端末103と104が例示されている。また、図1には、端末103を携帯するユーザ105と、端末104を携帯するユーザ106も図示されている。なお、図1にはデータ記憶装置102が1台しか図示されていないが、データ収集システム100は複数のデータ記憶装置102を含んでもよい。データ記憶装置102は、データを生成し、蓄積する。例えば、データ記憶装置102はセンサを有してもよく、センサが感知したデータを蓄積してもよい。データ記憶装置102は、センサ以外のモジュールによりデータを生成してもよい。つまり、データ記憶装置102が記憶するデータの種類は任意である。データ収集システム100は、データ記憶装置102に記憶されているデータをコンピュータ101が収集するシステムである。しかし、データ記憶装置102には、コンピュータ101と通信する機能がない。そこで、データ収集システム100においては、データ記憶装置102からコンピュータ101へのデータの収集が、端末例えば、端末103または104を介して行われる。端末103と104は、コンピュータ101と通信可能であり、データ記憶装置102とも通信可能である。したがって、データ記憶装置102に記憶されているデータは、データ記憶装置102から端末103に一旦転送され、端末103からコンピュータ101に転送されてもよい。もちろん、データは端末104を介してデータ記憶装置102からコンピュータ101に送られてもよい。いずれにしろ、データ収集システム100では、端末を介してコンピュータ101がデータ記憶装置102からデータを収集する。以下では説明の便宜上、端末103を介してデータが収集される場合を例として取り上げるが、端末103に関する説明は端末104についても同様に当てはまる。第1実施形態では、コンピュータ101と端末103の間の通信は、例えば3G3rdGeneration通信網などのネットワークを介して行われる。したがって、端末103は、物理的には必ずしもコンピュータ101の近傍に位置していなくても、不図示の基地局などを介してコンピュータ101と通信することができる。他方、第1実施形態における端末103とデータ記憶装置102の間の通信は、物理的にデータ記憶装置102と端末103が近くに位置することを前提とする種類の通信である。具体的には、データ記憶装置102と端末103の間の通信は、近距離無線通信か有線通信である。近距離無線通信の例は、例えば、以下のようなものである。IEEEInstituteofElectricalandElectronicsEngineers802.15シリーズの規格にしたがった通信。例えば、Bluetooth登録商標やZigBee登録商標などによる通信。UWBUltraWideBandによる無線通信。IEEE802.11シリーズの規格にしたがった無線LANLocalAreaNetwork通信。例えば、ISO/IEC18092やISO/IEC21481として規格化されているNFCNearFieldCommunicationなどの、近接場無線通信なお、ISOはInternationalOrganizationforStandardizationのこと、IECはInternationalElectrotechnicalCommissionのことである。赤外線や可視光線などを利用した光無線通信。また、有線通信の例は、例えば、USBUniversalSerialBusケーブルを介した通信である。近距離無線通信と有線通信のどちらが利用されるにしろ、端末103は、データ記憶装置102に近づかないとデータ記憶装置102と通信することができない。換言すれば、端末103とデータ記憶装置102の間の通信は、端末103のユーザ105の関与を伴う。具体的には、ユーザ105は、端末103を携帯してデータ記憶装置102に十分に接近するという行為を行うことで、端末103とデータ記憶装置102の間の通信に関与する。また、ユーザ105は、端末103とデータ記憶装置102の間をケーブルで接続するまたは通信開始のために端末103のボタンを押すなどの操作をさらに行うことで、端末103とデータ記憶装置102の間の通信に関与することもある。もちろん、近距離無線通信が使われる場合、データ記憶装置102と通信可能な範囲に端末103が入ったら、データ記憶装置102と端末103が自動的に通信を始めてもよく、その場合、ユーザ105の関与はデータ記憶装置102への接近行為だけでもよい。以上例示したようなデータ記憶装置102と端末103の間の通信への関与は、ユーザ105が自発的に行う可能性もある。また、ユーザ105が端末103を携帯したまま偶然データ記憶装置102の近くを通りかかる場合など、データ記憶装置102と端末103の間の通信に、ユーザ105が偶発的に関与することもある。しかしながら、ユーザ105が必ず適時にデータ記憶装置102と端末103の間の通信に関与するとは限らない。もちろん、データ記憶装置102からのデータの収集は、端末103ではなく端末104を介して行われてもよいので、データ収集のためには特定の1人のユーザ105の関与が必須というわけではない。しかし、端末104のユーザ106も、データ記憶装置102と端末104の間の通信に必ず適時に関与するとは限らない。そこで、第1実施形態では、データ記憶装置102からコンピュータ101へのデータ収集が適切に行われるようにするために、端末103がユーザ105に指示を与えるか、または、端末104がユーザ106に指示を与える。端末がユーザに与える指示は、具体的には、データ収集に関与するための行為を行うことをユーザに求める指示である。以下では説明の便宜上、端末がユーザに与える指示をアラームという。なお、データ収集に関与するための行為は、データ記憶装置102と端末の間の通信方法に応じて、上記のように、単にデータ記憶装置102に接近する行為だけであってもよい。あるいは、データ収集に関与するための行為は、ケーブルの接続操作またはボタン操作などの何らかのユーザ操作をさらに含んでもよい。しかし、以下では説明の簡単化のため、次のように仮定する。データ記憶装置102は、端末103および104との間で、近距離無線通信による通信を行う。データ記憶装置102は、通信可能な範囲内に入ってきた端末との間で自動的に通信を開始するので、ユーザはデータ記憶装置102への接近行為以外の行為を意識して行う必要はない。ところで、たとえユーザがデータ収集に関与するための行為が、データ記憶装置102への接近行為だけであったとしても、ユーザに手間が生じることには変わりない。例えば、端末104がユーザ106に対するアラームを出した場合、ユーザ106には遠くからわざわざデータ記憶装置102まで近寄るという手間が生じる。よって、端末104が必要以上にユーザ106に対してアラームを出すことは好ましくない。同様に、端末103が必要以上にユーザ105に対してアラームを出すことも好ましくない。換言すれば、データ収集の緊急度または必要性に応じて、アラームの発行が適切に制御されることが好ましい。例えば、データ記憶装置102からデータがコンピュータ101に収集された直後は、次のデータ収集を行う緊急度が比較的低い。よって、データ収集の緊急度が低ければアラームの発行を抑制するように、データ収集システム100が構成されることが好ましい。そこで、第1実施形態では、具体的にはコンピュータ101が以下のような制御を行うことで、データ収集の緊急度または必要性に応じた適度のアラームの発行が実現される。コンピュータ101は、データ記憶装置102が設置されている第1の位置を認識する。例えば、コンピュータ101は、第1の位置を記憶したデータベース以下DBと略すを参照することで、第1の位置を認識してもよい。また、コンピュータ101は、データ記憶装置102に記憶されていたデータを、いずれかの端末を介して過去にコンピュータ101が収集した収集時点からの、経過時間を認識する。例えば、コンピュータ101は、いずれかの端末を介してデータ記憶装置102からデータを収集するたびに、収集日時または収集日を適宜のDBに記憶してもよい。そして、コンピュータ101は、記憶した収集日時を現在時刻から引くことでまたは記憶した収集日を今日の日付から引くことで、経過時間を認識してもよい。さらに、コンピュータ101は、経過時間が長いほど大きくなるように定義された閾値を、経過時間に基づいて取得する。例えば、コンピュータ101は、経過時間と閾値を対応づけたDBを参照することにより、閾値を取得してもよい。コンピュータ101は、必要に応じて補間を行って閾値を取得してもよい。また、コンピュータ101は、経過時間を引数とする単調増加関数を用いて閾値を計算してもよい。以下では説明の便宜上、当該閾値をアラーム距離という。アラーム距離は、端末とデータ記憶装置102との間の距離に関する閾値である。具体的には、アラーム距離は、ユーザにアラームを出せという指示を、コンピュータ101が端末に与えるか否かの判断に使われる閾値である。図1には、データ記憶装置102を中心とし、アラーム距離を半径とする範囲以下アラーム範囲という107が図示されている。以上のようにして得られたアラーム距離を用いた処理は、具体的には以下のとおりである。コンピュータ101は、データ収集システム100に含まれる端末図1の例では端末103と104のうち少なくとも1台の端末について、当該端末の存在する第2の位置を認識する。例えば、端末103は、GPS機能を有してもよく、GPS機能により認識した端末103自体の位置をコンピュータ101に通知してもよい。端末104も同様にして、GPS機能により認識した端末104自体の位置をコンピュータ101に通知してもよい。すると、コンピュータ101は端末103と104の位置を認識する。コンピュータ101は、第1の位置つまりデータ記憶装置102の位置と第2の位置つまり個々の端末の位置の間の距離を計算する。例えば、コンピュータ101は、データ記憶装置102の位置と端末103の位置の間の距離を計算するとともに、データ記憶装置102の位置と端末104の位置の間の距離を計算する。なお、コンピュータ101が計算する距離は、ユークリッド距離直線距離でもよいし、緯度と経度を座標軸とするマンハッタン距離でもよい。また、コンピュータ101がある1台の端末例えば端末103について計算する距離は、ある1つの時点における当該端末の位置に基づく距離でもよいし、複数の時点における当該端末の位置に基づく距離でもよい。例えば、複数の時点における位置に基づいて得られる複数の距離の最小値もしくは平均値、または、複数の時点の平均位置から得られる距離などが利用可能である。そして、コンピュータ101は、計算した距離がアラーム距離未満の端末に対して、データ記憶装置102に記憶されているデータの当該端末への転送のための第1の指示つまりアラームを当該端末のユーザに対して与えるよう、第2の指示を与える。なお、計算した距離がちょうどアラーム距離と同じ端末に対してコンピュータ101が第2の指示を与えるか否かは、実施形態に応じて適宜方針が決められてよい。例えば、図1では、端末103がアラーム範囲107内に位置しており、端末104がアラーム範囲107外に位置している。つまり、データ記憶装置102と端末103の距離はアラーム距離より短いが、データ記憶装置102と端末104の距離はアラーム距離より長い。よって、図1の例では、コンピュータ101は、ステップS1において、ユーザ105に対してアラームを出せという指示以下、アラーム指示ともいうを端末103に与えるが、端末104に対しては特に指示を与えない。すると、ステップS2で端末103は、アラーム指示にしたがって、ユーザ105に対してアラームを出し、データ収集への関与をユーザ105に促す。よって、ステップS3でユーザ105は、アラームにしたがってデータ記憶装置102に近づく。その結果、端末103がデータ記憶装置102に十分に近づくと、端末103は、データ記憶装置102と通信可能な状態となる。すると、ユーザはデータ記憶装置102への接近行為以外の行為を意識して行う必要はないという上記仮定のとおり、ステップS4で自動的にデータ記憶装置102と端末103の間の通信が始まる。そして、データ記憶装置102に記憶されているデータが、端末103に転送される。その後、ステップS5で端末103からコンピュータ101へとデータが転送される。ステップS5の転送も、端末103が自動的に行ってよく、ユーザ105が意識的にボタン操作などを行わなくてもよい。以上のようにして、コンピュータ101は、端末103を介してデータ記憶装置102からデータを収集することができる。なお、ステップS5の転送は、ステップS4の直後に行われてもよいし、多少時間が経ってから行われてもよい。例えば、端末103の位置における電波状況が悪い場合には、端末103は、電波状況を監視し、電波状況が改善するまでステップS5の転送を待ってもよい。図1の例では、以上のようにして端末103を介したデータ収集が行われる一方で、アラーム範囲107外にある端末104は、コンピュータ101からアラーム指示を受けないので、ユーザ106に対してアラームを出さない。よって、ユーザ106は、データ記憶装置102と端末104の通信のために何かを行う必要がない。換言すれば、アラーム範囲107外にいるユーザ106は、データ記憶装置102と端末104の通信のために煩わされることがない。ところで、データ記憶装置102に近い位置にいるユーザほど、データ記憶装置102の位置まで移動するのにかかる手間は小さい。例えば、図1の例では、ユーザ105がデータ記憶装置102まで移動するのにかかる手間の方が、ユーザ106がデータ記憶装置102まで移動するのにかかる手間よりも小さい。よって、上記のように経過時間が長いほど大きくなるように定義されたアラーム距離をコンピュータ101が使うことで、データ収集システム100においては、データ収集の緊急度換言すれば必要性に応じて、アラームの発行が適切に制御される。つまり、コンピュータ101は、データ収集の緊急度が高いときには、ユーザの負担が大きくてもアラームが出されるように端末を制御するが、データ収集の緊急度が低いときには、負担が少ないユーザに対してのみアラームが出されるように端末を制御する。以上説明したデータ収集システム100の動作について、いくつかの評価軸を使って定性的にまとめると、図1の説明図108のとおりである。説明図108は、以下のことを示している。前回の収集からの経過時間が長いほど、データ記憶装置102から収集したデータに基づいてコンピュータ101が把握している状況は古く、また、データ記憶装置102の残り記憶容量は少ない。よって、前回の収集からの経過時間が長いと、コンピュータ101が、最近の状況を認識していないという意味でも、データ記憶装置102の記憶容量がもうすぐ使い尽くされてしまうという意味でも、データ収集の緊急度または必要性は高い。コンピュータ101が最近の状況を認識していないことは、例えば次のような問題を引き起こすおそれがある。例えば、コンピュータ101がデータ記憶装置102から収集したデータに基づいて何らかの制御を行うとする。この場合、コンピュータ101は、最近の状況を認識していないと、現状に合わない不適切な制御を行うおそれがある。また、データ記憶装置102の記憶容量が使い尽くされてしまうと、データ記憶装置102は、たとえ次の新たなデータを生成しても、生成したデータを記憶せずに破棄するかもしれない。あるいは、データ記憶装置102は、端末103または104を介してのコンピュータ101への収集がまだ済んでいなくても、古い方からデータを破棄することで最新のデータを記憶するための記憶領域を確保するかもしれない。いずれにしろ、コンピュータ101にとっては、一部のデータが、データ記憶装置102から収集できないまま失われてしまうことになる。以上のように、前回の収集からの経過時間が長いほど、データ収集の緊急度または必要性は高い。逆に、前回の収集からの経過時間が短ければ、データ収集の緊急度または必要性は比較的低い。そして、アラーム距離は、経過時間が長いほど、長くなるように定義されている。つまり、データ収集の緊急度または必要性が高ければ、データ記憶装置102から遠いユーザに対してもアラームが出される一方で、データ収集の緊急度または必要性が低ければ、データ記憶装置102に近いユーザにしかアラームが出されない。そして、データ記憶装置102から遠くにユーザがいるほど、データ記憶装置102までユーザが移動する手間は大きい。つまり、アラーム距離が長いほど、アラームを受けたユーザの負担が大きい傾向がある。もちろん、閾値であるアラーム距離が長くても、たまたまデータ記憶装置102のすぐ近くにユーザがいれば、当該ユーザの負担は小さい。しかし、アラームを受けたユーザの負担の期待値は、アラーム距離が長いほど、大きい。以上のように、コンピュータ101は、データ収集の緊急度または必要性が高ければ、ユーザの負担が大きくてもやむを得ないと判断し、ユーザにかかる負荷よりもデータ収集を優先する制御を行う。逆に、データ収集の緊急度または必要性が低ければ、コンピュータ101は、ユーザの負担が小さければ、データ収集のためにユーザに協力してもらうが、ユーザの負担が大きければデータ収集を今すぐ行う必要はないと判断する。つまり、データ収集の緊急度または必要性が低ければ、コンピュータ101は、データ収集よりもユーザにかかる負荷の軽減を優先する制御を行う。その結果、データ収集システム100においては、データ収集の緊急度または必要性と、データ収集に関与するためにユーザにかかる負荷との間で、均衡がとれる。続いて、具体的なユーザの動きの例を示す図2を参照して、図1に示したデータ収集システム100の利点についてさらに詳しく説明する。図2には、圃場201におけるユーザの動きの例が示されている。図1のデータ記憶装置102は、具体的には、例えば、圃場201内に設置されたセンサユニット202であってもよい。センサユニット202は、データを取得するための1つ以上のセンサと、人感センサ例えば赤外線センサなどを有する。つまり、図2の例では、コンピュータ101が収集する対象のデータは、センサユニット202が有するセンサが生成したデータである。センサユニット202はバッテリで駆動される。よって、通信による電力消費を抑えるために、センサユニット202は、通信機能を通常はオフにしている。ここで、通信による電力消費と比べて、人感センサによる電力消費は少ない。よって、センサユニット202は、人感センサをオンにしておく。そして、人感センサがユーザを検知したら、センサユニット202は、通信機能をオンにして、ユーザが携帯する端末と通信する。しかし、圃場201は広く、人感センサがユーザを検知することのできる検知領域203は、圃場201のごく一部である。よって、端末がアラームを出さなければ、ユーザが誰も検知領域203内に入ってこないかもしれない。例えば、図2に示すように、ある日、ユーザ204は軌跡205に沿って移動しながら除草などの作業を行い、同様に、ユーザ206は軌跡207に沿って移動しながら作業を行う。しかし、この日の作業は、軌跡205と207が通る範囲でのみ行われ、非作業領域208では何の作業も行われない。すると、非作業領域208の一部でしかない検知領域203には、ユーザ204が作業中に入ってくることもないし、ユーザ206が作業中に入ってくることもない。よって、もしユーザ204と206がそれぞれ携帯する端末図2には不図示のいずれもアラームを出さなければ、図2の作業が行われる日には、センサユニット202から端末を介して図1のコンピュータ101へとデータが収集されることはない。ここで、もし、図2の作業が行われる日におけるデータ収集の緊急度が低ければ、コンピュータ101へのデータ収集がこの日に行われなくても問題ない。また、データ収集の緊急度が低ければ、センサユニット202から遠く離れて作業しているユーザ204や206に作業を中断させて、データ収集への関与のための行動をとらせ、作業効率を落とすよりも、データ収集を後日に延期する方が好ましい。他方、もし、図2の作業が行われる日におけるデータ収集の緊急度が高ければ、ユーザ204または206にセンサユニット202へと接近する手間を生じさせてでも、コンピュータ101がセンサユニット202からデータを収集することが好ましい。そして、図1を参照して説明したコンピュータ101の制御によれば、データ収集の緊急度に応じたアラーム距離に基づいて、適切にアラームが発行される。よって、ユーザ204と206のどちらも作業自体のためには非作業領域208に入ることがないとしても、データ収集の緊急度が高ければ、例えばユーザ206が携帯する端末がアラームを発するので、ユーザ206の端末を介したデータ収集が可能となる。続いて、図1のデータ収集システム100について、図3~12を参照してより詳細に説明する。なお、図3はブロック構成図、図4はハードウェア構成図、図5~8はDBの例を示す図、図9は動作シーケンス図、図10~12はフローチャートである。さて、図3は、第1実施形態のセンサデータ収集システムのブロック構成図である。図3のデータ収集システム300は、図1のデータ収集システム100のより具体的な例である。データ収集システム300は、サーバ310と、1台以上のセンサユニットと、1台以上の端末を含む。サーバ310は、図1のコンピュータ101の具体例であり、コンピュータ101と同様に動作する。例えば、汎用的な情報処理装置が、サーバ310として利用可能である。また、図3には、3台のセンサユニット350a~350cが例示されているが、センサユニットの数は任意である。紙面の都合上、図3ではセンサユニット350aのみ内部の詳細が図示されているが、センサユニット350bと350cも、センサユニット350aと同様に構成される。以下では、センサユニット350a~350cを区別する必要がない場合は、後述の図4に示すように350という参照符号を用いることもある。センサユニット350は、図1のデータ記憶装置102の具体例である。なお、図2のセンサユニット202も、センサユニット350と同様に構成されているものとする。さらに、図3には、3台の端末370a~370cが例示されているが、端末の数は任意である。紙面の都合上、図3では端末370aのみ内部の詳細が図示されているが、端末370bと370cも、端末370aと同様に構成される。以下では、端末370a~370cを区別する必要がない場合は、後述の図4に示すように370という参照符号を用いることもある。端末370は、図1の端末103の具体例でもあり、図1の端末104の具体例でもある。また、図2では端末の図示が省略されているが、図2のユーザ204と206も、それぞれ端末370と同様の端末を携帯しているものとする。さて、サーバ310は、端末に関連して、GPSログDB311、端末管理DB312、およびGPSログ処理部313を有する。また、サーバ310は、センサユニットからの端末を介したデータ収集に関連して、収集日DB314とセンサログDB315とセンサログ処理部316を有し、センサユニットの管理のためのセンサ位置DB317とセンサ種別DB318を有する。そして、データ収集の緊急度とユーザの負荷のバランスをとるために、サーバ310は、センサユニット別アラーム条件DB319、アラーム条件DB320、サンプリング周期DB321、およびデータ量条件DB322を有する。また、データ収集の緊急度とユーザの負荷のバランスをとるために、サーバ310は、さらに、アラーム距離決定部323、端末センサ間距離計算部324、距離比較部325、およびアラーム決定部326を有する。また、サーバ310は、端末との通信のために通信部327も有する。以上のサーバ310内の各部についてより詳しく述べれば、以下のとおりである。GPSログDB311は、端末370の位置を示すGPSログを、端末370の識別子と対応づけて記憶するDBである。GPSログDB311の具体的なデータ例は図8とともに後述する。端末管理DB312は、各端末370に関する情報例えば、端末370のユーザの属性などを記憶するDBである。端末管理DB312の具体的なデータ例は図5とともに後述する。ところで、GPSログは、各端末370からサーバ310へと送信され、サーバ310の通信部327で受信され、通信部327からGPSログ処理部313に出力される。すると、GPSログ処理部313は、通信部327から受け取ったGPSログを、送信元の端末370の識別子と対応づけて、GPSログDB311に格納する。つまり、GPSログ処理部313と通信部327は、協働して、端末370の存在する位置を認識する位置認識手段として動作する。収集日DB314は、各センサユニット350について、当該センサユニット350からデータを最後に収集した日付を記憶するDBである。収集日DB314の具体的なデータ例は図7とともに後述する。センサログDB315は、いずれかの端末370を介してセンサユニット350から収集されたデータを、端末370の識別子と対応づけて記憶するDBである。以下ではセンサユニット350から端末370を介してサーバ310が収集する対象のデータをセンサログともいう。なお、端末370がサーバ310に送信するセンサログは、端末370がどのセンサユニット350から元のセンサログを取得したかを示すための、センサユニット350の識別子を含むように、端末370によって加工されたデータである。したがって、センサログDB315の各エントリは、端末370の識別子だけでなく、センサユニット350の識別子も含む。センサログDB315のより具体的なデータ例は、図7とともに後述する。ところで、いずれかの端末370からサーバ310へ送信されたセンサログは、サーバ310の通信部327で受信され、通信部327からセンサログ処理部316に出力される。すると、センサログ処理部316は、通信部327から受け取ったセンサログを、送信元の端末370の識別子と対応づけて、センサログDB315に格納する。センサ位置DB317は、各センサユニット350が設置された位置を記憶するDBである。つまり、センサ位置DB317は、センサユニット350が設置されている位置を示す位置情報を記憶する記憶手段の具体例である。センサ位置DB317の具体的なデータ例は図5とともに後述する。センサ種別DB318は、各センサユニット350に搭載されているセンサの種別を記憶するDBである。センサ種別DB318の具体的なデータ例は図5とともに後述する。センサユニット別アラーム条件DB319は、各センサユニット350についてのアラーム距離の取得の仕方を規定するためのDBである。換言すれば、センサユニット別アラーム条件DB319は、経過時間に応じたアラーム距離を定義する条件以下ではアラーム条件というと、センサユニット350とを対応づけるためのDBである。図1に関して説明したとおり、アラーム距離は、センサユニット350からデータつまりセンサログを前回収集してからの経過時間に依存して決まる閾値である。そして、詳しくは図6のデータ例とともに後述するが、経過時間とアラーム距離との間の関係は、センサユニット350ごとに異なっていてもよい。つまり、経過時間の長さが同じでも、異なるセンサユニット350に対して異なるアラーム距離が定義されてもよい。センサユニット別アラーム条件DB319は、以上のようなセンサユニット350に応じたアラーム距離の違いを管理するためのDBである。アラーム条件DB320は、経過時間とアラーム距離との間の関係を規定するDBである。アラーム条件DB320の各エントリは、経過時間からアラーム距離を得るための1つの方法を規定する1つのアラーム条件を表す。なお、アラーム条件DB320の具体的なデータ例は図6とともに後述する。サンプリング周期DB321は、各センサユニット350内の各センサのサンプリング周期を記憶するDBである。つまり、サンプリング周期DB321には、各センサが計測を行って計測結果のデータを生成する周期が記憶されている。サンプリング周期DB321の具体的なデータ例は図6とともに後述する。後述のとおり、サンプリング周期DB321は、サーバ310がセンサユニット別アラーム条件DB319に適切な値を予め設定しておくために利用される。データ量条件DB322は、1日あたりにセンサユニット350が生成するデータの量の範囲ごとに、推奨されるアラーム条件を規定するDBである。後述のとおり、データ量条件DB322も、サーバ310がセンサユニット別アラーム条件DB319に適切な値を予め設定しておくために利用される。アラーム距離決定部323は、各センサユニット350について、当該センサユニット350に関するアラーム距離を決定する。具体的には、アラーム距離決定部323は、収集日DB314とセンサユニット別アラーム条件DB319とアラーム条件DB320を参照して、アラーム距離を決定する。つまり、アラーム距離決定部323は、アラーム距離を取得する取得手段の具体例である。端末センサ間距離計算部324は、GPSログDB311とセンサ位置DB317を参照して、注目している端末370と注目しているセンサユニット350の間の距離を計算する。距離比較部325は、端末センサ間距離計算部324が計算した距離を、アラーム距離決定部323が決定したアラーム距離と比較する。アラーム決定部326は、距離比較部325による比較結果に応じて、端末370にアラーム指示を出すか否かを決定するとともに、アラーム指示の対象のセンサユニット350を決定する。例えば、センサユニット350aと端末370aの間の距離は、センサユニット350aに関するアラーム距離以下であるという比較結果を距離比較部325が得たとする。この場合、アラーム決定部326は、センサユニット350aについてのアラーム指示を端末370aに出すことを決定する。また、アラーム決定部326は、決定にしたがって、通信部327にアラーム指示を送信させる。つまり、距離比較部325とアラーム決定部326と通信部327は、協働して、計算手段としての端末センサ間距離計算部324が計算した距離がアラーム距離以下の端末370にアラーム指示を与える指示手段として機能している。通信部327は、端末370との間の通信を行う。例えば、通信部327は、ネットワークを介して端末370からGPSログやセンサログを受信する。また、通信部327は、アラーム決定部326の決定にしたがい、ネットワークを介して端末370にアラーム指示を送信する。さて、センサユニット350a~350cは、図2のセンサユニット202と同様に、圃場201の内部などの予め決められた場所に設置される。センサユニット350a~350cの各々は、各種センサ351、センサログDB352、センサログ処理部353、および通信部354を有する。各種センサ351は、サーバ310が収集する対象のデータを生成する1つ以上のセンサと、図2に関して説明した人感センサを含む。例えば、各種センサ351は、温度センサ、湿度センサ、または画像センサを含んでもよいし、他の種類のセンサを含んでもよい。センサログDB352は、各種センサ351が生成したデータを記憶するDBである。センサログDB352の具体的なデータ例は図7とともに後述する。センサログ処理部353は、各種センサ351が生成したデータをセンサログDB352に格納する。また、センサログ処理部353は、端末370a~370cのいずれかが人感センサの検知領域に入ってきたときに、通信部354をオンにして、センサログDB352内のデータを、通信部354を介して当該端末に送信する。センサログ処理部353は、送信済みのデータをセンサログDB352から消去してもよい。通信部354は端末370との間の通信を行う。図1に関して説明したように、第1実施形態では、図1のデータ記憶装置102と端末103が近距離無線通信により通信を行うものと仮定している。つまり、通信部354は、端末370との間で、例えばBluetooth登録商標などの近距離無線通信による通信を行う。なお、通信部354は、図2のセンサユニット202に関して説明したとおり、消費電力抑制のために、普段はオフにされており、必要に応じてセンサログ処理部353によりオンにされる。さて、端末370a~370cの各々は、例えば、携帯電話、スマートフォン、タブレット端末、モバイルPCPersonalComputerなどの端末である。端末370a~370cの各々は、GPS情報取得部371、GPSログDB372、サーバ通信部373、アラーム処理部374、センサ通信部375、センサログDB376、およびセンサログ処理部377を有する。GPS情報取得部371は、GPS衛星からの測位信号を受信することで、端末370の位置を示すGPS情報を取得する。そして、GPS情報取得部371は、取得したGPS情報をGPSログDB372に格納する。なお、GPSログDB372の具体的なデータ例は図8とともに後述する。サーバ通信部373は、ネットワークを介して、サーバ310より具体的には通信部327との間の通信を行う。例えば、端末370のサーバ通信部373とサーバ310の通信部327との間の通信は、3G通信網とインターネットを介して行われてもよい。アラーム処理部374は、サーバ310からサーバ通信部373を介してアラーム指示を受け取り、アラーム指示にしたがってユーザにアラームを出す。なお、アラームは、ブザーその他の音声的なものでもよいし、振動などの触覚的なものでもよいし、ディスプレイへのメッセージ表示などの視覚的なものでもよいし、それらの組み合わせでもよい。センサ通信部375は、センサユニット350より具体的には通信部354との間の通信を行う。図1に関して説明したように、第1実施形態では、図1のデータ記憶装置102と端末103が近距離無線通信により通信を行うものと仮定している。つまり、センサ通信部375は、センサユニット350の通信部354との間で、例えばBluetooth登録商標などの近距離無線通信による通信を行う。センサログDB376は、センサユニット350から受信したデータを一時的に記憶するDBである。なお、センサログDB376の具体的なデータ例は図7とともに後述する。センサログ処理部377は、センサログDB352に記憶されているデータを、センサ通信部375を介してセンサユニット350から受信し、受信したデータをセンサログDB376に格納する。また、センサログ処理部377は、センサユニット350からデータを受信し終わると、センサログDB376に格納したデータを、今度はサーバ通信部373を介してサーバ310に送信する。続いて、図3の各ブロックを実現するハードウェア構成について、図4を参照して説明する。サーバ310は、CPUCentralProcessingUnit401、RAMRandomAccessMemory402、およびHDDHardDiskDrive403を有する。また、サーバ310は、ネットワークIFinterface404、機器IF405、ディスプレイIF406、および駆動装置407を有する。そして、サーバ310内の上記各部は互いにバスで接続されている。CPU401は、プログラムをRAM402にロードし、RAM402をワーキングエリアとしても使いながら、プログラムを実行する。また、HDD403は、プログラムや各種DBを保持する。ネットワークIF404は、例えば、有線LANまたは無線LANのインタフェイスである。ネットワークIF404を介してサーバ310はネットワーク411に接続される。ネットワーク411は、例えば、LAN、インターネット、3G通信網の組み合わせであり、ネットワーク411を介してサーバ310と端末370は接続される。機器IF405は、入力機器をサーバ310に接続するインタフェイスである。入力機器の例として、図4には、キーボード412とマウス413が例示されているが、その他のポインティングデバイスが機器IF405に接続されてもよい。また、ディスプレイIF406は、ディスプレイ414をサーバ310に接続するインタフェイスである。ディスプレイ414は視覚的な出力機器の例である。サーバ310には、さらに、スピーカなどの音声的な出力機器が、適宜のインタフェイスを介して接続されていてもよい。駆動装置407は、コンピュータ読み取り可能な記憶媒体415の駆動装置である。記憶媒体415の例は、CDCompactDisc、DVDDigitalVersatileDiscなどの光ディスク、光磁気ディスク、磁気ディスク、半導体メモリを用いたメモリカードなどである。CPU401が実行するプログラムは、例えば、予めHDD403にインストールされていてもよいし、ネットワーク411とネットワークIF404を介してHDD403にダウンロードされてもよい。あるいは、プログラムは、記憶媒体415に記憶されて提供され、駆動装置407を介して読み取られ、HDD403にインストールされてもよい。なお、記憶媒体415、RAM402、およびHDD403は、いずれも、コンピュータ読み取り可能で有形のtangible媒体の例である。記憶媒体415、RAM402、およびHDD403は、信号搬送波のような一時的なtransitory媒体ではない。また、サーバ310に関して、図3と図4の関係を説明すると以下のとおりである。図3のサーバ310が保持するDBのうち、静的なDBは、予めHDD403に記憶され、必要に応じてRAM402にデータが読み込まれる。具体的には、端末管理DB312、センサ位置DB317、センサ種別DB318、センサユニット別アラーム条件DB319、アラーム条件DB320、サンプリング周期DB321、およびデータ量条件DB322は、予めHDD403に記憶される。また、動的にエントリが増えるGPSログDB311とセンサログDB315も、HDD403に記憶されていてもよい。なお、データ収集のたびに書き換えられる収集日DB314は、HDD403に記憶されていてもよいし、RAM402に記憶されていてもよい。そして、GPSログ処理部313、センサログ処理部316、アラーム距離決定部323、端末センサ間距離計算部324、距離比較部325、およびアラーム決定部326は、CPU401がプログラムを実行することにより実現される。また、通信部327は、ネットワークIF404により実現される。ここで図4の説明に戻る。センサユニット350は、バッテリ421によって駆動され、MPUMicroprocessorUnit422、RAM423、およびフラッシュROMReadOnlyMemory424を有する。なお、図4では紙面の都合上、バッテリ421とMPU422のみが線で結ばれているが、センサユニット350内の各部へは、いずれもバッテリ421から電力が供給される。MPU422は、プログラムをRAM423にロードし、RAM423をワーキングエリアとしても使いながら、プログラムを実行する。また、フラッシュROM424は、プログラムや各種DBを保持する。フラッシュROM424の代わりにあるいはフラッシュROM424と組み合わせて、HDDなどの他の種類の不揮発性記憶装置が使われてもよい。また、センサユニット350は、必要に応じて、適宜の種類の適宜の個数のセンサを有し、各センサはセンサIFを介してMPU422に接続される。図4の例では、具体的には、センサユニット350は、温度センサ425、湿度センサ426、温度センサ427、および人感センサ428を有する。センサユニット350は、さらに、センサIF429~433を有する。なお、紙面の都合上、図4には5個のセンサIF429~433のみが図示されているが、センサユニット350は6個以上のセンサIFを有していてもよいし、4個以下のセンサIFを有していてもよい。そして、温度センサ425はセンサIF429を介して、湿度センサ426はセンサIF430を介して、温度センサ427はセンサIF431を介して、人感センサ428はセンサIF432を介して、それぞれMPU422に接続されている。他方、センサIF433は余っており、センサIF433には何のセンサも接続されていない。センサユニット350はさらに、端末370との間で近距離無線通信を行う近距離無線通信機434を有する。電力消費を抑えるため、MPU422は、バッテリ421から近距離無線通信機434への電力供給を制御することが望ましい。また、センサユニット350に関して、図3と図4の関係を説明すると以下のとおりである。図3の各種センサ351は、具体的には、例えば、図4の温度センサ425、湿度センサ426、温度センサ427、および人感センサ428を含んでもよい。また、センサログDB352は、フラッシュROM424に記憶される。そして、センサログ処理部353は、MPU422がプログラムを実行することにより実現される。また、通信部354は、近距離無線通信機434により実現される。ここで図4の説明に戻る。端末370は、バッテリ441によって駆動され、MPU442、RAM443、およびフラッシュROM444を有する。なお、図4では紙面の都合上、バッテリ441とMPU442のみが線で結ばれているが、端末370内の各部へは、いずれもバッテリ441から電力が供給される。MPU442は、プログラムをRAM443にロードし、RAM443をワーキングエリアとしても使いながら、プログラムを実行する。また、フラッシュROM444は、プログラムや各種DBを保持する。フラッシュROM444の代わりにあるいはフラッシュROM444と組み合わせて、HDDなどの他の種類の不揮発性記憶装置が使われてもよい。また、端末370は、センサユニット350との間で近距離無線通信を行う近距離無線通信機445を有し、GPS衛星から測位信号を受信してGPS情報を取得するGPS受信機446も有する。端末370はさらに、3G通信網つまりネットワーク411の一部を介した通信を行う3G通信機447を有する。また、端末370は、ユーザインタフェイス用の1つ以上の装置を有する。具体的には、図4の例では、端末370は、ユーザインタフェイス用にLEDLightEmittingDiode448、ブザー449、振動モータ450、およびディスプレイ451を有する。もちろん、端末370は、例えばボタンやキーボードなどの入力機器をさらに有していてもよいし、スピーカとマイクをさらに有していてもよい。また、ディスプレイ451がポインティングデバイスを兼ねていてもよいつまり、ディスプレイ451がタッチスクリーンであってもよい。また、端末370に関して、図3と図4の関係を説明すると以下のとおりである。GPS情報取得部371はGPS受信機446により実現され、GPSログDB372はフラッシュROM444に記憶される。また、サーバ通信部373は3G通信機447により実現される。なお、実施形態によっては、3G通信機447が、複数の基地局からの受信電波強度と、それら複数の基地局の既知の位置に基づいて、端末370の位置を計算することで、GPS情報取得部371と類似の機能を実現してもよい。アラーム処理部374は、プログラムを実行するMPU442と、MPU442の制御にしたがってアラームを発するモジュールつまり、LED448、ブザー449、振動モータ450、およびディスプレイ451のうちの少なくとも1つにより、実現される。そして、センサ通信部375は近距離無線通信機445により実現され、センサログDB376はフラッシュROM444に記憶される。また、センサログ処理部377は、MPU442がプログラムを実行することにより実現される。ところで、図1のデータ収集システム100が図2の圃場201に適用される場合に、具体的には図3~4のような構成が好適である理由について説明すれば、以下のとおりである。図1のデータ記憶装置102を図2の圃場201のような広い屋外に設置する場合、金銭的なコストの観点から、コンピュータ101と通信する機能をデータ記憶装置102に実装することが難しいことが多い。その理由は次のとおりである。屋外に設置される装置がコンピュータ101と通信するには、例えば、3G通信網による通信機能または無線LANによる通信機能を利用することが考えられる。しかし、3G通信網による通信機能を利用するには、電話会社等の通信プロバイダとの契約料金がかかり、通信料金もかかる。また、無線LANによる通信機能を利用するには、中継用のアクセスポイントを設置する必要がある。しかし、例えば非常に広い範囲に散在する複数の圃場に複数のセンサユニットを設置しようとする場合、多数のアクセスポイントが必要になるかもしれず、中継用のインフラストラクチャの整備および保守にかかる金銭的人的なコストは、実用上は無視し難い。よって、実用上、コンピュータ101と通信する機能をデータ記憶装置102に実装することが難しい場合がある。他方、近年では農業に従事する作業者の多くが、携帯電話やスマートフォンなどの3G通信機能を備えた端末を作業中にも携帯しており、何らかの端末のユーザでもある。よって、コンピュータ101つまりサーバ310との間の通信は、ユーザが携帯する端末の機能を使うことで、新たな金銭的コストをそれほどかけずに実現可能である。また、近年の携帯電話やスマートフォンなどの端末は、GPS機能を有するものが多い。よって、ユーザの持つ既存の端末にプログラムをインストールすることで、図3の端末370の機能を実現することができる。すなわち、端末370の導入に関するコストは低い。さらに、近年の携帯電話やスマートフォンなどの端末の多くは、近距離無線通信機能も有する。よって、既存の近距離無線通信機能を、端末とデータ記憶装置102つまりセンサユニット350の間の通信のために利用することができる。そして、近距離無線通信であれば、当然アクセスポイントなどのインフラストラクチャは不要である。よって、センサユニット350に近距離無線通信機能を持たせても、データ収集システム300全体としてはさほど導入コストはかからない。また、有線通信と比べた近距離無線通信の利点の一つは、ユーザにケーブルを接続するなどの意識的な操作をさせなくても、装置同士例えば端末370とセンサユニット350が自動的に通信を開始することが可能なことである。つまり、図4に示すように近距離無線通信を端末370とセンサユニット350の間の通信に利用することで、ユーザがデータ収集に関与するための負荷を軽減することができる。したがって、図3~4のシステム構成は、データ収集システム300の導入と保守にかかる金銭的人的なコストの観点からも、ユーザの負荷軽減という観点からも、圃場201のような広い屋外での利用に好適である。続いて、図5~8を参照して、データ収集システム300内の各種DBの例について説明する。図5~6は、サーバ310が保持する静的なDBの例を示す図である。図5に示すように、端末管理DB312の各エントリは、データ収集システム300内の各端末370に対応し、端末IDとユーザ氏名というフィールドを有する。端末IDは、データ収集システム300内で端末370を一意に識別する識別子IDidentifierを示し、作業者名は、端末IDで識別される当該端末370を携帯するユーザの氏名を示す。図5の例によれば、端末IDが0001の端末370のユーザは山田太郎という氏名であり、端末IDが0002の端末370のユーザは佐藤二郎という氏名である。端末管理DB312の各エントリは、端末370とユーザを管理するための他のフィールド例えば、端末370で利用可能な電子メールアドレスや、ユーザの属性などのフィールドをさらに含んでもよい。端末管理DB312は、例えば、端末370がディスプレイ451に表示するアラームの内容を指定するために、サーバ310のアラーム決定部326により参照されてもよい。なお、端末管理DB312は静的なDBだが、端末370が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存の端末370の設定の変更または端末370のユーザの属性の変更などがあれば、それに応じて既存のエントリが変更される。また、図5に示すように、センサ位置DB317の各エントリは、データ収集システム300内の各センサユニット350に対応し、センサユニットIDと緯度と経度というフィールドを有する。センサユニットIDは、データ収集システム300内でセンサユニット350を一意に識別する識別子を示す。また、緯度と経度は、センサユニットIDで識別される当該センサユニット350が設置された場所を示す。図5の例によれば、センサユニットIDが0001のセンサユニット350は、北緯35.44354度東経139.3141度の場所に設置されている。また、センサユニットIDが0002のセンサユニット350は、北緯35.43989度東経139.3095度の場所に設置されている。図5には、他にもセンサユニットIDが0003と0010のセンサユニット350についてのエントリが例示されている。なお、センサ位置DB317は静的なDBだが、センサユニット350が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のセンサユニット350が移動されれば、それに応じて既存のエントリが変更される。また、図5に示すように、センサ種別DB318の各エントリは、データ収集システム300内の各センサユニット350に対応し、センサユニットIDとセンサNo.1~センサNo.10というフィールドを有する。なお、図5では紙幅の都合上センサNo.4~センサNo.9のフィールドの図示は省略されている。図5のセンサ種別DB318の例は、センサユニット350が、人感センサを除いて最大で10個のセンサを持ち得る場合の例である。そのため、図5では、各エントリが10個のセンサにそれぞれ対応するフィールドを含む。センサユニットIDは、センサ位置DB317と同様に、センサユニット350の識別子を示す。また、センサNo.a1≦a≦10は、センサユニットIDで識別される当該センサユニット350のa番目のセンサつまり、サーバ310による収集対象のデータを生成するセンサのうちa番目のものの種類を示す。図5の例によれば、センサユニットIDが0001のセンサユニット350は、1番目のセンサとして気温センサを有し、2番目のセンサとして湿度センサを有し、3番目のセンサとして土中温度センサを有する。また、センサユニットIDが0001のセンサユニット350のセンサNo.10フィールドに-と示されているのは、当該センサユニット350が10番目のセンサを持たないことを示す。同様に、図5の例によれば、センサユニットIDが0002のセンサユニット350は、1番目のセンサとして湿度センサを有し、2番目のセンサとして土中温度センサを有し、3番目のセンサとして土中水分センサを有するが、10番目のセンサは持たない。なお、センサ種別DB318は静的なDBだが、センサユニット350自体が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のセンサユニット350に対してセンサの追加削除交換などが行われれば、それに応じて既存のエントリが変更される。また、図6に示すように、センサユニット別アラーム条件DB319の各エントリは、データ収集システム300内の各センサユニット350に対応し、センサユニットIDとアラーム条件IDというフィールドを有する。センサユニットIDは、センサ位置DB317と同様にセンサユニット350の識別子を示す。また、アラーム条件IDは、センサユニットIDで識別される当該センサユニット350についてのアラーム距離を求めるのに用いるアラーム条件の識別子である。なお、以下の説明において、アラーム条件とは、経過時間に応じたアラーム距離を定義する条件のことである。第1実施形態では、複数のアラーム条件が利用可能である。そして、第1実施形態では、センサユニット350ごとに、サーバ310のアラーム距離決定部323は、どのアラーム条件にしたがって当該センサユニット350についてのアラーム距離を取得するかということが設定可能である。例えば、センサユニット350に搭載されているセンサの種類と数、各センサが単位時間あたりに生成するデータの量、センサユニット350のフラッシュROM424の容量などに応じて、適切なアラーム条件は異なる。そのため、第1実施形態では、センサユニット別アラーム条件DB319により、センサユニット350ごとにアラーム条件が管理される。図6の例によれば、センサユニットIDが0001のセンサユニット350用には、02というアラーム条件IDのアラーム条件が使われる。また、センサユニットIDが0002のセンサユニット350用には、01というアラーム条件IDのアラーム条件が使われる。なお、センサユニット別アラーム条件DB319は静的なDBだが、センサユニット350自体が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のセンサユニット350に対してセンサの追加削除交換設定変更、あるいはフラッシュROM424の増設などが行われれば、それに応じて既存のエントリが変更される。また、図6に示すように、アラーム条件DB320の各エントリは、各アラーム条件に対応し、アラーム条件IDと条件数というフィールドを有する。また、第1実施形態では、各アラーム条件が、1~4個の条件の組み合わせにより表現されるので、アラーム条件DB320の各エントリは、条件cと条件c距離1≦c≦4というフィールドも有する。もちろん、アラーム条件を表現するための条件の個数の上限は、実施形態に応じた適宜の数でよく、4でなくてもよい。そして、上限に応じて、アラーム条件DB320の形式も適宜変形されてよい。アラーム条件IDは、センサユニット別アラーム条件DB319と同様にアラーム条件の識別子を示す。また、条件数は、アラーム条件IDで識別される当該アラーム条件がいくつの条件の組み合わせで表されるかを示す。そして、条件数がCのとき、1≦c≦Cなる各cについて、条件cと条件c距離のペアは、経過時間とアラーム距離のペアで定義される条件を示す。例えば、図6の例によれば、アラーム条件IDが01のアラーム条件は、4つの条件の組み合わせで表される。そして、1つ目の条件は1日と1mのペアで定義され、2つ目の条件は3日と50mのペアで定義され、3つ目の条件は7日と200mのペアで定義され、4つ目の条件は10日と500mのペアで定義される。より具体的には、アラーム条件IDが01のアラーム条件は、以上の4つの条件の組み合わせにより、以下のことを示すなお、説明の便宜上、前回のデータの収集からの経過時間より具体的には、1日単位で数えた経過時間である経過日数をpとする。p<1日ならば、アラーム距離は0m1日≦p<3日ならば、アラーム距離は1m3日≦p<7日ならば、アラーム距離は50m7日≦p<10日ならば、アラーム距離は200m10日≦pならば、アラーム距離は500m同様に、図6の例によれば、アラーム条件IDが02のアラーム条件は、3つの条件の組み合わせにより、以下のことを示す。p<1日ならば、アラーム距離は0m1日≦p<3日ならば、アラーム距離は1m3日≦p<7日ならば、アラーム距離は200m7日<pならば、アラーム距離は600m以上の2つのアラーム条件を比較すると、アラーム条件IDが01のアラーム条件の方が、より細かい粒度でアラーム距離が規定されている。また、同じ経過時間に対しては、アラーム条件IDが01のアラーム条件によって決まるアラーム距離は、アラーム条件IDが02のアラーム条件によって決まるアラーム距離以下である。例えば、経過時間が同じ5日でも、アラーム条件IDが01と02のアラーム条件がそれぞれ適用されるセンサユニット350に関するアラーム距離は、50mと200mであり、後者のアラーム距離の方が長い。すなわち、アラーム条件IDが02のアラーム条件は、同じ経過時間に対してデータ収集の緊急度がより高いセンサユニット350に好適である。例えば、1日当たりに生成するデータの量が多いセンサユニット350ほど、同じ経過時間に対してデータ収集の緊急度がより高い。なお、アラーム条件DB320は静的なDBだが、アラーム条件が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のアラーム条件の定義が変更されれば、それに応じて既存のエントリが変更される。また、図6に示すように、サンプリング周期DB321の各エントリは、データ収集システム300内の各センサユニット350に対応し、センサユニットIDとセンサNo.1~センサNo.10というフィールドを有する。なお、図6では紙幅の都合上センサNo.4~センサNo.9のフィールドの図示は省略されている。図6のサンプリング周期DB321の例は、センサユニット350が、人感センサを除いて最大で10個のセンサを持ち得る場合の例である。そのため、図6では、各エントリが10個のセンサにそれぞれ対応するフィールドを含む。つまり、図5のセンサ種別DB318と図6のサンプリング周期DB321のフィールドの数は同じである。センサユニットIDは、センサ位置DB318と同様に、センサユニット350の識別子を示す。また、センサNo.a1≦a≦10は、センサユニットIDで識別される当該センサユニット350のa番目のセンサが、データをサンプリングするサンプリング周期を示す単位は秒。サンプリング周期は、換言すれば、センサが気温などの計測対象を計測してデータを生成する周期である。図6の例によれば、センサユニットIDが0001のセンサユニット350においては、1番目~3番目のセンサがいずれも900秒周期でデータを生成する。なお、1番目~3番目のセンサの種別は、図5のセンサ種別DB318に示すとおり、気温センサ、湿度センサ、および土中温度センサである。また、図5に示すように、センサユニットIDが0001のセンサユニット350は10番目のセンサを持たない。よって、図6のサンプリング周期DB321でも、センサユニットIDが0001のエントリのセンサNo.10フィールドの値は無効な値例えばNULL。図6では-と表記に設定されている。また、図6の例によれば、センサユニットIDが0002のセンサユニット350においては、1番目~3番目のセンサがいずれも3600秒周期でデータを生成する。なお、1番目~3番目のセンサの種別は、図5のセンサ種別DB318に示すとおり、湿度センサ、土中湿度センサ、および土中水分センサである。サンプリング周期DB321は静的なDBだが、センサユニット350自体が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のセンサユニット350に対してセンサの追加削除交換サンプリング周期の設定変更などが行われれば、それに応じて既存のエントリが変更される。また、図6に示すように、データ量条件DB322の各エントリは、各アラーム条件に対応し、アラーム条件IDとデータ量下限とデータ量上限というフィールドを有する。アラーム条件IDは、アラーム条件DB320などと同様に、アラーム条件の識別子を示す。データ量下限とデータ量上限のペアは、センサユニット350が1日あたりに生成するデータの量の範囲を示す。各エントリは、1日あたりに生成するデータの量が、データ量下限とデータ量上限のペアで表される範囲に該当するセンサユニット350にとっては、アラーム条件IDで識別されるアラーム条件が好適であるということを示す。例えば、図6の例によれば、アラーム条件IDが01のアラーム条件は、1日あたりに生成するデータの量が0以上240未満のセンサユニット350に好適である。そして、アラーム条件IDが02のアラーム条件は、1日あたりに生成するデータの量が240以上1440未満のセンサユニット350に好適である。なお、データ量条件DB322におけるデータ量下限とデータ量上限の単位は、実施形態に応じて任意である。第1実施形態では説明の簡略化のため、1つのセンサによる1回の計測によって固定長の記憶領域が消費されると仮定し、固定長の記憶領域を1単位として、データ量下限とデータ量上限を表している。実施形態によっては、各センサによる1回の計測で消費される記憶領域のバイト数をセンサ別に管理するDBをさらにサーバ310が有してもよく、データ量条件DB322における単位が1バイトであってもよい。サーバ310は、サンプリング周期DB321にエントリが追加されると、追加されたエントリのセンサユニットIDに関して、データ量条件DB322に基づいてアラーム条件IDを決定する。そして、サーバ310は、センサユニット別アラーム条件DB319に新規エントリを追加し、新規エントリに、上記センサユニットIDと上記で決定したアラーム条件IDを設定する。また、サーバ310は、サンプリング周期DB321のいずれかのエントリで1つ以上のサンプリング周期が変更されると、当該エントリのセンサユニットIDに関して、データ量条件DB322に基づいて、アラーム条件IDを決定しなおす。そして、サーバ310は、再決定したアラーム条件IDを、センサユニット別アラーム条件DB319において上記センサユニットIDに対応するエントリのアラーム条件IDとして設定する。エントリの追加とサンプリング周期の変更のいずれの場合にせよ、サーバ310は、サンプリング周期DB321とデータ量条件DB322を参照して、具体的には以下の式1にしたがってアラーム条件IDを決定する。ここで、dataiは、データ収集システム300内でi番目のセンサユニット350が1日あたりに生成するデータ量である。データ量dataiの単位は、データ量条件DB322で使われている単位と同じである。また、Aiは、i番目のセンサユニット350が有する人感センサ以外のセンサつまり、サーバ310が収集する対象のデータを生成するセンサの数である。そして、periodi,aは、i番目のセンサユニット350のa番目のセンサ1≦a≦Aiのサンプリング周期である。サーバ310は、サンプリング周期DB321を参照することで、i番目のセンサユニット350に関して、センサの数Aiと各センサのサンプリング周期periodi,a1≦a≦Aiを認識することができる。なお、式1におけるamounti,aは、i番目のセンサユニット350のa番目のセンサが1回の計測で生成するデータ量を示す。データ量amounti,aの単位も、データ量条件DB322で使われている単位と同じである。また、データ量条件DB322に関して上記で説明した1つのセンサによる1回の計測によって固定長の記憶領域が消費されるという仮定より、第1実施形態では、すべてのiとaの組み合わせに対して、amounti,a=1である。しかし、もちろん実施形態によっては、データ量amounti,aは、iとaに応じて可変のこともある。そして、サンプリング周期DB321ではサンプリング周期periodi,aが秒単位で表されているので、i番目のセンサユニット350が1日あたりに生成するデータ量dataiは、式1のとおりである。サーバ310は、サンプリング周期DB321を参照して式1にしたがってデータ量dataiを計算し、データ量dataiが該当する範囲をデータ量条件DB322から探す。そして、サーバ310は、データ量条件DB322で見つかったエントリのアラーム条件IDを、i番目のセンサユニット350用のアラーム条件IDとして決定し、決定したアラーム条件IDを、センサユニット別アラーム条件DB319に設定する。例えば、i番目のセンサユニット350のセンサユニットIDが01であり、計算されたデータ量dataiが384であったとする。すると、240≦384<1440なので、データ量条件DB322より、センサユニットIDが01のセンサユニット350に適切なアラーム条件は、02というアラーム条件IDのものである。よって、サーバ310は、センサユニット別アラーム条件DB319において、01というセンサユニットIDと、以上のようにして決定した02というアラーム条件IDを対応づける。さて、図7は、センサに関連して動的に変化するDBの例を示す図である。図7に示すように、サーバ310内の収集日DB314の各エントリは、データ収集システム300内の各センサユニット350に対応し、センサユニットIDと収集日というフィールドを有する。センサユニットIDはセンサ位置DB317などと同様にセンサユニット350の識別子を示す。収集日は、センサユニットIDで識別される当該センサユニット350からサーバ310がデータを前回収集した日付を示す。もちろん、実施形態によっては、収集日の代わりに収集日時が使われてもよい。図7の例によれば、センサユニットIDが0001のセンサユニット350からサーバ310がデータを前回収集したのは2011年3月1日である。また、センサユニットIDが0002のセンサユニット350からサーバ310がデータを前回収集したのは2011年3月3日である。そして、センサユニットIDが0003のセンサユニット350からサーバ310がデータを前回収集したのは2011年3月2日である。また、センサユニットIDが0010のセンサユニット350からサーバ310がデータを前回収集したのは2011年2月20日である。収集日DB314は動的に変化するDBである。具体的には、サーバ310がいずれかの端末370を介していずれかのセンサユニット350からデータを収集するたびに、当該センサユニット350に対応するエントリの収集日が更新される。また、もちろん、センサユニット350がデータ収集システム300に追加または削除されれば、それに応じて収集日DB314にもエントリが追加または削除される。また、図7に示すように、センサユニット350内のセンサログDB352には、当該センサユニット350の各種センサ351がデータを生成するたびにエントリが追加される。センサログDB352の各エントリは、取得日時とセンサNo.1~センサNo.10というフィールドを有する。なお、図7では紙幅の都合上センサNo.4~センサNo.10のフィールドの図示は省略されている。取得日時は、各種センサ351が計測を行ってデータを生成した日時を示す。また、センサNo.a1≦a≦10は、a番目のセンサが取得日時に計測した計測値を示す。図7のセンサログDB352の例は、センサユニットIDが0001のセンサユニット350内のセンサログDB352の例である。そして、図7のセンサログDB352の例によれば、2011年2月21日の3時には、1番目のセンサが2.1という計測値を取得し、2番目のセンサが70という計測値を取得し、3番目のセンサが5.0という計測値を取得している。また、2011年2月21日の3時15分には、1番目のセンサが2.3という計測値を取得し、2番目のセンサが73という計測値を取得し、3番目のセンサが5.3という計測値を取得している。なお、図6のサンプリング周期DB321に示すように、センサユニットIDが0001のセンサユニット350における1~3番目のセンサのサンプリング周期は同じ900秒である。そのため、図7のセンサログDB352の例では、1つの同じエントリのセンサNo.1~センサNo.3の各フィールドに計測値が記録されている。しかし、センサ間のサンプリング周期が異なるセンサユニット350においては、センサログDB352において、個々のセンサのサンプリング周期に応じて、NULLなどの無効な値が記録されることもある。例えば、仮に2番目のセンサのサンプリング周期が1800秒とすれば、図7のセンサログDB352の例の2番目のエントリのセンサNo.2のフィールドには、無効な値が記録される。もちろん、実施形態によっては、センサログDB352は、取得日時と、1つのセンサを識別する識別子と、当該1つのセンサが計測した計測値という3つのフィールドを持つ形式であってもよい。また、図7に示すように、端末370内のセンサログDB376の各エントリは、端末370がセンサユニット350から受信したセンサログを、当該センサユニット350の識別子および受信時刻と対応づけている。具体的には、センサログDB376の各エントリは、センサユニットID、端末収集日時、取得日時、センサNo.1~センサNo.10というフィールドを有する。センサユニットIDはセンサログの送信元のセンサユニット350の識別子を示し、端末収集日時は、センサログを端末370がセンサユニット350から受信した日時を示す。取得日時とセンサNo.1~センサNo.10の各フィールドは、端末370が受信したセンサログが元々センサユニット350において記憶されていたセンサログDB352と同様である。図7には、センサユニットIDが0001のセンサユニット350から受信された2つのエントリが図示されている。つまり、図7に例示したセンサログDB376の2つのエントリは、図7に例示したセンサログDB352の2つのエントリを含むセンサログを、端末370がセンサユニット350から2011年3月1日8時59分に受信したということを示す。なお、センサログDB376には、センサ通信部375を介してセンサログ処理部377がいずれかのセンサユニット350からセンサログを受信するたびに、受信したセンサログに含まれるエントリと同数のエントリが追加される。また、図7に示すように、サーバ310内のセンサログDB315の各エントリは、端末370からサーバ310が受信したセンサログを、当該端末370の識別子および受信日時と対応づけている。具体的には、センサログDB315各エントリは、端末ID、サーバ収集日時、センサユニットID、端末収集日時、取得日時、およびセンサNo.1~センサNo.10というフィールドを有する。端末IDは、センサログの送信元の端末370の識別子を示し、サーバ収集日時は、端末370からサーバ310がセンサログを受信した日時を示す。そして、センサユニットID、端末収集日時、取得日時、およびセンサNo.1~センサNo.10の各フィールドは、サーバ310が受信したセンサログが元々端末370において記憶されていたセンサログDB376と同様である。図7には、端末IDが0003の端末370を介してサーバ310が収集した2つのエントリが図示されている。つまり、図7に例示したセンサログDB315の2つのエントリは、図7に例示したセンサログDB376の2つのエントリに対応する。図7の例によれば、サーバ310は、端末IDが0003の端末370から、2011年3月1日9時にセンサログを受信している。なお、センサログDB315には、センサログ処理部316が通信部327を介していずれかの端末370からセンサログを受信するたびに、受信されたセンサログに含まれるエントリと同数のエントリが追加される。さて、図8は、端末の移動につれて動的に変化するDBの例を示す図である。図8に示すように、端末370内のGPSログDB372の各エントリは、ある時点でGPS情報取得部371が取得したGPS情報に対応し、取得日時と緯度と経度というフィールドを有する。取得日時は、GPS情報取得部371がGPS情報を取得した日時を示す。また、端末370の位置を示すGPS情報は、具体的には緯度と経度により表される。そして、GPSログDB372の1つ以上のエントリのかたまりが、GPSログとして端末370からサーバ310に送信される。図8には、端末IDが0003の端末370におけるGPSログDB372が例示されている。図8の例によれば、当該端末370のGPS情報取得部371は、2011年2月21日8時1分に、北緯35.44354度東経139.3141度というGPS情報を取得している。また、図8の例によれば、当該端末370のGPS情報取得部371は、2011年2月21日8時2分に、北緯35.44353度東経139.3142度というGPS情報を取得している。なお、GPSログDB372には、GPS情報取得部371がGPS情報を取得するたびにエントリが追加される。GPS情報取得部371は、サーバ通信部373を介してサーバ310にGPSログを送信した後、送信済みのGPSログつまり送信済みのエントリをGPSログDB372から消去してもよい。また、図8に示すように、サーバ310内のGPSログDB311の各エントリは、端末370からサーバ310が受信したGPSログを、当該端末370の識別子および受信日時と対応づけている。具体的には、GPSログDB311の各エントリは、端末ID、収集日時、取得日時、緯度、および経度というフィールドを有する。端末IDは、GPSログの送信元の端末370の識別子を示し、収集日時は、端末370からサーバ310がGPSログを受信した日時を示す。取得日時と緯度と経度は、サーバ310が受信したGPSログが元々端末370において記憶されていたGPSログDB372と同様である。図8には、端末IDが0003の端末370から収集された2つのエントリが図示されている。つまり、図8に例示したGPSログDB311の2つのエントリは、図8に例示したGPSログDB372の2つのエントリに対応する。図8の例によれば、サーバ310は、端末IDが0003の端末370から、2011年2月21日8時15分にGPSログを受信している。なお、GPSログDB311には、GPSログ処理部313が通信部327を介していずれかの端末370からGPSログを受信するたびに、受信されたGPSログに含まれるエントリと同数のエントリが追加される。図9は、第1実施形態のデータ収集システムの動作シーケンス図である。なお、図9には簡単のため1つのセンサユニット350と1つの端末370しか図示していないが、複数のセンサユニット350と複数の端末370がデータ収集システム300内に存在してもよい。センサユニット350は、ステップS101に示すように、ユーザが端末370を携帯して近づいてくるのを待ち受ける。つまり、ユーザがセンサユニット350の人感センサの検知領域に入ってくるまで、センサユニット350は通信部354をオフにして待機する。他方、端末370では、ステップS111に示すように、GPS情報取得部371がGPS情報を定期的に取得し、取得したGPS情報をGPSログDB372に格納する。GPS情報取得部371は、GPS情報の取得を所定回数繰り返す。例えば、GPS情報取得部371は、1分間隔でGPS情報を取得してもよく、上記の所定回数は、例えば、15回であってもよい。そして、所定回数GPS情報を取得すると、GPS情報取得部371は、GPSログDB372に格納したGPSログすなわち所定回数分のエントリを、サーバ通信部373を介してステップS112でサーバ310に送信する。また、図9では紙面の都合上省略しているが、端末370では、以上のステップS111~S112の処理が繰り返される。なお、ステップS111~S112の処理の詳細は、図10のフローチャートとともに後述する。さて、ステップS112で送信されたGPSログは、ステップS122においてサーバ310の通信部327で受信され、GPSログ処理部313に出力される。また、サーバ310では、以上のような端末370からのGPSログの受信とは独立して、ステップS121の処理も行われる。例えば、ステップS121の処理は、圃場201での作業が始まる前の、毎朝決まった時刻に行われてもよい。図9の例は、ステップS121の処理の後にステップS122でGPSログが受信される例である。具体的には、ステップS121では、アラーム距離決定部323が、収集日DB314とセンサユニット別アラーム条件DB319とアラーム条件DB320を参照して、各センサユニット350についてアラーム距離を決定する。アラーム距離決定部323は、決定した各アラーム距離を例えばRAM402上に記憶する。なお、ステップS121の処理の詳細は、図11のフローチャートとともに後述する。そして、ステップS122では、端末370からのGPSログを通信部327が受信し、受信されたGPSログは、GPSログ処理部313の制御のもと、GPSログDB311に格納される。すると、GPSログの受信を契機として、各センサユニット350についてステップS123~S124の処理が行われる。具体的には、ステップS123で端末センサ間距離計算部324が、GPSログDB311とセンサ位置DB317を参照して、センサユニット350と、GPSログの送信元の端末370の間の距離を計算する。そして、次のステップS124で距離比較部325が、端末センサ間距離計算部324がステップS123で計算した距離と、アラーム距離決定部323がステップS121で決定したアラーム距離を比較する。その後、ステップS125でアラーム決定部326は、比較結果に基づいて、GPSログの送信元の端末370に対してアラーム指示を与える対象のセンサユニット350を決定する。端末370の位置に応じて、アラーム指示を与える対象のセンサユニット350の台数は、0台のこともあるし、1台のこともあるし、複数台のこともある。そして、次のステップS126でアラーム決定部326は、GPSログの送信元の端末370に対して、ステップS125での決定に基づく適宜のアラーム指示を、通信部327を介して送信する。なお、以上のステップS122~S126の詳細は、図12のフローチャートとともに後述する。さて、ステップS126で送信されたアラーム指示は、端末370のサーバ通信部373において、ステップS113で受信される。すると、ステップS114でアラーム処理部374は、受信されたアラーム指示にしたがって、適宜のアラームを発する。例えば、アラームは、山田太郎さん、××圃場のセンサユニットに近寄って、データ収集に御協力くださいのように文字で表現されていてもよいし、圃場の地図などの画像を含んでもよい。文字や画像による視覚的なアラームは、図4のディスプレイ451に表示される。あるいは、アラームは、LED448の点灯や点滅により視覚的に表現されてもよいし、ブザー449や不図示のスピーカからの放音により音声的に表現されてもよい。また、アラームは、振動モータ450による振動のように、触覚的に表現されてもよい。もちろん、視覚的、音声的、触覚的なアラームが組み合わされてもよい。アラームを受けたユーザは、アラームにしたがって、端末370を携帯したままセンサユニット350に近づく。そして、センサユニット350の人感センサの検知領域にユーザが入ると、センサユニット350は通信部354をオンにする。その結果、センサユニット350の通信部354と端末370のセンサ通信部375の間での通信が可能となる。よって、センサユニット350内ではセンサログ処理部353が通信部354を制御し、端末370内ではセンサログ処理部377がセンサ通信部375を制御することで、センサログがセンサユニット350から端末370へと送信される。なお、図9には特に明示しないが、通信部354とセンサ通信部375の間の通信は、実施形態に応じた適宜のプロトコルにしたがって確立されればよい。つまり、通信を確立するための最初のトリガは通信部354による要求でもよいし、センサ通信部375による要求でもよい。いずれにしろ、センサユニット350においては、ステップS102で、センサログ処理部353が通信部354を介して、センサログDB352内のセンサログを送信する。そして、端末370においては、ステップS115で、センサログ処理部377がセンサ通信部375を介してセンサログを受信し、受信したセンサログを一旦センサログDB376に格納する。そして、センサログの送受信が完了すると、ステップS116で、端末370のセンサログ処理部377が、サーバ通信部373を介して、センサログDB376内のセンサログをサーバ310に送信する。すると、サーバ310では、ステップS127で通信部327を介してセンサログ処理部316がセンサログを受信する。センサログ処理部316は、受信したセンサログの各エントリを、送信元の端末370の端末IDおよび受信時刻と対応づけて、センサログDB315に格納する。そして、センサログのセンサユニット350から端末370への転送が済むと、ステップS128でセンサログ処理部316は、収集日DB314を更新する。すなわち、センサログ処理部316は、収集日DB314を検索して、センサログの送信元のセンサユニット350のセンサユニットIDを持つエントリを探し出す。そして、センサログ処理部316は、見つかったエントリの収集日に、今日の日付を上書きする。さらに、次のステップS129でセンサログ処理部316は、センサログの送信元のセンサユニット350のセンサユニットIDをアラーム距離決定部323に通知する。すると、アラーム距離決定部323は、通知されたセンサユニットIDに関して、ステップS121と同様にしてアラーム距離を再決定する。つまり、アラーム距離決定部323は、収集日の更新に応じて変化した経過時間に基づき、アラーム距離を再決定する。なお、サーバ310における以上のステップS128~S129の処理と並行して、端末370においてセンサログ処理部377は、ステップS116で送信し終わったセンサログをセンサログDB376から消去してもよい。図10は、端末におけるGPSログ処理のフローチャートである。図10の処理は、例えば、端末370に電源が入っている間中、実行され続けてもよい。ステップS201でGPS情報取得部371は、取得間隔用と送信間隔用のタイマをそれぞれ設定する。なお、以下の説明において取得間隔とは、GPS情報取得部371が測位信号を受信してGPS情報を取得する間隔である。また、以下の説明において送信間隔とは、GPS情報取得部371がサーバ通信部373を介してサーバ310にGPSログを送信する間隔である。以下では説明の便宜上、取得間隔が1分であり、送信間隔が15分であるものとする。つまり、ステップS201でGPS情報取得部371は、取得間隔用のタイマを1分に設定し、送信間隔用のタイマを15分に設定する。しかし、取得間隔と送信間隔の具体的な値は実施形態に応じて任意であり、実施形態によっては、取得間隔と送信間隔が等しくてもよい。さて、GPS情報取得部371は、取得間隔用のタイマにしたがい、取得間隔が経過するまで次のステップS202で待機する。取得間隔が経過すると、処理はステップS203に移行する。ステップS203でGPS情報取得部371は、GPS受信機446により測位信号を受信し、端末370の現在位置の座標つまり緯度と経度を取得する。そして、次のステップS204でGPS情報取得部371は、現在位置の座標を取得した取得日時つまり現在時刻と、取得した座標値つまり緯度と経度を、図8に例示するようにGPSログDB372に記録する。また、次のステップS205でGPS情報取得部371は、取得間隔用のタイマを再度1分に設定する。そして、次のステップS206でGPS情報取得部371は、送信間隔用のタイマに基づいて、送信間隔が経過したか否かを判断する。送信間隔がまだ経過していなければ、処理はステップS202に戻る。逆に、送信間隔が経過していれば、処理はステップS207に移行する。つまり、ステップS202~S205の処理を15=15/1回繰り返すごとに、処理はステップS206からステップS207へと移行する。なお、上記15回という回数は、図9のステップS111の所定回数に相当し、ステップS111はステップS202~S205を15回繰り返すことに相当する。そして、ステップS207でGPS情報取得部371は、送信間隔用のタイマを再度15分に設定する。続いて、ステップS208でGPS情報取得部371は、GPSログDB372のデータを、端末370自体の端末IDとともにサーバ310に送信する。すなわち、ステップS204の15回の繰り返しによりGPSログDB372に蓄積された15個のエントリを、GPS情報取得部371は端末IDとともに送信する。なお、ステップS208は図9のステップS112に相当する。また、次のステップS209でGPS情報取得部371は、ステップS208で送信したデータをGPSログDB372から削除する。そして、処理はステップS202に戻る。続いて、図11を参照して、サーバ310において所定の時刻に行われるアラーム距離決定処理について説明する。図11のアラーム距離決定処理は、図9のステップS121に相当する。ステップS301でアラーム距離決定部323は、今日の日付を取得する。次に、ステップS302でアラーム距離決定部323は、センサユニット350に関するループ変数iを1に初期化する。そして、次のステップS303でアラーム距離決定部323は、図7の収集日DB314を参照して、i番目のセンサユニット350から前回データを収集してからの経過日数を計算する。例えば、i番目のセンサユニット350のセンサユニットIDが0002であり、ステップS301で取得された日付が2011年3月5日だとする。図7の収集日DB314の例によれば、センサユニットIDが0002のセンサユニット350から前回サーバ310がデータを収集した日は2011年3月3日である。よって、ステップS303でアラーム距離決定部323は、計算により2日という経過日数を得る。なお、図11の例では、経過時間の一例として、1日単位の経過日数が使われる。しかし、実施形態によっては、例えば1秒単位などの、より粒度の細かい経過時間が使われてもよいことは無論である。続いて、ステップS304でアラーム距離決定部323は、図6のセンサユニット別アラーム条件DB319を参照して、i番目のセンサユニット350のアラーム条件IDを読み出す。例えば、上記のようにi番目のセンサユニット350のセンサユニットIDが0002の場合、図6の例によると、ステップS304で読み出されるアラーム条件IDは01である。そして、次のステップS305でアラーム距離決定部323は、ステップS304で読み出したアラーム条件IDを持つアラーム条件を、図6のアラーム条件DB320から読み出す。例えば、上記のようにアラーム条件IDが01の場合、アラーム距離決定部323は、図6のアラーム条件DB320の1番目のエントリを読み出す。そして、次のステップS306でアラーム距離決定部323は、ステップS303で計算した経過日数と、ステップS305で読み出したアラーム条件から、アラーム距離を決定する。また、アラーム距離決定部323は、以上のようにして決定したアラーム距離を、i番目のセンサユニット350のセンサユニットIDと対応づけてRAM402上に保持する。例えば、上記のように経過日数が2日であり、アラーム条件IDが01のアラーム条件が読み出されたとする。この場合、図6のアラーム条件DB320の定義によれば、1日≦2日<3日なので、ステップS306で決定されるアラーム距離は1mである。そして、次のステップS307でアラーム距離決定部323は、ループ変数iの値がデータ収集システム300内のセンサユニット350の総数Uに達したか否かを判断する。もし、i=Uであれば、図11のアラーム距離決定処理は終了する。逆に、i≠Uであればつまりi<Uであれば、処理はステップS308へと移行する。ステップS308でアラーム距離決定部323は、ループ変数iをインクリメントする。そして、処理はステップS303に戻る。ところで、上記のとおり、アラーム距離決定部323は、図11のアラーム距離決定処理により決定した各センサユニット350についてのアラーム距離を、例えばRAM402上に保持し続ける。よって、図9においては、図11に相当するステップS121で決定されたアラーム距離を、距離比較部325が後のステップS124で参照することが可能である。また、図9のステップS129の再決定は、具体的には、再決定の対象のセンサユニット350に関してアラーム距離決定部323がステップS303~S306の処理を行うことに相当する。続いて、図9のステップS122~S126に相当する処理について、図12を参照して説明する。図12は、第1実施形態のアラーム関連処理のフローチャートである。GPSログ処理部313は、いずれかの端末370から通信部327を介してGPSログを受信するまで、ステップS401で待機する。そして、GPSログが受信されると、GPSログ処理部313は、GPSログを端末370の端末IDおよび受信時刻と対応づけてGPSログDB311に格納し、その後、処理はステップS402に移行する。すると、ステップS402で端末センサ間距離計算部324は、ステップS401でGPSログ処理部313が受信したGPSログに相当するエントリをGPSログDB311から読み出す。例えば、端末370が図10にしたがって動作する場合、1回の送信で端末370から送信されるGPSログは、15=15/1個のエントリに相当するので、ステップS402ではGPSログDB311内で収集日時が最新の15個のエントリが読み出される。端末センサ間距離計算部324は、ステップS402においてさらに、読み出したエントリをウィンドウ間隔WごとにN個のブロックに分割する。ここで、ウィンドウ間隔Wは、GPSログの1回の送信に対応するエントリ数よりも小さな所定の値であり、端末370の位置の平均をとるための時間の幅を表す。以下では説明の便宜上W=5とする。例えば、図10の例のように取得間隔が1分であり、上記仮定のようにW=5の場合、ウィンドウ間隔Wが示す時間の幅は5分=1分×Wである。そして、ブロックの個数Nは、GPSログの1回の送信に対応するエントリ数をウィンドウ間隔で割った値である。よって、上記のように1回の送信で端末370から送信されるGPSログが15個のエントリに相当する場合、N=15/5=3である。以上のようなブロックへの分割の後、ステップS403で端末センサ間距離計算部324は、分割して得られた各ブロックにおける平均座標を求める。例えばW=5の場合、1つのブロックにはGPSログDB311から読み出された5つのエントリが対応するので、ステップS403では、各ブロックについて、5つのエントリの平均座標つまり平均緯度と平均経度が計算される。ここで説明の便宜上、ステップS401で受信されたGPSログが、j番目の端末termjが時刻tj,k~tj,kWN-1に取得したWN個の座標gpsj,k~gpsj,kWN-1に対応するものとする。すると、ステップS403でn番目1≦n≦Nのブロックについて計算される平均座標avrj,nは、式2のとおりである。なお、図8から理解されるように、個々の座標gpsj,k~gpsj,kWN-1と平均座標avrj,nのいずれも、具体的には、緯度と経度のペアで表される。続くステップS404~S413の処理は、各センサユニット350についてステップS405~S411の処理を繰り返すことを含む。そして、ステップS405~S411の処理は、ブロックの平均座標とセンサユニット350との間の距離がアラーム距離以下になるブロックが1つでもあるかということを判定する処理である。具体的には、ステップS404でサーバ310は、センサユニット350についてのループ変数iを1に初期化する。また、次のステップS405で距離比較部325は、i番目のセンサユニット350に対応するフラグをfalseに初期化する。当該フラグは、ステップS401で受信されたGPSログの送信元の端末370のブロックごとの平均座標のうち、i番目のセンサユニット350からの距離がi番目のセンサユニット350に関するアラーム距離以下のものが1つでもあるかということを示す。換言すれば、当該フラグは、ステップS401で受信されたGPSログの送信元の端末370に対してi番目のセンサユニット350についてのアラーム指示を送信するか否かを示す。初期値のfalseは、アラーム指示を送信しないことを示す。また、次のステップS406でサーバ310は、ブロックについてのループ変数nを1に初期化する。そして、次のステップS407で端末センサ間距離計算部324は、ステップS403で計算したn番目のブロックの平均座標が示す位置と、i番目のセンサユニット350との間の距離を計算する。つまり、端末センサ間距離計算部324は、図5のセンサ位置DB317を参照してi番目のセンサユニット350が設置された位置の緯度と経度を読み出し、読み出した緯度と経度と、ステップS403の計算結果を用いて、距離を計算する。説明の便宜上、i番目のセンサユニット350の位置をposiとする。すると、ステップS407で計算される距離disti,j,nは、式3のように表すことができる。なお、図5から理解されるように、i番目のセンサユニット350の位置posiは緯度と経度のペアで表される。また、式3において||x-y||は、位置xと位置yの間の距離例えば、ユークリッド距離でもよいし、マンハッタン距離でもよいを示すものとする。そして、次のステップS408で距離比較部325は、ステップS407で計算された距離disti,j,nが、図11の処理の結果としてアラーム距離決定部323がi番目のセンサユニット350に関して記憶しているアラーム距離以下か否かを判断する。以下では、説明の便宜上、アラーム距離決定部323がi番目のセンサユニット350に関して記憶しているアラーム距離をalarmiと表記する。計算された距離disti,j,nがアラーム距離alarmi以下のとき、処理はステップS409に移行する。逆に、距離disti,j,nがアラーム距離alarmiより大きいとき、処理はステップS410に移行する。ステップS409が実行されるのは、ブロックの平均座標avrj,nとi番目のセンサユニット350との間の距離disti,j,nがアラーム距離alarmi以下になるブロックが見つかった場合である。この場合、距離比較部325は、i番目のセンサユニット350に対応するフラグつまりステップS405で初期化したフラグをtrueに設定する。そして、さらに別のブロックについて検討する必要はもうないので、処理はステップS412に移行する。他方、ステップS410が実行されるのは、ブロックの平均座標avrj,nとi番目のセンサユニット350との間の距離disti,j,nがアラーム距離alarmi以下になるブロックがまだ見つかっていない場合である。この場合、ステップS410でサーバ310は、未注目のブロックが残っているか否かを判断する。すなわち、サーバ310は、n=Nであるか否かを判断する。そして、n=Nの場合は、全ブロックが注目済みであり、どのブロックの平均座標avrj,nも、i番目のセンサユニット350との間の距離がアラーム距離alarmiより大きい場合である。よって、n=Nの場合は、ステップS405で初期化されたフラグの値がfalseのまま、処理がステップS412へと移行する。他方、n≠Nの場合より具体的にはn<Nの場合は、未注目のブロックが残っている。よって、次のブロックに注目するために処理はステップS411に移行する。そして、ステップS411でサーバ310は、ブロックに関するループ変数nをインクリメントし、その後、処理はステップS407に戻る。ここで、j番目の端末termjからステップS401でGPSログが受信された場合の、i番目のセンサユニット350についてのフラグをflagi,jと表記する。上記のステップS405~S411の処理により、フラグflagi,jは、式4のように設定される。さて、ステップS412でサーバ310は、すべてのセンサユニット350について注目し終えたか否かを判断する。つまり、サーバ310は、センサユニット350についてのループ変数iの値がデータ収集システム300内のセンサユニット350の総数Uに達したか否かを判断する。そして、i=Uの場合、処理はステップS414に移行する。他方、i≠Uの場合より具体的にはi<Uの場合は、未注目のセンサユニット350が残っているので、処理はステップS413に移行する。ステップS413でサーバ310は、センサユニット350についてのループ変数iをインクリメントする。その後、処理はステップS405に戻る。さて、ステップS414の処理が実行されるのは、データ収集システム300内のすべてのセンサユニット350に関して、フラグflagi,jが設定された後である。そして、ステップS414でアラーム決定部326は、対応するフラグがtrueの全センサユニット350のリストを取得する。なお、センサユニット350のリストは、具体的にはセンサユニットIDのリストとして表現される。ここで説明の便宜上、i番目のセンサユニット350のセンサユニットIDをunitiと表記すると、ステップS414で取得されるリストは、式5の集合targetjを表すリストである。つまり、ステップS414においてアラーム決定部326は、ステップS401で受信されたGPSログの送信元の端末370すなわち端末termjに対してアラーム指示を出す対象のセンサユニット350の集合targetjを決定する。そして、次のステップS415でアラーム決定部326は、アラーム指示として、ステップS414で取得したリストを、ステップS401で受信されたGPSログの送信元の端末370に、通信部327を介して送信する。なお、場合によっては、ステップS414で得られるリストが空リストのことがあるつまり集合targetjが空集合のことがある。空リストがアラーム指示として送信される場合のアラーム指示とは、具体的にはどのセンサユニット350に関してもアラームを発する必要がないという指示である。しかし、アラームを発する必要がないということは、明示的に指示されなくても構わない。よって、ステップS414で得られるリストが空リストの場合、ステップS415の送信が省略されてもよい。逆に、非空のリストがアラーム指示としてステップS415で送信される場合、アラーム指示は当該リストに含まれる各センサユニットIDのセンサユニット350について、アラームを発せよという指示である。いずれにしろ、ステップS415でのリストの送信後、処理はステップS401に戻る。なお、図12のステップS401における受信が図9のステップS122における受信に対応し、図12のステップS407とS408が図9のステップS123とS124に対応する。また、図12のステップS414が図9のステップS125に対応し、ステップS415がステップS126に対応する。そして、以上説明した第1実施形態によれば、センサユニット350ごとに、データ収集の緊急度に応じてアラーム距離が決定され、アラーム距離と端末370の位置に基づいてサーバ310が端末370にアラーム指示を出す。つまり、端末370がユーザに対してアラームを出すか否かは、センサユニット350からのデータ収集の緊急度に依存する。よって、第1実施形態によれば、センサユニット350からのデータ収集にユーザが関与するデータ収集システム300において、データ収集の緊急度とユーザの負担のバランスがとれる。続いて、図13~20を参照して第2実施形態について説明する。なお、第1実施形態との共通点については適宜説明を省略する。第2実施形態は、第1実施形態と同様にデータ収集の緊急度とユーザの負荷のバランスをとる効果だけでなく、さらに、ユーザの作業効率の低下を防ぐ効果を奏する。まず、図13を参照して、第2実施形態により解決しようとする課題について説明する。図13は、データ収集への関与が原因でユーザの作業効率が悪くなる例を示す図である。図2と同様に図13にも、圃場201におけるユーザの動きの例が示されている。図2と同様に図13でも圃場201の隅にセンサユニット202が設置されており、センサユニット202の人感センサの検知領域203は、広い圃場201のごく一部である。ここで、ユーザ209が軌跡210に沿って移動しながら除草などの作業を行っているものとする。そして、軌跡210の矢印の先端までユーザ209が移動した時点で、ユーザ209が携帯する不図示の端末がアラームを発したとする。すると、アラームを受けたユーザ209は、作業を中断して、軌跡211として示すようにセンサユニット202の近傍まで移動する。そして、ユーザ209が検知領域203に入ると、センサユニット202の人感センサがユーザ209の存在を検知し、センサユニット202は通信機能をオンにする。すると、センサユニット202と端末が通信を開始し、その結果、センサユニット202から端末へとセンサログが転送される。ユーザ209は、センサログが端末に転送され終わるのを待ってから、軌跡212として示すように元の位置まで移動する。その後、ユーザ209は、中断した作業を再開する。具体的には、ユーザ209は、軌跡213に沿って移動しながら作業の続きを行う。以上の図13の例のとおり、ユーザ209がアラームを受けるタイミングによっては、ユーザ209は、データ収集に関与するために作業を中断することがある。作業の中断は、作業効率を落とす。また、アラームを受けたときにユーザ209がいる場所が図13のようにセンサユニット202から遠く離れている場合、ユーザ209が軌跡211と212に沿って移動する距離も長い。長い距離をユーザ209が移動する場合、作業の中断時間も長い。すると、ユーザ209は、移動に気を取られて、例えばどこまで作業が済んだかということを忘れてしまうかもしれない。その結果、作業効率がさらに悪化するおそれもある。以上の図13の例から理解されるように、ユーザ209の作業中に端末がアラームを出すことは、作業効率を悪化させるおそれがある。そこで、第2実施形態では、作業効率が悪化する度合を小さくするために、作業スケジュールに基づいて2種類の制御が行われる。すなわち、第1に、データ収集の緊急度がまだそれほど高くない場合換言すれば、前回の収集からの経過時間がまだそれほど長くないためアラーム距離がそれほど大きくない場合は、アラームの発行を後日に延期する制御が行われる。あるセンサユニットに関するアラームの発行を延期するということは、端末の位置によらず、延期された日までは、当該センサユニットに関するアラームが発行されないということである。つまり、延期により、アラームによる作業の中断が防止され、作業効率の悪化を防ぐことができる。しかし、無制限の延期は好ましくない。そこで、第2実施形態では、どの程度の延期が適切なのかという判断のため、センサユニットが設置された場所例えば圃場201での作業スケジュールが参照される。また、第2に、アラームの発行は、なるべくユーザの作業を中断させないタイミングで行われるように制御される。ユーザの作業を中断させないタイミングとは、ユーザが作業をしていないと想定されるタイミングであり、具体的には、休憩時間である。例えば、休憩時間の開始時刻もしくは終了時刻、または休憩時間中にアラームが出されれば、ユーザは作業を中断せずに済む。つまり、端末がアラームを出す時刻を調整することは、ユーザの負荷自体を減らすことはないとはいえ、作業効率に与える悪影響を減らす効果がある。以下では、以上に概略を述べたような第2実施形態の動作と構成について、より具体的に説明する。図14は、第2実施形態のセンサデータ収集システムのブロック構成図である。図14では、第1実施形態と同様の構成要素には図3と同じ参照符号が割り当てられている。図14のデータ収集システム300bは、サーバ310bと、1台以上のセンサユニットと、1台以上の端末を含む。図14には図3と同様に、3台のセンサユニット350a~350cと3台の端末370a~370cが例示されているが、センサユニット350および端末370の台数は任意である。また、図14に示す第2実施形態のセンサユニット350a~350cと端末370a~370cは、図3に示す第1実施形態のものと同様である。図14のサーバ310bは、以下の点において図3のサーバ310と異なる。すなわち、サーバ310bは、図3の収集日DB314の代わりに収集日DB328を有し、図3のアラーム決定部326の代わりにアラーム決定部334を有する。また、サーバ310bはさらに、圃場形状DB329、スケジュールDB330、休憩時間DB331、スケジュール単位定義DB332、および圃場特定部333を有する。収集日DB328は、詳しくは図15に示すとおり、図7の収集日DB314とは異なる構造を有する。収集日DB328は、収集日DB314と同様に、図4のHDD403に保持されていてもよいし、RAM402に保持されていてもよい。また、アラーム決定部334は、図3のアラーム決定部326が行う処理とはやや異なる処理を行う。アラーム決定部334も、アラーム決定部326と同様に、図4のCPU401がプログラムを実行することにより実現される。そして、圃場形状DB329は、センサユニット350が設置された圃場の形状を表す情報を記憶するDBである。また、スケジュールDB330は、各圃場での作業スケジュールを記憶するDBである。なお、第2実施形態ではどの圃場でも作業の休憩時間は共通であると仮定しており、休憩時間DB331はこの仮定に基づいて休憩時間を記憶するDBである。スケジュール単位定義DB332は、作業が予定されている日と作業が予定されていない日が混在する場合に、どの範囲をひとかたまりの作業の単位として見なすかを規定する規則を記憶するDBである。具体的には、スケジュール単位定義DB332には、規則を表現するための1つ以上のパラメタが記憶される。以上の各種DBの詳細は図15とともに後述する。また、以上の各種DBは、例えば、図4のHDD403に格納され、必要に応じてRAM402に読み出される。そして、圃場特定部333は、端末370が存在する圃場を、端末370から受信したGPSログに基づいて特定する。圃場を特定することにより、当該圃場でのスケジュールを参照することが可能になる。圃場特定部333は、図4のCPU401がプログラムを実行することにより実現される。図15は、第2実施形態においてサーバが保持するDBの例を示す図である。収集日DB328は、図7の収集日DB314と類似のDBだが、各エントリがアラーム予定日および圃場IDというフィールドを含む点で、収集日DB314と異なる。アラーム予定日は、センサユニットIDで識別される当該センサユニット350に関するアラーム指示を端末370に出す予定の日である。換言すれば、アラーム予定日は、当該センサユニット350に関するアラームを端末370に出させる予定の日である。図15の例では、センサユニットIDが0002のエントリに関してのみアラーム予定日が2011年3月5日に設定されており、他のエントリではアラーム予定日が未設定である。なお、詳しくは後述するが、アラーム予定日は、アラーム決定部334によって随時更新され得る。また、実際にサーバ310bがデータを収集すると、アラーム予定日はクリアされ、未設定の状態に戻される。また、圃場IDは、センサユニットIDで識別される当該センサユニット350が設定されている圃場を、データ収集システム300b内で一意に識別する識別子を示す。圃場IDは、センサユニットIDから一意に定まるので、例えば図5のセンサ位置DB317などに記憶されていてもよいが、説明の便宜上、第2実施形態では収集日DB328に記憶されているものとする。図15の例では、センサユニットIDが0001と0002のセンサユニット350は、0005という圃場IDの圃場に設置されている。また、センサユニットIDが0003のセンサユニット350は、0001という圃場IDの圃場に設置されており、センサユニットIDが0010のセンサユニット350は、0007という圃場IDの圃場に設置されている。さて、図15に示すように、圃場形状DB329は、センサユニット350が設置される圃場の形状を表すDBである。第2実施形態では、1つの圃場の形状が多角形で近似され、x角形3≦xで近似される圃場の形状は、圃場形状DB329のx個のエントリで表される。具体的には、圃場形状DB329の各エントリは、圃場ID、頂点数、頂点ID、緯度、および経度というフィールドを有する。圃場IDは圃場の識別子を示す。頂点数は、圃場IDで識別される圃場の形状を近似する多角形の頂点の数を示す。頂点IDは、1つの圃場内で各頂点を一意に識別する識別子であり、緯度と経度は頂点の位置を示す。図15の例によれば、圃場IDが0001の圃場は4角形で近似され、そのうち2つの頂点は、北緯35.43996度東経139.3071度と、北緯35.43996度東経139.3080度にある。なお、圃場形状DB329は静的なDBだが、センサユニット350を設置する対象の圃場の増減に応じてエントリが追加または削除される。また、実施形態によっては、圃場形状DB329のように数値による圃場の形状を表すDBの代わりに、緯度と経度に対応づけて圃場の範囲を示す2値画像などによって圃場の形状を表す画像DBが利用されてもよい。さて、図15に示すように、スケジュールDB330の各エントリは、個々の圃場での個々の作業に対応し、圃場IDと開始日時と終了日時と作業内容というフィールドを有する。圃場IDは、圃場形状DB329と同様に、圃場の識別子である。開始日時と終了日時は、作業がいつからいつまで行われる予定であるかを示す。作業内容は、作業の内容を示す。図15の例によれば、圃場IDが0001の圃場では、2011年3月14日の8時から12時まで、草取りが予定されている。また、圃場IDが0002の圃場では、2011年3月14日の13時から15時まで、播種が予定されている。スケジュールDB330は動的なDBであり、新たな作業の予定が立てられるたびに、例えば、端末370からの指示またはサーバ310bのキーボード412からの入力に応じて、エントリが追加される。また、図15に示すように、休憩時間DB331の各エントリは、1回の休憩時間に対応する。なお、第2実施形態では、どの圃場でも休憩時間のスケジュールは共通であると仮定している。よって、休憩時間DB331の各エントリは、休憩時間IDと開始時刻と終了時刻というフィールドを有する。休憩時間IDは個々の休憩時間を識別する識別子であり、開始時刻と終了時刻は休憩時間の範囲を示す。図15の例によれば、休憩時間IDが01の休憩時間は10時から10時15分までであり、休憩時間IDが02の休憩時間は12時から13時までであり、休憩時間IDが03の休憩時間は15時から15時15分までである。なお、休憩時間DB331は静的なDBだが、休憩時間の予定が変われば、エントリの追加削除変更などが行われてもよい。また、図15に示すように、スケジュール単位定義DB332には、作業が予定されている日と作業が予定されていない日が混在する場合に、どの範囲をひとかたまりの作業の単位として見なすかを規定する規則を表現するためのパラメタが設定されている。第2実施形態では、上記規則は、具体的には、作業なし期間の最大長さと作業なし期間の最大回数という2つのパラメタで表される。そして、図15の例では、これら2つのパラメタの値は、それぞれ3日と2回である。すなわち、図15の例は、以下のような規則を表す。作業なし期間をはさんで断続的に作業が予定されている場合であっても、作業なし期間をはさんだ全体を、ひとかたまりの作業の単位として見なせることがある。具体的には、作業なし期間をはさんで断続的に作業が行われる場合、3日以内の作業なし期間を2回まで含んでいても、全体をひとかたまりの作業の単位として見なしてよい。3日より長い作業なし期間がある場合は、当該作業なし期間が、作業の単位同士の区切れ目になる。3回目の3日以内の作業なし期間も、作業の単位同士の区切れ目になる。なお、スケジュール単位定義DB332は静的なDBである。スケジュール単位定義DB332に設定されるパラメタの種類と値は実施形態に応じて適宜決められてよい。図16は、作業スケジュールとアラーム予定日の例を示す図である。図16には4通りのスケジュール例501~504が例示されている。スケジュール例501は、前回のデータ収集日から2週間あいて、今日から3日間作業が予定されているという例である。スケジュール例501のように前回のデータ収集日からの経過時間が長い場合は、データ収集の緊急度が高いので、データ収集を延期しないことが望ましい。つまり、サーバ310bは、今日のうちにアラーム指示を出し、端末370を介してセンサユニット350からデータを収集することが望ましい。換言すれば、アラーム決定部334は、アラーム予定日を設定しないことそれにより、暗黙的に、今日をアラーム予定日として指定することが望ましい。なお、図16ではアラーム予定日が二重丸で示されている、他方、スケジュール例502は、前回のデータ収集日から3日間だけあいて、今日から3日間作業が予定されているという例である。スケジュール例502のように前回のデータ収集日からの経過時間が短い場合は、データ収集の緊急度が低いので、データ収集を延期しても構わない。また、3日間の作業の最終日であっても前回の収集日の6日後である。例えば、データ収集の緊急度が当日中にデータを収集することが望ましいという程度にまで高まるのが、前回の収集日から10日後であるとすると、スケジュール例502の作業最終日にデータが収集されることは十分許容される。そこで、スケジュール例502の場合、アラーム決定部334は、今日から予定されている3日間の作業の最終日をアラーム予定日として設定することが好ましい。すると、サーバ310bは、作業1日目をアラーム予定日として設定する場合と比べて、次の収集でより多くのデータつまり作業2日目や3日目のセンサログを取得することができる。もちろん、設定されたアラーム予定日よりも前に、偶発的または自発的にユーザがセンサユニット350に近寄ってデータ収集に関与することもあり得る。よって、例えば、作業2日目にデータが収集される場合もあり得る。すると、収集に応じて、アラーム決定部334はアラーム予定日を新たに設定しなおす。また、スケジュール例501と502は、作業が3日間連続する例だが、場合によっては、作業のない日を間にはさみながら、断続的に作業が予定されることもある。例えば、スケジュール例503と504はその例である。スケジュール例503は、前回のデータ収集日から2日間あいて、今日から3日間作業が予定されており、その後、2日間の作業なし期間をはさんで作業が再開される予定であり、再開後の作業は4日間にわたる予定であるという例である。そして、図15のスケジュール単位定義DB332によれば、2日間の作業なし期間をはさんだ合計7日間の作業の全体つまり、作業なし期間も数えれば9日にわたる期間の全体は、ひとかたまりの単位と見なせる。また、ここで、スケジュール例502について例示したのと同様に、前回の収集日から10日後には、データ収集の緊急度が当日中にデータを収集することが望ましいという程度にまで高まる、と仮定する。つまり、収集を後日に延期することが許容されるのは、前回の収集日から9日目までである、と仮定する。したがって、前回の収集日から10日目になったら、サーバ310bはアラーム指示を出すことが望ましい。スケジュール例503の例では、ひとかたまりの単位の最終日は再開後作業最終日であるが、再開後作業最終日には前回の収集日から11日が経過してしまう。よって、アラーム予定日は、前回の収集日から10日後にあたる再開後作業3日目とすることが望ましい。つまり、たとえ今日が前回の収集日から間もないとしても、ひとかたまりの作業の単位が長ければ、最終日には、前回の収集日から大幅な日数が経過してしまうおそれがある。よって、サーバ310bは、一律にひとかたまりの作業の単位の最終日をアラーム予定日とするのではなく、前回の収集日からの経過時間がある程度の範囲内に収まるように、アラーム予定日を設定することが好ましい。また、スケジュール例504は、前回のデータ収集日から4日間あいて、今日から3日間作業が予定されており、その後、3日間の作業なし期間をはさんで作業が再開される予定であり、再開後の作業は3日間にわたる予定であるという例である。そして、図15のスケジュール単位定義DB332によれば、3日間の作業なし期間をはさんだ合計6日間の作業の全体つまり、作業なし期間も数えれば9日にわたる期間の全体は、ひとかたまりの単位と見なせる。スケジュール例503の場合と同様に、スケジュール例504でも、前回の収集日から10日後がアラーム予定日として設定されてもよい。スケジュール例504の場合は、前回の収集日から10日後が偶然にも作業なし日であるが、例えば上記の10日という閾値が多少の余裕をもって設定された値であれば、このように作業なし日にアラーム予定日が重なってもよい。例えば、アラーム予定日の翌日つまり作業再開1日目に実際にユーザが作業をしに圃場に来たときに、サーバ310bは、既に前回の収集日から10日以上経過していることを検知して、アラーム指示を出せばよい。図17は、第2実施形態のデータ収集システムの動作シーケンス図である。なお、センサユニット350の動作は第1実施形態と同様なので、図17ではセンサユニット350の動作は省略されている。また、端末370の動作も第1実施形態と同様である。図17には、図9の第1実施形態のシーケンス図と同様に、端末370が行うステップS111~S113の処理が図示されているが、ステップS114以後の端末370の処理は、紙幅の都合上、図17では省略されている。サーバ310bにおいては、図9の第1実施形態と同様に図17の第2実施形態でも、ステップS121でアラーム距離決定部323が各センサユニット350についてのアラーム距離を決定する。そして、図9のステップS122~S126の代わりに図17にはステップS501~S508が示されている。なお、紙幅の都合上、図17では省略されているが、ステップS508の後でサーバ310bは、いずれかの端末370通常は、アラーム指示の送信先の端末370を介してセンサログを受信することがある。その場合、サーバ310bは図9のステップS127~S129と同様の処理を行う。以下では、図9と異なるステップS501~508でのサーバ310bの動作について詳しく説明する。ステップS501では、端末370からのGPSログを通信部327が受信する。受信されたGPSログは、GPSログ処理部313の制御のもと、GPSログDB311に格納される。次に、ステップS502でアラーム決定部334は、アラーム指示を送る時刻か否かを判断するために、図15の休憩時間DB331を参照し、現在が休憩時間か否かを判断する。現在がまだ休憩時間でなければ、サーバ310bは再度GPSログの受信待ち状態に戻る。図17の例は、ステップS502でのチェックの結果、現在が休憩時間であることが判明した場合の動作シーケンスである。現在が休憩時間である場合、サーバ310bは、各端末370について以下のステップS503~S506の処理を行う。なお、ステップS503~S504の処理は各センサユニット350について行われるが、紙幅の都合上、図17ではセンサユニット350ごとのループを示すループ端が省略されている。ステップS503で端末センサ間距離計算部324は、GPSログDB311とセンサ位置DB317を参照して、処理対象として注目している端末370とセンサユニット350の間の距離を計算する。なお、ステップS503の動作は、図9のステップS123の動作と似ているが、計算に用いるGPSログの範囲が異なる。そして、次のステップS504で距離比較部325は、端末センサ間距離計算部324が計算した距離と、アラーム距離決定部323がステップS121で決定したアラーム距離を比較する。比較結果は、処理対象として注目している端末370とセンサユニット350の組み合わせに関して、当該端末370に当該センサユニット350についてのアラーム指示を与えるか否かという暫定的な判定結果を表す。また、次のステップS505で圃場特定部333は、処理対象として注目している端末370が休憩時間の直前の時間帯例えば、休憩時間が始まる30分前から休憩時間の開始時刻までの時間帯に存在していた圃場を特定する。圃場特定部333は、GPSログDB311と圃場形状DB329に基づいて、圃場を特定することができる。そして、次のステップS506でアラーム決定部334は、ステップS504での暫定的な判定について再判定を行う。すなわち、アラーム決定部334は、圃場のスケジュールに基づき、端末370へのアラーム指示の要否を再判定する。具体的には、アラーム決定部334は、まず、図15のスケジュールDB330を参照することで、ステップS505で特定された圃場での作業スケジュールを認識する。そして、アラーム決定部334は、認識した作業スケジュールと、スケジュール単位定義DB332で定義される規則と、前回のデータ収集からの経過時間に基づいて、アラーム指示の送信を延期するか否かを判断する。アラーム指示の送信を延期するということは、ステップS504で暫定的に決められたアラーム指示をキャンセルするということであり、今日はアラーム指示は不要であると決定することである。つまり、アラーム決定部334は、アラーム指示の送信を延期するか否かを判断することで、アラーム指示の要否を判定しなおす。そして、以上のステップS503~S506の処理が各端末370について行われた後、ステップS507では、アラーム決定部334が、アラーム指示を送信する送信先の端末370を決定する。ステップS507の決定は、ステップS506での再判定結果に基づく。さらに、次のステップS508でアラーム決定部334は、ステップS507で決定した端末370に対して、通信部327を介してアラーム指示を送信する。なお、以上のステップS501~508の詳細は、図18~20のフローチャートとともに後述する。また、送信されたアラーム指示は、端末370においてステップS113で受信される。図18は、第2実施形態のアラーム関連処理のフローチャートである。GPSログ処理部313は、いずれかの端末370から通信部327を介してGPSログを受信するまで、ステップS601で待機する。そして、GPSログが受信されると、処理はステップS602に移行する。すると、ステップS602でGPSログ処理部313は、GPSログを端末370の端末IDおよび受信時刻と対応づけてGPSログDB311に格納し、その後、処理はステップS603に移行する。ステップS603でアラーム決定部334は、休憩時間DB331を参照して、現在が休憩時間か否かを判断する。例えば、図15の休憩時間DB331の例では、10時から10時15分と、12時から13時と、15時から15時15分が休憩時間である。よって、例えば現在時刻が9時や14時などであれば、アラーム決定部334は現在は休憩時間中ではないと判断し、処理はステップS601に戻る。つまり、第2実施形態では、休憩時間外では、GPSログが単にGPSログDB311に蓄積されるだけであり、GPSログの受信を契機にアラーム指示が送信されるわけではない。逆に、例えば現在時刻が10時や12時3分などであれば、アラーム決定部334は現在は休憩時間中であると判断し、処理はステップS604に移行する。第2実施形態では、休憩時間に入ると、サーバ310bがステップS604~S616の処理を行い、必要に応じてアラーム指示を送信する。もちろん、実施形態によっては、ステップS601~S602でのGPSログの蓄積とは独立した処理として、休憩時間の開始時刻になるとサーバ310bがステップS604~S616の処理を行ってもよい。さて、ステップS604で端末センサ間距離計算部324は、休憩開始時刻よりも所定の時間だけ遡った時刻以降のデータをGPSログDB311から抽出する。ここでの所定の時間は、実施形態に応じて適宜定められていてよい。以下では説明の便宜上、上記所定の時間を30分とする。また、以下では説明の便宜上、ステップS603において現在は12時から13時の休憩時間中であると判断されたものとする。つまり、ステップS604では、端末センサ間距離計算部324が11時30分以降のエントリをGPSログDB311から抽出するものとする。次に、ステップS605でサーバ310bは、端末370についてのループ変数jを1に初期化する。そして、次のステップS606で端末センサ間距離計算部324は、ステップS604で抽出したデータの中からさらに、j番目の端末370のデータのみを抽出する。例えば、第1実施形態と同様に、端末370は、1分に1回GPS情報を取得し、15分に1回GPSログを送信してもよい。仮に、j番目の端末370が11時35分と11時50分にGPSログをサーバ310bに送信し、現在時刻が12時1分であるとすれば、ステップS606では、11時30分から11時50分までのGPSログのエントリが抽出される。そして、次のステップS607では、j番目の端末370について、第1実施形態と同様にして、各センサユニット350についてフラグflagi,jの値が求められる。なお、データ収集システム300b内のセンサユニット350の総数をUとすると、1≦i≦Uである。つまり、ステップS607では以下の処理が行われる。まず、図12のステップS402と同様に、端末センサ間距離計算部324が、適宜のウィンドウ間隔Wを用いて、ステップS606で抽出したエントリをいくつかのブロックに分割する。ステップS607で得られるブロックの数は、ステップS402でのブロック数とは異なるかもしれないが、以下では説明の便宜上、ステップS607でN個のブロックが得られたとする。なお、個々の端末370がGPSログを送信するタイミングによっては、ブロックの個数Nが端末370ごとに異なる場合もあり得る。さて、その後、端末センサ間距離計算部324と距離比較部325とアラーム決定部334が協働し、第1実施形態の図12のステップS403~S414と同様にして、フラグflagi,jの値を求める。つまり、n番目1≦n≦Nのブロックにおける、j番目の端末とi番目のセンサユニット350との間の距離disti,j,nと、i番目のセンサユニット350についてのアラーム距離alarmiに基づいて、フラグflagi,jの値が求められる。なお、図17のステップS503とS504は、ステップS607に含まれる。フラグflagi,jの値がtrueの場合は、すなわち、i番目のセンサユニット350についてのアラーム指示を出す対象の端末370の候補として、j番目の端末370を、アラーム決定部334が暫定的に選んだという場合である。逆に、フラグflagi,jの値がfalseの場合は、i番目のセンサユニット350についてのアラーム指示を出す対象の端末370の候補として、アラーム決定部334はj番目の端末370を選ばなかったという場合である。以上のようにしてステップS607で得られたフラグflagi,jの値は、第2実施形態では暫定的な値である。より具体的には、フラグflagi,jの値がtrueの場合、値がfalseに変更される余地がある。つまり、フラグflagi,jの値は、次のステップS608で書き換えられることがある。ステップS608の圃場特定アラーム再判定処理の詳細は図19とともに後述するが、ステップS608は図17のステップS505~S506に対応する。そして、ステップS608での再判定により、具体的には、フラグflagi,jの値が場合に応じて書き換えられる。つまり、フラグflagi,jの値は、今日、i番目のセンサユニット350についてのアラーム指示をj番目の端末370に送信するか否かを示す。よって、ステップS608の再判定により、i番目のセンサユニット350についてのアラーム指示の送信が後日に延期されると決まる場合は、ステップS608でフラグflagi,jは、送信しないと示す値つまりfalseに書き換えられる。その後、ステップS609でサーバ310bは、すべての端末370について注目し終えたか否かを判断する。つまり、サーバ310bは、端末370についてのループ変数jの値がデータ収集システム300b内の端末370の総数Tに達したか否かを判断する。そして、j=Tの場合、処理はステップS611に移行する。他方、j≠Tの場合より具体的にはj<Tの場合は、未注目の端末370が残っているので、処理はステップS610に移行する。ステップS610でサーバ310bは、端末370についてのループ変数jをインクリメントする。その後、処理はステップS606に戻る。さて、ステップS611の処理が実行されるのは、データ収集システム300b内のすべてのセンサユニット350と端末370の組み合わせについて、フラグflagi,jが設定された後である。そして、ステップS611の時点でのフラグflagi,jの値は、アラーム指示の送信を後日に延期するか否かについてのアラーム決定部334の再判定結果を反映している。そこで、ステップS611~S616では、再判定結果を反映したフラグflagi,jの値を参照して適宜アラーム指示を送信するための処理が行われる。具体的には、まずステップS611でサーバ310bが、センサユニット350についてのループ変数iを1に初期化する。そして、次のステップS612でアラーム決定部334が、i番目のセンサユニット350に対応するフラグflagi,jの値がtrueの端末370のリストを取得する。ステップS612で取得されるリストは、具体的には端末IDのリストであり、式5の集合targetjを表すリストである。ただし、第2実施形態では、式5のフラグflagi,jは、再判定結果を反映している点で第1実施形態のフラグflagi,jと異なる。そして、次のステップS613でアラーム決定部334は、i番目のセンサユニット350との距離が最短の端末370を、ステップS612で得たリストの中から選択する。なお、例えばj番目の端末370の端末IDがステップS612で得られたリスト中に存在する場合、ステップS613でj番目の端末370に関して参照される距離として、例えば以下のようなものが利用可能である。ステップS607でフラグflagi,jの値を暫定的に求めるのに用いられた、N個のブロックに対応するN個の距離disti,j,1~disti,j,Nの、平均値または最小値が使われてもよい。すると、リスト中の各端末370の休憩時間の直近30分における動きが、ステップS613の選択に反映される。より直近の端末370の位置を重視するならば、最後のブロックつまりN番目のブロックから得られた距離disti,j,Nが使われてもよい。そして、次のステップS614でアラーム決定部334は、ステップS613で選択した端末370に、通信部327を介して、i番目のセンサユニット350に関するアラーム指示を送信する。なお、ステップS612で得られたリストが空リストの場合は、アラーム決定部334はステップS613で何も選択しないので、ステップS614でもアラーム指示の送信は行われない。その後、ステップS615でサーバ310bは、センサユニット350についてのループ変数iの値がデータ収集システム300b内のセンサユニット350の総数Uに達したか否かを判断する。そして、i=Uの場合、今回の休憩時間の開始に合わせて送信する対象のアラーム指示はすべて送信し終わっているので、処理がステップS601に戻る。逆に、i≠Uの場合より具体的にはi<Uの場合は、未注目のセンサユニット350が残っているので、処理はステップS616に移行する。そして、ステップS616でサーバ310bは、センサユニット350についてのループ変数iをインクリメントする。その後、処理はステップS612に戻る。さて、続いて図19を参照して、上記のステップS608の圃場特定アラーム再判定処理について説明する。図18から理解されるとおり、圃場特定アラーム再判定処理は、j番目の端末3701≦j≦Tについて呼び出される。ステップS701で圃場特定部333は、圃場IDリストを空に初期化する。そして、次にステップS702で圃場特定部333は、引数で指定されたj番目の端末370についてステップS606で抽出されたGPSログの各ブロックでの平均座標を取得する。なお、ステップS702で取得する対象の平均座標すなわち、式2のavrj,nは、図18のステップS607でフラグflagi,jの値を暫定的に求めるために、既に端末センサ間距離計算部324が計算済みである。例えば、端末センサ間距離計算部324は、ステップS607で得た各端末370の各ブロックでの平均座標avrj,nの値を、圃場特定部333からもアクセス可能なRAM402上の領域に格納しておいてもよい。すると、ステップS702で圃場特定部333は、単にRAM402からj番目の端末370の各ブロックについての平均座標avrj,nの値を読み出すだけでよい。もちろん、圃場特定部333は、端末センサ間距離計算部324と同様の方法にて、ステップS702で改めて、j番目の端末370の各ブロックでの平均座標avrj,nを計算してもよい。いずれにせよ、圃場特定部333は、j番目の端末370に関して、ブロックの個数Nと同数の平均座標avrj,1~avrj,Nを取得する。そして、圃場特定部333は、取得した各平均座標avrj,n1≦n≦Nについて、圃場形状DB329に形状が登録されている圃場の中から、当該平均座標avrj,nを含む圃場を探す。そして、もし圃場が見つかれば、圃場特定部333は、見つかった圃場の圃場IDを、ステップS701で初期化した圃場IDリストに追加する。ここで、説明の便宜上、圃場形状DB329には、H箇所の圃場の形状が登録されているものとする。すると、n番目のブロックの平均座標avrj,nを含む圃場を探して圃場IDリストを更新する上記の処理は、具体的には例えば以下のような処理である。圃場特定部333は、1番目の圃場から順に注目していく。ここで、圃場特定部333が処理対象として注目しているのがh番目の圃場であるとする1≦h≦H。このとき、圃場特定部333は、h番目の圃場の形状を近似する多角形のすべての頂点の座標つまり緯度と経度を、圃場形状DB329から読み出す。そして、与えられた点が多角形の内部または辺上に位置するか否かを判定するための公知のアルゴリズムにしたがって、圃場特定部333は、平均座標avrj,nがh番目の圃場の内部または境界線上に位置するか否かを判定する。もし、平均座標avrj,nがh番目の圃場の内部または境界線上に位置していれば、圃場特定部333は、h番目の圃場の圃場IDを、圃場IDリストに追加する。なお、圃場特定部333は、n番目のブロックの平均座標avrj,nに関しては、もう残りの圃場に注目する必要はない。逆に、平均座標avrj,nが、h番目の圃場の外部に位置していれば、圃場特定部333は、未注目の圃場が残っているか否かつまりh<Hか否かを判断する。そして、もしh<Hならば、次の圃場に注目して、n番目のブロックの平均座標avrj,nに関する上記の処理を繰り返す。逆に、既にH箇所すべての圃場に注目し終えていれば、n番目のブロックの平均座標avrj,nは、どの圃場から見ても外部に位置しているので、n番目のブロックに関する処理は終了する。以上のようにして、ステップS702で圃場特定部333は、各平均座標avrj,n1≦n≦Nについて、当該平均座標avrj,nを含む圃場を探し、見つかった圃場の圃場IDを圃場IDリストに追加する。例えば、j番目の端末370が、休憩時間の開始30分前からずっと1番目の圃場の中に位置していたとする。すると、圃場IDリストには、1番目の圃場の圃場IDのみが含まれる。あるいは、j番目の端末370が、休憩時間の開始直前の30分間のうち、最初の10分間は1番目の圃場に位置しており、その後移動して、残りの時間はずっと2番目の圃場に位置していたとする。すると、圃場IDリストには、1番目と2番目の圃場の圃場IDが含まれる。以上のようにして、j番目の端末370が休憩時間の開始直前の30分間に位置していたことのある圃場が判明すると、次に、ステップS703でアラーム決定部334は、以下の処理を行う。すなわち、アラーム決定部334は、圃場IDリストに圃場IDが含まれる圃場に設置されたすべてのセンサユニット350のリストを求める。リストは、具体的にはセンサユニットIDのリストとして表される。また、アラーム決定部334は、具体的には、圃場IDリストに含まれる圃場IDを検索キーにして図15の収集日DB328を検索することで、当該圃場IDで識別される圃場に設置されたセンサユニット350のセンサユニットIDを取得することができる。例えば、ステップS702で得られた圃場IDリストに、0005と0007という圃場IDのみが含まれているとする。また、圃場IDが0005の圃場にはセンサユニットIDが0001と0002のセンサユニット350が設置されており、圃場IDが0007の圃場にはセンサユニットIDが0010のセンサユニット350が設置されているとする。すると、アラーム決定部334は、ステップS703で、0001と0002と0010という3つのセンサユニットIDを要素として含むリストを取得する。そして、次のステップS704でアラーム決定部334は、ステップS703で得たリストの各要素に順に注目するためのループ変数bを1に初期化する。また、次のステップS705でアラーム決定部334は、図15の収集日DB328を参照して、ステップS703で得たリスト内のb番目のセンサユニットIDに対応してアラーム予定日が設定されているか否かを判断する。図15に示すように、収集日DB328では、あるセンサユニットIDに対してはアラーム予定日が設定されているかもしれないが、別のあるセンサユニットIDに対してはアラーム予定日が設定されていないかもしれない。そこで、アラーム決定部334は、b番目のセンサユニットIDに対応するアラーム予定日の有無を、収集日DB328を参照して判断する。もし、b番目のセンサユニットIDに対応するアラーム予定日があれば、処理はステップS706に移行する。つまり、過去にアラーム決定部334が後述の図20の処理を行うことで設定されたアラーム予定日が見つかれば、処理はステップS706に移行する。例えば、図16のスケジュール例502の作業1日目に、図20の処理が行われて、作業最終日がアラーム予定日として設定されたとする。この場合、作業2日目に図19の処理が呼び出されると、ステップS705で、設定済みのアラーム予定日が見つかる。逆に、b番目のセンサユニットIDに対応するアラーム予定日がなければ、処理はステップS705からステップS708へと移行する。例えば、図16のスケジュール例501の作業1日目に初めて図19の処理が呼び出された場合には、アラーム予定日がまだ設定されていない。さて、ステップS706が実行されるのは、上記のとおり、リスト中のb番目のセンサユニット350に関して、アラーム予定日が設定されている場合である。この場合、アラーム決定部334は、設定されているアラーム予定日が今日またはそれより前の日付であるか否かを判断する。そして、設定されているアラーム予定日が今日またはそれより前の日付である場合、リスト中のb番目のセンサユニット350に関して、アラーム指示の送信を延期する必要はない。よって、設定されているアラーム予定日が今日またはそれより前の日付である場合は、フラグの暫定的な値を何も変えずに、ただ処理がステップS710へと移行する。つまり、リスト中のb番目のセンサユニット350と、引数で指定されたj番目の端末370の組み合わせに対応するフラグの暫定的な値がtrueであれば、フラグの値はtrueのままでよい。逆に、フラグの暫定的な値がfalseであれば、そもそもリスト中のb番目のセンサユニット350についてのアラーム距離よりも遠くにj番目の端末370がある。つまり、j番目の端末370はそもそも、リスト中のb番目のセンサユニット350に関するアラーム指示の送信対象ではないので、フラグの暫定的な値を書き換える必要がない。よって、設定されているアラーム予定日が今日またはそれより前の日付である場合、フラグの暫定的な値が何であれ、処理はステップS710へと移行する。逆に、既に設定されているアラーム予定日が今日よりも後の日付である場合は、リスト中のb番目のセンサユニット350に関するアラーム指示の送信は、アラーム予定日まで延期可能である。つまり、リスト中のb番目のセンサユニット350に関するアラーム指示は、今日送信する必要がない。そこで、今日の送信をキャンセルするために、処理はステップS707に移行する。そして、ステップS707でアラーム決定部334は、リスト中のb番目のセンサユニット350に関するアラーム指示の今日の送信を強制的にキャンセルする。つまり、アラーム決定部334は、リスト中のb番目のセンサユニット350と、引数で指定されたj番目のセンサユニット350の組み合わせに対応するフラグの値を、暫定的な値がtrueであるかfalseであるかによらず、強制的にfalseに設定する。そして、処理はステップS710に移行する。さて、ステップS708が実行されるのは、リスト中のb番目のセンサユニット350に関してアラーム予定日が設定されていない場合である。この場合、アラーム予定日を新たに設定することができるか否か、すなわち、リスト中のb番目のセンサユニット350に関してアラーム指示の送信を延期する余地があるか否かをアラーム決定部334が判断する。具体的には、ステップS708でアラーム決定部334は、リスト中のb番目のセンサユニット350が設置されている圃場について、今日または明日以降のスケジュールがスケジュールDB330に登録されているか否かを判断する。なお、アラーム決定部334は、収集日DB328を参照することで、リスト中のb番目のセンサユニット350が設置されている圃場の圃場IDを認識することができる。あるいは、アラーム決定部334は、ステップS703の処理を行ったときに、圃場IDとセンサユニットIDの対応関係をRAM402上に記憶しておいてもよい。もし、リスト中のb番目のセンサユニット350が設置されている圃場について、今日または明日以降、スケジュールDB330に1つもスケジュールが登録されていなければ、処理はステップS710に移行する。なぜなら、スケジュールが登録されていなければ、リスト中のb番目のセンサユニット350についてのアラーム指示の送信を延期する余地はないからである。つまり、リスト中のb番目のセンサユニット350と、引数で指定されたj番目の端末370の組み合わせに対して暫定的に決められたフラグの値を書き換える必要がないからである。逆に、リスト中のb番目のセンサユニット350が設置されている圃場について、今日または明日以降、スケジュールDB330に1つ以上スケジュールが登録されていれば、場合によっては、アラーム指示の送信を延期することが可能である。つまり、スケジュールの分布と前回の収集日からの経過時間によっては、リスト中のb番目のセンサユニット350に関するアラーム指示の送信を、明日以降に延期することが可能な場合がある。そこで、延期の可能性を検討し、可能ならばアラーム予定日を設定してアラーム指示の送信を延期するために、処理はステップS709に移行する。そして、ステップS709のスケジュール確認処理では、リスト中のb番目のセンサユニット350に関するアラーム指示の送信の延期の可能性が検討され、可能ならばアラーム予定日が新たに設定される。ステップS709の詳細は図20とともに後述する。また、ステップS709の実行後、処理はステップS710に移行する。さて、ステップS710は、リスト中のb番目のセンサユニット350と、引数で指定されたj番目の端末370の組み合わせに関して、フラグの値を書き換えた後、またはフラグの値を書き換える必要がないと判明した後に、実行される。すなわち、フラグの値が確定すると、ステップS710が実行される。ステップS710でアラーム決定部334は、ステップS703で求めたリスト内の全センサユニット350に注目し終えたか否かを判断する。そして、未注目のセンサユニット350が残っている場合は、処理がステップS711に移行する。逆に、リスト内の全センサユニット350に、アラーム決定部334が既に注目し終えた場合は、図19の圃場特定アラーム再判定処理つまり図18のステップS608も終了する。ステップS711でアラーム決定部334は、センサユニットIDのリスト内の要素に関するループ変数bをインクリメントする。そして、処理はステップS705に戻る。さて、続いて図20を参照して、上記のステップS709のスケジュール確認処理について説明する。図19から理解されるとおり、スケジュール確認処理は、確認の対象として指定された特定のセンサユニット350と端末370の組み合わせに対して呼び出される。つまり、具体的には、図20のスケジュール確認処理は、センサユニットIDと端末IDを引数として呼び出される。ステップS801でアラーム決定部334は、スケジュールの初日として、今日に注目する。以下ではアラーム決定部334が注目している日付を注目日という。そして、次のステップS802でアラーム決定部334は、図20の処理を開始してから今までに数えた作業なし期間の回数が2回未満か否かを判断する。ステップS802の判断が最初に実行される時点では、今までに数えた作業なし期間の回数は当然0回である。なお、ステップS802における2回という閾値は、図15のスケジュール単位定義DB332の作業なし期間の最大回数として定義されている値であり、実施形態に応じて適宜その他の値が用いられてもよい。スケジュール単位定義DB332や図16に関して説明したごとく、作業のひとかたまりの単位は、3日以内の作業なし期間を2回までははさんでいてもよい。しかし、3回目の作業なし期間のところで、作業のひとかたまりの単位は途切れる。よって、今までに数えた作業なし期間の回数が既に2回に達しているならば、注目日から始まって連続する1日以上の作業予定日の最後の日で、作業のひとかたまりの単位は終了する。逆に、今までに数えた作業なし期間の回数が2回未満ならば、注目日から始まって連続する1日以上の作業予定日の最後の日よりもさらに後の日付までを、作業のひとかたまりの単位として見なせる可能性がある。そこで、今までに数えた作業なし期間の回数が既に2回に達していれば、処理はステップS806に移行する。逆に、今までに数えた作業なし期間の回数が2回未満ならば、処理はステップS803に移行する。ステップS803でアラーム決定部334は、引数として指定されたセンサユニットIDのセンサユニット350が存在する圃場における、注目日から始まって連続する作業予定日の後の、次の作業予定日までの作業なし日数を数える。なお、注目日から連続する作業予定日は、1日だけの場合もあるし、2日以上の場合もある。例えば、図16のスケジュール例503の作業1日目が注目日の場合、注目日から始まって連続する作業予定日は3日であり、ステップS803でアラーム決定部334が数えた結果は2日である。ステップS803の処理は、具体的には例えば次のような処理である。アラーム決定部334は、収集日DB328を参照することで、引数として指定されたセンサユニットIDのセンサユニット350が存在する圃場の圃場IDを特定する。そして、アラーム決定部334は、特定した圃場IDを検索キーにしてスケジュールDB330を検索し、注目日から連続する作業予定日の後の次の作業予定日までの作業なし日数を数える。なお、図20の処理は、図19のステップS708で今日または明日以降のスケジュールがスケジュールDB330に登録されていると確認されたときに実行される。そして、説明の簡単化のため、スケジュールDB330が正しいすなわち、スケジュールどおりにユーザが作業を行うと仮定するならば、少なくとも今日は何らかの作業が予定されているはずである。なぜなら、以下のように考えられるからである。今日、ある圃場で作業が予定されており、その予定にしたがってユーザが当該圃場にいたからこそ、ユーザが携帯する端末370が当該圃場に存在していることが図19のステップS702で検出された。その結果、当該圃場に設置されたセンサユニット350と、上記ユーザの携帯する端末370の組み合わせに対して、図19のステップS709から、図20の処理が呼び出された。よって、図20の処理が呼び出される場合、引数として指定されたセンサユニットIDのセンサユニット350が存在する圃場に関して、少なくとも今日は何らかの作業が予定されている。したがって、ステップS803では、引数として指定されたセンサユニットIDのセンサユニット350が存在する圃場において、注目日から始まる1日以上の連続した作業予定日が存在する。ただし、注目日から始まる1日以上の連続した作業予定日の後の、次の作業予定日は、あるとは限らない。例えば、図16のスケジュール例502において、注目日が作業1日目の場合、注目日から始まる1日以上の連続した作業予定日は、作業1日目から作業最終日までの3日間である。しかし、当該3日間の後には何の予定もまだないので、次の作業予定日は見つからない。このように、次の作業予定日がない場合、アラーム決定部334は、ステップS803において、次の作業予定日までの作業なし日数は、無限大であると認識する。以上のようにしてステップS803で作業なし日数を数えた後、アラーム決定部334は、ステップS804において、作業なし日数が3日より多いか否かを判断する。なお、ステップS804における3日という閾値は、図15のスケジュール単位定義DB332の作業なし期間の最大長さとして定義されている値であり、実施形態に応じて適宜その他の値が用いられてもよい。スケジュール単位定義DB332や図16に関して説明したごとく、作業なし日数が3日より多ければ、そこで作業のひとかたまりの単位は途切れる。そこで、処理はステップS806に移行する。逆に、作業なし日数が3日以内であれば、作業のひとかたまりの単位がまだ終わっていない可能性がある。そこで、処理はステップS805に移行する。ステップS805でアラーム決定部334は、ステップS803で日数を数えた作業なし日をはさんだ、次の作業予定日に注目する。例えば、図16のスケジュール例503において、現在の注目日が作業1日目の場合、ステップS805で作業再開1日目が新たな注目日として注目される。そして、アラーム決定部334が注目日を更新すると、処理はステップS802に戻る。ステップS806でアラーム決定部334は、注目日から連続する1日以上の作業予定日の最後の日を、ひとかたまりのスケジュールの最終日として決定する。例えば、ステップS805に関して例示したように、図16のスケジュール例503の作業再開1日目が新たな注目日となった場合は、その後のステップS803で数えられる作業なし日数は無限大である。よって、処理はステップS804からステップS806へと進む。そして、ステップS806でアラーム決定部334は、注目日である作業再開1日目から連続する作業予定日の最後の日つまり、図16に示す再開後作業最終日を、ひとかたまりのスケジュールの最終日として決定する。なお、スケジュールDB330に登録されているスケジュールによっては、ステップS806で決定される最終日が、今日と一致する場合もある例えば、今日1日だけ作業が予定されており、明日以降の予定がまったくない場合など。また、次のステップS807でアラーム決定部334は、ステップS801で注目した初日すなわち今日における、前回のデータ収集からの経過日数と閾値を比較する。より具体的には、アラーム決定部334は、引数で指定されるセンサユニットIDを含むエントリを図15の収集日DB328で検索し、見つかったエントリの収集日を読み取る。そして、アラーム決定部334は、図20の処理を行っている今日の日付から、読み取った収集日を引くことで、経過日数を計算する。また、ステップS807で参照される閾値は、実施形態に応じて適宜定められる。例えば、10日などと固定の閾値が使われてもよい。あるいは、ステップS807で参照される閾値は、引数で指定されるセンサユニットIDに依存する値であってもよい。例えば、アラーム決定部334は、引数で指定されたセンサユニットIDと対応づけられているアラーム条件IDを図6のセンサユニット別アラーム条件DB319から読み取る。そして、アラーム決定部334は、読み取ったアラーム条件IDに対応するエントリをアラーム条件DB320で検索する。そして、アラーム決定部334は、見つかったエントリのアラーム条件で使われる境界値のうち、最大のものを、ステップS807での閾値として利用してもよい。例えば、図6のセンサユニット別アラーム条件DB319の例では、0002というセンサユニットIDに対応するアラーム条件IDは01である。そして、01というアラーム条件IDで識別されるアラーム条件で使われる最大の境界値は、図6のアラーム条件DB320の例では、条件4フィールドに設定されている10日という値である。よって、0002というセンサユニットIDが図20の処理の引数として与えられた場合、アラーム決定部334は、ステップS807での閾値として10日を利用してもよい。もちろん、実施形態によっては、アラーム決定部334は、上記のようにして見つかったアラーム条件で使われる境界値のうち2番目に大きなものを使ってもよいし、あるいは、最大の境界値から所定値例えば1日を引いた値を使ってもよい。なお、具体的にどのような閾値が利用されるにしろ、初日における経過日数が閾値以上のとき、図20のスケジュール確認処理は終了する。つまり、初日における経過日数が閾値以上のとき、アラーム決定部334は初日の時点で既にアラーム指示の送信を延期する余地がないと判断する。よって、引数として与えられたセンサユニットIDと端末IDの組に対応して図18のステップS607で求められたフラグは、書き換え不要である。そのため、初日における経過日数が閾値以上のときは、フラグの書き換えは行われず、そのままスケジュール確認処理が終了する。逆に、初日における経過日数が閾値未満の場合、アラーム指示の送信を延期する余地があるかもしれない。そこで、処理はステップS808に移行する。ステップS808でアラーム決定部334は、ステップS806で決定した最終日における、前回のデータ収集からの経過日数と閾値を比較する。アラーム決定部334は、最終日から、ステップS807で読み取った収集日を引くことで、最終日における経過日数を計算する。また、ステップS808で使われる閾値は、ステップS807で使われる閾値と同じものである。最終日における経過日数が閾値未満であれば、アラーム指示の送信を最終日まで延期することは妥当である。そこで、処理はステップS809に移行する。逆に、最終日における経過日数が閾値以上であれば、処理はステップS810に移行する。例えば、閾値が7日であり、前回の収集が2日前であり、今日から15日間連続で作業が予定されているといった場合など、作業のひとかたまりの単位が長期間に及ぶ場合があり得る。そのような場合には、最終日よりも前にサーバ310bが一旦センサログを収集することが好ましい。そのため、ステップS808でアラーム決定部334は最終日における経過日数と閾値を比較している。さて、ステップS809でアラーム決定部334は、図15の収集日DB328にアラーム予定日を設定する。具体的には、アラーム決定部334は、引数で指定されたセンサユニットIDに対応する収集日DB328のエントリを検索し、見つかったエントリのアラーム予定日に、ステップS806で決定した最終日の日付を設定する。さらに、ステップS809でアラーム決定部334は、引数で指定されたセンサユニットIDと端末IDの組み合わせに対応して図18のステップS607で求められたフラグの値を、flaseに設定する。つまり、アラーム決定部334は、今日は、引数で指定されたセンサユニットIDに関して、引数で指定された端末IDの端末370にアラーム指示を送信しないと決定する。そして、図20のスケジュール確認処理は終了する。また、ステップS810でアラーム決定部334は、図15の収集日DB328にアラーム予定日を設定する。具体的には、アラーム決定部334は、ステップS807で読み取った前回の収集日に、ステップS807とS808で使った閾値を足し、前回の収集日から閾値のぶんだけ経過した日付を計算する。また、アラーム決定部334は、引数で指定されたセンサユニットIDに対応する収集日DB328のエントリを検索し、見つかったエントリのアラーム予定日に、上記の計算で得られた日付を設定する。さらに、ステップS810でアラーム決定部334は、引数で指定されたセンサユニットIDと端末IDの組み合わせに対応して図18のステップS607で求められたフラグの値を、flaseに設定する。つまり、アラーム決定部334は、今日は、引数で指定されたセンサユニットIDに関して、引数で指定された端末IDの端末370にアラーム指示を送信しないと決定する。そして、図20のスケジュール確認処理は終了する。以上のようにして、図20のスケジュール確認処理により、アラーム指示の送信の延期の妥当性が検討され、検討結果に応じてフラグが書き換えられる。よって、書き換え後のフラグに応じて図18のステップS611~S616の処理が行われることで、不急のアラーム指示の送信が抑制される。なお、以上の図18~20の処理についてまとめれば以下の通りである。サーバ310bは、センサユニット350が設置された領域における作業のスケジュールを認識し、端末370にアラームを出させるつまりユーザへの指示を与えさせる日または日時を、スケジュールに応じて決定する。具体的には、図20のステップS807に示すように、所定の基準よりも経過時間が長ければ、サーバ310bは、日または日時を決定する処理が行われる当日を、端末370にアラームを出させる日として決定する。逆に、所定の基準よりも経過時間が短ければ、サーバ310bは、スケジュールによって作業が計画されている日と計画されていない日の分布に基づいて、端末370にアラームを出させる日または日時の延長期限を決定する。例えば、図20の例では、ステップS801~S806で認識された分布に基づいて、ステップS809またはS810で延長期限が決定されている。そして、延長期限の決定は、例えば以下のような情報と上記分布を照らし合わせた結果に基づく。作業なし期間の長さの上限と、作業なし期間の回数の上限の少なくとも一方例えば、スケジュール単位定義DB332の例では双方前回のデータ収集時点からの時間の長さの上限例えば、図20のステップS807~S810で使われる閾値そして、サーバ310bは、アラーム指示の与え方を制御することで、端末370に、決定された日または日時にアラームをユーザに与えさせる。アラーム指示の与え方を制御する方法としては、上記のように、アラーム指示を端末370に与えるタイミングを、決定された日または日時に応じてつまり、アラーム予定日や休憩時間などに応じて制御する方法がある。あるいは、サーバ310bは、アラーム指示の与え方を制御する方法として、アラームをユーザに与える日または日時を指定する情報をアラーム指示に含めて端末370に送るという方法を採用してもよい。ところで、本発明は上記の第1~2実施形態に限られるものではない。上記の説明においてもいくつかの変形について説明したが、上記実施形態は、さらに例えば下記の1~9の観点から様々に変形することもできる。上記および下記の変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。1ハードウェア構成についての変形図4には、プログラムにしたがって動作する汎用的なプロセッサすなわち、CPU401、MPU422、およびMPU442が例示されている。しかし、汎用的なプロセッサの代わりに、ASICApplicationSpecificIntegratedCircuitなどの専用のハードウェア回路が利用されてもよいし、汎用的なプロセッサと専用のハードウェア回路の組み合わせが利用されてもよい。2データ構造についての変形また、図面では便宜上、各種DBをテーブル形式で表現しているが、各種DBのデータ構造は実施形態に応じて適宜変形されてもよい。例えば、アレイや連想配列などが利用されてもよいし、XMLExtensibleMarkupLanguageなどによりマークアップされた形式のデータが利用されてもよい。また、例えばセンサユニットIDを一意のキーとして含む複数のDBが、1つのテーブルにまとめられてもよい。また、センサログは、図7のように1つのエントリが複数のセンサについてのフィールドを有する形式でもよいし、1つのエントリが1つのセンサについてのフィールドとセンサを識別するフィールドを有する形式であってもよい。3数値の計算方法についての変形実施形態によっては、式3の代わりに式6が使われてもよい。また、式4の代わりに式7が使われてもよい。さらに、式2などで使われるウィンドウ間隔Wの値が1であってもよいつまり、ウィンドウが利用されなくてもよい。なお、式7のようにN個のブロック間で距離を平均する代わりに、N個のブロック間で最小距離を求めてもよい。また、実施形態によっては、アラーム距離が、離散的に図6のようにDBにより定義されるのではなく、経過時間pを引数とする連続関数fpにより定義されてもよい。経過時間pに対して単調増加する適宜の関数が、アラーム距離を定義する関数fpとして利用可能である。もちろん、図6のアラーム条件DB320と同様に境界値を規定するDBと、境界値同士の間の補間によって、アラーム距離が連続的に定義されてもよい。つまり、アラーム距離は、経過時間につれて増大するように定義されてさえいれば、どのような形式で定義されていてもよい。4閾値その他の定数についての変形上記に説明したいくつかの処理は、閾値との比較を含む例えば、図12のステップS408や、図20のステップS807とS808など。閾値との比較は、実施形態に応じて比較対象の数値が、閾値を超えるか否かを判断する処理でもよいし、比較対象の数値が、閾値以上か否かを判断する処理でもよい。また、上記の説明における各種定数の例は、説明の便宜上のものである。各種定数の具体的な値は、実施形態に応じて適宜に決められてよい。5センサユニットの設置場所に関する変形なお、図2と13には、センサユニット202が圃場201に設置される例を示したが、センサユニット202が設置される場所は、端末370のユーザのうち少なくとも1人が何らかの作業を行う任意の領域であってよい。センサユニット202は、例えば、以下のような場所に設置されてもよい。また、当該場所における作業スケジュールが第2実施形態と同様にして参照され、アラーム予定日の決定のために用いられてもよい。水田、畑をはじめとする各種圃場林班、準林班、林小班などの、林業用に区切られた森林区画放牧場、養鶏場、養豚場、養牛場など、畜産業が営まれる場所養魚場、その他の水生生物藻類、海老、真珠などの養殖場人工池でもよいし、自然の湖沼、河川、港湾等の特定部分でもよいなど、水産業が営まれる場所養蜂場など、その他の生き物を飼養するための場所鉱山、採石場、砂利採取場など、鉱業が営まれる場所土木工事現場、建設現場など、建設業が営まれる場所圃場をはじめとして、上記に例示したような場所は、広い屋外であることが多いので、データ収集に関与するためのユーザの負担例えば移動距離の長さを無視しがたい。よって、上記に例示したような場所にセンサユニット350が設置されている場合に、データ収集システム300や300bは好適である。また、農林水産業などの第一次産業では特に、毎日同じ場所での作業が予定されているとは限らない。つまり、毎日データ収集が可能であるとは限らず、データ収集の緊急度が日によって変動し得る。よって、農林水産業等に関連する上記のような場所に設置されたセンサユニット350を含むシステムとして、データ収集システム300や300bは好適である。また、データ収集システム300bは、作業スケジュールと経過時間に基づいて柔軟にアラーム予定日を適宜延期するという点においても、毎日同じ場所での作業が予定されているとは限らない農林水産業向けのシステムとして好適である。6端末370間の比較を第1実施形態に導入する変形ところで、第1実施形態と第2実施形態を比べると、第2実施形態では図18のステップS613で端末370間の比較が行われるのに対し、第1実施形態では端末370間の比較は行われない。しかし、ある1台のセンサユニット350からアラーム距離の範囲内に、複数のユーザがいる場合もあり得る。よって、端末370間の比較をサーバ310が行うように、第1実施形態が変形されてもよい。具体的には次のとおりである。ある1台のセンサユニット350からアラーム距離の範囲内に、複数のユーザがいるとする。この場合、ユーザの負荷軽減という観点からは、サーバ310は、複数のユーザがそれぞれ携帯する複数の端末370のうち、センサユニット350により近い一部の端末370にのみ、アラーム指示を送信することが好ましい。例えば、サーバ310は、センサユニット350に最も近い1台の端末370にのみ、アラーム指示を送信してもよい。そして、センサユニット350からアラーム距離の範囲内の複数の端末370の中から一部だけをアラーム指示の送信対象として選び出すためには、サーバ310は、端末370間でセンサユニット350までの距離を比較すればよい。例えば、サーバ310は、図12のように個々の端末370からステップS401でGPSログを受信するたびにステップS402~S415の処理を行うのではなく、GPSログの受信と蓄積を行う処理と、アラーム指示の送信に関する処理を独立して行ってもよい。例えば、サーバ310は、いずれかの端末370からGPSログを受信するたびに、GPSログDB311にGPSログを蓄積する。一方で、サーバ310は、所定の間隔で例えば1時間ごとに、次のような処理を行ってもよい。サーバ310は、直近の所定の時間例えば上記間隔と同じ1時間でもよいし、より短い15分などの時間でもよいに受信されたGPSログを、GPSログDB311から抽出する。そして、サーバ310は、抽出したGPSログについて、端末370ごとに、図12のステップS402~S413と同様の処理を行う。その後、サーバ310は、各センサユニット350について、当該センサユニット350に対応するフラグの値がtrueの端末370の端末IDを抽出する。もし、2台以上の端末370の端末IDが抽出された場合、サーバ310は、当該センサユニット350までの距離が一番短い端末370を選択する。ここで、端末370間での比較のために使われるセンサユニット350までの距離としては、例えば、複数のブロックについてそれぞれステップS407で計算された距離の最小値または平均値が利用可能である。あるいは、最新のブロックについてステップS407で計算された距離が利用されてもよい。以上のようにしてサーバ310は、各センサユニット350に関して端末370を選択し、当該センサユニット350についてのアラーム指示を、選択した端末370に対してのみ送信してもよい。すると、あるセンサユニット350の近辺に大勢のユーザがいる場合に、全員の端末370がアラームを発してしまうといった事態が避けられるようになり、複数のユーザ全体での作業効率の悪化を防ぐことができる。なお、以上のような第1実施形態の変形例と図13~20の第2実施形態は、あるセンサユニット350からの距離がアラーム距離未満の端末370が2台以上ある場合に、アラーム指示を与える対象の端末370を絞り込むという点で共通である。その絞り込みは、具体的には、センサユニット350からの距離がアラーム距離未満の端末370のうちで、相対的に距離が短い端末370に絞り込むという処理である。そして、以上の絞り込みにより、第1実施形態の変形例でも、第2実施形態でも、複数のユーザ全体での作業効率の悪化を防ぐことができる。7休憩時間に関する変形ところで、第2実施形態では、図15の休憩時間DB331のような静的なデータに基づいて、図18のステップS603で現在が休憩時間か否かという判断が下される。しかし、例えば、サーバ310bは、GPSログDB311に基づいて端末370が存在する位置を追跡することで、動的に休憩時間を認識してもよい。例えば、端末370が所定の時間以上、1箇所に留まっている場合に、サーバ310bは、当該端末370のユーザは休憩中であると判断してもよい。また、圃場ごとに休憩時間が異なる場合は、休憩時間DB331のデータ構造が、圃場ごとに休憩時間を管理するように変形されてもよい。そして、サーバ310bは、個々の圃場について、当該圃場での休憩時間になったら、当該圃場に設置されているセンサユニット350のみを対象として、図18のステップS604~S616と同様の処理を行ってもよい。8アラーム指示の送信タイミングに関する変形図18のステップS603では、現在時刻が休憩時間に該当するか否かが判断される。しかし、サーバ310bは、例えば休憩終了時刻よりも所定時間だけ前の時刻にステップS604以降の処理を行うことで、ユーザが休憩終了直後、作業を始める前にデータ収集に関与することができるようにしてもよい。あるいは、サーバ310bは、例えば休憩開始時刻よりも所定時間だけ前の時刻にステップS604以降の処理を行ってもよい。その場合、サーバ310bは、さらに、アラーム指示の送信のタイミングを調整してもよい。つまり、サーバ310bは、休憩時間に応じて決まる適宜の時刻にアラームがユーザに与えられるようにアラーム指示の与え方を制御すればよく、休憩時間に応じて決まる適宜の時刻が具体的にどのような時刻であるかは、実施形態によって異なっていてよい。例えば、12時から13時が休憩時間であり、上記の所定時間が10分間とする。この場合、サーバ310bは、GPSログの受信および蓄積とは独立して、11時50分になったらステップS604以降の処理を開始してもよい。端末370のユーザは、必ずしも予定どおり12時きっかりに休憩を始めるとは限らない。例えば、ユーザは、12時よりも少し前から休憩し始めて、昼食をとるために圃場から出て行こうとするかもしれない。このような状況を想定すると、ユーザが圃場から出て行ってセンサユニット350から遠ざかってしまう前に、確実に端末370がアラームを発するようにするために、サーバ310bが11時50分にステップS604以降の処理を行うことは有意義である。なお、その結果として11時50分に端末370がアラームを発した場合であっても、ユーザは12時から休憩をとるかもしれない。たとえそうだとしても、ユーザは、アラームを受けた後、自分の都合のよいとき例えば12時になったときにアラームにしたがってセンサユニット350に近寄ればよい。また、あるセンサユニット350についてのアラーム距離が長い場合、当該センサユニット350に関するアラーム指示は、当該センサユニット350から遠く離れた端末370へと送信される可能性がある。そして、センサユニット350からの距離が長いほど、ユーザがセンサユニット350まで移動するのにかかる時間も長い。例えば、サーバ310bが、あるセンサユニット350から歩いて5分の距離にいるユーザの端末370にアラーム指示を送信する場合、サーバ310bは、休憩開始時刻の5分以上前にアラーム指示を送信してもよい。すると、端末370からアラームを受けたユーザは、アラームにしたがってセンサユニット350まで移動してデータ収集に関与しても、データ収集に関与することで休憩時間が減ってしまうということがない。つまり、サーバ310bは、休憩開始時刻よりも所定時間前例えば11時50分になったら、ステップS604~S610の処理を行い、さらに、各センサユニット350についてステップS612とS613の処理を行ってもよい。そして、i番目のセンサユニット350についてのアラーム指示の送信先としてステップS613で選んだ端末370からの、i番目のセンサユニット350までの距離に応じて、サーバ310bがアラーム指示の送信時刻を決めてもよい。例えば、サーバ310bは、ステップS613で選んだ端末370がi番目のセンサユニット350から遠いほど、送信時刻を早くしてもよい。そして、送信時刻になったら、サーバ310bは、アラーム指示を送信する。以上述べたとおり、休憩時間の開始に合わせてユーザにデータ収集に関与させる場合は、サーバ310bが休憩開始時刻よりも前にステップS604以降の処理を開始することが有益である。なお、上記とは逆に、サーバ310bは、ステップS613で選んだ端末370がi番目のセンサユニット350から遠いほど、送信時刻を遅くしてもよい。例えば、もし端末370のユーザがセンサユニット350から歩いて1分の距離にいるのであれば、データ収集への関与の手間はさほど大きくない。そこで、休憩時間に入る前にユーザがデータ収集への関与をさっさと済ますことができるように、サーバ310bは、早め例えば11時50分にアラーム指示を送信してもよい。他方、もし端末370のユーザがセンサユニット350から歩いて15分の距離にいるのであれば、例えばサーバ310bは休憩開始時刻まで待ってから端末370にアラーム指示を送信してもよい。つまり、センサユニット350から遠くにいるユーザに関しては、サーバ310bは、休憩開始時刻まではユーザの作業をアラームによって邪魔しないことを優先させてもよい。9スケジュール確認処理に関する変形図20のスケジュール確認処理のステップS810によれば、アラーム予定日がたまたま途中の作業なし日にあたってしまう場合もあり得る。そこで、アラーム決定部334は、前回のデータ収集日に閾値を足した日が作業なし日にあたる場合は、当該作業なし日よりも前で当該作業なし日の直近の作業予定日を、アラーム予定日として決定してもよい。例えば、図20のステップS807~S810で使われる閾値が10日であるとする。すると、図16のスケジュール例504のように、前回のデータ収集日から10日後が作業なし日にあたる場合もある。この場合、アラーム決定部334は、当該作業なし日よりも前で当該作業なし日の直近の作業予定日スケジュール例504の例では、前回収集日から7日後の作業最終日を、アラーム予定日として設定してもよい。また、図20のスケジュール確認処理では、アラーム決定部334が作業のひとかたまりの単位を認識するが、作業のひとかたまりの単位をどのように定義するかは、実施形態に応じて任意である。図15のスケジュール単位定義DB332とは異なる基準で、作業のひとかたまりの単位が定義されてもよい。つまり、作業のひとかたまりの単位に関しては、その中に含まれる作業予定日と作業なし日の分布に関する何らかの基準が与えられさえすればよく、具体的にどのような基準が使われるかは、実施形態に応じて任意である。例えば、スケジュール単位定義DB332により与えられる基準の代わりに、以下のような基準を適宜に組み合わせた基準が利用されてもよい。開始日と終了日には作業が予定されていること作業なし日の比率が所定値例えば25以下であること作業なし日の合計日数が所定値例えば6日以下であること最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。付記1コンピュータに、前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第1の位置を認識し、前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な1台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識し、前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得し、前記1台以上の端末のうち少なくとも1台の端末について、当該端末の存在する第2の位置を認識し、前記第1の位置と前記第2の位置の間の距離を計算し、前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第1の指示を当該端末のユーザに対して与えるよう、第2の指示を与えることを含む処理を実行させるプログラム。付記2前記データ記憶装置は、前記1台以上の端末それぞれのユーザのうち少なくとも1人が作業を行う領域に設置されており、前記プログラムが前記コンピュータに実行させる前記処理が、さらに、前記領域における前記作業のスケジュールを認識し、前記端末に前記第1の指示を与えさせる日または日時を、前記スケジュールに応じて決定し、前記第2の指示の与え方を制御することで、前記端末に、決定された前記日または前記日時に前記第1の指示を前記ユーザに与えさせる、ことを含むことを特徴とする付記1に記載のプログラム。付記3前記日または前記日時を決定する処理は、所定の基準よりも前記経過時間が長ければ、前記日または前記日時を決定する前記処理が行われる当日を、前記端末に前記第1の指示を与えさせる日として決定し、前記基準よりも前記経過時間が短ければ、前記スケジュールによって前記作業が計画されている日と計画されていない日の分布に基づいて、前記端末に前記第1の指示を与えさせる前記日または前記日時の延長期限を決定することを含むことを特徴とする付記2に記載のプログラム。付記4前記延長期限を決定する処理が、前記作業が計画されていない日が連続する作業なし期間の長さの上限と、前記作業なし期間の回数の上限の少なくとも一方と、前記収集時点からの時間の長さの上限を前記分布と照らし合わせた結果に基づくことを特徴とする付記3に記載のプログラム。付記5前記プログラムが前記コンピュータに実行させる前記処理が、さらに、前記作業の休憩時間に応じて決まる時刻に、前記端末に前記第1の指示を与えさせるように、前記第2の指示の与え方を制御することを含むことを特徴とする付記3または4に記載のプログラム。付記6前記プログラムが前記コンピュータに実行させる前記処理が、さらに、前記休憩時間を表す情報を読み出すこと、または、前記第2の指示を与える対象の前記端末が存在する位置を追跡することにより、前記休憩時間を認識することを含むことを特徴とする付記5に記載のプログラム。付記7前記第2の指示の与え方を制御する処理は、前記第2の指示を前記端末に与えるタイミングを、決定された前記日または前記日時に応じて制御するか、または、決定された前記日または前記日時を指定する情報を、前記第2の指示に含めることを含むことを特徴とする付記2から6のいずれか1項に記載のプログラム。付記8前記プログラムが前記コンピュータに実行させる前記処理は、前記1台以上の端末のいずれかから、前記データ記憶装置から当該端末に転送されて格納されたデータを、前記コンピュータが受信するたびに、当該データを前記コンピュータが受信した収集時点を記憶することを含み、前記経過時間を認識する処理は、記憶された前記収集時点と現在日時に基づいて前記経過時間を計算することを含むことを特徴とする付記1から7のいずれか1項に記載のプログラム。付記9前記1台以上の端末と前記データ記憶装置との間の通信は無線通信であり、前記第1の指示は、前記ユーザに対して前記データ記憶装置へ接近することを求める指示であることを特徴とする付記1から8のいずれか1項に記載のプログラム。付記10前記1台以上の端末の数は複数であり、前記プログラムが前記コンピュータに実行させる前記処理は、前記複数の端末のうち少なくとも2台以上の端末について、前記第1の位置と前記第2の位置の間の前記距離を計算し、前記距離が前記閾値未満の端末が2台以上ある場合、前記第2の指示を与える対象の端末を、前記距離が前記閾値未満の端末のうちで相対的に前記距離が短い端末に絞り込むことを含むことを特徴とする付記1から9のいずれか1項に記載のプログラム。付記11情報処理装置であって、前記情報処理装置が収集する対象のデータを記憶しているデータ記憶装置が設置されている第1の位置を示す位置情報を記憶する記憶手段と、前記データ記憶装置と通信可能な1台以上の端末の各々との通信を行う通信手段と、前記データ記憶装置に記憶されていたデータを、前記1台以上の端末のいずれかと前記通信手段を介して過去に前記情報処理装置が収集した収集時点からの経過時間を認識し、前記経過時間が長いほど大きくなるように定義された閾値を、認識した前記経過時間に基づいて取得する取得手段と、前記1台以上の端末のうち少なくとも1台の端末について、当該端末の存在する第2の位置を認識する位置認識手段と、前記記憶手段から前記位置情報を読み出し、前記位置情報が示す前記第1の位置と、前記位置認識手段が認識した前記第2の位置との間の距離を計算する計算手段と、前記計算手段が計算した前記距離が、前記取得手段が取得した前記閾値未満のとき、前記計算手段が前記距離の計算に用いた前記第2の位置に存在すると前記位置認識手段により認識された当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第1の指示を当該端末のユーザに対して与えるよう、第2の指示を与える指示手段を備える情報処理装置。付記12コンピュータが、前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第1の位置を認識し、前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な1台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識し、前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得し、前記1台以上の端末のうち少なくとも1台の端末について、当該端末の存在する第2の位置を認識し、前記第1の位置と前記第2の位置の間の距離を計算し、前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第1の指示を当該端末のユーザに対して与えるよう、第2の指示を与えることを特徴とする方法。"