现代流行的web地图都采用了分块和分层(分级)的方式来组织和加速数据的查询和显示。我们回想传统纸质地图,比例尺是固定的,在有限的纸张范围上,既要表现大的地理范围,又需要显示更详细的地理元素。
一、百度地图和高德地图的具体开发架构
现代流行的web地图都采用了分块和分层(分级)的方式来组织和加速数据的查询和显示。
分级
我们回想传统纸质地图,比例尺是固定的,在有限的纸张范围上,既想表现大的地理范围,又需要显示更详细的地理元素,那只有一个方式,就是增加元素的排列密度,所以一般我们看到纸质地图的字特别小。
而电子地图采用分级的方式解决这个问题
也就是电子地图其实提供了若干个固定的比例尺,比例尺每增加一次,同样的屏幕范围上,能表现的地理范围就变小了,但是能表现的地物元素更细致了。比如在比较小的比例尺下,我们只能看到国家边界,而在较大比例尺下我们能看某个理发店的名称和位置。
经过行业里的长期发展,业内逐渐采用了分级代替了比例尺,一般使用0~18这样得分级数表示。
级数每增加1级,那么比例尺实际是变大2倍。 这个分级数一般用z表示,楼主给出的链接的z参数就是这个。
至于每个z表示何种比例尺,这个涉及到地图的投影方式问题。
现在业内流行的投影方式是谷歌发明的 web墨卡托,具体再百度。
分块
现在第0级是256*256的地图图片,当第1级的时候就是512*512,每一级变为2倍。这样当到18级的时候,整个地图的分辨率是个天文数字,这样任意一台计算机都无法在瞬间完成下载,读取和显示。
实际上把某一级地图 完整下载也是没有意义的,因为我们的屏幕分辨率有限,超出屏幕的范围图片都是浪费。
所以在每一级上都分割为256*256的块,然后对每块都编码。经度方向使用x编码。纬度方向使用y编码。每次我们只看需要下载屏幕范围内的相关图片即可。
为什么这个分辨率是256*256,而不是255*255 或者 是32*32,我个人认为有以下几个原因:
1,在以前的图像显示技术里基本会要求图像的分辨率是2的幂次方,在N年前做windows上显示图片开发的时候基本都要把图像宽度调整2的幂次方才能正常绘制。以及一些老的gpu都要求纹理必须是2的幂次方。所以如果为了兼容老设备和性能上的一点提升,必须采用幂次方的宽度高度
2,最终选用256 ,还主要考虑到网络的数据传输效率,数据太大容易下载失败,数据太小下载效率又过低。而256的图片压缩后一般是10K左右,而这个数据量在各种网络下还是表现比较好的。另外实际单张图片过大,覆盖整个地图窗口之后,浪费的区域更多。所以业内最终使用了256。
地图块的生成
电子地图的生成一般是地理几何数据(点,线,面)按照一定的规则, 配置不同的显示样式,预渲染成图片,可以搜一些制图软件,arcgis等。
现在制图软件基本都提供了cach功能,就是可以根据样式和数据自动切块生成预渲染的地图。当然每种制图软件采用的数据存储方式不同,可以百度到arcgis的cach数据格式。
当然对于百度和高德这样的大公司一般不会采用商业的软件的去预渲染地图,因为这块是地图生成的核心,他们都会有专门的团队去做相关的事情。至于他们预渲染的图片是如何保存在服务器的这个都会不同,不过没什么太难的。中国范围全部缓存成18级图片,总量不到1TB,这个量对于一般的服务器存储没什么问题。
再说如果你要下载地图,那也不需要考虑服务器端如何存储的,只需要根据数据链接去组织
x,y,z。
当然每种地图的x,y,z编码规则会稍有不同。
就我的了解谷歌 和高德是一致的。
腾讯地图的z和上述两种 是一致的,x,y的尺度也是一致的,只是x,y的计数原点不同。上述两种x从左向右计数,0开始。y从上往下计数,0开始。而腾讯可能是经纬度原点往两边去计数,这样可能会存在x和y为负的情况。
百度和其他家各有差异,百度的分级比例尺我记得是不满足乘2的关系的,这个可以具体百度。
矢量地图块
现在我们用的手机地图 和 运行在chrome浏览器的地图 基本都不是栅格图片形式了,而是一块块的矢量数据。
矢量地图的切分方式和栅格形式相似的,不再赘述。
矢量地图的优点是:数据量更小,而且可以在客户端改变地图显示样式,更好的提升用户体验吧。
延伸阅读:
二、实例(instance)是什么
一组Oracle 后台进程/线程以及一个共享内存区,这些内存由同一个计算机上运行的线程/进程所共享。这里可以维护易失的、非持久性内容(有些可以刷新输出到磁盘)。就算没有磁盘存储,数据库实例也能存在。也许实例不能算是世界上最有用的事物,不过你完全可以把它想成是最有用的事物,这有助于对实例和数据库划清界线。