車輪を再発明することは必ずしも意味をなさない。 これもシュトゥルマンの意見であり、ナビゲーションプログラムのエンジンを作成して地図を最初から作成する代わりに、BeNomadの開発とHERE地図作成を使用しました。 企業自身が、情報コンテンツ、インターフェイスライブラリ、およびそれに基づいて構築されたユーザーインターフェイス、WinCEの自動更新システムなどを開発しました。 その結果、ユーザーは最終製品を受け取ります。
メインパートナーおよびコンテンツプロバイダーはYandex.Tubesであり、Yandex.Tubesから受信したデータを正確に使用して、多くの操作を実行する必要があります。
ナビゲーターのユーザーがマップのみを必要とする場合、ロシアの道路の厚い地図を使用できます。 ナビゲーションプログラムの主なものは、正確に最適なルートの敷設です。 ルーティングは、常に理想に最も近い結果を生成するために、絶えず継続的に最適化および調整されます。
オンラインバージョンのルートは、Yandex.Trafficから取得した地図作成と交通データを使用して作成されます。 最初から、すべてが明確です-定期的に更新されるHEREマッピングがあります。 しかし、渋滞には困難があります。それらは、ID、速度、方向、色の4つの基本的な特徴を持つポイントの形で提供されます。 このポイントのセットは、カードに正しく配置する必要があります。
さらに、Yandexからのデータを何らかの方法でパックして、遅いデバイスでも問題なく迅速に解凍できるようにすることが重要です。この方法はShturmannで開発されました。 さらに、接続が切断されたときに再開を実装しました。
クロスプラットフォーム
現在、3つの商用リリースがあります。WinCEのナビゲーター用と2つのモバイルバージョン-Android OS用とiOS用です。 長期的に-WinPhoneのバージョンの開発の完了。 開発者が使用するWindowsおよびLinux用のデスクトップバージョンもあります。 さらに、ShturmannのLinuxバージョンは、MarussiaおよびLuxoftとの共同プロジェクトの基礎を形成しました。
ナビゲーションプログラムは、通常、通常のC ++コンパイラを使用して任意のプラットフォームに簡単に移植できることを期待して作成されました。 現在、これらはAndroid OS、iOS、Mac OS、Linux、WinCE、Windows（デスクトップ）です。
したがって、異なるプラットフォーム用のプログラムのバージョンは並行して開発されています。 ただし、モバイルアプリケーションの開発では、バージョンを記述するときに考慮しなければならない機能があります。たとえば、ナビゲーションShturmannのマップマネージャーは、Android専用のJavaで記述されています。
ルート例
トヴェルスカヤ、ラッシュアワー。 レーンを迂回することもできますが、レーンは5つあることが確認されていますが、6日にはデータがありません。 しかし、これは車線が空いていることを意味するものではなく、データの不足を意味する可能性があります：狭い通りの2列の車に駐車された交通量-他の通行不能。
このプログラムはルートを構築し、より多くの情報がある道路を優先します。
プログラムはどのようにルートを決定しますか？
地図作成では、道路はさまざまなカテゴリに分類されます。 各道路のデータには、平均速度、道路の長さ、その他の多くの情報など、さまざまな指標が含まれています。 渋滞が考慮されていない場合、平均速度を考慮し、異なるカテゴリの道路への誘引力を決定する係数を使用して、ルートが設定されます。 これらの係数は、時期によっても異なります。
プログラムは数字で動作するため、交通渋滞を考慮してルートを構築するために、ポイントで推定された交通データを取得するだけでは不十分です（Yandexなど）。
サーバーからナビゲーションに入る渋滞は、円弧のように見えます-道路のセクション。 このような各アークで、移動の平均速度を決定できます。 （これらのデータを考慮して）ルートを構築するために、アーク伸び係数が設定されます。 道路が混雑するほど、アークは長くなります。 そして、プログラムが交通渋滞をユーザーに導く可能性が低くなります。
交通渋滞のない悪名高いトヴェルスカヤの平均速度は時速50 kmであるとしましょう。 そして、突然、渋滞が時速10 kmで発生します。 これは、重力係数を5倍に比例して増やす必要があるということですか？ 答えはノーです。 実際には、重力係数に加えて、ルート、季節性、および他の多くの要因に応じて使用される係数があります。
もちろん、プログラムは緑の道に惹かれます。 ルートが平均速度50 km / hの2つの同等の道路上でポイントAからポイントBに敷設されているが、一方が40 km / hの渋滞があり、もう一方に関する情報がない場合、2番目のオプションが評価されるため、プログラムは「交通渋滞」を取ります十分な信頼性がない。 アルゴリズムは時々他の係数を使用しますが。
カラフルなコルク
プロットで同じ速度であっても、色が異なる場合があります。 言い換えれば、モスクワ環状道路での時速15 kmとモスクワ中心部の車線での時速15 kmは、2つの大きな違いです。 ある場合には、渋滞は赤になり、別の黄色には-異なる速度範囲が使用されるためすべてです。
別の良い例：建設中のインターチェンジ。 Yandexのデータを使用して、道路のブロックが考慮されます。 Yandexのバーガンディ（または茶色）色は、道路が「価値がある」ことを意味します。 このプログラムは、円弧の色を考慮に入れて、ユーザーをブルゴーニュ、たとえばルートに沿って誘導しません。
仕事、仕事、そして再び仕事をする
ルーティング作業は定期的です。 まず、道路が更新されるたびに道路の速度が変わる場合があります。 第二に、Yandexからのデータもその範囲を変更します-これを考慮に入れる必要があります。 そして、他のことに加えて、季節性は重要な役割を果たします：夏には運転がより自由になり、大きな道路への重力はより高くなり、冬には、ナビゲーターはバイパスルートに送りますが、ドライバーはそれを知らず、定期的に使用することができます。 彼がそれを好めば。
ルートをプロットするとき、多くのデータが考慮されます：
-左折の数。
-可能なターン数（ドライバーが誤ってまたは意図的に道路をオフにした場合、プログラムはすぐにそれを送り返しませんが、ルートを再ルーティングし、乗り心地をよりリラックスさせます。これは特に巨大都市に当てはまります。
-信号機と交通事故の数。
実際、交通情報は要約データであるため、カードに負荷をかけすぎず、不必要な情報でドライバーの注意をそらさないようにすることが決定されました。 信号機と複雑な地図上のターンがあり、残りは最終的な渋滞形式でユーザーに受け取られます。
オッズ
プログラムがユーザーの好みに基づいて機械学習の可能性を受け取ったことは非常に興味深いです：プラグの速度からアーク拡張への最適な変換係数を見つけるために、ユーザーグループから受信したルートの履歴を分析し、特定のルーティングに最適な係数セットを提供するクライアントサーバーソリューションが実装されます期間（日、夜など）。
これは興味深いです：
モバイルワールドコングレス2014のスマートシティ
月額料金なしのモバイルインターネット料金