日誌~

日誌とは、区画・ゾーン・サイトについて、選んだ期間の間に何を育て、何を測定し、どう制御したかを記録した特定時点のスナップショットです — 認証機関や次作の栽培者に引き渡すことも、単に自分の記録として残しておくこともできる文書です。

日誌は Additional Features > Journals（/geo/journal）にあります。

ライブレポートではなくスナップショット

日誌は一度生成されると、二度と再計算されません。あとで配線やプログラムが変わっても、すでに保存された日誌は作成された時点で正しかった内容をそのまま示し続けます — それこそが記録を残す意味です。

日誌を生成する~

area（エリア）（サイトまたはゾーン）を選びます。
日誌がひとつの区画についてのものであれば、エリアの下に履歴リストが現れます — その土地を占めたことのある、過去・現在すべての作期（「区画」）が、作物・品種・名前・施設／棟／ゾーン／サイト・プログラムで絞り込める形で並びます。ひとつ選ぶと、その作期の実際の日付から開始日・終了日が自動的に入力されます。
ひとつの区画ではなくエリア全体を対象にするには、区画のフィールドを Whole area のままにしておきます。
その対象が実際に持っている測定項目のチェックリストから、含める内容を選びます。バッテリー電圧・RSSI/SNR・ファームウェアバージョンといったデバイスの診断チャネルは、デフォルトではチェックが外れています — 文書に含めたい場合はオンにしてください。
記録単位を選びます: Automatic（自動、デフォルト）、Daily（日次）、Weekly（週次）、Monthly（月次）。
開始日と終了日を設定し、Generate journal を押します。

日誌はバックグラウンドで作成されます — ページはそのまま日誌の固定リンクに移動し、完成するまで「Generating…」と表示されます。後で戻ってきても、ページを開いたままにしておいても構いません。表示は自動的に更新されます。

大きすぎる選択は削られるのではなく拒否される

非常に広いエリアや非常に長い期間を選ぶと、生成が始まる前に拒否され、エリアを狭めるか期間を短くするようメッセージが表示されることがあります。日誌が、頼んだ内容の一部を黙って削ってしまうことは決してありません — 完全に見えるのに実は不完全な文書は、エラーになるよりも悪いものです。

記録単位 — 日次・週次・月次~

データは内部では常に日次の粒度で保持されています。「記録単位」が制御するのは、完成した文書がそれをどう折りたたんで読みやすくするかだけです。

Automatic は、期間の最初のおよそ2か月は日次の行のまま保ち、それ以降は週次に切り替えます — そうしないと、1年分の日誌がほとんど同じ内容の行が何百も並ぶものになってしまいます。
Daily / Weekly / Monthly は、期間の長さにかかわらずそのグルーピングを強制します。
折りたたみは一方向にしか行えません — 週次・月次の日誌はその粒度でしか文書として保存されていないため、あとから日次に戻すことはできません。
週は暦の月曜日ではなく、記録自体の開始日を起点とします — 第1週はその期間（または区画の作期）の最初の7日間であり、これは実際の作期の数え方に合わせたものです。Monthly のみが暦の月に従います。

文書の内容~

Section（項目）	Content（内容）
Overview	何を・どこで、期間、プログラム（区画のみ）、面積、タイムゾーン
Stages	区画の場合: 各ステージのガイダンス、目標、そしてそのステージの実際の期間に実際に何が起きたか — 目標に対する実測の最小・最大・平均、ノート、写真
Log	1日ごと（または週次・月次、上記参照）に1エントリ — 目標に対する環境の最小・最大・平均、積算温度と積算光量、灌漑、制御デバイスの稼働時間、その日に書かれたノート

環境の値には目標とΔ（差）が付きます — ただし、それはプログラムがその測定項目について目標をひとつでも定義している場合に限られます。昼または夜に固有の目標 — あるいはカーブで表される目標 — は、それぞれの時間帯に測定された実測値と比較されます。その区画に該当する測定を行うセンサーが存在しない場合は、ありもしない数値を推測して埋めるのではなく、ログにその旨がはっきりと記されます。
その対象・サイトにそもそも何の目標も定義されていない場合は、TargetとΔの列は空欄で表示されるのではなく、ログの表から完全に省かれます。
メーターの使用量（たとえば水流量計）は、そのメーター自身が記録した読み取り値から求めたその日の使用量として表示されます — どのメーターがどのデバイスに対応しているかをシステム側が記録していないため、特定の1台のバルブの使用量として割り当てて表示されることはありません。
区画・ゾーン・サイト、その中にある何か、あるいは単にその中の地図上の位置に留められたノートは、いずれも書かれた日に表示されます。
この文書が値を取得しているデバイスに関するノートも表示されます — センサーの不具合、修理、バルブの点検など。これらは値を読み解くために必要な文脈です。値の欠落や不自然な読み取りの多くは、そこで説明が付きます。デバイス名がノートの前に表示され、座標は不要です。ノートは日誌が作成されたときに取り込まれるため、既存の日誌にあとから反映させるには再生成が必要です。
期間内でまだ始まっていないステージは、暗く表示され「planned」バッジが付きます — ガイダンスと目標は印刷されますが、まだ何も測定されていません。
ログの行はアルファベット順ではなく、固定された読み取り順に従います: 光 → DLI → CO₂ → 温度・湿度 → VPD → 水 → 風 — これは栽培者が実際に考える順序です。屋内と屋外の実測はふたつの別々の表ではなく、ひとつの表の中でサイドインジケーターにより区別されます。ある測定項目をセンサーがちょうど1台だけカバーしている場合、列にはそのセンサー自身のチャネル名が付きます。複数ある場合は、一般的な測定名に戻ります。

積算温度（GDD）~

プログラムに基準温度が設定されている場合、日誌は作期の開始からの積算温度と、その日（またはその単位）ごとの寄与分を示します。

積算温度を計算できない場合は、その行そのものが表から消えてしまうのではなく、数値の代わりに計算できなかった理由が表示されます。

Reason（理由）	Message（メッセージ）
対象にプログラムが設定されていない	"No program attached"
プログラムに基準温度が設定されていない	"The program has no base temperature"
温度履歴が不足している、センサーがない、または作期が始まったばかり	"Not enough measured days"

「1日」とは、UTCでもサーバーのタイムゾーンでもなく、対象自身のタイムゾーンにおける暦日を意味します。

光合成光量（DLI）~

Daily Light Integral（日積算光量、DLI）は、他の環境値とまったく同じ方法（実測値／目標／Δ）で、プログラムが定めた目標と比較されます。

その区画に適切な単位で光を直接測定できるセンサーがない場合、DLIの値は推定によって求められ、「Estimated」というラベルとともに表示されます。

Sensor measures（センサーの測定値）	How DLI is estimated（DLIの推定方法）
PPFD（µmol/m²/s）	そのまま使用 — 推定ではありません
日射量（W/m²）	太陽エネルギーのうち光合成有効な割合を標準値と仮定して換算
照度（lux/klux）	標準的な昼光スペクトルを仮定して換算

被覆下の区画については、施設の被覆資材の透光率で屋外光を補正し、実際に作物に届く光を推定します — ここでカウントされるのは固定された屋根材のみで、遮光カーテンは含まれません。

日長と昼夜別の目標~

日の出、日の入り、日長は、それぞれの対象自身の所在地に基づいて計算され、日ごとのエントリに印刷されます。プログラムの目標が昼専用または夜専用のものである場合は、その時間帯に限定して該当する実測値を平均し、実際のΔを示すようになりました — これは以前の挙動からの変更で、以前は目標の値がそのまま比較なしに印刷されるだけでした。センサーにその時間帯内の実測が一件もない場合、その日のΔの欄は数値を推測で埋めるのではなく、空欄のまま省かれます。

カーブの目標も比較される~

プログラムがある項目に対してカーブを設定している場合、日誌はその日にあたる作物週についてそのカーブを評価し、そこから昼用と夜用、それぞれ別の目標値を導き出したうえで、対応する実測値の平均とそれぞれ比較します。週は端数を含む小数の単位で数えられます — カーブは週ごとのキーフレームの間を線形に補間するため、目標値は1日ごとに週の7分の1ずつ滑らかに動いていきます（これはコントローラーや区画モーダルが目標を計算するときに使うのとまったく同じ基準です）。Targetのセルには昼夜両方の値（たとえば「Daytime 0.79・Nighttime 0.45」）が表示され、Δのセルにはその両方に対応する差が表示され、さらにその下の行にどのカーブが使われているかの名前が示されます。

1日分をひとつの平均値には折りたたみません。 日ごとのカーブは、その1日の中だけでも大きく上下に動きます（たとえばキュウリのVPDカーブは、夜明け前の0.4から正午の1.0まで動きます）。これをひとつの数字に折りたたんでしまうと、湿った夜と乾いた午後の差が互いに打ち消し合い、実態の見えない数字になってしまいます。
この計算が行われるのは日誌を開いたときです — 保存されている記録そのものは書き換えられないため、この機能が実装される前に作られた日誌であっても、あらためて開き直すだけでΔが表示されるようになります。
週次・月次に折りたたむと、目標の値はその期間全体の平均に置き換わり、Δは単一の数値ではなく範囲（たとえば「Daytime -0.41 ~ +0.32」）として示されます。同じことが、ひとつの区画に複数のセンサーがある場合にも当てはまります — 設置場所が違えば（群落の内側と外側など）、同じひとつの目標から正反対の方向にずれることがあるため、折りたたんだひとつの数値ではなく、幅を持たせた範囲として示されます。
日の出・日の入りのない日（極夜や白夜にあたる日）や、そのカーブがすでに削除されている場合は、ログは以前の挙動と同じように、カーブの名前だけを表示するにとどまります。

目標からの乖離のまとめ~

文書全体について、そして各ステージについても、「Against target」という表が表示されます。これは保存されているΔの値から閲覧のたびに集計し直されるため、この機能が実装される前に作られた日誌であっても、あらためて開き直すだけで表示されるようになります。

Target（対象）	日数	Above（超過）	Below（未達）	Avg（平均）	Range（範囲）
Night temp（2センサー）	30 ~ 48	30 ~ 48		+5.54 ~ +5.91 °C	+1.66 ~ +9.31

この表は数え上げるだけで、良し悪しの判定はしません。 「この目標はここでは守られていない」と言い切るには許容範囲（トレランス）という基準が必要ですが、そうした基準はこのデータには意図的に含まれていません。この表が示すのはあくまで日数・平均・範囲だけであり、それ以上のことは語りません。

センサーごとに数える~

ひとつの区画に、同じ項目を測定するセンサーが複数設置されている場合、各センサーは別々に数えられます。設置場所が違えば — 群落の内側と外側、高さの違いなど — 同じひとつの目標に対して正反対の方向に外れることがよく起こるためです。

複数のセンサーの結果が一致している場合、その行はひとつにまとめて表示されます。「2 sensors」をクリックすると展開して個別に確認できます。まとめられた値は平均ではなく範囲として示されます — 平均を取ってしまうと、どのセンサーも実際には報告していない数字が新たに生まれてしまい、しかも分母（測定日数）まで混ざってしまいます（48日間測定したセンサーと30日間測定したセンサーの日数を平均すると、「51日」という誰も測定していない日数になってしまいます）。
複数のセンサーの結果が一致しない場合は、その行には「Sensors disagree」と表示されます。どちらか一方だけを代表として選ぶようなことはしません — それをしてしまうと、それもまた事実に反することになるためです。
分母には常にそのセンサーが実際に測定した日数が使われます。そうすることで、「48日中48日で超過」といった文が、実際に測定された日数に基づいて正しく成り立つようになります。

文書を印刷する際には、まとめられて表示されていたセンサーの行も、すべて個別の行に展開された状態で印刷されます。

灌漑量~

Plot type（区画の種類）	How the amount is worked out（算出方法）
露地の区画	実際にその区画と重なり合っている、地図上に描かれた灌漑カバレッジエリア（バルブの配置マーカーそのものではありません）を対象とします。それらの合計流量を、その区画全体の灌漑量として使います。
施設内の区画（棟の中）	その区画に給水しているバルブについて、その棟の配管設計上の流量に、そのバルブが受け持つゾーン全体の中でこの区画が占める面積の割合を掛け合わせた値。

どちらの場合であっても、表示される数値は稼働時間 × 流量 × 割合という式で求められる推定値であり、直接測定した値ではありません。その区画に実際の流量計も設置されている場合は、その実測の読み取り値もあわせて表示され、そちらこそが信頼すべき値になります。週次・月次に折りたたまれたログでは、稼働時間の場合と同じように、その期間全体の水量が合算されて示されます。

気象の実測~

風向は、単純な平均値としてではなく、その日最も出現頻度の高かった方位として示されます（あわせて、その方位を指した実測がどれくらいの割合を占めたかも添えられます）— 真北をまたぐような方位をそのまま平均してしまうと、実際にはどこも指していない、意味のない数字が出てしまうためです。
屋外の実測は、屋内の実測とは別の表に分けて示されるのではなく、同じひとつの表の中でサイドマーカーだけによって区別されて表示されます（前述のとおり）。

出力形式~

同じ保存済みデータは、日誌自身のページから5つの形式で出力できます。

Format（形式）	Use（用途）
HTML	ページそのもの — 印刷用レイアウトも兼ねており、ログの前に表紙と用語集・算出方法のページが付きます。PDFとして保存するにはブラウザの印刷機能を使ってください。
Markdown	ダウンロード形式。他の場所に貼り付けたり、手作業で編集したりするためのものです。
JSON	ダウンロード形式。保存されたスナップショット全体を、自分のツールで再処理するためのものです。
CSV	ダウンロード形式。ログの表のみで、期間・測定項目ごとに1行、稼働時間とノートも含み、表計算ソフト向けに列見出しは翻訳されていません。
ODT	ダウンロード形式。認証機関や次作の栽培者が開いて自分のノートを書き加えられる、標準的なワープロ文書（表紙、Overview、ログ全体）です。

コメントを追加する~

完成した日誌の一番下には、AoTの他の場所でも使われているのと同じノートパネルがあります。そこに書いたものは日誌自体に対するノートとなり、他のノートと同じようにノート検索にも表示されます。

まだ対応していないこと~

日誌は、対象と期間を人がその都度手作業で選んで生成するものであり、あらかじめ決めた条件で自動的に生成したり、スケジュールを組んで定期的に生成したりする機能はまだありません。
地図上にまだ位置が描かれていない施設については、その区画の履歴リストにも表示されません — 先にFacilityの設定で、その施設の位置を登録しておいてください。

日誌~