2017年4月から、小道に沿って、ゲートを通り、中庭をショートカットできるハイキングトレイルを建設しています。最近では、歩行者向けの本格的なナビゲーターを2GISに追加しました。これには、ターンバイターンモードとルート上の重要なポイントの声優が含まれます。
カットの下には、自動車のナビゲーションの専門知識に基づいて、この問題を迅速に解決したかったという話があります。その結果、新しいシナリオを考え出し、基地のサイズを求めて戦い、正しい指示を与えることを学びました。 。
新しいシナリオ
私たちは、車の操縦のロジックを少し変更することで、「数週間以内に」この問題に対処することを計画しました。最初のテストでは、カーナビゲーションのアルゴリズムに基づいて、足の操作の音声動作である「傷」を使用してアセンブリを作成しました。結果は素晴らしかった。
自宅からのルートを計画し、携帯電話をポケットに入れました。音声ガイダンスのみに焦点を当てています。無意味に彷徨い始めていて、音声プロンプトで終点から遠ざかっていることに気づいたとき、ルートを再構築することにしました。この問題が8回繰り返されたとき、私たちには膨大な作業の層があることが明らかになりました。
音声による指示は、その使用シナリオに基づいています。標準のシナリオテンプレートは、歩行者が交差点にどれだけ正確に近づくか、どれだけ速く移動するか、そして後でどこに行くかです。自動車の指示は、再現の条件が歩行者の条件とあまりにも異なるため、機能しませんでした。それは些細なことです-歩行者の速度は数分の1であり、これは操作の声優の瞬間に影響を与えます。
同時に、横断歩道、信号機、ゲート、階段、地上および地下の交差点などのニュアンスを考慮することが重要です。これらのオブジェクトに関する情報は、歩行者が自分の方位をすばやく見つけるのに役立つためです。
新しい実用的なシナリオを収集して説明し、新しいルールを策定して、地下道に近づくときに「道路を横断する」だけでなく「地下道に降りる」と言うようにしました。
古いアルゴリズム
ルーティングの品質は、ルートの構築に使用されるデータの完全性（道路グラフの基本的な知識、エッジの位置、およびそれらの追加の属性）に直接依存します。
データの完全性は2つの段階で達成されます。最初に情報を収集し、次に事前計算アルゴリズムを使用して情報を改善します。
基本情報に基づいて、アルゴリズムは、車の指示などの追加の属性を使用して、グラフに関する知識を充実させることができます。
そのため、車のルートについては、交差点を運転するためのすべての可能なオプションを事前に生成し、オプションごとに必要な命令を計算して、それに属性を追加します。このアプローチには、いくつかの利点があります。
検証可能性
事前計算の段階でも、一般的なケースをチェックするためのさまざまなアルゴリズムを実装できます。正しく計算され、検証された指示は変更されなくなります。これにより、データとアルゴリズムをユーザーに提供する前に、受け取った指示の正確さを確認することができます。
データの更新
2GISアプリケーションのデータは、アプリケーション自体とは別に更新されます。また、携帯電話用のライブラリのアルゴリズムの変更よりも頻繁にリリースします。これにより、アプリケーションのリリースを待たずに、命令を修正または追加できます。
生成前アルゴリズムの効率
ルートに沿って命令を発行するためのアルゴリズムは、実際には、ルートを構成するすべてのエッジについてデータベースにすでに存在する命令を比較し、それらをユーザーに発行することになります。アルゴリズムを使用すると、これは実行時に起こりうる状況を分析してそれらから命令を生成するよりもはるかに簡単で高速です。
ただし、2つの大きな欠点があります。このアプローチでは、新しい情報を格納するために追加のリソースを割り当てる必要があり、データパケットの更新に依存することになります。データが更新されていないか、そこにない場合、ユーザーはアルゴリズムを持っていても機能にアクセスできません。
新しいアルゴリズム
最初のプロトタイプを作成した段階でも、歩行者の指示により、ルートを見つけるために使用されるローカルベースのサイズが大きくなっていることがわかりました。ルーティングパッケージは平均して20％増加しました。これは、オーディエンスの電話のオフラインデータベースのサイズが大きくなるため、許容できない量です。
車の交差点と比較して、横断歩道では通路の選択肢がはるかに多くなります。標準の交差点には、始点（交差点の8辺）と終点（7辺）の位置に応じて、56の歩行オプションがあります。そして、各バージョンで-最大3回の歩行者操作。
また、歩行者の交差点自体は、さまざまな歩行者の経路とグラフ内の交差点のために、自動車の交差点よりも何倍も多くなっています。指示書の作成の初期段階でのみ成長に気づき、未解決のケースがまだ多いことを考えると、その傾向は恐ろしいものでした。
このため、歩行者の指示を事前に計算するというアイデアを放棄し、それらの生成のロジックをランタイムに移動しました。インターネットがある場合、命令はサーバー上で計算され、インターネットがない場合、またはサーバーの応答がタイムアウトに達していない場合は、モバイルアプリケーションで計算されます。実際、アルゴリズムを最初から書き直しました。
データのバージョンへの依存度が低くなりました。また、ほとんどのスクリプトがオンラインサーバーを介して構築されているという事実と組み合わせて、すべてのユーザーのアルゴリズムを一度にすばやく改良することが可能になりました。
新しい手順
交差点を通る歩行者用通路は、自動車用通路に比べてはるかに変化しやすいことを繰り返します。
それぞれの交差点はルートを変える機会
です。指示の精緻化の段階で、私たちはそれらのコンパクトで明確でタイムリーなプレゼンテーションの問題に直面しました。タスクのアスタリスクは、電話をポケットに入れることができ、ユーザーにはガイドラインと矢印が表示されないという事実によって追加されました。あなたは音声ガイダンスにのみ集中することができます。さらに、歩行者は車とは異なり、非常に狭い領域でほぼすべての角度で簡単に向きを変えることができます。そして、道路を横断する方法と場所を正確に説明することが重要です。
最初に私は周りを回ってエラーを書き留めました。オプションが何であるかを理解するために、時々私は交差点を数十回通過しました。それから彼らはエミュレーターを作り、その上で仮想歩行者を立ち上げ、彼に何がいつ声をかけられたかを聞いた。
林道、中庭道路、広い交差点の交差点、信号機のある規制されていない横断歩道と規制されている横断歩道の音声動作を確認しました。
収集された実践的な経験は分析され、議論され、改善のグループに分けられ、共通の解決策によって統合されました。それらのそれぞれについて、アルゴリズムシナリオが発明されました。
この段階で、自動車のような1つのコンポーネントの指示では不十分であることがわかりました。歩行ルートでは、2つの別々の指示が非常に接近しているため、GPSが不正確であるため、時間切れに聞こえて人を混乱させる可能性があります。
私たちは、移行前に自分自身を方向付け、その後どの方向に移動するかについて、複合音声指示を作成しました。
ユーザーの観点からは、このような指示は通常の自動車の指示と同じです。したがって、車の場合、「左に曲がり、100メートル後に右に曲がる」というフレーズは2つの1つのコンポーネントの指示です。
「左折」+「100メートル後、右折」。そして、歩行者にとって、「横断歩道で左折してから右折する」という道路を横断するというフレーズは、完全に1つの指示です。
実際、そのような指示は、基本的なターン指示の束ですが、単一の音声による指示の形式です。このアプローチにより、情報量とバックグラウンドメンテナンスの利便性を大幅に向上させることができました。特に重要な交差点を横断する場合。
最寄りの横断歩道で左折
し、交差点の直後で右折します。
ほかに何か
ジオポジショニングの「調整」
歩行者ルートには、グラフの端である比較的浅い通路が含まれることがよくあります。また、都市の状況では、信号が不安定であるか、高層の物体によって遮蔽されている場合、測位エラーがルートに沿った指示やガイダンスの正しい計算を妨げる可能性があります。現在のポイントを誤って通りの反対側に投げ込まないように、アルゴリズムをわずかに「調整」しました。エラーのニュアンスを考慮し、最大30メートルのルートに描画するようにアルゴリズムを調整します。
バイブロ
音声ガイダンスは、電話がポケットに入っているときの解決策です。しかし、騒がしい都市で声が聞こえない状況を回避するために、目的の操作の前に動作する声と一緒にトリガーされる振動を追加しました。メッセンジャーで通信するときの振動パターン自体は通常とは異なります。
何が起こった
その結果、歩行者用ナビゲーターの最初の公開バージョンには約6か月かかりました。iOSおよびAndroid用の2GISバージョンで利用できるようになりました。
私たちは素晴らしい仕事をしましたが、私たち自身はトリッキーなオプションを逃したことをよく知っています。私たちが示して間違って声を出したケースをモバイルアプリケーションを介して送信します-それぞれがアルゴリズムで考慮され、考慮されます。