導航軟件的開發(fā)多以eVC+WinCE或者C++ + Linux等開發(fā)環(huán)境為主，核心算法為Dijkstra最短路徑算法，需要解決路徑分析，行車規(guī)劃與引導等功能。Djkstra算法是經典的數(shù)學算法
，其地位不容動搖。
ESRI的關于geometric network的開發(fā)幫助時，就是一個導航地圖的模型，不僅可以指導導航地圖制作也可以指導開發(fā)。GDF的概念與ESRI的諸多概念如出一轍。
導航地圖規(guī)格與對應的導航引擎是不可分割的整體。通常，道路規(guī)劃會在中心線層加上相關的權值進行計算。如果是簡單的道路十字相交，這種思路用于解決規(guī)劃功能不成問題。
網上流行的Djkstra算法所提供的數(shù)據(jù)也是解決簡單的十字相交問題。對于復雜問題只能借助于地圖數(shù)據(jù)。
ESRI的network由junction和edge構成，在Arcgis的toolbox中創(chuàng)建network后，會自動生成新圖層用于保存相關的junction和edge等信息。junction由線段的起點，終點生成，edge
則由起點和終點之間的弧段生成。同時將每個junction、edge的拓撲結構都保存起來。只在geodatabase里面對一線層創(chuàng)建過network，在arcmap里做最短路徑分析時速度是不言而
喻。另外，KIWI里也將路口、交叉口等視為地物信息，不僅可以將空間數(shù)據(jù)存放于某一圖層，而且還有詳細的屬性信息，包括相關的拓撲結構。
軟件算法上的不足可以在地圖數(shù)據(jù)上彌補。但是導航地圖采用通用gis平臺，以及軟件從底層開發(fā)等策略限制了功能的完善。國內的企業(yè)多采用通過gis平臺進行地圖加工，有
mapinfo、arcgis等，如果軟件采用二次開發(fā)，可以直接使用到平臺的最短路徑分析接口。可是，導航引擎多以從底層開發(fā)為主，所有的功能，包括最短路徑算法都得自己寫，而且
地圖規(guī)格也是依照引擎規(guī)定的標準而制定。引擎對于地圖的讀取性較差，只能識別單一標準數(shù)據(jù)，引擎變則導航地圖也得變。
所以，導航儀規(guī)劃時間長短引擎得承擔主要責任，因為所有的地圖規(guī)范都是依照引擎的要求制定。但是，導航地圖數(shù)據(jù)的結構組織也有不可推卸的責任，這種組織不是指行政區(qū)劃
如何分層，道路如何分層等類似的邏輯結構，而是關乎道路信息的組織，比如是否將路口、交叉路口等視為地物要素，以及如何存放、讀取等。導航引擎要上一個臺階，必須解決
這個問題。