2GISは街をナビゲートするのに役立ちます。 アプリケーションを開き、検索で通りまたは組織の名前を入力し、見つけ、喜ぶ。 必要な組織が見つかった後、合理的な質問が発生します：そこに到達する方法？ そして最近、自動車のシナリオにかなり注意を払った場合、公共交通機関での道順の検索は少し忘れられたことが判明しました。 ルートの検索がどのように作成されたかについて説明し、情報の収集と処理の複雑さを共有します。
タスクはどこから来たのですか
ユーザーとのチャットが大好きです。 2016年の終わりに、ユーザーが公共交通機関をどのように使用しているかを調べるために、調査を実施しました。 結果は興味深かった-共有。
「 公共交通機関をどのくらいの頻度で使用しますか？ 」
一般に、2GISが存在するすべての都市では、回答者の半数以上が毎日公共交通機関を利用しています。 都市が大きいほど、毎日多くの人が公共交通機関を利用します。 平日はモスクワとサンクトペテルブルクの住民に最も人気があり、他の都市では週末に公共交通機関を積極的に利用しています。
使用頻度、どのタイプの公共交通機関が町民のお気に入りであるかを調べる時間を把握しました。
「 どの交通手段がお好みですか？」 」
トップのポジションに関しては、結果は非常に期待されています。 大都市では、好ましい交通手段は地下鉄です。 バスの2位。 モスクワ市民の3分の1以上が電車を利用しています。 ノボシビルスクではミニバスに乗り、サンクトペテルブルクでは路面電車が大好きです。
興味深い発見は、調査対象者の半数が徒歩で目的地に到着できることです。
次のステップは、2GISの弱点を明らかにすることでした。 ユーザーに質問がありました-何が欠けていますか？
「 2GISには何が欠けていますか？ 」
ユーザーが使用するトランスポートの種類を指定できる最近リリースされたフィルターを使用して、特定のトランスポートモードを選択することで問題を解決しました。 しかし、「バスはいつ到着しますか？」という質問は、調査対象ユーザーの64％に関連したままでした。
この時点で、公共交通機関の時刻表を2GISに追加し、すべての要望をどのように実現するかを考えました。
データはどこで入手できますか？
これは私たちが遭遇した最初の問題です。 実際、当社製品のほとんどの場合、独自にデータを収集しています。 新しいマイクロディストリクトが市内に建設されたとき、情報収集の専門家は宣言された場所に移動し、「フィールド内」で必要なすべての詳細を確認します。 新しい機能では、使い慣れたアプローチは機能しません。 専門家を停留所に派遣することは、スケジュールが絶えず変化するため、時間と労力の無駄です。 新しいキャリアが登場し、ルートが最適化され、冬は春に置き換えられます。 収集中、計画されたスケジュールと間隔は単に古くなっています。
はい 残念ながら、データは古くなっており、これが私たちが直面した2番目の問題でした。 論理的かつ非常に明白な決定は、このスケジュールを編集および管理する人々、つまり下位機関に頼ることでした。 多くの場合、建設的な対話は、次のような厄介な官僚的な道とアドバイスを通じてのみ始まりました。
彼らは責任者を見つけ、対話を始めました-半分のトラブル。
それからマラソンは始まりました：
- 何が欲しいのか、なぜそれが必要なのかの説明。
- 私たちのアイデアは、住民や都市の訪問者にとって有用であるという信念。
- 2GISが移動の頻度を考慮してルート構築を収益化しないことの証明。
- 安全であるという保証。
勝利？ しかし、ありません。
最も興味深いのは、問題の技術的な側面、特にデータ転送形式です。 はい、一部の都市には、このデータにアクセスするためのスケジュールとAPIを維持する自動システム（gtfsまたは独自の形式でjsonに転送）がありますが、これはどこからでも遠く離れていました。 セキュリティの理由から、データベースへのアクセスを提供せずに、単にサイトを解析することを申し出たところです。 ファイル（.xls、.doc、.pdf）を送信する準備はできていましたが、ディレクトリ内の情報をタイムリーに更新する機能がなく、一度だけでした。
独創性の面で最初の場所は、公共交通機関のスケジュールと紙の写真を割り当てました。
しかし、当初はタスクは簡単に思えました-ソースから公開されているデータを取得するためです！
内部システムへのデータのアップロード
アクセスを取得し、自分自身にデータをアップロードすると、さらに別の問題に直面しました。 他の人のデータを内部システムに取り込んでロードすることはできません。
なんで？
ソースデータが2GIS内にどのように保存されているかを確認します。
情報を収集および保存するための社内製品をすべて開発しています。 地図作成者（地図だけでなく輸送も担当）のソフトウェアはフィジーと呼ばれます-詳細なストーリーはこちらです （要するに、地図製作者はフィジーで輸送グラフを描き、公共交通機関のデータを入力し、スケジュールを保存します。収集されたすべてのルートはすでにシステムに入力されています）
最初の分析では、システムとサプライヤ内のルートが、場所によって劇的に異なることが示されました。 独自のルートとサプライヤルートを何らかの方法でマップする必要がありました。 もちろん、手動で行うこともできますが、独自のマッチャーを作成することにしました。
GTFSは 、一般に受け入れられている標準として、ストレージの中間形式として選択されました。また、一部のベンダーはこの形式でスケジュールを発行できます。 ゲーマーが実行されている中間データベースには、PostgreSQLが選択され、ゲーマーは簡単にするためにPythonで作成されました。
ルートの種類と名前による単純な一致は機能しませんでした。ルートは私たちとサプライヤーの名前が非常に異なるためです。 同じ理由でストップ名による一致が機能しませんでした。 その結果、ゲーマーはかなり複雑なスキームに従って機能し、ルートのジオメトリ、輸送のタイプ、そしてストップの名前とルート番号を考慮します。
同時に、サプライヤには非常に多くの方向性があるため、比較にはまだエラーがあります。平日ごとに、週末ごとに別々です。 また、プロバイダーと社内システム（フィジー）でリングルートが異なって作成されている場合、リングルートの比較にもエラーがあります。
したがって、最終決定は依然として人次第です。地図製作者は、アルゴリズムが正しく機能しないことを理解した場合、手動でスケジュールマッチングをキャンセルできます。
アルゴリズム
検索アルゴリズムのコアはC ++で記述されています。 実際、公共交通機関で旅行を見つけることは1つのアルゴリズムではなく、いくつかのアルゴリズムです。 最寄りの停留所への通路の検索は、2つのアルゴリズムで構成される歩行者ルーティングアルゴリズムと見なされます。これは、「 ピクセル 」（道路グラフなしで領土を通る通路を構築する）と通常のアルゴリズム（すでに歩行者グラフに沿って停車する）です。
停車地間を走行するための検索アルゴリズムとして、高度に修正されたA *を使用し、それにスケジュールアカウンティングのサポートを追加しました。 また、停車地での輸送の待機時間が以前に各プロジェクトおよび各輸送タイプの一種の「平均」時間であった場合、正確なスケジュールまたは間隔のスケジュールが考慮されます。
同時に、アルゴリズムはデータ内の多くの面白いニュアンスを考慮する必要がありました。 たとえば、ルートの停留所からの出発時間は25時間または47時間です。 データの観点から見ると、これは前の日に行ったのと同じフライトであり、まだ作業を完了していないことを意味します。 また、フライトが「明日」になり始める可能性があり、ユーザーが当日の終わりにルートを検索する場合、翌日を調べる必要があることに留意してください（スケジュールを日ごとに維持することが重要です）。
データをスケジュールとスケジュールなしで結合する方法の問題を個別に解決しました。 その結果、彼らは、スケジュールのないルートがまだ検索に関与していると判断し、単純に重みを減らしました。 さらに、プラットフォームを停止する際にスケジュールのないルートがスケジュールのあるルートと一致する場合、単にそれを配送に接着します。それが何らかの形で異なる場合、これは重量の少ない旅行の別のバリアントになります。バス停での待ち時間を知っています。
2GISはオンラインとオフラインの両方で機能するため、アルゴリズムはアプリケーション内とサーバーの両方で機能します。 スケジュールデータがほぼ静的であるという事実にもかかわらず、ここではサーバー検索も使用されます。低速デバイスでは、インターネットが利用可能な場合、サーバーへのリクエストはローカル検索よりもはるかに高速に機能するからです。 サーバー検索では、ノボシビルスク、モスクワ、ドロンテン（オランダ）の3つのデータセンターにある8つの検索バックエンドを使用します。
発売日
Google PlayとApp Storeのモバイルアプリケーションで、公共交通機関のスケジュールを2GISに追加した最終結果を評価できます。 ウェブ版は少し後に表示されます。
それを取得した後、非常に多くのフィードバックを受け取りました。 ネガティブを分析した後、苦情の2つの主な原因を特定しました。
- 時刻表が道順の検索に使用されており、アプリケーションを操作する通常のシナリオが破られていることをユーザーに適切に伝えませんでした。
夕方または夜間にルートを検索すると、ユーザーは検索結果で通常のルートを失いました。 ルートの構築中の旅行の日付/時間の選択の制御は範囲外でした。
テクニカルサポートの呼び出しのほとんどは、次のようなものでした。
-こんにちは、公共交通機関でのルート検索は不十分になりました。 特定の問題の説明。
-ご存知のように、私たちは公共交通機関での道順を検索するスケジュールを発行しました。ここでは、制御することができ、旅行を計画する時間を設定できます。
-なるほど、ありがとう！ - アルゴリズムは、スケジュールのある代替案がある場合、スケジュールのないルートを提供しない（または結果でそれらを省略する）ことを試みました。 このため、場合によっては、発行の関連性が低くなりました。
当社の技術者は、配達に戻すために、残りのすべての輸送モードの間隔スケジュールを緊急に明確にし、手動で入力する必要があり、検索アルゴリズムをさらに構成する必要がありました。
キャプテンの結論
打ち上げからどのような結論を引き出すことができますか？
- アプリケーションで他の人のデータを使用する場合は、これらの同じデータをどのように取得するかを必ず検討してください。 あなたの期待と現実が一致するという事実ではありません。 リスクを考慮してください。
- アプリケーションの現在のロジックを大幅に変更する場合-必ずユーザーにこのことを伝え、新機能の使用方法を教えてください。ユニットの「新機能」はユニットを読み取ります。
- 新機能とその使用方法についてどれだけよく話しても、急増する電話のテクニカルサポートを準備します。
PSデータの完全性について
すべてのデップトランス/運輸省に同意することは不可能だったため、これまでのスケジュールはモスクワ、サンクトペテルブルク、ノボシビルスク、エカテリンブルク、クラスノヤルスク、オムスク、チェリャビンスク、クラスノダール、ロストフオンドンでのみ利用可能です。 新しい都市を追加するのと同じように、データを受信するときに、これらの都市の時刻表ごとに交通機関のカバレッジを増やします。