在绘图方面,Python 比 NodeJS 好用,首先 Python 绘图库多,而且 API 强大而完善。 NodeJS 还是少点,一些库还没测就放弃了,需要 window 支持,而我需要在后端执行。

最近一直在搞地面雷达的可视化工作。在研究如何将基数据可视化过程中,着实汲取了相当多的知识和技能。

传统的雷达数据可视化采用图片方式,同一时刻,雷达基数据会产生多种单站产品和组合产品,针对不同数据产品生成不同的图像。这样会产生大量的图像数据和基数据,对数据容量是个考验不说,图像本身也非矢量,渲染效果总不是那么好。

所以最开始想用 GIS 的方式将数据直接渲染,理想中使用 Mapbox 是美丽的,省去了图像数据,使用 Geojson Layer 在缩放过程中,都能清晰得看影像。但最终效果不然,明显的一点是会存在空隙,即使将 Circle 放大尺寸,也达不到理想的效果。

最终除了风速风向数据(数据量小,而且不需要填充),其余的还是采用了传统的图片渲染方式。在接下去的过程中,我开始同时使用 NodeJS 和 Python 来实现。说真的,我越来越喜欢 NodeJS,他无所不能,从前端到后端,无孔不入。我已经开始慢慢从 Python 迁移到 NodeJS。在这个工作上,他的异步方式让读取文件,简单快速,比 Python 好用多了。让我在用 Python 实现的同时,也想用 NodeJS 写一遍,如果可行的话,直接在后期将项目迁移到 NodeJS。

扯远了,回到主题。大部分数据产品的生成方式是一样的,总共会出现两种情况。

第一种是分辨率为 620*490 格点数据,每个格点的值对应一种颜色。这种情况比较简单,只需要创建一个宽高为 620x490 的图像,然后修改对应格点坐标的颜色即可。

  • Python PIL 处理时间 1s,其中读文件数据 80 ms
  • NodeJS pngjs 处理时间从读取到绘图 35ms

可谓差距明显。

第二种是扫描一圈的数据,半径等分 920 个圈,每圈再等分 372 个点数据,需要填充成圆弧的值对应一种颜色,这个是最效率最低的,因为每个圈等分后需要填充,涉及到圆弧的计算。

比较完美的做法就是使用 drawArc 方法,这样能画出一个完整漂亮的圆,计算 372×920 个圆弧,但是 Python PIL 库的 arc 方法不支持浮点型的弧度值,从而不得不使用其他方法。对 Python 来说,绘图的库无非就是 Matplotlib 和 PIL 这俩,Matplotlib 使用了一下算是翻车了,等得我直接 ctrl c 了。

NodeJS 的画图库很少,pngjs 无法绘图。用了一个基于 graphicsmagick 的库——gm,graphicsmagick 是一个强大的图像处理程序,使用 C 写的,有各种流行语言的 SDK。结果,翻车了,得花 10 几分钟才能处理完。顺便我用了 Python 的 SDK,也挺慢,大概 10 秒,而且绘图的时候,是完全并发的。本来以为相对慢是 Python 语言的性能导致的,然后用 C++ 的 SDK 写了一下,运行也得花 7 秒,看了下 Python 的源码,貌似 graphicsmagick 只映射了方法,最终还是调用了 C 的 graphicsmagick。

放弃了 drawArc 方法,那只能采用 drawPolygon 方法了,计算出圆环扇形四个点的坐标画一个梯形,显然最终的圆不是完整的圆,是一个 372 边形,不过由于等分得很细,肉眼没有那么清晰的分辨,几乎等同于圆了。主要是省去了很多计算的时间。

graphicsmagick Python 画 Polygon 性能还是得不到明显的提升,而 node 的 gm 继续翻车。用回了 PIL,他的 drawPolygon 方法支持浮点数据,处理完花了 1.3 秒,可谓很快了,而且是单核的,多进程下可以同时处理。NodeJS 使用了 svg.js 库,但是处理过程中因为 svg 数据一直在添加 polygon 导致内存飙升了 2-3G,从 svg 转换 png 也花了相同的时间,最终花了 5.8 秒。我想这算是用 NodeJS 处理最快的一次了。

在绘图工作的过程中,尝试了各种手段,从简单理解图像的原理到理解了绘图的原理,获益匪浅。目前来看,对于我的需求,NodeJS 还未能满足,但是 NodeJS 并不是做不到,而是没有好的工具。