最近从北京搬到了上海,开始了一段新的生活,算是人生中一个比较大的事件,于是特地用 Three.js 做了下可视化。
随着接触的地图种类越来越多,每种产品对地图服务的坐标系的要求不同,今天遇到了整理的好文,整理记录分享。
WMTS地图服务每一层级的分辨率是多少?关于这个问题以前推算过,但总是忘记了。网上查询又是一堆废话,现在把这个问题记录如下。
天地图API:http://lbs.tianditu.gov.cn/server/MapService.html 需要登录后进入控制台,申请免费的Key:
主流被使用的地理坐标系并不统一,常用的有WGS84、GCJ02(火星坐标系)、BD09(百度坐标系)以及百度地图中保存矢量信息的web墨卡托,本文利用Python编写相关类以实现4种坐标系统之间的互相转换。
目前 GPS 的国际标准坐标系统, GPS 所发布的星历参数就是基于此坐标系统的。WGS-84 坐标系统的全称是World Geodical System-84(世界大地坐标系-84),它是一个地心地固坐标系统。WGS-84 坐标系统由美国国防部制图局建立,于1987 年取代了当时GPS所采用的坐标系统―WGS-72坐标系统而成为GPS 的所使用的坐标系统。WGS-84 坐标系的坐标原点位于地球的质心,Z 轴指向BIH1984.0 定义的协议地球极方向,X 轴指向BIH1984.0 的启始子午面和赤道的交点,Y 轴与X 轴和Z 轴构成右手系。
我在《大地经纬度坐标与地心地固坐标的的转换》这篇文章中已经论述了大地坐标系/地理坐标系的概念,简单来说就是由经度、纬度以及高程(BLH)确定的坐标系,它是一种曲面坐标。
地球近似为一个“椭球体”,在不考虑高程的情况下其实经纬度坐标就是描述了某点在球面的位置。在没有电脑、没有数字化地图的时代最实用的是纸质地图,但纸质地图是平面的,要把地“球”展开到地图的“平面“上(把地球在一张纸上“画”出来)就需要投影(Projection)。
基于很多同志询问添加经纬度办法,系统性重编了地图的经纬度添加方式。各种投影中以矩形投影PlateCarree最为方便,可以套用matplotlib.mticker的形式。在最新的0.18版本的cartopy中,虽然还不完善,但是终于能直接绘制兰勃脱下的标签了。墨卡托在官网上有示例。
iOS墨卡托和GPS坐标计算距离时误差测试,测试结果: 墨卡托和gps坐标来回转换没有误差。 墨卡托坐标计算出的距离比gps坐标计算出的距离大,100/92*100 = 108米,每100米多算出8米。 故随着导航距离缩短,误差会逐渐变小。 log 25.780135+0800 gps_mktDistanceTest[91276:1928266] mkt dis = 10.00 25.781216+0800 gps_mktDistanceTest[91276:1928266] gps dis = 9.20
投影坐标系统 PCS(Projection Coordinate System),它也叫非地球投影坐标系统 (notearth),或者再简单点叫平面坐标系统,也就是使用基于 X,Y 值的坐标系统来描述地球上某个点所处的位置
cesiumjs中可定制多种图层,可以使用互联网上很多地图提供商的图层数据,也可以使用自己的地图数据。Cesium支持多种标准化格式的GIS瓦片服务,可以把栅格图层绘制到地球的表面——cesiumjs的地图图层本质上是一些瓦片数据,这些图层的亮度、对比度、色相均可以动态调整。
坐标的问题是Mapxtreme中最郁闷的问题,前几天在这上面耗了很多时间,没有搞定,今天又是不得不钻研,还好,小有心得。 1、分类: 1)图层的坐标:或者说图元的坐标,只能通过ftr.Geometry.CoordSys来获得坐标系的信息(通过图层无法获得坐标系的信息,我试过很多次反正没成功。有时不得不采用一个笨办法,先查出一个图元,再通过该图元访问坐标系)。我碰到的大多是横轴墨卡托(也许跟从MapGis转换过来有关),单位是米(通过Coord
目前工作中有不少涉及到地图的项目,我参加了几次技术评审,前端伙伴们在 WebGIS 方面的知识储备稍有不足,这次分享的主要目的是科普一些在前端领域比较常用的 WebGIS 知识。另外,我之前的工作中积攒了一些从零开始搭建 WebGL 地图引擎的微薄经验,虽然最终遗憾没有上线,但在其中学到的一些WebGL知识还是值得分享一下。WebGL 可以说是前端可视化技术领域难度最大的一项图形编程技术,所以今天就结合 WebGIS 这个话题顺带分享一些 WebGL 的相关知识,不会太深入,很细节的技术点在后续文章里再讲解。
由于复制过来,如果有格式问题,推荐大家直接去我原网站上查看: 相机模型与坐标转换 - 生活大爆炸
WebGIS系统通常都围绕地图进行内容表达,但并不是有地图就一定是WebGIS,所以有必要讨论下基于Web的地图API分类及应用场景。
作者:郭子豪 中国地质大学(武汉)研究生 HPSCIL Urban Comp 城市之光团队成员
所谓地图投影,是利用一定数学法则把地球表面的经、纬线转换到平面上的理论和方法。由于地球是一个赤道略宽两极略扁的不规则的梨形球体,故其表面是一个不可展平的曲面,所以运用任何数学方法进行这种转换都会产生误差和变形,为按照不同的需求缩小误差,就产生了各种投影方法,eg:墨卡托投影,高斯克吕格投影, Lambert__投影,UTM__投影…
本文介绍了一种基于 canvas 的热力图实现方案,通过分析每个像素的透明度,对颜色进行映射,从而实现热力图效果。该方案包括准备数据、创建 canvas 渐变填充、根据透明度生成颜色映射表、重置 canvas 画布颜色和实现热力原理等步骤。
本文作者:TalkingData 可视化工程师李凤禄 编辑:Aresn inMap 是一款基于 canvas 的大数据可视化库,专注于大数据方向点线面的可视化效果展示。目前支持散点、围栏、热力、网格、聚合等方式;致力于让大数据可视化变得简单易用。 GitHub 地址:https://github.com/TalkingData/inmapinmap 热力图这个名字听起来很高大上,其实等同于我们常说的密度图。 📷 如图表示,红色区域表示分析要素的密度大,而蓝色区域表示分析要素的密度小。只要点密集,就会形成聚类
由于地球是一个赤道略宽两极略扁的不规则的梨形球体,表面是一个不可展平的曲面,而地图通常是二维平面,因此在地图制图时首先要考虑把曲面转化成平面。然而,从几何意义上来说,球面是不可展平的曲面。要把它展成平面,势必会产生破裂与褶皱。这种不连续的、破裂的平面是不适合制作地图的,所以必须采用特殊的方法来实现球面到平面的转化。
预热文章系列:《GIS历史概述与WebGis应用开发技术浅解》、《GIS坐标系:WGS84,GCJ02,BD09,火星坐标,大地坐标等解析说与转换》、《OGC标准WMTS服务概念与地图商的瓦片编号流派》、《GIS基础知识 - 坐标系、投影、EPSG:4326、EPSG:3857 》我们过一遍如下概念:
最近想做一个简单的地理位置分析,比如获取一些城市公交站点对应的geohash,geohash其实是将平时常见的经纬度进行了降维,这样可以进行类似附近的餐馆等内容的分析。
OD数据是交通、城市规划以及GIS等领域常见的一类数据,特点是每一条数据都记录了一次OD(O即Origin,D即Destination)行为的起点与终点坐标信息。
「OD数据」是交通、城市规划以及GIS等领域常见的一类数据,特点是每一条数据都记录了一次OD(O即Origin,D即Destination)行为的起点与终点坐标信息。
其原理是这样的:保密局开发了一个系统,能将实际的坐标转换成虚拟的坐标。所有在中国销售的数字地图必须使用这个系统进行坐标转换之后方可上市。这是生产环节,这种电子地图被称为火星地图。在使用环节,GPS终端设备必须集成保密局提供的加密算法(集成工作由保密局完成),把从GPS卫星那里得到的坐标转换成虚拟坐标,然后再去火星地图上查找,这样就在火星坐标系上完成了地图的匹配。 所以大家所用的百度,高德等地图定位准是偏差几百米
POI点POI是“Point of Information”的缩写,中文可以翻译为“信息点”。在地理信息系统中,一个POI可以是一栋房子、一个商铺、一个邮筒、一个公交站等。
很多时候,我们都会遇到这样的需求:查找某个点周边多少距离的点。从本质来说,是一个缓冲区分析+空间查找,本文结合Geohash来实现类似的功能。
本文说说geotools中坐标转换的那点事情,以WGS84和web墨卡托相互转换为例。
前面的几篇文章总结了怎样用 SwiftUI 搭建基本框架时候的一些注意点(和这篇文章在相同的分类里面,有需要了可以点进去看看),这篇文章要总结的东西是用地图数据处理结合来说的,通过这篇文章我们能总结到的点有下面几点:
百度使用的自家BD09LL坐标系,高德和腾讯都是GCJ02即火星坐标系,所以相互之间是需要转换的,不然会有位置偏移。
世界大地测量系统(World geodetic system,简称WGS)是指1960年以来, 由美国国防制图局(DMA)建立的四个世界大地测量系统(WGS60、WGS66、WGS72和WGS84)的统称
IP 地址会与真实位置有一个大概的对应关系,形成 IP - 地点 的映射,本文记录相应工具和使用方法。 简介 IP - 地址 的映射本质上只要建立一个字典就好了,但是数据量还是很大的,有专门的机构已经
这个功能最重要的就是路线规划,路线两端分别是点外卖的人,商家,送外卖的骑手,商家的位置,后端接口直接就能拿到给前端,而用户的位置,由于地址是自己填的,因此前端也可以轻松的拿到地址转为经纬度。那骑手的位置呢?这就要从第三方物流接口去获取了,那得看实际的项目接入的是顺丰,美团还是哒哒或者其他什么。而且这个小demo也不需要那么复杂,虽然没有骑手位置,那就简单模拟一下好了。首先在小程序上创建一张地图出来:
各地图的瓦片坐标系定义、转换原理和转换公式可以参见博文:国内主要地图瓦片坐标系定义及计算原理[2]
4、Cartographic(地理坐标系下经纬度的弧度表示),通常情况下通过它和WGS84坐标系之间互转。
写在最前面~ 这篇文章是对前端定位方案的一篇总结,平日我们在前端开发过程中针对定位问题不会专门专注内部的实现原理,会直接调用封装好的库去实现定位能力。这样就会出现一个问题,当线上报出定位问题的时候,我
说到地图,大家一定很熟悉,平时应该都使用过百度地图、地图、腾讯地图等,如果涉及到地图相关的开发需求,也有很多选择,比如前面的几个地图都会提供一套js API,此外也有一些开源地图框架可以使用,比如OpenLayers、Leaflet等。
在前面的教程中,我们已经讲解了常用的二维型数据的可视化方法。但是在日常研究中,由于大气科学属于地学系统,和地球地理信息的结合十分密切,大多数时间,需要在图形中添加地理信息。作为胶水语言,在Python中,目前还在使用的地理可视化库包尚有basemap、cartopy、geopandas等,但由于basemap是基于Python 2,而2已经不再维护,这意味着basemap也要为Python 2陪葬。而geopandas是基于pandas的,属于商务图表利器,但对于气象科研,显得力不从心。现在仅介绍basemap接班者cartopy。
目前项目的中国地图是echarts画的,现在这想再次基础上增加一个中国地图描边动画。
作为菜鸟分析师一枚,日常工作中需要处理大量地理位置相关(如城市、辖区、街道、商场、楼宇等)数据。分析报告中总是用吐了的柱形图、条形图,不仅自己看着辣眼睛,老板也审美疲劳。
手上有一堆地址的信息,例如电商行业的买家收货地址信息,想使用powerbi等可视化工具将其在地图上作展示,就需要将其转换为经纬度的信息。
地图应用非常广泛,目前地图服务,都提供地图操作、标注、地点搜索、出行规划、地址解析、街景等接口,功能非常丰富。在实际开发过程中,各有优劣。本次基于需求,使用腾讯位置服务作为一个公用厕所位置标注的H5页面开发。
这个需求在百度地图里面实现很简单,但是出了一大堆的乱起八糟的错误,错误等到后面的文章再说,先说要获取当前位置怎么做
http://www.cnblogs.com/LBSer/p/3310455.html
墨卡托投影是一种“等角正切圆柱投影”,荷兰地图学家墨卡托(Mercator)在1569年拟定:假设地球被围在一个中空的圆柱里,其赤道与圆柱相接触,然后再假想地球中心有一盏灯,把球面上的图形投影到圆柱体上,再把圆柱体展开,这就是一幅标准纬线为零度(即赤道)的“墨卡托投影”绘制出的世界地图。 墨卡托投影在今天对于航海事业起着极为重要的作用,目前世界各国绘制海洋地图时仍广泛使用墨卡托投影,国际水路局(IHB)规定:“除特殊情况外,各国都要用墨卡托投影绘制海图”。国际水路局发行的《大洋水深总图》是把全世界分
地址和经纬度互相转换的功能也经常用到,比如上次的路线方案查询的功能,之前官网是提供了直接输入出发地点和目的地的中文汉字,就可以查询到最优的路线,后面只支持输入出发地点和目的地的经纬度坐标了,这个就有点绕了,让用户输入什么经纬度坐标,那是个什么鬼?没有几个用户搞得懂的,所以就需要先将用户输入的出发地点和目的地的中文汉字先查询到对应的经纬度坐标,然后再传入路线查询的JS函数中查询结果即可,为什么突然关闭了这个地址经纬度自动转换的功能呢?我去后台看了下,原来这项功能变成收费模块了。
在去年cosbeta曾经发布了一个网页计算工具,这个作用就是根据地球上两点之间的经纬度计算两点之间的直线距离。经纬度到距离的计算在通信工程中应用比较广泛,所以cosbeta通过搜索找到了一个js的计算脚本(其实是google map的计算脚本,应该算是比较准确了),做成了这个经纬度算距离的工具。
redis地理位置信息geo的基本操作和使用咱们之前已经聊过,可以看看这篇文章 微信附近的人,用redis也能实现?
领取专属 10元无门槛券
手把手带您无忧上云