はじめに
こんにちわ、LITALICO、入社1年目のsaitoです。
この記事は、LITALICOアドベントカレンダー2の23日目の記事です。
この記事では、私が趣味で作っているアプリ、点字ブロックを考慮したナビゲーションアプリの話をしたいと思っています。本記事で触れているアプリは、まだ、未公開です、理由としては、きちんと検証を行った上で公開した方が良いと考えているためです。今後、検証を行い、利用者の方の安全も含め、問題ないようでしたら公開して行きたいと考えています。
何故、作ろうと思ったのか
散歩をしている際に、散歩道に点字ブロックのある道がありまして、この点字ブロックを辿っていくと、どこまで行けるのか、気になったのがスタートです。実際に辿ってみたところ、駅などにつながっておらず、あるエリアを周回するような形だったので、？マークがたくさん浮かびました。そこで調べてみたところ、関連の法律はたくさんあり、設置の基準やガイドラインもあるのですが、実際に設置を行う自治体ごとに、方針が異なることがわかりました。各自治体ごとに事情が異なるのは理解できるので、利用者にとっての利便性を高めることはできないかと考え、アプリで解決できないかなと思い至りました。
元々、私は、今までの経験から位置情報の扱いに慣れております。また、LITALICOのビジョンである、「障がいのない社会をつくる」のアプローチとしても重要だと考えたため、余暇の時間でアプリの作成に挑戦しました。
データをどのように集めるか
地図データ
日本は、地図データ、専門的にはGIS（Geographic Information System）データがかなりしっかり整備されております。しかも、無償で入手可能です。国土地理院の方々ありがとうございます。今回、私が使用したデータは、下記のデータで、それぞれの用途も整理します。
基盤地図情報
URL: https://fgd.gsi.go.jp/download/menu.php
データ仕様： https://fgd.gsi.go.jp/download/documents.html
データのダウンロードには無料登録が必要です。
こちらは、主に、道路縁と、建築物の外周線のデータを使用しております。仕様もかなり丁寧に書かれているので利用しやすいです。一般的なGISとデータ仕様が異なりますが、同サイトで基盤地図情報閲覧コンバートソフトも用意されております。
国土数値情報
URL: https://nlftp.mlit.go.jp/ksj/index.html
こちらは、主に、交通のバス停留所やバスルート、鉄道、地域の医療機関、公共機関、福祉施設のデータを利用しております。上記の基盤地図情報と親和性が高く扱いやすいです。
位置参照情報
URL: https://nlftp.mlit.go.jp/cgi-bin/isj/dls/_choose_method.cgi
こちらは、主に住所と位置情報の変換、ジオコーディングに使用しております。
点字ブロックのデータ
こちらに関しては、現在のところ、効率的に収集する方法がありません。個人的には、各自治体ごとに予算化や設置の際の資料が残っていると思い、自分の住んでいる自治体や近隣自治体に問い合わせたのですが、公開用のデータはないとのことでした。また、下記のように、研究として取り組まれている方や、NPO法人として、データ化に取り組まれている団体があるので、将来的には、そういった方々と連携して、データ整備を行うのが良いかと思います。今回は、自分でデータを収集しました。（データ収集方法に関しては、次項で整理します。）
参考：
- 視覚障害者誘導用ブロック設置状況のGISデータベース化
- 認定NPO法人ことばの道案内 点字ブロックデータ検索サイト
データ収集アプリの開発
前項の通り、点字ブロックに関しては、データを得るのが難しいと判断したため、スマホのアプリで、位置情報を記録し、前述の基盤地図情報の道路縁データと組み合わせて、マップマッチングを行い、補正した位置情報と、アプリのUIから選択したオブジェクトと紐付ける形式を採用しております。
下記、地図で表示しておりますのは、LITALICOの本社付近です。私の家付近ではございません。
上記のように、線で情報が必要なデータは、start / endで、位置情報の記録の開始 / 終了をし、点で必要なデータは、押下した時の位置情報を記録する簡単なアプリです。（画面の青い点が記録した位置情報。）スマホのGPSを利用しておりますので、多少の位置ずれがあり、その位置ずれをマップマッピングを使用して、道路に沿うように補正します。マップマッピングに関しては、Point to Curve map-matchingという、実装が簡単なアルゴリズムを使っております。
Point to Curve map-matching
- 道路のノードの位置情報を、ハッシュ文字列（このアプリだとquadKeyを使用）に変換
- アプリで測定した位置情報もハッシュ文字列に変換
- 道路のノードの位置情報と、測定した位置情報、それぞれのハッシュ文字列を前方一致でどの桁まで一致するか比較。こうすることで、ある程度、近傍のノードを絞り込め、距離計算を行う道路を絞りこみます。詳細は、下記の参考記事を確認ください。
- 絞り込んだ道路のエッジと、測定した位置情報の距離を計算していき、一番距離が短い道路のエッジに下ろした垂線の足を補正後の位置情報として記録します。
参考：
- Bing Maps Tile System
注） Point to Curve map-matchingの場合、道路のエッジ間が狭いと、別の道路に補正されることがあります。今回のアプリでは取り入れてませんが、位置情報の記録の順番を利用したり、道路同士のつながりを利用して、更に良い結果になる補正を行うことも可能で、今後の課題として検討しております。
また、今回、わざわざ、データ収集アプリを作成してみたのは、点字ブロックのデータが簡単に手に入らなかったのもありますが、今後の拡張性を考慮して、協力者に各種オブジェクトの位置情報の記録を手伝ってもらうことも想定したためです。
集めたデータから、どのようにナビゲーションするか
ナビゲーションアルゴリズム
ナビゲーションのアルゴリズムは、AStarを応用しております。自分でAStarの説明を書こうかと思ったのですが、参考のページがアニメーション付きでめっちゃわかりやすいので、こちらを見ていただいた方がわかると思います。
参考：
- 【Unity】AStarアルゴリズムのサンプル
AStarのアルゴリズムでは、最短経路を求めますが、それぞれの経路に対して、点字ブロックが設置されている道路のエッジを通った距離に応じて、別の得点を加点する方式をとっております。また、拡張の方向性として、車椅子を使ってる方向けに、段差などでは得点の減点を、階段しかない経路は、除外することも可能だと考えております。元々のAStarで求められる各経路ごとの距離による点数と、点字ブロックや段差による加算、減産の点数と2軸での評価になっておりますので、それぞれの得点のウェイトの調整が今後必要と考えております。
- 距離は最短だけど、点字ブロックを全く通らない
- 距離は上より延びるが、点字ブロックがある道を多く通る
一概にどちらが良いか決められない、程よいバランスを目指すべきと思っています、また、それぞれの方にとって、最適なものを選べるように選択肢を示すという方法もあると思っています。
ナビゲーションテキストの生成
ユーザとして、目の不自由な方を想定しているので、ナビゲーション結果を音声で提供する必要があると考えています。上記のアルゴリズムで経路を求め、各経路上のノードと、リアルタイムで測位した位置情報を元に、音声ナビゲーションを作成する方法で今回は実装しています。音声自体は、テキストの読み上げを使っているため、まずは、ナビゲーションテキストの生成を行います。
- 各経路で、曲がる地点のノードをピックアップ、各曲がる地点のノードまで、他のノードが経路上いくつあるかカウント。
- 上記を元に、ナビゲーションテキストをテンプレートから作成。 ex) 道なりに進んで、{¥d}目の角を[左折|右折]
- 基盤地図情報から、道路自体のカーブなどの情報を抽出し、情報を付与。 ex) 3.の「途中、右にカーブしています」
- ジオコーディングした目的地に対し、ジオフェンスで、周辺にたどり着いたか検知。ナビゲーション終了。
音声読み上げ
今回は、AWSのAmazon Pollyを使用しました。とても優秀。
今後の課題
安全面への配慮が十分か
ナビゲーションの性質上、安全面の配慮について、公開前に十分に検討する必要があります。今回は、その部分の検討が足りなかったため、まだ、アプリの公開ができず、申し訳ありません。
- 白杖や盲導犬が一緒の場合、両手が塞がってしまう可能性が高い
- 電波の届かない場所や電源が切れてしまった場合の対応
- 工事などの期間限定の情報の反映
- 交通量への配慮
データ収集アプリの補正精度の改善
都内だと、結構ズレるので、今回は、補正後、手修正するというズルを一部してしまいました。。。データ収集アプリも公開したいので、補正の精度向上も必要ですね。これ、ちゃんと作れば、学校の授業とかでも使ってもらえるんじゃないかなと夢想しております。ex) 地域のハザードマップを作るとか、登下校の危険ポイントを学ぶとか
進行方向の検知
スマホのアプリを想定すると、実際に進んでもらわないと、進行方向が検知できず、間違った方向に進んでしまわれた場合の、アラートがめちゃめちゃ遅く流れます。スマホのジャイロを使って、スマホの向いている向きは検知できるので、そこから、その人がどちらを向いているか検知できないかなーと考えておりますが、ここがめちゃめちゃ難しく、今回は取り入れられませんでした。
UI / UXの改善
ナビ自体もそうですが、目的地のインプットなど、実際に目の見えない方や、体の不自由な方に使っていただくには、更なるUI/UXの工夫が必要だと思います。また、複数の操作方法や出力方法（今回は音声ナビゲーションだが、耳の不自由な方向けには、むしろ、GUIでのナビゲーションの方が有効であるため）を簡単に切り替える方法も必要になります。
コストに関して
意外と計算量が多いため、実際にアプリ提供することを考えると、サーバのランニングコストが結構かかることがわかりました。マネタイズをちゃんと考えないと、安定的にアプリの提供ができないため、これに関しても考慮が必要です
提供エリアに関して
今回は自分で、一部データの収集もしたため、特定のエリアしかデータが揃っておらず、全ての機能を使えるエリアが限定されてしまいます。追加のエリアのデータの収集方法、および、提供可能なエリアについて、検討が必要です。
最後に
今後の課題にいくつも挙げさせていただいた通り、まだまだ穴だらけだとは思っています。ですが、課題解決に向けて、まずは検討・挑戦してみることが個人的に重要だと思っています。オープンデータを使うことで、想定よりも楽に位置情報の利用ができることは、皆さんにお伝えしたかったことの一つです。今回のケースですと、国の機関がオープンデータを公開してくれているので、目的をある程度満たすアプリのプロトを簡単に作成できました。個人的には、それぞれの企業や個人、機関が互いに持っているデータを適切に有効活用できるようになる社会が実現する、Society 5.0実現に向けたデータ連携基盤に期待しております。
また、このアプリに関しても、各種課題に関してクリアしましたら、公開したいので、引き続き、課題の検討を進めていきます。