日誌~

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

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

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

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

日誌を生成する~

区画を選びます — 過去・現在・予定のすべての区画が、地図（農場）ごとにまとめられた、検索できる一つのリストです。作物・品種・名前・施設・棟・ゾーン・サイト・プログラムで絞り込めます。ひとつ選ぶと、その作期の日付から開始日・終了日が入力され、まだ進行中で終了予定日も記録されていない場合は、その対象がある場所の「今日」が入ります。
ひとつの区画ではなくサイトまたはゾーン全体を対象にするには、Or make a journal for a whole site or zone（サイトまたはゾーン全体の日誌を作成） を開いてそのリストから選びます — その中のすべての区画が対象になります。エリアには作期の日付がないため、開始日にはそのエリアのデータが実際に始まる日、終了日には今日が入ります。まだ何も測定されていなければ、その旨が画面に表示されます。二つの経路は同時には選べず、一方を選ぶともう一方は解除されます。
その対象が実際に持っている測定項目のチェックリストから、含める内容を選びます。バッテリー電圧・無線信号品質・ファームウェアバージョン・コントローラ内部値といったデバイスの診断チャネルは、デフォルトではチェックが外れています — 文書に含めたい場合はオンにしてください。現在オフにされているチャネルは "(現在オフ)" と示され、同じくチェックが外れていますが、その期間には値を記録していた可能性があるので選んで含めることができます。区画に自前のセンサーと気象台の両方がある場合、リストは On-site sensor measurements to include（含める現場センサーの測定値） と Weather station measurements to include（含める気象台の測定値） の二つに分かれます — 気象台の温度を外すつもりで現場の温度まで一緒に外れてしまわないようにするためです。
記録単位を選びます: Automatic（自動、デフォルト）、Daily（日次）、Weekly（週次）、Monthly（月次）。
開始日と終了日を確認し、Generate journal を押します。

日誌はバックグラウンドで作成されます — ページはそのまま日誌の固定リンクに移動し、完成するまで「Generating…」と表示されます。後で戻ってきても、ページを開いたままにしておいても構いません。表示は自動的に更新されます。日誌の一覧でも、完成するまで「Generating…」のバッジが付き、作成できなかった場合は「Generation failed」が付きます。再起動で途中で切れた生成も、いつまでも待たされるのではなく失敗として示されますので、もう一度生成してください。

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

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

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

「記録単位」は、その文書をどの単位まで保存するかを決めるものです。完成した日誌は、その単位か、それより粗い単位で読むことができます。

Automatic は日次で保存します。日ごとに保存すると文書ひとつが抱えられる量を超えてしまう場合にだけ週次に下がり、そのときは日次の詳細が利用できないことを文書の注記が述べます。
Daily / Weekly / Monthly は、期間の長さにかかわらずその単位で保存します。粗い単位にすると文書は小さくなりますが、生成が速くなるわけではありません — どの単位でも読み取るセンサーデータの量は同じです。
折りたたみは一方向にしか行えません — 週次・月次の日誌は、日次の詳細がそもそも保存されていないため、あとから日次に戻すことはできません。
完成した日誌は、その日誌のページで読む単位を選びます — Daily、Weekly、Monthly、区画のプログラムにステージが二つ以上あれば By stage（ステージ別）、期間全体を一行に折りたたむ Whole period（全期間）。保存された単位より細かい単位は、そもそも選択肢として出てきません。ステージのある日誌はステージ別で開きます — 先に知りたいのは各ステージがどうだったかであり、37日目の数値ではないからです。
週は暦の月曜日ではなく、記録自体の開始日を起点とします — 第1週はその期間（または区画の作期）の最初の7日間であり、これは実際の作期の数え方に合わせたものです。Monthly のみが暦の月に従います。週次で保存した日誌は例外で、その週は月曜日に始まる暦の週です。

文書の内容~

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

環境の値には目標とΔ（差）が付きます — ただし、それはプログラムがその測定項目について目標をひとつでも定義している場合に限られます。昼または夜に固有の目標 — あるいはカーブで表される目標 — は、それぞれの時間帯に測定された実測値と比較されます。その区画に該当する測定を行うセンサーが存在しない場合は、ありもしない数値を推測して埋めるのではなく、ログにその旨がはっきりと記されます。同じ項目を現地のセンサーと気象台の両方が測定している場合、目標とΔは現地センサーの行にだけ付きます。
その対象・サイトにそもそも何の目標も定義されていない場合は、TargetとΔの列は空欄で表示されるのではなく、ログの表から完全に省かれます。
メーターの使用量（たとえば水流量計）は、そのメーター自身が記録した読み取り値から求めたその日の使用量として表示されます — どのメーターがどのデバイスに対応しているかをシステム側が記録していないため、特定の1台のバルブの使用量として割り当てて表示されることはありません。
区画・ゾーン・サイト、その中にある何か、あるいは単にその中の地図上の位置に留められたノートは、いずれも書かれた日に表示されます。
この文書が値を取得しているデバイスに関するノートも表示されます — センサーの不具合、修理、バルブの点検など。これらは値を読み解くために必要な文脈です。値の欠落や不自然な読み取りの多くは、そこで説明が付きます。デバイス名がノートの前に表示され、座標は不要です。ノートは日誌が作成されたときに取り込まれるため、既存の日誌にあとから反映させるには再生成が必要です。
期間外のステージは暗く表示され、「planned」または「before this journal」と示されます — 期間より前に終わったステージを「planned」とは呼びません。ガイダンスと目標は「Show plan」で展開する形になっており、前のステージと目標が同じステージでは、表の代わりに同じであることを示す一行が表示されます。印刷するときはそのすべてが展開されます。
ログの行はアルファベット順ではなく、固定された読み取り順に従います: 光 → DLI → 積算温度 → CO₂ → 温度・湿度 → VPD → 水 → 風 — これは栽培者が実際に考える順序です。屋内と屋外の実測はひとつの表に収められ、屋外のものはサイドインジケーターで示されます。さらに、同じ項目を現地のセンサーも測定している場合は、屋外の行の名前が「Weather station …」になります。ある測定項目をセンサーがちょうど1台だけカバーし、その名前が他の行と重ならない場合、列にはそのセンサー自身のチャネル名が付きます。それ以外の場合は、一般的な測定名に戻ります。
表は結果指標から開いた状態で表示されます — DLI、積算温度、VPDです。残りの測定項目は「Show N more」で同じ表の中に展開されます。この3つの指標がどれもない対象では、代わりに上記の読み取り順の先頭のいくつかが開いた状態になります。同じものを測定するセンサーが複数ある場合は1行にまとめて範囲を示し、「N sensors」で個別に展開できます。印刷するときはどちらも展開されます。
その期間の時間のうち80%に満たない記録から求めた平均には、「partial coverage」と付記されます — 値そのものは消しませんが、半日分に基づく数字が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の値は以下の基準で推定され、実測であるかのように見せる代わりに、何から求めた値なのかを文書の「Notes on accuracy」が明示します。

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

被覆下の区画については、施設の被覆資材の透光率で屋外光を補正し、実際に作物に届く光を推定します — ここでカウントされるのは固定された屋根材のみで、遮光カーテンは含まれません。その行には根拠がそのまま示され（「Weather station 42.3 × cover 0.78」）、注記にはどの資材でどの係数を使ったかが記されます。係数は資材だけから決まるため、厚さ・経年・汚れは考慮されておらず、実際の値は多くの場合これより少し低くなります。施設に遮光スクリーンがある場合は、ある日にそれを引いたかどうかが記録されていないため、引いた日には表示より少ない光しか作物に届いていないことも注記が併せて述べます。

日長と昼夜別の目標~

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

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

プログラムがある項目に対してカーブを設定している場合、日誌はその日にあたる作物週についてそのカーブを評価し、そこから昼用と夜用、それぞれ別の目標値を導き出したうえで、対応する実測値の平均とそれぞれ比較します。週は端数を含む小数の単位で数えられます — カーブは週ごとのキーフレームの間を線形に補間するため、目標値は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（算出方法）
露地の区画	地図上に描かれたスプリンクラー（単なる配置マーカーではありません）のうち、その区画と、給水するバルブが受け持つ区域とが重なる場所にあるものだけを対象に、流量を合算します。重なった部分だけを数えるので、割合を推測する必要がありません。
施設内の区画（棟の中）	その区画に給水しているバルブについて、その棟の配管設計上の流量に、この区画がその棟の中で占める割合を掛け合わせた値。割合が記録されていない場合は、0 とはせず流量の全体を使います。

どちらの場合であっても、表示される数値は稼働時間 × 流量 × 割合という式で求められる推定値であり、直接測定した値ではありません（画面上も「estimated（推定）」と示されます）。その区画に実際の流量計も設置されている場合は、その実測の読み取り値もあわせて表示され、そちらこそが信頼すべき値になります。流量が分からない機器は水量の欄が空のままになり、分かる機器がひとつもない場合は水量の列そのものが出ず、その理由を文書の注記が述べます — どちらも「水を使わなかった」という意味ではありません。週次・月次に折りたたまれたログでは、稼働時間の場合と同じように、その期間全体の水量が合算されて示されます。

気象の実測~

風向は、単純な平均値としてではなく、その日最も出現頻度の高かった方位として示されます（あわせて、その方位を指した実測がどれくらいの割合を占めたかも添えられます）— 真北をまたぐような方位をそのまま平均してしまうと、実際にはどこも指していない、意味のない数字が出てしまうためです。方位の名前は16方位（N, NNE, NE, …）で、閲覧している言語で表示されます。
風向の行では、最小・最大の列は空欄のままになります。 方位には最も低い値も最も高い値も存在せず、そこに数字を入れればありもしない事実を作ってしまうためです — 空欄であることが正常な状態で、不具合ではありません。
風向は期間のグラフからは除かれ、表の中だけに示されます。まっすぐな軸に載せると、同じ方位である359度と0度が図の両端に離れて並んでしまうためです。
屋外の実測は、屋内の実測とは別の表に分けて示されるのではなく、同じひとつの表の中でサイドマーカーだけによって区別されて表示されます（前述のとおり）。

出力形式~

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

Format（形式）	Use（用途）
HTML	ページそのもの — 印刷用レイアウトも兼ねており、ログの前に表紙と用語集・算出方法のページが付きます。ページの Print (save as PDF)（印刷してPDFで保存）ボタンがブラウザの印刷ダイアログを開きます。
Markdown	ダウンロード形式。他の場所に貼り付けたり、手作業で編集したりするためのものです。ファイルを受け取る側にはページの案内がないため、この文書に実際に出てくる用語の短い説明も一緒に入ります。
JSON	ダウンロード形式。保存されたスナップショット全体を、自分のツールで再処理するためのものです。
CSV	ダウンロード形式。ログの表のみで、期間・測定項目ごとに1行、稼働時間とノートも含み、表計算ソフト向けに列見出しは翻訳されていません。稼働時間の行には灌漑量が入り、昼・夜の目標とそのΔはそれぞれ専用の列になります。
ODT	ダウンロード形式。認証機関や次作の栽培者が開いて自分のノートを書き加えられる、標準的なワープロ文書（表紙、Overview、ステージがある区画ではそのステージ、ログ全体）です。

Markdown・CSV・ODT は、いま日誌を読んでいる単位のまま出力されます — 受け取ったファイルが、ダウンロードした画面と一致します。JSON は常に保存されたスナップショットそのままで、その日誌が保存された単位です。生成がまだ終わっていない日誌では、空のファイルではなく「生成中」という短い応答が返ります。

コメントを追加する~

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

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

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

日誌~