geohash vs PostGIS

标签

PostgreSQL , PostGIS , GEOHASH , 经纬度 , geometry , geography


背景

业界有几种地理位置的表示方法。

通常我们使用经纬度表示地球上的位置,PostgreSQL的PostGIS可以很好的描述这种类型,包括海拔在内。使用最为广泛,精度、功能最高的应该是PostGIS。

但是并不是所有的数据库都有这样的技术(或者实现难度的问题导致了很多数据库在初期会选择较为简单的geohash)。

什么是geohash呢?

geohash 原理

通常我们使用经纬度表示地球上的位置,PostgreSQL的PostGIS可以很好的描述这种类型,包括海拔在内。

但是并不是所有的数据库都有这样的技术(或者实现难度的问题导致了很多数据库在初期会选择较为简单的geohash)。

什么是geohash呢?

实际上geohash是一套网格化的编码方式,经过编码,可以将经纬度对应的点,表示为一个网格,网格的大小,取决于geohash的精度。

通常,geohash使用32个字符进行编码。业界也有使用geo base 36的编码,即36个字符来表示的。

编码后,离得越近的点,编码值也是越近的。prefix永远会包含更长的编码字符表示的范围。(例如wb12x是5位的,包含了wb12x..........的网格,即wb12x是个大格子,wb12x....是更小的格子。),但是请注意,边界问题,例如-180和180实际上是一个地方。但是它们的geohash编码却完全不一样。这也是geohash的问题之一。

如何将geohash编码转换为经纬度?

首先有一个base32的映射表(以32个字符进行编码为例)

例如一个hash=ezs42的geohash值,通过这个表,可以翻译成 13, 31, 24, 4, 2。

将以上每个数字,使用5位BIT表示,进而翻译成 01101 11111 11000 00100 00010 。

接下来是关键不走,以上BIT串,位置从0开始,偶数的BIT位连起来作为 longitude code (0111110000000), 奇数比特位连起来作为 latitude code (101111001001).

得到了经纬度BIT串后,该怎么办呢?

经度范围-180 ~ 180

纬度范围-90 ~ 90

每次将范围对半拆开,例如-180, 0, 180。当bit=0时,表示点落在左边的范围,当bit=1时,表示点落在右边的范围。然后再将下一个范围对半拆开,例如-180, -90, 0。继续根据BIT选择范围,循环往复。

得到一个范围,取范围的中值,作为对应的经度或者纬度。

上图就是101111001001的计算过程,右,左,右,右,右,右,左,左,右,左,左,右。

value指范围的中间值,ERR指误差。

当geohash的字符串长度越长时,误差越小,我们来看看误差表如下。

geohash缺陷

由于编码,地球非正球体,等问题。导致了geohash 存在几个比较致命的缺陷。

1. 网格化算法带来的精度问题

2. 地球是不规则椭圆,geohash的偏差会随着纬度的变大骤变,越接南北极地,距离计算越不准确。

  • At the Equator (0 Degrees) the length of a degree of longitude is 111.320 km, while a degree of latitude measures 110.574 km, an error of 0.67%.
  • At 30 Degrees (Mid Latitudes) the error is 110.852/96.486 = 14.89%
  • At 60 Degrees (High Arctic) the error is 111.412/55.800 = 99.67%, reaching infinity at the poles.

3. 经度边界(-180,180)数据的处理,边界的哈希值完全不同,但是他们却相邻,不利于相邻计算。

PostGIS geometry, geography, raster, ...

PostgreSQL PostGIS 发展了几十年,有非常深厚的理论背景,广泛应用于军工、科研、商业场景。

PostGIS adds extra types (geometry, geography, raster and others) to the PostgreSQL database.

It also adds functions, operators, and index enhancements that apply to these spatial types.

These additonal functions, operators, index bindings and types augment the power of the core PostgreSQL DBMS, making it a fast, feature-plenty, and robust spatial database management system.

Feature List

The PostGIS 2+ series provides:

  • Processing and analytic functions for both vector and raster data for splicing, dicing, morphing, reclassifying, and collecting/unioning with the power of SQL
  • raster map algebra for fine-grained raster processing
  • Spatial reprojection SQL callable functions for both vector and raster data
  • Support for importing / exporting ESRI shapefile vector data via both commandline and GUI packaged tools and support for more formats via other 3rd-party Open Source tools
  • Packaged command-line for importing raster data from many standard formats: GeoTiff, NetCDF, PNG, JPG to name a few
  • Rendering and importing vector data support functions for standard textual formats such as KML,GML, GeoJSON,GeoHash and WKT using SQL
  • Rendering raster data in various standard formats GeoTIFF, PNG, JPG, NetCDF, to name a few using SQL
  • Seamless raster/vector SQL callable functions for extrusion of pixel values by geometric region, running stats by region, clipping rasters by a geometry, and vectorizing rasters
  • 3D object support, spatial index, and functions
  • Network Topology support
  • Packaged Tiger Loader / Geocoder/ Reverse Geocoder / utilizing US Census Tiger data

geohash vs PostGIS

参考自

http://www.cnblogs.com/LBSer/p/3629149.html

一个玩具级场景(PostGIS说:我可不是玩具^_^....)的对比

功能 Mysql spatial extension PostGIS
空间索引 仅MyISAM支持R树索引,InnoDB不支持 GIST树索引(R树的变种)
支持的空间类型 仅二维数据 二维、三维以及曲线
空间操作函数 有限的空间函数 基本实现OGC标准定义的空间操作函数
空间投影 不支持 支持多种常用投影坐标系
事务支持 不支持 PostGIS提供了一系列的长事务支持,可以有效支持复杂的空间分析功能
加载速度 MySQL > PostGIS (事务) (作者可能没有进行优化,性能不会更差)。 -
空间索引的创建速度 MySQL < PostGIS (diff split algo)。 -
查询效率 MySQL PostGIS(不同性质查询结果不一样,各有千秋) -
GIS系统使用 使用较少 使用较多,例如openstreetmap的数据库后台就是Postgresql+Postgis

例:想查找蓝色多边形内的点,mysql空间扩展仅能查出在最小外包矩形(红色框)内的点,而postgis能查出任意多边形内的点。

例:想查找两点间距离。MySQL Spatial仅能计算欧式空间距离,而PostGIS能计算不同投影坐标系下的真实空间距离

PostGIS不仅支持geometry,geography也支持geohash

PostGIS虽然不推荐使用geohash,但是它内置了转换函数,可以将geometry转换为geohash

Name

ST_GeoHash — Return a GeoHash representation of the geometry.

Synopsis

text ST_GeoHash(geometry geom, integer maxchars=full_precision_of_point);

Description

Return a GeoHash representation (http://en.wikipedia.org/wiki/Geohash) of the geometry. A GeoHash encodes a point into a text form that is sortable and searchable based on prefixing. A shorter GeoHash is a less precise representation of a point. It can also be thought of as a box, that contains the actual point.

If no maxchars is specified ST_GeoHash returns a GeoHash based on full precision of the input geometry type. Points return a GeoHash with 20 characters of precision (about enough to hold the full double precision of the input). Other types return a GeoHash with a variable amount of precision, based on the size of the feature. Larger features are represented with less precision, smaller features with more precision. The idea is that the box implied by the GeoHash will always contain the input feature.

If maxchars is specified ST_GeoHash returns a GeoHash with at most that many characters so a possibly lower precision representation of the input geometry. For non-points, the starting point of the calculation is the center of the bounding box of the geometry.

Availability: 1.4.0

[Note]

ST_GeoHash will not work with geometries that are not in geographic (lon/lat) coordinates.

This method supports Circular Strings and Curves

Examples

SELECT ST_GeoHash(ST_SetSRID(ST_MakePoint(-126,48),4326));  

	 st_geohash
----------------------
 c0w3hf1s70w3hf1s70w3  

SELECT ST_GeoHash(ST_SetSRID(ST_MakePoint(-126,48),4326),5);  

 st_geohash
------------
 c0w3h

参考

https://en.wikipedia.org/wiki/Geohash

http://postgis.net/docs/ST_GeoHash.html

http://www.cnblogs.com/LBSer/p/3629149.html

http://planet.postgis.net/

时间: 2024-04-18 05:40:29

geohash vs PostGIS的相关文章

无人驾驶背后的技术 - PostGIS点云(pointcloud)应用

标签 PostgreSQL , PostGIS , box , grid , pointcloud , pgpointcloud , point聚合 , KNN , 自动驾驶 , 自动配送 , 无人驾驶 , 机器人配送 , 物流 背景 科幻电影的场景随着技术的发展,正在一步步的从荧幕变成现实.从军用到民用,比如汽车厂商.科技公司在尝试的无人驾驶,无人飞行器. 无人驾驶应用非常广泛,比如快递行业,时机成熟以后,将来可能快递员这个职业也会逐渐从社会上消失(解放快递员的双手和创造力,让更多的人参与到科

无人驾驶背后的技术 - PostGIS点云(pointcloud)应用 - 2

标签 PostgreSQL , PostGIS , box , grid , pointcloud , pgpointcloud , point聚合 , KNN , 自动驾驶 , 自动配送 , 无人驾驶 , 机器人配送 , 物流 , 无用功 背景 无人驾驶.配送机器人的业务背景,方案设计请参考: <无人驾驶背后的技术 - PostGIS点云(pointcloud)应用> 本文针对以上文章,补充一些新鲜内容. 一.transfer table消除索引build.格式检查等无用功 在服务端存储了所

数据库案例集锦 - 开发者的《如来神掌》

背景 「剑魔独孤求败,纵横江湖三十馀载,杀尽仇寇,败尽英雄,天下更无抗手,无可柰何,惟隐居深谷,以雕为友.呜呼,生平求一敌手而不可得,诚寂寥难堪也.」 剑冢中,埋的是剑魔独孤求败毕生几个阶段中用过的几柄剑: 利剑无意:第一柄是青光闪闪的利剑,凌厉刚猛,无坚不摧,弱冠前以之与河朔群雄争锋. 软剑无常:第二柄是紫薇软剑,三十岁前所用,误伤义士不祥,悔恨不已,乃弃之深谷. 重剑无锋:第三柄是玄铁重剑,重剑无锋,大巧不工,四十岁之前恃之横行天下. 木剑无俦:第四柄是已腐朽的木剑. 无剑无招:四十岁后,不

PostgreSQL 助力企业打开时空之门 - 阿里云(RDS、HybridDB) for PostgreSQL最佳实践

标签 PostgreSQL , Greenplum , 时间 , 空间 , 对象 , 多维透视 , 多维分析 背景 时空数据无处不在,未来空间数据的占比会越来越高,在TP与AP场景的需求也会越来越旺盛. 选址.网格运营 空间数据自动聚集分析:时间+多边形圈人:驻留时间分析:舆情分析:... 室内定位 3D坐标:相对坐标系:+以上:运营活动效果分析报表: 科研 太空探索.测绘.气象.地震预测.溯源 无人驾驶 点云:动态路径规划: 空间调度(菜鸟.饿了么.滴滴.高德.快递...) 实时位置更新:多边

音视图(泛内容)网站透视分析 DB设计 - 阿里云(RDS、HybridDB) for PostgreSQL最佳实践

标签 PostgreSQL , 用户透视 , 设备透视 , 圈人 , 标签 , 视频网站 , 优酷 , 土豆 , 喜马拉雅 背景 日常生活中,人们使用最多的除了社交类网站.购物网站,估计就是音频.视频.图文信息类内容网站了. 视频网站,已经渗透到各种终端,除了喜闻乐见的手机,还包括移动终端.电脑.盒子.电视.投影仪等.有设备属性.会员属性.渠道属性等. 内容运营是非常重要的环节,而透视则是运营的重要武器. 业务需求 1.生成设备.会员画像 ID.各个维度的标签.其中包括一些多值列标签(例如最近7

Greenplum 空间(GIS)数据检索 B-Tree &amp; GiST 索引实践 - 阿里云HybridDB for PostgreSQL最佳实践

标签 PostgreSQL , GIS , PostGIS , Greenplum , 空间检索 , GiST , B-Tree , geohash 背景 气象数据.地震数据.室内定位.室外定位.手机.车联网.还有我们最喜欢的"左划不喜欢.右划喜欢",越来越多的位置属性的数据.将来会越来越多. 基于GIS的数据分析.OLTP业务也越来越受到决策者的青睐,例如商场的选址决策,O2O的广告营销等.有很多基于多边形.时间.用户对象属性过滤的需求. 阿里云HybridDB for Postgr

PostgreSQL 实时位置跟踪+轨迹分析系统实践 - 单机顶千亿轨迹/天

标签 PostgreSQL , PostGIS , 动态更新位置 , 轨迹跟踪 , 空间分析 , 时空分析 背景 随着移动设备的普及,越来越多的业务具备了时空属性,例如快递,试试跟踪包裹.快递员位置.例如实体,具备了空间属性. 例如餐饮配送,送货员位置属性.例如车辆,实时位置.等等. 其中两大需求包括: 1.对象位置实时跟踪,例如实时查询某个位点附近.或某个多边形区域内的送货员. 2.对象位置轨迹记录和分析.结合地图,分析轨迹,结合路由算法,预测.生成最佳路径等. DEMO 以快递配送为例,GP

新零售空间数据库实践一例 - PostGIS 点面叠加视觉判断输出

标签 PostgreSQL , 点面视觉输出 , subquery , nestloop join , 空间索引 , gist 背景 在新零售.快递等行业,有大量的点数据(例如包裹位置.快递员位置.仓库位置等),同时有大量的面数据(如小区,商圈,写字楼等). 如何判断实时的正在配送的包裹落在哪个面呢?并且将之联系起来. 这个从视觉角度来思考,非常简单. 例如有一个地图,将其划分为若干个面(例如前面提到的小区). 然后有一些小点,这些是POINT数据. 我们从图上一眼就能看出每个点落在哪个小区(面

PostGIS 2.2.0dev(最新版)手册中文完整版

Hi,all     最近我翻译了PostGIS 2.2dev版本的开发手册    下载地址:http://pan.baidu.com/s/1eS8wyGE    有兴趣的可以下载看看.英文水平比较好的可以直接看英文版.     PostgreSQL和PostGIS都是开源的,所以这份文档也是"开源"的.但我不希望你拿它做商业用途.愿我们一起将PostgreSQL和PostGIS发展的更好!!    涉及到PostGIS的中文书籍目前没有找到,所以本次翻译希望能成为良好的开端,愿大家贡