前回は、過去画像と現在画像を対応づけ、同じ作業帯の中で植生の変化を比較する処理を紹介しました。今回は、そこで扱う領域や、以前の記事で取り上げた太陽光パネルのno-go領域を、地図上で扱うためのデータにする部分へ進みます。
画像に色を重ねれば、検出した場所を伝えることはできます。一方、現場の管理画面では、その領域を選び、境界を調整し、施設の情報と一緒に保存したくなります。同じような見た目でも、「表示するための画像」と「編集するためのデータ」では、設計するものが違います。
今回取り上げるのは、パネルなどの検出領域を、編集可能なポリゴンの下書きとしてアプリ側へ渡す仕組みです。AIの結果を、地図を使った確認作業へつなぐための開発です。
色のついた画像から、頂点を持つ領域へ
画像解析では、対象が写っているピクセルをまとめた「マスク」を扱います。マスクは細かな形を表現しやすく、画像に重ねれば、どこを検出したのかを直感的に確認できます。
地図上で境界を編集するときには、別の表現が役立ちます。輪郭を頂点の列で表した多角形、つまりポリゴンです。頂点を動かすことで形を調整でき、領域ごとに名前や種類を持たせることもできます。
そこで、マスクの中でつながっている部分を一つのまとまりとして取り出し、輪郭から頂点列を作る処理を整えました。見つけた場所を色で示す段階から、選択・編集できる一つの領域として渡す段階へ変える、ということです。
図1 検出領域をマスクとして捉え、輪郭を頂点列へ変換する考え方。色付きの領域はパネル側のno-go候補を表す。説明用の模式図。
輪郭を整理しても、場所の特徴は残す
ポリゴン化で意識したのは、頂点を減らすことと、形を保つことのバランスです。ピクセルの細かな段差をすべて頂点にすると編集しにくくなりますが、単純化しすぎると、その場所の特徴まで変わってしまいます。
例えば、斜めに長く並ぶパネル列を、画像の縦横に沿った四角形だけで囲むと、列の脇にある空間まで大きく含みます。一方で、頂点の数だけを少なくしようとすると、細長い輪郭が別の形に近づいてしまうこともあります。
そのため、輪郭の向きや細長さを残しながら、細かな凹凸を整理する方針にしました。きれいな図形にすること自体が目的ではありません。地図で見たときに、何を囲んでいるのかが伝わり、必要な修正を加えやすい形にすることが大切です。
ここは、画像解析と画面操作の接点として面白いところでした。検出結果を細かく表現するだけでなく、その後に人がどう触るかを考えることで、出力の作り方が変わります。
地図に置くには、画像の位置情報も必要になる
画像内の頂点は、最初は「左からどれだけ、上からどれだけ」という位置です。地図に重ねるには、その画像がどの地理的範囲を表しているかを対応づけ、地図側で扱う座標へ変換する必要があります。
今回の連携では、画像の地理的範囲と座標系を入力として受け取り、領域を緯度・経度の頂点列として返す形式を整理しました。前提になるのは、画像と地図の対応関係が分かっていることです。画像内の形と、その形を地図のどこに置くかを、分けて扱います。
また、検出する対象範囲と、画像全体が表す地理的範囲も区別します。施設の一部だけを調べる場合でも、その結果を元の画像のどこに対応づけるかが、地図表示につながるからです。
この対応を含めて渡すことで、画像上の検出結果を、施設の境界や周辺設備と同じ地図の中で確認するための土台ができます。
図2 画像内の位置と、画像が表す地理的範囲を対応づけ、地図上の領域として扱う構成。座標と図形は説明用に模式化。
アプリが使う情報と、解析を確かめる情報を分ける
もう一つ整理したのは、結果を受け取る側に何を渡すかです。解析側には、検出の確からしさ、画像内の位置、元のマスクとの関係など、確認に使う情報があります。ただ、それらをすべて保存用のデータに詰め込む必要はありません。
そこで、アプリ側へ渡す下書きは、施設との対応、領域名、領域の種類、頂点列を中心とした構成にしました。一方、検出の根拠や解析結果を確認する情報は、別の出力として持たせています。
保存・編集に必要な情報を分かりやすく保ちつつ、開発側では元の結果をたどれるようにする。この分け方によって、画像解析とアプリ開発が同じデータを異なる目的で使いやすくなります。
下書きデータや保存後の応答形式を確認するサンプルも用意し、受け渡す項目の対応を確かめました。画像として見えることだけでなく、次の処理が受け取れる形になっていることまで確認するのが、この工程のポイントです。
AIが下書きを作り、アプリ側で確定する
今回の出力は、編集可能な領域の下書きとして位置づけています。AI側は検出した形を渡し、アプリ側が施設との対応を確認し、編集・保存の流れへつなぐ役割分担です。保存時の識別子や日時なども、アプリ側で管理する設計に整理しました。
ここで扱うパネルの領域は、草刈りの対象ではなく、避ける側の情報です。頂点の形だけでなく、「その領域を何として扱うのか」という種類も一緒に渡すことで、作業候補とno-go領域を区別できます。
現場の画面では、下書きを地図に重ね、必要な境界を調整してから登録する流れを想定しています。人が一から囲む作業をAIが支え、確定した領域は施設管理のデータとして残す。そのつなぎ方を考えると、画像解析の役割がより具体的になります。
図3 AIが出力する領域の下書きを、アプリ側の確認・編集・保存へつなぐ役割分担。画面と操作は構成を説明するためのイメージ。
まとめ
今回は、検出マスクから輪郭を取り出し、画像の位置情報と対応づけ、アプリで扱える領域の下書きへ変換する部分を紹介しました。
輪郭の特徴を残すこと。地図との対応を持たせること。保存用のデータと解析確認用の情報を分けること。こうした設計を通じて、検出結果は「見るための画像」から「確認し、編集し、残せるデータ」へ近づきます。
開発していて手応えを感じるのは、画像解析の成果が、別の開発者や現場の人の次の操作につながるところです。何を見つけるかに加えて、それをどう受け渡すかを設計する。そこにも、草刈り自動化を形にしていく面白さがあります。
次回は、複数の対象範囲をまとめて解析しながら、それぞれの結果がどの施設・領域に由来するかを分かる形で返す仕組みを紹介したいと思います。
本記事は開発の考え方を伝えるため、技術内容の一部を簡略化・抽象化しています。掲載画像は説明用のコンセプトイメージであり、実際の撮影画像・計測結果・運用画面ではありません。