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