アカウント名:
パスワード:
カーナビデータとしての地図情報って, 実は人間が目で見た図面としての地図とは構造が違っていたりするんですよね. 要は交差点や分かれ道のところ以外は道なりに進んでいけばいいので, グラフ理論的な結節と枝みたいな形でまとめることができたりして. 逆に右/左折専用車線なんかがある道だと, 道としては1本でもデータ的には交差点のずっと前から複数本の道に分かれていたりして. また, 高速道路なんかで上下車線がトンネルやインターなんかで別ルートになっている場合, 通常サイズではちゃんと別の道として表示するんだけど, 都市間ビューみたいな場合には1本にまとめて表示するとかも要件としてあって, このあたりに色々とKnow-Howがあるみたいです. 海外に多いロータリーはどうするのかなんて問題もあるみたいですし.
なので, 従来の地形図・住宅地図での実績があっても, それを即カーナビの方に活かそうってのは難しいんじゃないですかね.
いや, 最終的にはナビ研になるのですが, そこに落とす前段階の内部データ形式の方が重要なんですよ.
と言うのも指摘されているようにガソリンスタンドなどのランドマークが重要な付加価値なのですが, これらと道路情報の連携とか(実際に道路を走っていると, 進行方向によって見え方が変わってきますし), あるいはデータのメンテナンスシステムとの関連でデータベース上でどのように実装するかとかが問題になります.
私も具体的な実装は知らないのですが, クラス構造の設計にはかなりの作業量が必要になるみたいです.
ランドマークの正確さって各社どうなんでしょ? 以前、某ホテルが山の上にあるように示されて実は山の反対側の麓だったことが・・・
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
ゼンリンやインクリメントPの場合 (スコア:3, 参考になる)
Super Souya
Re:ゼンリンやインクリメントPの場合 (スコア:0)
抱え込んだほうが色々得そうだし。
Re:ゼンリンやインクリメントPの場合 (スコア:2, 参考になる)
カーナビデータとしての地図情報って, 実は人間が目で見た図面としての地図とは構造が違っていたりするんですよね. 要は交差点や分かれ道のところ以外は道なりに進んでいけばいいので, グラフ理論的な結節と枝みたいな形でまとめることができたりして. 逆に右/左折専用車線なんかがある道だと, 道としては1本でもデータ的には交差点のずっと前から複数本の道に分かれていたりして. また, 高速道路なんかで上下車線がトンネルやインターなんかで別ルートになっている場合, 通常サイズではちゃんと別の道として表示するんだけど, 都市間ビューみたいな場合には1本にまとめて表示するとかも要件としてあって, このあたりに色々とKnow-Howがあるみたいです. 海外に多いロータリーはどうするのかなんて問題もあるみたいですし.
なので, 従来の地形図・住宅地図での実績があっても, それを即カーナビの方に活かそうってのは難しいんじゃないですかね.
Re:ゼンリンやインクリメントPの場合 (スコア:1, 参考になる)
ちょうど住宅地図なんかが国土地理院のデータをベースにしているように。
各社ががんばるのは、ガソリンスタンドとかコンビニとかのデータ。
これらのデータの質と量が問題。
よって、即カーナビに活かすのはけっこう簡単。
Re:ゼンリンやインクリメントPの場合 (スコア:2, 参考になる)
いや, 最終的にはナビ研になるのですが, そこに落とす前段階の内部データ形式の方が重要なんですよ.
と言うのも指摘されているようにガソリンスタンドなどのランドマークが重要な付加価値なのですが, これらと道路情報の連携とか(実際に道路を走っていると, 進行方向によって見え方が変わってきますし), あるいはデータのメンテナンスシステムとの関連でデータベース上でどのように実装するかとかが問題になります.
私も具体的な実装は知らないのですが, クラス構造の設計にはかなりの作業量が必要になるみたいです.
Re:ゼンリンやインクリメントPの場合 (スコア:0)
ランドマークの正確さって各社どうなんでしょ?
以前、某ホテルが山の上にあるように示されて実は山の反対側の麓だったことが・・・
# 山の上まで行って気付いたが、反対側の麓への道は通行止めで手前側の山道を降りて迂回。結局2時間以上もロスした。
Re:ゼンリンやインクリメントPの場合 (スコア:0)