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