座標轉換收集的小資料
座標轉換那些事兒
在GIS中,最基礎(basic)、最關鍵(essential)的部分應該就是座標系(coordinate)了,或者說空間參考(spatial reference)。只有明確了空間參考,才能正確地確定地物的空間位置、度量地物之間的空間關係,以及發揮GIS融合多源資料的功能,等等。顯然,空間參考是GIS的一個根本問題。
在實際工作中,當你準備用GIS來完成一項任務時,如果你手頭上資料的空間參考是正確一致的,至少基準面(datum)是正確並一致的。那麼恭喜你,你基本上可以跳過座標轉換這一道坎了,可以直接使用GIS軟體進行資料處理與分析了。如果空間參考是不一致的,甚至是沒有空間參考的資料,那該怎麼辦呢?顯然是要定義一個空間參考,甚至還要進行座標轉換,在一致的座標系下才能進行後續的工作。還有,向量、柵格資料在進行座標轉換時的原理與操作又是一致的嗎?
前面廢話了比較多,其實我就是想談一談座標轉換的問題。很基礎,也不會完全正確,但應該有點用處。
向量資料座標轉換
先來看一張向量資料座標轉換的流程圖:
(向量資料座標轉換流程圖 v0.1)
這個是我自己定義的,有點誠惶誠恐。如果接觸過座標轉換,或者對GIS中的空間參考概念瞭解的話,我想這張圖應該表達的比較清楚了。當然還有幾點需要特別說明下:
(1)空間參考“已有”、“已知”的區別。“已有”說明資料是有座標檔案的,比如Shapefile資料有prj檔案,而且“已有”當然“已知”了。但是“已知”並不一定“已有”,比如一份Shapefile資料知道是WGS84空間參考,但是沒有prj檔案,這樣的情況需要重新給資料定義(define)空間參考。
(2)PCS與GCS,PCS是Projected Coordinate System的縮寫,GCS是Geographic Coordinate System的縮寫。PCS定義在一個GCS之上(Web Mercator比較特別,可以參考這裡),GCS定義在一個Datum(大地基準面)之上,Datum又是Ellipsoid(地球橢球體)經過橢球定位、定向之後的產物,Ellipsoid就是通過長短半軸去描繪地球形態的光滑橢球體了。
(3)“N引數擬合”的說明。當有一份資料並不知道其空間參考時,這時就需要根據座標資料的大小、範圍等因素去推測原始座標系,找到準確的同名控制點,再根據經驗選擇一個合適的物理模型,例如:仿射變換六引數,N階多項式變換。之後進行模型引數求解,最後就是計算座標了。特別是小範圍城市級別的座標轉換,一般使用仿射變換就能滿足普通需求了。這整個流程,我概括為“N引數擬合”。另外,這有點類似於ArcGIS中Spatial Adjustment工具條做的事情。
(4)“基準面不一致”的說明。當基準面不一致時,才要真正考慮到座標轉換(convertion),因為在基準面一致時,任何PCS1到PCS2都是有解析式的,座標系之間只存在變換(transformation)的關係。基準面不一致時,一般通N個引數來確定兩個基準面之間的關係,這也就是轉換的物理模型。比如三引數轉換、Molodenski轉換、Helmert轉換以及Molodenski-Badekas轉換等等。這些轉換大多是基於地心空間直角座標的,也就是XYZ。
戴勤奮老師翻譯了Coordinate Conversions and Transformations including Formulas中的“Formulas for Coordinate Operations other than Map Projections”章節,中文名為“座標系轉換公式”,裡面介紹了許多座標轉換模型的方方面面,是很好的學習資料。
另外還參考了《現有測繪成果轉換到2000國家大地座標系技術指南》、楊啟和教授的《地圖投影變換原理與方法》以及別的各種小論文。
順帶說點八卦:
楊啟和教授是吳忠性教授的學生,吳忠性教授是王家耀院士、高俊院士、孟立秋以及祝國瑞等等知名教授的導師,也是吳邦國委員長的父親。吳忠性教授被稱為“測繪將軍”,應該是現代中國地圖學界的宗師級人物之一了。
楊啟和教授的這本書曾被John Snyder和Waldo Tobler翻譯為Map Projection Transformation: Principles and Applications,至今在Amazon上還有銷售,胡毓鉅教授曾專門撰文談到過這部書的出版意義。值得強調一下的是,John Snyder生前是USGS的首席地圖投影專家,他將在USGS的工作成果整理為了一本書,Map Projections: A Working Manual,另外他也是Space oblique Mercator投影的發明者。Waldo Tobler就更不用多解釋了,地理學第一定律的提出者,UCSB的教授。
柵格資料座標轉換
柵格資料與向量資料的定義不同,空間參考定義也是不同的,因而座標轉換當然也不會相同了。一般來說,柵格資料的座標轉換往往是一步到位。對小範圍的資料,選好控制點和座標轉換模型,直接擬合;大範圍資料,先分成幾塊,分別擬合,最後合併。這樣做的原因,個人認為可能是柵格資料座標轉換涉及重取樣的問題,重取樣本身就有誤差,若是像向量資料一樣有按嚴格的空間參考定義去進行一步步轉換,那期間要涉及多次重取樣,最終的結果可能會面目全非。另外,還可以參考ArcGIS中的Georefrencing工具的原理和使用。
仿射變換
在所有座標轉換模型中,仿射變換是最簡單,也是最常用的。
所以,使用仿射變換,只需使用3對同名控制點,解出A~B六個引數,即能得到座標轉換公式(模型)。如果超過3對控制點,就要通過最小二乘來解算,這些使用Matlab來計算還是很方便的。
仿射變換的原理,通過幾何關係可以很清楚的看出:
(仿射變換幾何原理,via 戴勤奮)
由上圖可知公式:
杭州公交資料轉換
今年4月份的時候,呼叫過杭州公交資料。但當時因為一些別的原因,沒有用心去做,也就沒有對資料進行糾偏了。
從文獻來看,杭州本地基準是在北京54的基礎上經過偏移的,平面座標當然是高斯克呂格投影。而Web上的地圖服務一般都是Web Mercator投影(天地圖除外),基準是WGS84。
我要做即是將hzbus.cn上資料轉換到arcgisonline.cn上。轉換模型選擇仿射變換,如果效果不好,可以再換。以地理座標(經緯度)資料為基礎,因為原始資料就是經緯度的,而且WGS84與Web Mercator的正反算也很容易。
這樣,我只需要找出3對同名控制點就可以計算了。因為原始資料是公交車站的點位座標,而這個車站的位置與實際中的位置並不一致(地圖做得太爛),而且目標地圖上並沒有公交車站的點位標識。因而,只能使用靠近道路交叉口的公交車站,再去目標地圖上找相同的交叉口,最後確定附近大概是公交車站的位置。這樣來選擇控制點,確實有些不友好,但也沒辦法呀。
找到同名控制點的座標,通過Matlab解算引數,最後計算座標。最終結果可以接受,至少車站都分佈在道路兩側。考慮到原始資料的質量,這樣的結果已經挺不容易啦。
(hzbus上的公交車站位置)
(arcgisonline上的公交車站位置)
學了這麼久的GIS,座標系也是一開始就開始接觸的。簡單來說,“座標虐我千百遍,我待座標如初戀”。
Mercator那些事兒
Mercator(1512~1594),生於Rupelmonde(現比利時某地,當時屬於 Flanders——荷、法、比交界的地方),製圖學家、哲學家及數學家。擬定了著名的Mercator投影(正軸等角切圓柱),推動了航海事業和Web地圖產業(這個您老沒想到吧~)發展;首次使用“Atlas”來表示地圖集,並延續至今。今年恰逢Mercator誕辰500週年,Esri曾專門撰文紀念,在此也向Mercator表示敬意。
(比利時法郎中的Mercator頭像,及Mercator投影和Atlas,via umich)
Mercator與航海
在Mercator投影發明之前,航海中使用的是最簡單的plate carrée投影(現在天地圖還在用),最早由Ptolemy發明,投影公式簡單到不能再簡單了:x=lon, y=lat。但這個投影既不等角也不等積,特別在高緯度地區,與實際相差很大,所以並不實用。Mercator於1569年發明了Mercator投影,通過對普通透視圓柱投影的改進,根據緯度越高的緯圈投影到圓柱上長度變化越大,因此考慮緯度變長時將對應的經線也拉長,從而保證兩者之比恆定,即能等角。
在Mercator投影的海圖中,恆向線(Rhumb line)是一條直線,這對航海來說有重要意義。沿恆向線航行不用改變航向就能到達目的地。比如你要從A航行到B,只需拿把尺子在Mercator海圖上將AB連起來,計算AB與經線所成的角度,在航行中使用羅盤一直保持這個角度就能到達B了。但要注意,恆向線並不是球面上的最短距離。球面上兩點間的最短距離是大圓航線(Great circle)。在實際航海中,考慮到航行的距離和駕駛的方便性,往往是兩者結合起來使用。在近距離航海中,沿著恆向線朝一個方向航行就能到達目的地。遠距離航行中,可以先繪製從出發到目的地的大圓航線,再將大圓航線分為幾段,每段按恆向線航行,這就能兼顧了距離和方便性了。當然,實際中並沒那麼簡單。也可以想這麼個問題,你一直朝一個方向走(與經線成一個恆定的角度),最終不是走到北極就是南極,除非你沿著經緯網走,那能走回原地。所以,恆向線其實是一條螺旋線。
(大圓航線和恆向線在Mercator投影中的對比,via esri)
人類征服海洋的過程是十分坎坷的,Mercator投影的發明只是一部分。直到偉大的Harrison發明了海鍾(1737),人類才能在航海時精確地計算經度,進而保證航行的安全。Harrison發明海鍾又是一個百味雜陳的故事,有機會可以另說,或者閱讀這本書。
Mercator投影公式
雖然我沒推導過,但不妨礙我們看看起投影公式的真面容:
(Mercator投影正解公式)
(以赤道、本初子午線為原點)
使用的引數不做過多解釋,參看地圖投影書籍。Mercator投影的最大優點就是正形(conformal),
(變形橢圓,via wikipedia)
但與之相伴的在高緯度地區極度的失真(面積、距離),最經典的是格陵蘭島和南美洲的大小差異,這個可以從投影公式中用到的正切函式看出。
(比例尺,via wikipedia)
Mercator並不很適合用來展現世界地圖,特別是一些專題圖的製作,面積與實際的差異實在是誇張,地圖也會撒謊的。在教育小孩的時候,最好不要用Mercator投影地圖,這可能會影響“世界觀”的呀。
Web地圖之空間參考
自從Google Maps(2005)出現以來,現今全球範圍的Web地圖,用的空間參考都是Web Mercator投影(3857)。Web Mercator與Mercator相似,可以看下其投影公式:
(Web Mercator投影正解公式)
與Mercator投影的主要差別在於緯度的計算上,Google工程師為了簡便起見,沒有使用橢球第一偏心率(e1),從而簡化了投影公式。即將WGS84橢球在投影時看作了以其長半軸(6378137)為半徑的正球體,而經緯度座標還是參考WGS84的,這顯然與GIS中的空間參考規範不符。眾所周知,常用空間參考主要有投影座標系(PCS)與地理座標系(GCS)兩大類,一個PCS建立在一個GCS之上,並要指定一個投影公式,這個投影公式是要以GCS為基準的,不然定義PCS基於GCS就沒有意義了。但Google沒有這麼做,這就搞亂了空間參考的標準體系,不過這樣我們可以從兩個角度來理解Web Mercator:
(1)GIS角度。如前所述,Web Mercator採用了兩個橢球,WGS84橢球和以WGS84長半軸為半徑的正球。GCS用的是WGS84,而GCS投影到PCS時,使用的是正球,雖然地理座標是參考WGS84的,這點最關鍵!
(2)非GIS角度。從數學上看,投影無非是一個函式。Mercator投影利用了WGS84橢球的所有引數(a、b、e1、e2),而Web Mercator只不過使用了部分引數罷了(a)。這麼理解,就能忽略橢球與正球的差異了,那Web Mercator就是Google參考Mercator投影發明的一種新投影。
值得注意的是,Web Mercator投影不是等角的,只是近似等角(near-conformality),Mercator投影是等角的。雖然我不能證明,但我可以理解。從投影公式去看,或者想象一下投影時橢球和正球的區別,顯然是能直觀地想明白的。
Google的Hack行為一來推動了Web地圖的發展,並形成了一套標準,二來也攪亂了GIS界。EPSG開始並不認可這種投影,至少是不推薦,並不給其編號。但是坊間已經應用廣泛,並編之為900913,意指google。後來900913儼然成為了業界標準,EPSG資料庫中也就出現了3785這個投影,但沒過多久又換成了3857(3785與3857之間的差異後面再說)。Esri方面,Esri的Web地圖開始用的都是4326,到09年末才轉換為3857,並逐步停用了原先的4326。選擇3857自然有許多好處,比如這是業界標準,這樣大家都能互相mashup,一起建設和諧社會。4326的瓦片大小是512×512,3857是256×256,瓦片變小既能減少單張瓦片的網路流量,又能縮小瓦片數目的規模,而且在一張256×256的瓦片正好能做一張世界地圖。
Web Mercator與Web Mercator(Auxiliary Sphere)之異同
ArcGIS中的Web Mercator就是3785,Web Mercator(Auxiliary Sphere)就是3857。如果你有一份與Google Maps使用相同投影的資料A,但失去了投影資訊,那麼你在ArcGIS中使用任何一個去定義(define)你的空間參考都是正確的。但是,假如你再將一份WGS84(4326)定義的GCS資料B與A去疊加,那麼B與A3857可以直接疊加,而B與A3785就不能了,至少不能on the fly。為什麼呢?這個通過看一下投影檔案,結合前述的Web Mercator投影介紹,再自己實踐一下就能明白。
(3785投影檔案)
(3857投影檔案)
兩個比較明顯的區別:
(1)3785用的是正球體,3857用的是橢球體。
(2)3857的投影引數裡面多了“Auxiliary_Sphere_Type: 0.0”。
也就是說3785是以正球體上為基準的,但其GCS還是參考WGS84;3857是以橢球體為基準的,但投影時參考正球體,“Auxiliary_Sphere_Type: 0.0”的作用就在這裡吧。
那麼,我現在有一份4326的資料,分別要投影到3785和3875上,該怎麼做呢?
對於3857,因為3857本身基於4326的,所以可以直接project。但是對於3785,就稍微麻煩點了,如果你直接project,那arcgis會提示你進行橢球轉換,結果顯然會與你預期的不一致。所以你得先重新給這份4326的資料定義一個新的空間參考,定義一個空間參考並不改變其資料,而橢球轉換顯然是會改變資料的。根據3785所使用的橢球,為4326定義一個新的GCS(104199),就是6378137為半徑的正球體,然後再project到3785。這樣得到的資料會跟4326直接project到3857一致,但空間參考是不一致的,一個是3857,一個是3785。如果有興趣可以自己嘗試,我附了資料在後面。
顯而易見,3857比3785更合適一些,至少Datum是正常的。GIS的一大特徵就是能疊加多源資料,3785這樣的投影在疊加資料就很尷尬了,這也是Esri最終使用3857的原因。Esri Dev Summit的視訊中也表示,3875和3785在數學上是一致的,如果要考慮疊加資料,建議使用3857。其實我覺得3785現在基本上沒什麼用了,只是Esri自己凌亂狀態下定義的一個過渡空間參考:P
回過頭看,Google 工程師的一次偷懶行為,破壞了GIS界的規範,還最終逆襲成為了事實上的標準,讓人唏噓不已。如果Google使用的是正常的Mercator投影,同樣也可以在一張256×256的瓦片中容納世界地圖,只不過南北的跨度略有差異,這樣既能保證真正的等角,又符合GIS規範,也不會給我們帶來這麼困擾。同樣,如果Esri或者EPSG能更有話語權,那或許也不會有Web Mercator的存在了。只能說IT和GIS相遇,失意的總是GIS,至少目前是這樣的。
———
空間參考本身比較複雜,所以文中難免有所疏漏和錯誤,請批評、指正。另外,現今GIS中的地圖學課程越來越式微,地圖投影等學習也十分薄弱。個人覺得,GIS的教育是很失敗的,但是教育失敗並不是我們止步的藉口,而是我們更應發奮的緣由之一。
有關座標系常見問題的問與答
座標系是gis的靈魂,座標系問題在桌面版是個永恆的主題,下面將常見的座標系問題以問答的形式列出來,希望對大家有所幫助。
問:
我這有2個不同座標的shp要素,這2個要素是同一地理位置的,但是在arcmap中開啟不能顯示在同一範圍內,所以我將其中一個要素的座標轉換成另一個要素的座標,但是轉換後,2個要素還是不能顯示在同一範圍內。怎麼辦?
答:
能不能疊加的關鍵是各自的座標系要正確,不一定要相同。檢查資料的座標系,錯誤的重新定義成正確的即可疊加到一起。
問:
犯了個錯誤:有一個shape檔案是54座標系的,我不小心定義成80座標系了,然後以之為標準對其它shape檔案進行空間配準,今天弄分幅圖的時候才發現錯位了,請問有沒有什麼辦法補救呢?
答:
把那些資料都重新定義成54座標系。
問:
如何看出定義的座標系是錯誤的?我聽說是從extent能看出來,但是我怎麼看不出來?
答:
從extent看出座標系是否正確要建立在對各種座標系的座標形式、座標範圍很瞭解的條件下。比如wgs84等地理座標系的範圍應滿足-180≤X≤180,-90≤Y≤90,再比如Xian_1980_3_Degree_GK_Zone_38座標系的座標的形式是(38XXXXXX,YYYYYYY)等,如果你資料的座標形式是(19XXXXXX,YYYYYYY)而你定義成Xian_1980_3_Degree_GK_Zone_38就錯了。當然有些錯誤從extent是看不出來的,比如你的資料正確的座標系是Xian_1980_3_Degree_GK_CM_111E而你定義成了Beijing_1954_3_Degree_GK_CM_111E,這個錯誤從extent是看不出來的。
問:
我的資料是wgs84座標系的,在dataframe的屬性裡將display unit改成米後右下角顯示的座標就會變成以米為單位,我想問這個座標是怎麼計算出來的?
答:
是根據赤道長度及經緯度計算出來的。地球長軸為6378137米,赤道長度為2×6378137×π≈40075016.686米,則赤道上1°≈111319.491米。假設某點的經緯度座標為(63.767584,36.747445),則將display unit換成meter後其座標就是(7098574.996427,4090706.892127),自己驗證一下。
問:
有一個數據有座標系,是錯誤的,想進行修改,那麼使用哪個工具呢?
答:
用define projection重新定義座標系。
問:
我的柵格是北京54投影座標系下的tif格式檔案,做裁切後為什麼座標系變成Krasovsky_1940_Transverse_Mercator了,我什麼也沒設定啊。
答:
你存成grid格式了吧?北京54和西安80投影座標系的柵格轉存成grid格式後會自動改變。北京54座標系會變成Krasovsky_1940_Transverse_Mercator,西安80座標系會變成User_Defined_Transverse_Mercator,這是歷史原因造成的,不必理會它。
問:
我用arcgis計算面積時,資料的座標系為WGS_84,求出來的結果是平方度,如何將其轉換為平方米?
答:
地理座標系不適合求面積,平方度也不是面積單位,不同緯度1°×1°範圍的面積不相同。可將你的資料用project轉成WGS 1984 UTM投影座標系後再求面積。
問:
有一個無座標系統的shp層,我用define projection給它定義座標系統後,然後加到arcmap中來,提示Warning,inconsistent extent!這是什麼原因?怎麼解決?
答:
座標系定義錯誤,比如有帶號的座標系資料定義成沒帶號的座標系,或者把投影座標系的資料定義成了地理座標系等等。找出正確的座標系並用define projection或在arccatalog裡重新定義。
問:
我想計算中國各大港口之間的歐式距離,但用ArcGIS和google earth兩種方式計算的結果相差200多公里,我用ArcGIS計算的步驟如下:
a蒐集天津港和深圳港的經緯度並製作成Excel表
b在ArcCatalog中建立port點圖層(shapefile格式),選擇GCS-WGS1984
c在ArcMap中新增port圖層,使用Tool->add XY data建立點圖層中要素
d使用project轉換port圖層,投影座標系選擇PDC-WGS1984
e使用Point Distance計算點間距離
以上五步中,哪一步出錯了?
答:
同樣兩地在不同座標系下所求的距離有可能不相等。google earth裡求距離、面積等並不是用PDC-WGS1984座標系算出的,用此座標系算出的距離、面積和實際的數比有很大的誤差。一般計算距離時用等距離投影,計算面積時用等面積投影。
問:
按理說,計算距離等應該在投影座標系下進行,書上也說經緯度座標系不是一種平面座標系,因為度不是標準的長度單位,不可用其量測面積長度。但是在地理座標系下(比如WGS84)arcmap的measure工具是可以選擇公里為單位進行測量的,請問這個是怎麼計算長度的(比如以什麼投影系統為基準)?
答:
用測量學的方法根據兩點的經緯度計算出的球面距離。
問:
為什麼我的資料做了clip後變形很大,原來不相連的地方都連在一起了?
答:
tolerance的問題。一般原因是地理座標系資料沒有定義座標系或定義成了投影座標系。當地理座標系資料沒有定義座標系或定義成了投影座標系時系統預設的tolerance是0.001,這對投影座標系的資料來說是合適的,這樣的資料不會出錯。當你的資料是地理座標系時,0.001就顯得太大了,相當於投影座標系的100米左右,當兩個節點距離小於這個值時就會合併成一個,所以就會出現處理後的資料不該合併的地方合併了,慘不忍睹。
問:
在做Extract By Mask時出現錯誤:
An error was encountered while executing ExtractByMask.
("esriGeoAnalyst.GridEngine") Could not get a valid extent.
Failed to execute (ExtractByMask_3).
請問是什麼地方出錯了?改如何解決呢?
答:
檢查是否都正確定義了座標系。
問:
建立點時出錯提示“不能建立要素座標或測量值超出範圍”,這是什麼原因?
答:
這問題經常出現在空的圖層中“隨意畫”時。要素類或shapefile是有有效範圍的,超出這個範圍就不能建立要素了。
問:
我在用ArcGIS計算DEM坡度時,最低0度,最高89度,平均坡度也達到了87度,肯定是不對的,這是什麼原因?
答:
一般出現這種情況是因為你的資料是經緯度的座標系。轉換成投影座標系後再做。
問:
為什麼地理座標系dem求出的slope是錯誤的呢?
答:
因為slope和距離、高程有關,你的資料中XY座標是度,Z座標是米,單位不一樣,但資料中可能只有X、Y的單位資訊,沒有Z的單位資訊,系統會認為它們單位都一樣,所以計算會出錯。比如說,在地理座標系下,兩個象元相距0.001度,高程相差1米,在地理座標系下計算時這兩點連線和水平面夾角的正切就是1000,也就是兩點連線和水平面的夾角是89.943°
問:
為什麼我的柵格不能做配準,georeferencing工具條中不出現柵格圖層名?
答:
因為你的柵格的座標系資訊和data frame的座標系不一致,把data frame的座標系設成柵格的座標系後就能做了。
問:
在arcmap中顯示全國地圖全圖比例尺大概有1比幾百萬吧,也不知道被我執行了什麼操作,地圖好像被所縮小了一樣,在整個中國全顯示的情況下,比例尺竟然達到1:128,請問這是怎麼回事?
答:
錯誤的定義了座標系,將地理座標系資料定義成了投影座標系,或者對無座標系資訊的地理座標系資料在data frame裡將map unit設成了meter。
問:
給shp格式的定義座標系,用的是define projection,但是定義完後出現了"Datum conflict between map and output"這句綠色字型的警告,什麼原因?
答:
提示Datum conflict between map and output是因為你的資料的座標系和dataframe的座標系不一致,一般可不必理會。
問:
先開啟有地理座標系的圖層1,然後在這個圖層上面疊加一個無座標系統的圖層2。圖層2也和圖層1一樣都是地理座標系,但圖層2顯示的地理位置卻全部錯了,飛到老遠的地方去了,原來是可以疊加到一起的,這是為什麼?
答:
那是因為你當前的的dataframe的座標系統和圖層一的不一致,而圖層一因為有座標系統能正確動態投影,而圖層二沒有座標系統不能正確投影。你試著開啟arcmap後只加進這兩個圖層看看能否正確疊加。
問:
我們需要提交shape成果,要求:“以度為單位的地理座標系資料,大地座標參照系為1954北京座標系”,我的資料現在是北京54座標系,顯示的是六位七位的公里網格座標,我轉換了座標系後還顯示的六七位數,不是經緯度,我試了老半天了,開始把投影刪了,直接定義投影為地理座標系裡的asia的beijing1954,但是單位還是錯的,而且每次一載入還提示一個錯誤,哪裡出問題了?
答:
你需要的是轉換座標系而不是重新定義座標系。轉換座標系要用project(向量)或 project raster(柵格)來做而不是用define projection來做。
問:
地理座標系不是球面座標系麼,如果沒有投影的話,為什麼能在arcmap這個平面上顯示呢?
答:
地球表面是球面,但地圖是平面的。繪製地圖時在平面上建立一個直角座標系,x軸代表經度,y軸代表緯度,座標軸單位是度。地球上任意一點都有經緯度,按照這個經緯度在地圖上找到對應座標點即可將球面上的點轉繪到平面地圖上。
問:
怎樣得到某個投影座標系的座標範圍?比如西安80,37°帶座標系,它的X、Y最大最小值分別是多少,怎麼計算?
答:
x座標範圍:37500000加減赤道1.5°的長度
y座標範圍:正負二分之一中央經線長度
問:
UTM 的是“以中央經線投影為縱軸x,赤道投影為橫軸y”,高斯克呂格 具體構成方法是“以中央經線為x軸,赤道為y軸”,而在描述投影座標系統時說的是“中心水平線稱為x軸,中心垂直線為y軸”----以上引號皆摘自清華大學出版的那套上下冊的gis書,請問,這到底是為什麼?我校正影象的時候都暈乎的,到底哪個是x,哪個是y?
答:
數學座標系(也叫笛卡爾座標系)水平的是x軸,垂直的是y軸,測量座標系水平的是y軸垂直的是x軸。你說的那書是以測量座標系敘述的,而 在gis軟體裡一般都用笛卡爾座標系。入鄉隨俗,既然用gis軟體就要按笛卡爾座標系的規矩來做,不要被書上說的所左右。
問:
我看一本書上寫的是,在使用十進位制度的wgs_1984座標系中,資料精度是1釐米,容限值為(0.01/(6378137*0.017453292519943299))/10,約等於8.983e-9,當時看了之後不明白為什麼要除以(6378137*0.017453292519943299)這串數字,現在也不明白,我現在的資料的Projected Coordinate System是WGS_1984_UTM_Zone_49N,在按照此作拓撲時,拓撲容限值預設是0.001,而不是8.983e-9,不知為什麼,我如果把0.001改成8.983e-9,在結束時就會出錯,不知為什麼,請大家指教。
答:
除以那個數是計算在赤道上1米相當於多少度的一段圓弧。360°=2π*赤道半徑(≈6378137)米,則1米≈360°/(2π*6378137),而2π/360≈0.017453292519943299,也就是1米≈1/(6378137*0.017453292519943299)° 而一般設為容差為精度的10倍。根據上面的分析不難得出那個結果。
WGS_1984_UTM_Zone_49N的單位是米,所以該設成0.001,而不是設成8.983e-9,只有以度為單位的地理座標系才能設成8.983e-9
問:
我的shp資料檔案是1980座標系的,不過沒有加大數的,請問如何加大數啊?就是x座標前面都加一個40.
答:
用project或project raster轉換到相應有帶號的座標系。
問:
原始資料為gtopo 1km的全球dem,地理座標系為wgs84,但經過投影轉換後,dem嚴重變形。我選擇的是蘭伯特雙標準緯線等角圓錐投影,投影引數為:
Projection: Lambert_Conformal_Conic
False_Easting: 0.000000
False_Northing: 0.000000
Central_Meridian: 97.000000
Standard_Parallel_1: 30.000000
Standard_Parallel_2: 62.000000
Latitude_Of_Origin: 0.000000
Linear Unit: Meter (1.000000)
Geographic Coordinate System: GCS_WGS_1984
Angular Unit: Degree (0.017453292519943299)
Prime Meridian: Greenwich (0.000000000000000000)
Datum: D_WGS_1984
Spheroid: WGS_1984
Semimajor Axis: 6378137.000000000000000000
Semiminor Axis: 6356752.314245179300000000
Inverse Flattening: 298.257223563000030000
答:
全球資料不適合用蘭伯特雙標準緯線等角圓錐投影,可改用Robinson投影座標系。
問:
投影資訊中有幾個引數不是太瞭解:首先Projection: Gauss_Kruger這個是知道的,下面的Parameters:引數是指什麼,通常取什麼值呢?還有Angular Unit: Degree(0.017453292519943299) 這個角度為什麼取這個特定值,他是怎麼計算出來的?還有一個我在程式裡看到有個引數,取值是57.29577951308232,這個是代表什麼?希望瞭解的幫忙解釋一下
答:
每種投影的Parameters個數不一定一樣、值也不一定相等,一般有偽偏東false_east、偽偏北false_north、中央經線central_meridian、投影原點latitude_of_origin、線性單位linear unit等。0.017453292519943299是一度等於多少弧度,57.29577951308232是一弧度等於多少度。
問:
我有一個政區圖向量檔案,座標是(123456,1234567)這樣的形式,檢視屬性裡顯示無座標系。我就利用arctoolbox 定義一個地理座標系,但是定義後顯示的經緯度數值沒任何變化,這是怎麼回事。後來定義投影座標系數值也是沒變化。
答:
定義座標系不會改變座標的數值。你的資料應該是投影座標系的資料。先搞清楚正確的座標系並定義之,需要經緯度的話用project轉換到相應的地理座標系。如果只是要顯示經緯度的話,也可以正確定義座標系後在dataframe的屬性裡將其座標系設成相應的地理座標系,並把display unit設成度或度分秒。
問:
為什麼同一個區域兩個座標系完全一樣的SHP檔案卻無重合?
答:
至少有一個數據的座標系是錯誤的。能否正確疊加不在於兩個資料的座標系是否一樣,而在於是否正確。
問:
有個投影座標系的世界地圖,中國在邊上,出圖時怎麼能使中國位於中間呢?
答:
投影座標系引數裡邊有個中央經線(Central_Meridian),將data frame的座標系設成世界地圖的座標系,並把中央經線設定為105°。
問:
兩個資料座標系不同,為啥加進arcmap中能夠重合?
答:
arcmap會自動將加進去的資料的座標系在記憶體中轉換到data frame的座標系來顯示,即所謂的動態投影。它只是在記憶體中轉換,並不改變資料本身的座標系。
問:
我將向量資料從Beijing_1954_3_Degree_GK_CM_111E轉換到了Beijing_1954_GK_Zone_19N,為什麼座標值沒有變化啊?
答:
這兩個座標系的投影方式、中央經線、原點、偽偏東等引數都一樣,計算座標的方法也就一樣,所不同的只是包含範圍不一樣,所以在三度帶的範圍內所有點在這兩個座標系下的座標都一樣。
問:
我原來有個資料裡的圖形是圓形的,現在怎麼變成橢圓了,我保證資料沒有動過。
答:
data frame的座標系和資料的座標系不一致造成的,比如你資料的座標系是以地理座標系,現在用了投影座標系顯示。
問:
為什麼我的全國地圖顯示出來比較扁,和掛圖上的中國地圖樣子不一樣呢?
答:
不同座標系下同一個圖的樣子可能會不一樣,若你的全國資料是在地理座標系下顯示的就會看起來比較扁。
問:
我的資料座標系為:
China_Lambert_Conformal_Conic
Projection: Lambert_Conformal_Conic
False_Easting: 0.000000
False_Northing: 0.000000
Central_Meridian: 125.000000
Standard_Parallel_1: 42.000000
Standard_Parallel_2: 51.000000
Latitude_Of_Origin: 0.000000
Linear Unit: Meter
GCS_Beijing_1954
Datum: D_Beijing_1954
新增經緯度grid後經線和緯線不是直線,我想要直的經緯線該怎麼做啊?
答:
將data frame的座標系設為相應的地理座標系,即Beijing 1954地理座標系。
問:
原有的SHP圖層是沒有投影的,我用define projection 把投影轉成albers,可是為什麼中國地圖還是扁的,檢視圖層投影已經是albers了
答:
應該先用define projection定義正確的地理座標系,再用project轉換到albers投影座標系,而不是直接定義成albers投影座標系。
問:
我在arcmap裡面載入了一副中國省界shp資料。右下角顯示的座標是:102.968 5.936 Meters..單位是米,但是102.968 5.936分別代表的是經緯度啊,這裡顯示成米,不知道該怎麼轉換呢?
答:
兩種可能:
1、無座標系資訊的資料在data frame的特性裡將map unit設成了meter
2、錯誤地將地理座標系的資料定義了投影座標系
問:
地理座標系資料想轉成UTM投影座標系,資料不在一個6°帶範圍內該怎麼選座標系?
答:
若資料東西跨度不超過6°,可修改已有的座標系,建個非標準的座標系,中央經線選你資料範圍中間的經度。例如我的資料東西範圍是東經105.5°到東經110°,跨WGS_1984_UTM_Zone_48N和WGS_1984_UTM_Zone_49N兩條帶,我可修改WGS_1984_UTM_Zone_48N座標系的引數,中央經線設為108°,名稱改為WGS_1984_UTM_Zone_48N_A。
若東西跨度超過了6°就不適合用utm座標系了,用其他投影座標系吧,例如lambert投影的座標系。
問:
現有一批國內某地區的資料,跨帶很廣,要拼接到一起,那這些資料在投影上應該如何選擇,尤其是大比例尺地圖,還是用常規的分帶投影嗎?
比如按慣例1:10w的資料是6度分帶,現在假如有17-21帶的資料,放大到一定程度以後如果還是6度分帶並且統一到一個帶,兩邊的地圖肯定會變形很大;如果不統一到一個帶,接縫的地方可以正常拼接嗎?
這種情況下是大比例尺地圖也使用WGS84的球面座標呢?還是將這些資料都投影到一個帶,即使變形也不管?
答:
研究區域跨多條帶拼接時應該用albers、lambert等投影座標系來做。
問:
全國資料是albers座標系的,怎麼將經緯網新增上去,線線都是直的呀?
答:
檢查data frame的座標系是否是地理座標系。data frame設成資料的座標系後應該就正確了。
問:
我將地理座標系的全國資料轉換到了albers投影座標系,但轉換後最後出來的地圖不是北朝上而朝左了,這是哪裡出問題了呢?
答:
檢查中央經線設定是否正確,全國albers座標系的中央經線通常用105°。中央經線決定了圖形旋轉的方向和角度,與中央經線為105度的圖相比較,小於105度就會向左轉,大於105度就會向右轉。
問:
DEM柵格圖轉成點圖層,操作Add XY Coordinate時,計算出來的點座標是以米為單位的,請問我想得到經緯度值應如何操作呢?
答:
將data frame設成地理座標系,用calculate geometry按data frame的座標系計算點的經緯度座標。
問:
一個圖層從WGS-1984-Albers到xian-1980-Albers,下面的Geographic transformation怎麼選擇?
答:
因WGS-1984-Albers到xian-1980-Albers是不同橢球體之間的座標轉換,精確轉換需要用轉換引數來定義Geographic transformation。轉換引數可去當地測繪部門索取或購買。如果精度要求不是很高的話可用arcgis的動態投影轉換,即:將data frame的座標系設成xian-1980-Albers,按data frame的座標系匯出資料。 轉載連結: http://user.qzone.qq.com/617662776/2
http://bbs.esrichina.com.cn/ESRI/viewthread.php?tid=121932 相關程式程式碼: http://pan.baidu.com/s/1c09tRZa