ArcGIS中使用PostGIS数据源

以下测试场景为ArcGIS 10.4.1。

PostGIS Geometry vs SDE st_geometry

ArcGIS 10.4.x开始直接支持PostGIS Geometry,而无需再单独拷贝st_geometry,以及使用sde账户等等繁琐的事情(一如当年支持Oracle Spaitial和SQL Server Spatial)。这无疑是很大利好,PostGIS的功能、函数和增长性、活跃程度上,也不是sde所能媲美的。sde的方式可查看之前写的这篇博文

继续阅读ArcGIS中使用PostGIS数据源

PostgreSQL性能相关的基础要点

事务化处理

对数据库的修改,尤其是直接改变数据或数据结构,尽量使用事务块来完成。关于事务,PostgreSQL默认把每个SQL语句放在一个事务中执行,相当于被自动加上了begin和commit包围。事务当然可以全部回滚,但是在包围内可以定义savepoint,并且可以用rollback to回滚到指定的savepoint。

正确使用索引

优化的首要方式,还是要先处理好索引。虽然索引都是有成本的,但该尝试的时候还是该果断尝试。PG支持的几个主要索引方式:

继续阅读PostgreSQL性能相关的基础要点

PostgreSQL性能相关的必知SQL

创建索引

索引的类型,有B-tree, Hash, GiST, SP-GiST和GIN。对于这些type,使用如下语句创建索引:

执行计划

使用EXPLAIN命令来显示SQL的执行计划,在pg中,EXPLAIN的命令格式如下:

option可以为ANALYZE/VERBOSE/COSTS/BUFFERS/FORMAT

继续阅读PostgreSQL性能相关的必知SQL

椭球体的重要参数和公式

基准和椭球体

地球表面非常的不规则,如果按照大地水准面来定义地球表面,别说是球体了,估计连一个椭球体都得不到。假想一个扁率极小的椭圆,绕大地球体短轴旋转所形成的规则椭球体称之为地球椭球体。地球椭球体表面是一个规则的数学表面,可以用数学公式表达,所以在测量和制图中就用它替代地球的自然表面。椭球体是通过长半轴和短半轴(或长半轴和扁率)来定义或控制。椭球通过基准来定义,一般包括中心和方向。大地基准是大地测量计算时的参考依据和尺度。大地基准面(Geodetic Datum),由椭球体本身及椭球体和地表上一组点视为原点间之关系来定义。一般认为此关系能以6个量来定义,通常是大地纬度、大地经度、原点高度、原点垂线偏差之两分量及原点至某点的大地方位角。这些概念并不是特别容易理清,暂时不理会。

国际上使用最广泛的World Geodetic System 1984 (WGS84),是一种地心坐标系,坐标原点为地球质心。包括了一个基准和一个坐标系统。至于为什么总是用年份来标识基准,主要因为大陆漂移等原因,用来定义基准的那些点位,总是在变化的。所以通常使用定义基准的年份来命名,所以在84之前,还有WGS72,WGS66和WGS60。GPS的广播星历是以WGS84坐标系为依据的,而据说当年定义这个基准的时候,有人忘记加入欧洲的控制点,所以欧洲又有了一套ETRS89(…懵逼)。

在我国,北京54采用的是克拉索夫斯基椭球,在该坐标系内进行了许多地区的局部平差,其成果得到了广泛的应用。1978年4月在西安召开全国天文大地网平差会议,确定重新定位,即建立西安80坐标系,此后西安80坐标系取代北京54坐标系成为新的国家坐标系。西安80采用的是1975国际椭球。

常用椭球

坐标系 椭球 长半轴 短半轴 扁率
WGS84大地坐标系 WGS84地球椭球 6378137 6356752.314 1/298.257223563
北京54坐标系 克拉索夫斯基椭球 6738245 6356863 1/298.3
西安80坐标系 IAG75地球椭球 6378140 6356755 1/298.257
国家2000大地坐标系 CGCS2000地球椭球 6378137 6356752.31414 1/298.257222101

重要公式

椭球体(或称旋转椭球体)有两个半径,即长半轴(a)和短半轴(b)。椭球体可以由a和b定义,也可以由a和扁率定义,扁率f(Flattening)的定义为:
\[f={{a-b}\over a}\]

在坐标系中除了长半轴、短半轴和扁率这三个直观数字外,偏心率的平方,也可以用来描述椭球体形状,加上其余的一些参数,汇总如下:

参数 公式
第一偏心率 \(e_1=\sqrt{a^2-b^2\over a^2} \)
第二偏心率 \(e_2=\sqrt{a^2-b^2\over b^2} \)
第一辅助参数 \(W=\sqrt {1-e^2 \sin^2B}\)
卯酉圈曲率半径 \(N ={ a \over W } = {a \over \sqrt {1-e^2 \sin^2B}}\)
子午线曲率半径 \(M = {a(1-e^2) \over W^3} = { a(1-e^2) \over (1-e^2 \sin^2B)^{3 \over 2} }\)

Mapbox矢量切片源码分析

为了了解矢量切片的更多技术细节,轻微挖一挖Mapbox-gl-js的前端结构。比较关键的内容是矢量切片如何在前端如何被定义、加载和绘制,下面结合源码稍微介绍下。

概念

矢量切片规范

Mapbox矢量切片规范定义的内容:文件格式(后缀名、MIME)、投影和范围、内部结构(图层、要素、几何图形编码、要素属性)。切片文件里不在是地理坐标(例如经度和纬度),而是屏幕坐标,也并不包含任何地理信息。在切片文件里,原点坐标是左上角,x轴向右递增,y轴向下递增。

绘制

Mapbox-gl-js使用客户端绘制,这是vector tiles在前端最核心的部分,也因为此,在前端运行时修改地图样式变得轻而易举。大多数地图前端SDK或api(如arcgis、openlayers、leaflet),决定mapview的通常就是center point + zoom level(或 center point + extent),在矢量绘制情况下,zoom level可以是任意的,包括小数(例如6.5),应该基本上算是无极缩放了。除此之外,还有两个很重要的参数:
1. bearing:地图旋转参数,单位是度数。
2. pitch:地图倾斜角度(3d才cool嘛)。

在图层方面,Mapbox gl中定义了渲染数据的方式,这些数据即可以是栅格,也可以是矢量。但由于前端渲染,所以实际上底图和专题图在技术实现上,并没有实质的区别。这样的好处是,所有的要素都可以如同arcgis下的GraphicLayer,或者Javascript中的div一般可拥有较可控的交互能力。

camera和Map

Mapboxgl.camera控制目标位置的中心点位置、缩放级别、旋转角度和倾斜角度。Mapboxgl.Map对象是提供开发接口的最基本对象,继承自camera,并在初始化的时候通过container的设置(HTML元素)来告知Mapboxgl渲染出对应的Map对象。

继续阅读Mapbox矢量切片源码分析

矢量地图切片技术分析

1. 什么是矢量切片

传统的栅格地图切片,是预先在Server端绘制好固定的PNG和JPG切片集合。而矢量切片是很早就已经出现,并已通过各种不同的技术手段在应用中表现出来,大多以json或二进制文件将矢量地图数据传输至前端进行绘制。例如百度地图、Google地图等都较早实现了栅格和矢量两种模式。

矢量地图切片将矢量数据通过不同的描述文件来组织和定义,通常通过自定义文件或json文件进行传输,在前端按需请求不同的矢量瓦片数据文件,并利用类似canvas等技术进行绘制。使用这种技术有不少好处,例如不再需要为不同的样式而反复进行制图、渲染、切片、更新service等过程,并且在当前各种高分屏、视网膜屏大肆发展的阶段,避开按照特定DPI和分辨率渲染的栅格图片在不同的显示设备上无法以统一清晰的效果呈现,等等。

当前,矢量切片已经广泛应用开了,现在的在OSM数据中得到了广泛的使用,例如这个站点提供了OSM Planet和分国家区域的daily下载包,并且以MBTiles文件的形式提供。

 

1.1 矢量切片规范

Mapbox提出了Vector Tile的开放规范,并遵守Creative Commons Attribution 3.0 United States License:Mapbox Vector Tile Specification,该规范用到了Google的Protocol Buffers作为数据编码规范。同样被Mapbox列入规范的还有MBTiles is a specification,作为在SQLite中存储切片数据的规范。在两者的github页面上,都可以找到对应规范的实现清单,这些实现大多是开源工具,也包含一些闭源软件,而这些所有,足以支撑起矢量切片的数据转换、数据存储、数据服务的全技术架构的基本骨架。

继续阅读矢量地图切片技术分析

说一说新出的ArcGIS Runtime SDK v100.0

11月21日,ESRI在官博上发布了题为“ArcGIS Runtime SDK 100.0 has arrived!”的博文,这个100.0足够吸引了眼球,其实回头算算,quartz beta已经太久太久了,而这个100.0,本质上就是quartz release。

以下只是一些吐槽,以及从地图结构的变化角度,来看看ESRI的思路。

关于Desktop Development

ESRI的Runtime产品线在不断壮大,其中单个开发语言中的具体选型,也看出了跨平台的思路。Android、iOS、macOS三者不说,都是运行在特定平台之上,而似乎有不能被忽略的。而Java(Windows/Linux/macOS)、.NET(Windows/iOS/Android)、Qt(Windows/Linux/Android/iOS)三者,无一不是看起来牛气冲天。但是冷静思考下来,其核心竞争力还是很难讲,毕竟在跨平台这个层面,Qt受众较小;.NET独大,但app开发者中,没有足够多的Xamarin用户;Java本该是一枝独秀,无奈Oracle强取豪夺之下,发展堪忧,其客户端开发技术更是令人无所适从,在这种情况下,ESRI此次的v100居然选择了JavaFX这个看似时髦(2008年才推出)却又实际上后劲不足的语言实现。按我建议,更倾向于继续使用swing来保留住传统意义的Java开发者。不过值得推崇的是,此次的Java SDK已经扩展到了macOS(除了Local Server之类无法支持)。相比之下,macOS在ArcGIS的用户(尤其是中国用户)中也属于相对小众,但是单看Swift和Objc的双重策略,也该为ESRI点赞。毕竟在“语系”上,macOS的开发技术与iOS/watchOS系出同门。

继续阅读说一说新出的ArcGIS Runtime SDK v100.0

Synergy-多主机共享键鼠的神器

需求场景

始终有这样的困惑,办公桌上同时有2台电脑、多个显示器同时投入工作,实际上有的人可能更多。当然,Windows、macOS、Ubuntu…都是我常要用到的操作系统。通常,大家都能习惯给一台主机接多台显示器分屏,但多台电脑同时工作的时候,需要多套键鼠间来回切换,因此即便有很大的办公桌,也是非常不爽的。尤其对于对于舒适性有一定强迫症的人来说。

终结工具 – Synergy

Synergy,真的算的上是神器。最庆幸的事情莫过于挽起袖子准备大干一场造一个轮子的时候突然google到了这样一个存在。看介绍,不但是跨平台,而且操作应当是无缝的。

官网:https://symless.com/。

继续阅读Synergy-多主机共享键鼠的神器

SNE与t-SNE降维算法理解

1. SNE概要

数据降维,大体分为线性方法和非线性方法。其中线性方法例如PCA和LDA,而非线性方法又有保留局部特征、基于全局特征等方法。有人整理了一张分类图,下面这张图从网上引用而来:

相比于其他降维方法,t-SNE是近年比较火热的一种高维数据可视化技术,能够通过降维,将高维数据降维并给出二维或三维的坐标点,从而可以在人能够轻易理解的平面或立体空间内将数据可视化出来。这个方法是SNE的变种,SNE是Hinton在2002年提出来的方法。Stochastic Neighbor Embedding,好吧,又是embedding。目标是将高维数据映射到低维后,尽量保持数据点之间的空间结构,这样在高维空间里距离较远的点,在低维空间中依然保持较远的距离。在传统的方法中,PCA和MDS是线性技术,用于保持相距较远的数据点之间的低维表示。Maaten将t-SNE的降维结果与其他7种降维方法的结果,在5种不同的数据集中作了对比。

1.1 高维数据的相似度概率分布

SNE将数据点之间高维的欧氏距离转换为表示相似度的条件概率,即用条件概率\(p(j|i)\)表示点\(x_j\)到点\(x_i\)的相似度,这个含义可以理解为:若以\(x_i\)为中心的高斯分布来选取邻居,则\(x_i\)选择\(x_j\)作为自己邻居的概率是\(p(j|i)\)。若数据点相距较近,则\(p(j|i)\)较大,相反若数据点相距非常远,\(p(j|i)\)则可以接近无穷小。条件概率\(p(j|i)\)定义如下:

继续阅读SNE与t-SNE降维算法理解

Word2Vec原理之负采样算法

这篇主要根据前人的文章内容,整理了一遍skip-gram模型下negative-sampling的基本推导思路,只作学习之用,并不完整。公式也都是来自于已有论文。

分布式假设

Word2Vec虽然一直火热,也引发了各种词嵌入,但实际上不可否认依然是缺乏严谨的可解释性。所谓的分布式假设,就是处于相似上下文中的词具有相似的含义,一般认为这种相似包含了语义层面的相似,但却很难使用自然语言的词法、句法或语义的层面的现有知识来充分地解释。这可能也是词向量的一个缺陷,不过另一方面,这种分布式假设的概念可以应用到很多其他的领域的数据分析,比如广告分析、app点击数据分析等,毕竟只要能替代词和语料的关系,并且有上下文和中心词的类比关系,就可以一试,所以应用的广度可以说无法估计。

继续阅读Word2Vec原理之负采样算法