How it works(14) GDAL2Tiles源码阅读
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了How it works(14) GDAL2Tiles源码阅读相关的知识,希望对你有一定的参考价值。
参考技术A gdal2tiles(以下简称g2t),这个历史悠久的切图脚本依然能发挥其功用,因为它稳定的做好了它应做的东西.相比前面说过的gdal2mbtiles(以下简称g2m),我倒是更喜欢它,单文件脚本,运行只安装一个GDAL库足矣.同样因为有了g2m,我也是带着对比的心态提出几个问题:原始的g2t脚本近3000行,包含了详细的注释和一些其他的功能,分析起来会产生干扰,因此我精简掉全部注释和我所用不上的功能,保留了核心功能,方便分析和使用.
相比原来精简掉的内容:
相比原来修改的内容:
以下是修改后的脚本,不到500行,下面就基于这个修改后的核心脚本进行分析
g2t的流程没有分支,非常清晰:
生成任务列表的功能被完全封装在 TileJobsMaker 这个类中,观察TileJobsMaker的调用可以发现其实际运行流程如下
当然可以尽可能的将有用的信息写入元数据中.
这里最重要的部分就是坐偏移量的计算,生成的几组变量在后面切图的时候都会用到:
特殊情况:在所有tif的边缘处,都会出现瓦片冗余,这些地方需要单独处理:
单进程调用:
多进程调用:
切瓦片的时候充分利用核心资源无异是非常合算的.在没有阅读之前,我构思的多线程是固定若干个处理进程,然后给每个进程单独分配任务.g2t的实现方式更加简单,实现也清晰.因为不断有进程创建/结束,我无法确定创建/结束进程的会耽误多长时间,不过实际来看应该影响不大.
切下层瓦片时并没有采用多进程模式,我猜可能是已经够快了,事实也确实如此.或许如果也采用多进程模式,整体运行还会更快?应在在瓦片数量比较多的情况下才有所体现吧.
只用GDAL使得g2t部署简单,但也限制了其性能.如果把读取tif和生成png都替换成类似g2m的vips,或许能获得和g2m一样的效率.
以上是关于How it works(14) GDAL2Tiles源码阅读的主要内容,如果未能解决你的问题,请参考以下文章
What is Web Application Architecture? How It Works, Trends, Best Practices and More
How Node.js Multiprocess Load Balancing Works