WGS84与WGS84 Web Mercator

简介:

1. WGS84与WGS84 Web Mercator

1.1 关于WGS1984投影坐标系

UTM (Universal Transverse Mercator)坐标系是由美国军方在1947提出的。虽然我们仍然将其看作与“高斯-克吕格”相似的坐标系统,但实际上UTM采用了网格的分带(或分块)。除在美国本土采用Clarke 1866椭球体以外,UTM在世界其他地方都采用WGS84。
UTM是由美国制定,因此起始分带并不在本初子午线,而是在180度,因而所有美国本土都处于0-30带内。UTM投影采用6度分带,从东经180度(或西经180度)开始,自西向东算起,因此1带的中央经线为-177(-180 -(-6)),而0度经线为30带和31带的分界,这两带的分界分别是-3和3度。纬度采用8度分带,从80S到84N共20个纬度带(X带多4度),分别用C到X的字母来表示。为了避免和数字混淆,I和O没有采用。UTM的“false easting”值为500km,而南半球UTM带的“false northing”为10000km
 
在arcgis中打开WGS1984投影文件,仔细看看,我们可以发现里面中有三种不同的投影文件:如下:
WGS1984 BLM Zone 14N(ftvs).prj
WGS 1984 Complex UTM Zone 20N.prj (该处由20N——30N)
WGS 1984 UTM Zone 9s.prj(该处由9s——60s)此处的S代表南半球,同样北半球有同样的变化
1.UTM投影
UTM投影全称为“通用横轴墨卡托投影”,英文名称为Universal Transverse Mercator,是一种等角横轴割圆柱投影,圆柱割地球于南纬80度、北纬84度两条等高圈,被许多国家用作地形图的数学基础,如中国采用的高斯-克吕格投影就是UTM投影的一种变形,很多遥感数据,如Landsat和Aster数据都应用UTM投影发布的。
UTM投影将北纬84度和南纬80度之间的地球表面积按经度6度划分为南北纵带(投影带)。从180度经线开始向东将这些投影带编号,从1编至60(北京处于第50带)。每个带再划分为纬差8度的四边形。两条标准纬线距中央经线为180KM左右,中央经线比例系数为0.9996.
UTM北半球投影北伪偏移为零,南半球则为10000公里。
2.在ArcGIS中UTM投影坐标文件名的N和S的区别
N代表北半球,S代表南半球,文件内容的区别在与参数False_Northing 北伪偏移值,如下图所示:
3.中国UTM投影带号
中国国境所跨UTM带号为43-53
我国的疆域范围:
最西端 北纬39度15分、东经73度33分
最北端 北纬53度33.5分 东经124度27分
最南点,处北纬3°51′,东经112°16′
最东端 北纬47度27.5分 东经134度46.5分
4.UTM投影带号计算
如WGS_1984_UTM_Zone_49N,这个49的计算方法:
49:从180度经度向东,每6度为一投影带,第49个投影带
49=(114+180)/6,这个114为49投影带的最大经线
 

1.2 Web Mercator

EPSG,即 European Petroleum Standards Group 欧洲石油标准组织

ArcGIS 10Web Mercator有三种EPSG编号。他们分别是EPSG3857 EPSG102100

EPSG102113。其实三者表示同一个投影,而这个投影跟谷歌以及Open Street Map等使用的投影EPSG:900913是一致的,只是这个编号以前人们使用的时候并没有被EPSG组织采纳。

以下是这几个编号代表的投影在ArcGIS中的元数据信息:(其中EPSG3857 EPSG102100 完全相同,EPSG102113稍有差异)

EPSG3857     -  WGS_1984_Web_Mercator_Auxiliary_Sphere

EPSG102100  - WGS_1984_Web_Mercator_Auxiliary_Sphere

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
PROJCS[
  "WGS_1984_Web_Mercator_Auxiliary_Sphere" ,
   GEOGCS[
   "GCS_WGS_1984" ,
   DATUM[ "D_WGS_1984" , SPHEROID[ "WGS_1984" , 6378137.0, 298.257223563]],
   PRIMEM[ "Greenwich" , 0.0],
   UNIT[ "Degree" , 0.0174532925199433]
   ],
 
  PROJECTION[ "Mercator_Auxiliary_Sphere" ],
  PARAMETER[ "False_Easting" , 0.0],
  PARAMETER[ "False_Northing" , 0.0],
  PARAMETER[ "Central_Meridian" , 0.0],
  PARAMETER[ "Standard_Parallel_1" , 0.0],
  PARAMETER[ "Auxiliary_Sphere_Type" , 0.0],
  UNIT[ "Meter" , 1.0]
]

 

EPSG102113     WGS_1984_Web_Mercator 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
PROJCS[
   "WGS_1984_Web_Mercator" ,
   GEOGCS[ "GCS_WGS_1984_Major_Auxiliary_Sphere" ,
DATUM[ "D_WGS_1984_Major_Auxiliary_Sphere" ,SPHEROID[ "WGS_1984_Major_Auxiliary_Sphere" ,6378137.0,0.0]],
   PRIMEM[ "Greenwich" ,0.0],
   UNIT[ "Degree" ,0.0174532925199433]
  ],
 
  PROJECTION[ "Mercator" ],
  PARAMETER[ "False_Easting" ,0.0],
  PARAMETER[ "False_Northing" ,0.0],
  PARAMETER[ "Central_Meridian" ,0.0],
  PARAMETER[ "Standard_Parallel_1" ,0.0],
  UNIT[ "Meter" ,1.0]
]
 

1.3 Web Mercator 的定义

我们知道,地理数据的坐标系一般有两大类,一是地理坐标系(GCS),是经纬度单位的椭球坐标系;二是投影坐标系(PCS),是平面直角坐标系。

投影坐标系(PCS)的定义一般会包含两方面的定义信息: 
(1)基准面/Datum — 与GCS相应 
(2)投影方法/Projection Method

 

Web Mercator 是一个投影坐标系统,其基准面是 WGS 1984 。

 

那么,第一个问题,WGS 1984 是什么?

“ 世界大地坐标系是美国国防部制图局(Defence Mapping Agency, DMA)为统一世界大地坐标系统,实现全球测量标准的一致性,定义用于制图、大地、导航的坐标基准。它包括标准地球坐标框架、用于处理原始观测数据的标准椭球参考面(即基准和参考椭球)和定义标准海平面的重力等势面(大地水准面)。……”(摘自《大地坐标系统及其应用》)

在上面一段中可以知道,定义一个坐标系绝对是一个复杂浩大的数学工程。 我们经常听说的 WGS 1984 (或 WGS 84)就是其中一个世界大地坐标系统。我们经常使用的 GPS 的坐标参考系统也是它。

WGS 1984 的具体定义参数:

GCS_WGS_1984 
WKID: 4326 Authority: EPSG

Angular Unit: Degree (0.0174532925199433) 
Prime Meridian: Greenwich (0.0) 
Datum: D_WGS_1984 
Spheroid: WGS_1984 
Semimajor Axis: 6378137.0 
Semiminor Axis: 6356752.314245179 
Inverse Flattening: 298.257223563

通过参数描述,我们知道 WGS 1984 是一个长半轴(a)为6378137,短半轴(b)为6356752.314245179 的椭球体,扁率(f)为298.257223563,f=(a-b)/a 。

这里写图片描述

Web Mercator 坐标系使用的投影方法不是严格意义的墨卡托投影,而是一个被 EPSG(European Petroleum Survey Group)称为伪墨卡托的投影方法,这个伪墨卡托投影方法的大名是 Popular Visualization Pseudo Mercator,PVPM。 看起来就觉得这个投影方法不是很严谨的样子,大众化的?受欢迎的?可视化伪墨卡托投影……

因为这个坐标系统是 Google Map 最先使用的,或者更确切地说,是Google 最先发明的。在投影过程中,将表示地球的参考椭球体近似的作为正球体处理(正球体半径 R = 椭球体半长轴 a)。这也是为什么在 ArcGIS 中我们经常看到这个坐标系叫 WGS 1984 Web Mercator (Auxiliary Sphere)。Auxiliary Sphere 就是在告知你,这个坐标在投影过程中,将椭球体近似为正球体做投影变换,虽然基准面是WGS 1984 椭球面。

这里写图片描述

后来,Web Mercator 在 Web 地图领域被广泛使用,这个坐标系就名声大噪。尽管这个坐标系由于精度问题一度不被GIS专业人士接受,但最终 EPSG 还是给了 WKID:3857。

 

1.4 两者的区别

WGS84坐标系
1、WGS84是地心坐标系,空间直角坐标系,原点与地球质心重合,为GPS采用的坐标系;
2、通过GPS可以直接获取WGS84下的坐标(B,L,H),B为纬度,L为经度,H为大地高即到WGS84椭 球面的高度;
3、我国地图采用的是北京1954或西安1980坐标系下的高斯投影坐标(x,y),也有采用北京1954或西安1980坐标系下的经纬度坐标(B,L),高程一般为海拔高度;
4、GPS的测量结果与北京54或西安80坐标相差几十米到一百多米,随区域各异;
WGS84 Web Mercator:
1、谷歌地图(WGS_1984_Pseudo_mercator)、Virtual Earth、Bing Maps、百度地图、Mapabc、ArcGIS Online等采用Web Mercator或Spherical Mercator坐标系,天地图采用CGCS2000国家大地坐标系;
2、Web Mercator与常规墨卡托投影的主要区别就是把地球模拟为球体而非椭球体;
3、为什么选择墨卡托投影?等角正轴圆柱投影,等角保证了对象的形状不变形,也保证了方向和相互位置的正确性(在航海、航空中应用),等角的代价是面积的巨大变形,特别是两极地区;
4、WebGIS开发经常碰到坐标系互转,如底图使用Web Mercator,定位(GPS,wifi等)信号坐标为WGS84坐标,代码实现如下:
//经纬度转Wev墨卡托

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
dvec3 CMathEngine::lonLat2WebMercator(dvec3  lonLat)
{
     dvec3  mercator;
     double  x = lonLat.x *20037508.34/180;
     double  y = log(tan((90+lonLat.y)*PI/360))/(PI/180);
     y = y *20037508.34/180;
     mercator.x = x;
     mercator.y = y;
     return  mercator ;
}
//Web墨卡托转经纬度
dvec3 CMathEngine::WebMercator2lonLat( dvec3   mercator )
{
     dvec3 lonLat;
     double  x = mercator.x/20037508.34*180;
     double  y = mercator.y/20037508.34*180;
     y= 180/PI*(2*atan(exp(y*PI/180))-PI/2);
     lonLat.x = x;
     lonLat.y = y;
     return  lonLat;
}

 

2. 从WGS84到WGS84 Web Mercator

对于非地理专业的开发人员,对与这些生涩的概念,我们不一定都要了解,但是我们要理解,凡是以经纬度为单位的都是地理坐标系,因为它归根结底是一个椭球体,只不过各个国家为了反映该国家所在区域地球的真实形状,而采用不同的数学模型对本不是椭球体的地球进行椭球体化。而投影坐标系,是对地理坐标系按照某种方式投影到平面上的,所以可以认为它是一个平面坐标系,单位自然是米或千米。
       

        我们在做开发的时候,尤其是web地图开发,两种坐标系至关重要4326 GCS_WGS_1984 和 102100WGS_1984_web_mercator_auxiliary_sphere 。


            1)、4326 GCS_WGS_1984 是WGS1984,属于地理坐标系,相信大家对它都有所耳闻,他就是大名鼎鼎的gps采用的坐标系,也就是通过gps拿到的坐标信息都是按这个坐标系给我们的经度和纬度。当然,如果你是做移动平台上的gps,获得的经纬度也是按这个坐标系。


           2)、102100 WGS_1984_web_mercator_auxiliary_sphere则是目前在线地图采用的通用坐标系,属于投影坐标系。


          如果我们采用googlemap做底图,然后想通过gps将位置在地图上显示,不经过任何转换直接在googlemap上显示是不行的,因为他们的坐标系不统一。所以在显示之前就必须将gps获取点进行坐标转换到WGS_1984_web_mercator,然后在googlemap上显示。

       

       在我们的实际应用中,经常用到SpatialReference空间参考系,我们大都用的是WKID=4326的D_WGS_1984的地理坐标,而由于需要,向之前的一篇博文中介绍的,叠加Google Map地图的话,就涉及到将我们现有的地图从WKID=4326的地理坐标系转换成WKID=102100的投影坐标系,怎么转换?

 

   ArcMap中的工具箱中有这样的工具,以下截图详细说明:

 

1、打开已有的地图,并打开工具箱

 

2、按照箭头指向,依次展开节点后,选择“Project”工具,如下:

 

3、在打开的Project窗口中,选择输出的空间坐标系统,然后,点击“Select”,如下图:

 

4、选择“Projected Coordinate System”,如下图:

 

5、选择“World”,点击“Add”,如下图:

 

6、找到WGS 1984 Web Mercator.prj,点击“Add”,如下图:

 

7、在下拉框中,选择仅有的一项,然后点击“OK”,至此已经完成(这里请注意:请记住Output Dataset or Feature Class中的位置,那是转换后的输出shp位置)

 

8、关闭ArcMap,重新打开ArcMap,并Add Data上一步中转换后的那个图层shp文件,此时的图层已经是墨卡托坐标系了。



参考文章

WGS1984 -UTM投影问题

WGS84WGS84 Web Mercator的区别  

ArcGIS中利用ArcMap将地理坐标系转换成投影坐标系(从WKID=4326WKID=102100

Web Mercator 公开的小秘密

 

没有整理与归纳的知识,一文不值!高度概括与梳理的知识,才是自己真正的知识与技能。 永远不要让自己的自由、好奇、充满创造力的想法被现实的框架所束缚,让创造力自由成长吧! 多花时间,关心他(她)人,正如别人所关心你的。理想的腾飞与实现,没有别人的支持与帮助,是万万不能的。




    本文转自wenglabs博客园博客,原文链接:http://www.cnblogs.com/arxive/p/6103358.html ,如需转载请自行联系原作者



相关文章
|
定位技术
wgs84和wgs84web如何转换?
wgs84和wgs84web如何转换?
1270 60
|
2月前
|
算法 Java Go
【GoGin】(1)上手Go Gin 基于Go语言开发的Web框架,本文介绍了各种路由的配置信息;包含各场景下请求参数的基本传入接收
gin 框架中采用的路优酷是基于httprouter做的是一个高性能的 HTTP 请求路由器,适用于 Go 语言。它的设计目标是提供高效的路由匹配和低内存占用,特别适合需要高性能和简单路由的应用场景。
263 4
|
6月前
|
缓存 JavaScript 前端开发
鸿蒙5开发宝藏案例分享---Web开发优化案例分享
本文深入解读鸿蒙官方文档中的 `ArkWeb` 性能优化技巧,从预启动进程到预渲染,涵盖预下载、预连接、预取POST等八大优化策略。通过代码示例详解如何提升Web页面加载速度,助你打造流畅的HarmonyOS应用体验。内容实用,按需选用,让H5页面快到飞起!
|
6月前
|
JavaScript 前端开发 API
鸿蒙5开发宝藏案例分享---Web加载时延优化解析
本文深入解析了鸿蒙开发中Web加载完成时延的优化技巧,结合官方案例与实际代码,助你提升性能。核心内容包括:使用DevEco Profiler和DevTools定位瓶颈、四大优化方向(资源合并、接口预取、图片懒加载、任务拆解)及高频手段总结。同时提供性能优化黄金准则,如首屏资源控制在300KB内、关键接口响应≤200ms等,帮助开发者实现丝般流畅体验。
|
前端开发 JavaScript Shell
鸿蒙5开发宝藏案例分享---Web页面内点击响应时延分析
本文为鸿蒙开发者整理了Web性能优化的实战案例解析,结合官方文档深度扩展。内容涵盖点击响应时延核心指标(≤100ms)、性能分析工具链(如DevTools时间线、ArkUI Trace抓取)以及高频优化场景,包括递归函数优化、网络请求阻塞解决方案和setTimeout滥用问题等。同时提供进阶技巧,如首帧加速、透明动画陷阱规避及Web组件初始化加速,并通过优化前后Trace对比展示成果。最后总结了快速定位问题的方法与开发建议,助力开发者提升Web应用性能。
|
6月前
|
JSON 开发框架 自然语言处理
【HarmonyOS Next之旅】基于ArkTS开发(三) -> 兼容JS的类Web开发(三)
本文主要介绍了应用开发中的三大核心内容:生命周期管理、资源限定与访问以及多语言支持。在生命周期部分,详细说明了应用和页面的生命周期函数及其触发时机,帮助开发者更好地掌控应用状态变化。资源限定与访问章节,则聚焦于资源限定词的定义、命名规则及匹配逻辑,并阐述了如何通过 `$r` 引用 JS 模块内的资源。最后,多语言支持部分讲解了如何通过 JSON 文件定义多语言资源,使用 `$t` 和 `$tc` 方法实现简单格式化与单复数格式化,为全球化应用提供便利。
262 104
|
6月前
|
JavaScript 前端开发 API
【HarmonyOS Next之旅】基于ArkTS开发(三) -> 兼容JS的类Web开发(二)
本文介绍了HarmonyOS应用开发中的HML、CSS和JS语法。HML作为标记语言,支持数据绑定、事件处理、列表渲染等功能;CSS用于样式定义,涵盖尺寸单位、样式导入、选择器及伪类等特性;JS实现业务逻辑,包括ES6语法支持、对象属性、数据方法及事件处理。通过具体代码示例,详细解析了页面构建与交互的实现方式,为开发者提供全面的技术指导。
284 104
|
6月前
|
开发框架 编解码 JavaScript
【HarmonyOS Next之旅】基于ArkTS开发(三) -> 兼容JS的类Web开发(一)
该文档详细介绍了一个兼容JS的类Web开发范式的方舟开发框架,涵盖概述、文件组织、js标签配置及app.js等内容。框架采用HML、CSS、JavaScript三段式开发方式,支持单向数据绑定,适合中小型应用开发。文件组织部分说明了目录结构、访问规则和媒体文件格式;js标签配置包括实例名称、页面路由和窗口样式信息;app.js则描述了应用生命周期与对象管理。整体内容旨在帮助开发者快速构建基于方舟框架的应用程序。
283 102
|
7月前
|
Web App开发 前端开发 JavaScript
鸿蒙5开发宝藏案例分享---Web适配一多开发实践
这是一份实用的鸿蒙Web多设备适配开发指南,针对开发者在不同屏幕尺寸下的布局难题提供了解决方案。文章通过三大法宝(相对单位、媒体查询和窗口监听)详细介绍如何实现智能适配,并提供了多个实战案例,如宫格布局、对话框变形和自适应轮播图等。此外,还分享了调试技巧及工具推荐,帮助开发者快速上手并优化性能。最后鼓励读者实践探索,并提示更多官方资源等待发现。
|
9月前
|
关系型数据库 MySQL 数据库
基于Flink CDC 开发,支持Web-UI的实时KingBase 连接器,三大模式无缝切换,效率翻倍!
TIS 是一款基于Web-UI的开源大数据集成工具,通过与人大金仓Kingbase的深度整合,提供高效、灵活的实时数据集成方案。它支持增量数据监听和实时写入,兼容MySQL、PostgreSQL和Oracle模式,无需编写复杂脚本,操作简单直观,特别适合非专业开发人员使用。TIS率先实现了Kingbase CDC连接器的整合,成为业界首个开箱即用的Kingbase CDC数据同步解决方案,助力企业数字化转型。
1959 5
基于Flink CDC 开发,支持Web-UI的实时KingBase 连接器,三大模式无缝切换,效率翻倍!