|
Q1: |
地圖和Location
Table是用什麼方式link的? |
|
A1: |
Location
Table主要是依照ISO14819之規範,先把每條所挑選的路徑定為Location Path,再將每一條Path上所有重要的點位 (Point,包括十字路口、圓環、交流道、收費站、休息站、甚至橋樑、涵洞等)定義成一個個連續的點,每個Location Path及Location Point均有代號可供對應,至於道路形狀,並不包含在TMC之規範當中,而是由圖資廠商自行ㄧ點一線的數化到自己的圖資上去,目前世界各國的作法都是如此,在運研所所提供的Location
Table當中,每個Location Point所在的點位座標已有欄位提供給圖資廠商參考,且由LINEAR REFERENCE欄位可以得知該Location Point屬於哪個Location
Path。圖資廠商如要由Location Table當中找到所在地點可以藉由LATITUDE、LONGITUDE欄位(經緯度座標)或是FIRST NAME、SECOND NAME及CFIRST_NAME、CSECOND_NAME欄位(path名稱或交叉路口名稱)找到相對應位置。 |
|
|
|
|
Q2: |
Location Table TYPE欄位的第一位數, A:Area、L:Location
Path、P:Location
Point |
|
A2: |
編碼方式規範於ISO14819當中,於Location Table制定過程當中,此欄位是自動產生的,依照歸納的結果,可以發現P1.11應屬於十字路口、P1.1應為系統交流道、P1.3應屬於交流道、P3.3應屬於收費站、P3.4應屬於休息站等,其他L及A第二位數以後的對應代碼運研所並未利用。 |
|
|
|
|
Q3: |
Location Table和MAP Data是否做好整合對應 ? |
|
A3: |
本Location Table主要是選擇高快速公路全線及台北縣市、臺中市、台南市、高雄市的主要道路,所謂的主要道路,是指有佈建路側設施(車輛偵測器、CMS、CCTV等)的路段,其他有很多的較小的道路或路口,就不會做成Location Path及Location Point,所以並非所有的路段路口都有做成Location
Path及Location Point,因此Location Table當中的節點與節線數遠小於實際路網的節點及節線數,另外,依照規範,Location
Path之建置過程當中,同一條路的去程與回程都屬於同一個path上,並不會另外做區分。因此: |
|
|
|
|
Q4: |
請教關於Location
Table記錄和MAP道路的對應關係。 |
|
A4: |
當Location Code為Path時,該筆資料會紀錄該Path之名稱及起迄point名稱,當Location
Code為Point時,亦會紀錄此Point是屬於哪條Path,透過這些關係可以找出Path與Map的對應道路名稱。基本上一條Path是有可能涵蓋多條道路的可能,例如:敦化南北路這條Path,他就包含敦化南路及敦化北路兩條道路。 |
|
|
|
|
Q5: |
Location Code在該檔案中是唯一(unique)的嗎 ? |
|
A5: |
Location
Code在該檔案中是唯一的;另外,並不會有終點座標trace不到的問題,因為每一個point的上ㄧ點是哪個點都有記載在NEGATIVE
OFFSET欄位當中,而每一個點的下一個點是哪個點則記載在POSITIVE
OFFSET當中,而由LINEAR REFERENCE欄位可以得知該Location Point屬於哪個Location
Path。 |
|
|
|
|
Q6: |
請教RDS-TMC
data的提供單位(是一個呢 ?還是分縣市提供) |
|
A6: |
RDS-TMC所發佈之資訊乃不分縣市,另全台僅提供一份Location Table,一個Location Table最多可包含65,536筆資料,全台目前僅5,000點左右,目前並未考量分縣市作表,每個Location
Point所屬的縣市可由AREA REFERENCE的欄位對應出來。 |