CONTACT
PiomatixLBSで最適な巡回ルートを見つけよう!(後編)

PiomatixLBSで最適な巡回ルートを見つけよう!(後編)

前編 では、 PiomatixLBS の紹介と巡回最適化APIを用いてどのようなデータが得られるのかをサンプルを交えて解説しました。
今回はその後編と題して、出力されたデータをもとに実際に走行してみてどのようなルートが得られたかを検証していきます。 

ルート表示機能の改良

今回の走行テストに向けて、前編で使用したルート表示機能にいくつか改良を加えています。
  • ポリラインに矢印を表示
    単に線を引くだけでは拡大表示時にどちらに向かうべきかがわかりにくくなってしまうため、方向がわかりやすいように矢印を表示してみました。
    ポリラインの座標情報は実際の走行順序の通りに並んでいるため、その向きに合うように回転させた矢印をルートに重ねて表示します。
  • 有料道路ルートの表示
    今回は有料道路を使う設定でルートを出力するため、どこから有料道路を通るかをわかりやすくするため、一般道とは別の色で表示してみました。
    APIのレスポンスにはポリラインの座標情報が有料道路であるかが含まれているので、それを利用します。
技術ブログ画像

走行テストで検証する条件とそのルート

検証ルートもいくつかの条件を変更してみます。

  • 大阪のランドマーク(大阪城、通天閣、梅田スカイビル、京セラドーム大阪、万博記念公園)を、順不同で回る
  • 時間を優先して回る
  • 必要に応じて有料道路を使用する

万博記念公園は大阪市内ではなく吹田市に所在しているため必然的に走行距離は長くなりますが、有料道路の利用を許可することで所要時間の短縮を図ります。
この条件でルートを出力すると、以下のようになりました。
技術ブログ画像

青色のラインを一般道(いわゆる「下道」)、ピンク色のラインを有料道路としています。
出力されたルートを一見すると、やはり距離のある大阪市内~万博記念公園間で有料道路を使って時間の短縮を図っているように見えます。

いざ、実走行!

では、いよいよ実際に走って妥当なルートになっているかを見ていきましょう。

今回は特に時間をフォーカスするため、APIで出力される予想時間と各ポイントの実際の時間を比較してみます。
その他、混雑や交通規制などを避けられているかなどもチェックしていきます。
技術ブログ画像

まず距離的に近い通天閣と京セラドーム大阪を回ります。
この2つは有料道路を使わず一般道のみを走りました。比較的交通量の多い道路ですが、ルートのほとんどで車線の多い道路を走行できました。

その後、有料道路に乗り梅田スカイビルに向かいます。
この区間は短いので有料道路でなくてもよかったのでは?という気もしますが、梅田スカイビルが梅田北側に位置する関係で、混雑する大阪駅や福島駅周辺を回避できるメリットはあったかもしれません。

梅田スカイビルを出発すると、万博記念公園に向かうために福島から再び有料道路に入ります。
豊中ICを経由して吹田で出ると、すぐ目の前に万博記念公園があります(一時停車できそうな場所がなかったので太陽の塔の写真はありません、残念!)。

万博記念公園を出発してからは再び有料道路に入り、最後の目的地である大阪城を目指します。
大阪市内に戻るため走行距離が長くなりますが、こちらもきっちりと有料道路を使って時間の短縮を図ります。
守口JCT、東船場JCTを経由して法円坂で下り、しばらく道なりに走ると大阪城公園が見えてきます。

最後にぐるっと大阪城公園をひと回りし、中央大通から大阪オフィスに戻りました。
技術ブログ画像
では、各ポイントの時間を見てみましょう。

計測ポイント

予測時刻

実測時刻

誤差

大阪オフィス出発(始点)

10:45

10:45

0:00

通天閣到着

10:54

10:58

+0:04

通天閣出発

10:59

11:03

-

京セラドーム大阪到着

11:10

11:19

+0:09

京セラドーム大阪出発

11:15

11:24

-

梅田スカイビル到着

11:30

11:48

+0:18

梅田スカイビル出発

11:35

11:53

-

万博記念公園到着

12:08

12:16

+0:08

万博記念公園出発

12:13

12:21

-

大阪城公園到着

12:51

12:48

-0:03

大阪城公園出発

12:56

12:53

-

大阪オフィス到着(終点)

13:12

13:08

-0:04

終点到着の時刻で見ると-4分という誤差となりました。
特に遅れを「回復」するような運転はしませんでしたが、2時間以上走行した結果として誤差が-4分と考えるとなかなか興味深い結果ですね。

各区間ごとにみるとそれなりの誤差になってしまっていますが、ナビ担当の指示ミスや有料道路での路面清掃による車線規制などがあったため、いずれもAPIの精度とは異なる理由で生まれた誤差も含んでいます。
遅くなる要素が含まれていた区間では予想よりも遅くなり、逆に遅くなる要素が含まれなかった区間では予想よりも早く到着するという結果となり、感覚的にもマッチした結果になったと思います。

また、道路の選択傾向としては、走りにくい側道や脇道などで無理な近道はせずほとんどが2車線以上の道路になっている印象で、順当なルートを取っているなという印象を受けました。

まとめ


巡回ルートの出力と走行テストの結果はいかがだったでしょうか。

今回はAPIのレスポンスがどの程度のものかを検証することに注力したため盛り込めませんでしたが、位置情報をもとにより便利なナビゲーション機能などを入れても良いかもしれませんし、そのあたりの機能を含めたSDKも用意されているので、実現できそうなアプリの幅は非常に広そうです。

また、ルート探索系のAPIでは探索条件を「エコ優先」にすることで燃料や電力消費を抑えたルートを出力することもでき、レスポンスに含まれる推定消費量と併せてルートを検討することによって「環境にやさしい運送事業」にも一役買ってくれるかもしれませんね。

開催が間近に迫る大阪・関西万博でもスマートモビリティはひときわ注目を集めるコンテンツの一つ。
未来の運送を見据えた高効率化・環境配慮・人材確保などのさまざまな課題を PiomatixLBS と私たちで一緒に解決していきませんか?

アンクシステムズでは、ソフトウェアの設計や実装はもちろん、ビジュアルデザインも含めたワンストップのビジネスソリューションもご提供できます。
ご興味やご関心があれば、 お問い合わせフォーム よりお気軽にご相談ください。

技術の力で未来の運送をより良いものにするために、皆様と一緒に取り組んでいけることを楽しみにしています。

NEED SOME HELP?

各種案件のご相談・ご依頼は
こちらよりお問い合わせください。

CONTACT