在绘图方面，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 并不是做不到，而是没有好的工具。