Chap.1万万没想到，上次搭建框架后，我这辈子的名气就埋在地图坑里了time得到一个粗略的demo后，我毫无抵抗地尝试了基本的图形组件。我天真地以为我离真相只有一步之遥。想到自己还有一些模拟的地理数据没有可视化，将数据信息的内容放在名为location的属性下，具体格式如下：{"location":{"lat":12.345,"lon":56.789},"temperature":49.966,"more-props":"value"}一个很自然的想法出现了——用地图来显示相关信息。但！没想到一进地图坑就卡了10天没出坑。（部分原因是圣诞节让我变懒了[写不出来就怪圣诞节哈哈哈哈]，没做作业）。在基于地图的信息可视化方面，PowerBI上的地图工具给我留下了友好易用的良好印象。只要使用直接的经纬度数据对，就可以在地图上定位显示位置。逻辑惯性让我习以为常，天真地认为所有的地图插件都是一样的“简单”。首先，Grafana的标准可视化工具是不包含地图相关工具的，但是官方在插件库中发布了一个基于地图的可视化工具WorldmapPanel，满足我的需求，看起来不错。简单的下载并安装了这个插件之后，我发现事情并没有我想的那么简单。这个工具和我的可视化框架最大的冲突是：WorldmapPanel不支持通过纬度和经度数据对在地图上定位和可视化e.g.（纬度、经度）。它仅支持两种数据格式：国家/州代码或geohash。官方文档中的以下句子很好地解释了这两种数据类型。目前有两种方法可以将数据与地图上的点连接起来。通过将标签或系列名称与国家/地区代码/州代码（例如瑞典的SE，德克萨斯的TX）匹配，或者使用geohashes映射到地理坐标。Tips：擦亮眼睛，认真复习题目（这个狗屎一样的文档）。Grafana和InfluxDB的文档大概是我这辈子见过的逻辑最混乱的文档之一。投诉请参考之前的博客。值此新年之际，想请大家继续欣赏来自Grafana官方WorldMapPanel的文档。说实话，一口气看了三遍，比第一次看的时候还要懵。以表格数据、时序数据、json为数据源，在文档中引入相关配置是非常不明智的。以我的架构为例：首先，使用influxdb得到的数据应该是时序数据吧？毕竟influxdb号称时序数据库，写入数据库时??的时间戳作为表的唯一索引。不过最后使用的配置方式其实是在tabledata下归档的（influxdb：不想丢脸）；其次，标题“时序数据”或许也能直观理解以时间戳为索引的数据（更多的理解其实是错误的），那么如何理解“表数据”呢？“时序数据”不是以表格的形式组织存储的吗？至于“json”，就更含糊了。是json格式的数据吗？还是以json形式传递的数据？那么json格式的数据是不是不能同时是“时序数据”或者“表数据”呢？这三类数据并不相互排斥，可见这种分类方法的不科学性。我个人认为正确的分类方法如文档开头所述，我在本文第一章也引用了这句话：目前有两种方法可以将数据与地图上的点连接起来。通过将标签或系列名称与国家/地区代码/州代码（例如瑞典的SE，德克萨斯的TX）匹配，或者使用geohashes映射到地理坐标。注意：对于代码：可以使用grafana预定义的代码，也可以自定义一些代码，使用json/jsonpimport；对于geohash：主要是为了支持elasticsearch，但是对于influxdb，可以手动添加geohash标签，将数据读取为表格读取geohash标签中的内容；这两种数据源在不同数据库下的配置方法》---如果用这种方法组织文档，一目了然，结构清晰；读者可以根据图片查找，效率会大大提高改进了，至少比现在的文档好。而且整个文档这么重要的一句话放在了一个不起眼的角落。抱歉，我真的无法理解作者的意图。第2章绞尽脑汁和更改关键字后的结果去问google+看文档停不下来，为了解决这个挥之不去的数据匹配问题，经过一番折腾，出现了几种可能的解决方案：1.在原始数据中手动添加一个countrycode字段或者geohash字段；最容易想到的方法。简单粗暴，速度快！但是考虑到这样的方法不能适配所有IoT设备，GPS产生的数据大部分还是经纬度。排除！2.添加插件-在Telegraf中，可以处理经纬度数据并生成geohash；遗憾的是，我没有找到这样一个可以直接使用的插件。然后我想我可以自己开发插件，但是对于我来说，时间和学习成本太大了。高的。（golang小白，不懂geohash算法）。两个字：排除！P.S：有兴趣的朋友可以看看telegraf的文档，欢迎各种形式的插件PR。暗中观察，这样的插件应该属于处理器插件。目前官方只给出了该类别的打印机。基本上没什么用，cmd里打印数据流就行了。急等小伙伴们来填坑！ref:https://github.com/influxdata...3.使用Kapacitor对从数据库流出的数据进行分析处理，然后发送到可视化终端；Kapacitor是influxdata的四大开源核心产品之一（TICKstack，K--Kapacitor），可以对数据进行相应的分析和处理，比如使用机器学习模型来处理和分析数据。具体其他功能不是特别清楚，也没有仔细研究过。有兴趣的学生会搬到这里。排除的原因和2类似，没有可用的脚本，开发成本太高。4、使用node-influx、node-geohash等开源插件，后端语言（如node.js）处理，直接在数据库中添加geohash标签并写入值；这似乎是一个物美价廉的不错的解决方案。但是，由于本文讨论的是实时物联网数据的可视化，每分钟都可能有大量数据写入数据库。如果在数据存储后对数据进行操作，则必须频繁调用数据库I/O进行读写操作，将存储的数据记录一条条处理写回，增加了数据库的负担。因此排除。ref:https://community.influxdata....5.使用Node-Red管理数据流，使用现有的集成块调用接口计算geohash后再入库，减轻数据库负担.Node-RED是一个开源的物联网设备数据流编辑器，主要用于物联网数据流的可视化，管理和连接数据流。它依赖于一个活跃的node.js社区，拥有大量可用资源和强大的社区支持。不仅可以将数据从源头以流程图的形式有效表达所经历的各种技术栈，而且可以对数据流进行简单的管理，支持javascript对数据流进行处理，非常友好前端工程师。吸引我使用Red-Node的一个最重要的原因是Node-RED中有一个名为node-red-node-geohash的节点模块。在Node-RED项目中使用npm简单安装后，数据可以将中的经纬度数据对直接编码成geohash码，反之亦然。这让我不用投入大量的时间和开发成本从geohash转码为经纬度；其次，Node-RED具有强大的数据流管理和编辑功能，允许在流中插入自定义javascript函数代码；这大大提高了数据流设计的灵活性，所以我也可以充分利用这种灵活性，将我的经纬度数据转成geohash再存入数据库，从而避免了方法4的浪费和重复数据库资源;最后，Node-RED可视化的编辑界面能够以简单直接的方式有效表达数据流向，这是选择使用该工具的加分项。权衡性价比后，我们决定采用最后一个方案。Chap.3解决方案的详细步骤注：整个解决方案的详细步骤参考本博客内容（https://primalcortex.wordpres...）1.配置Node-REDtips：使用Node-RED的前提条件是确保node.js已经安装安装；已经安装了node.js的朋友可以跳过这个party！如果你是和我一样使用windows系统的朋友，推荐一个叫chocolately的插件。从此，Windows也有了软件包管理工具。从命令行安装包不是梦！打开windowscmd并使用chocolately安装node.js：chocoinstallnodejs-lts安装Node-RED：C:\WINDOWS\system32>npminstall-g--unsafe-permnode-red安装关键的geohash节点：用户应用程序路径\npm\node_modules\node-red>npminstallnode-red-node-geohash运行Node-RED:Userapppath\npm\node_modules\node-red>node-redcmd提示成功信息用浏览器打开高亮地址，进入node-red的用户界面---新世界的大门打开，咚！2.在Node-RED上创建数据流。Node-RED的数据流编辑器采用模块拖拽的形式，易于用户理解和使用，因此上手并不难，学习曲线平缓。根据我的案例，在Node-RED上搭建的数据流是这样的在我机器上的MQTTbroker上订阅了我的模拟器发来的特定主题的数据后，使用geohashnode模块处理经纬度数据并生成geohash，然后使用MQTTbroker再次发布新的topic来传输处理后的数据。这时候只要数据库订阅这个新topic，就可以使用telegraf成功将数据入库。在这个流向中，除了必要的mqtt和geohash节点外，我还使用了两个函数节点来自定义代码。它们分别用于处理流入geohash节点之前的数据，以及流入geohash节点之后的数据。根据官方文档中的描述，geohash节点会直接读取msg.payload中的lat和lon属性。如果指定了精度，即存在msg.payload.precision，那么会一起处理生成唯一的geohash码。具体描述如下：一个将lat,lon与geohash进行编码的函数。如果msg.payload是一个具有lat或latitude和lon或longitude属性的对象-它会向payload添加一个geohash属性。精度可以通过msg.payload.precision设置为1到9。注意：如果msg包含.location属性，它将优先于.payload对其进行操作。在第一章中，我提到我的地理数据被包装在位置属性中，即msg.payload.location。所以geohash不能直接获取经纬度信息。此时借助location-preprocessor功能节点提取location中的信息。注意引用文档描述中的最后一句，如果msg中包含location属性，则直接处理location属性中的lat和lon属性，忽略payload中的信息。这样我们就可以将msg.payload.location中的信息直接放到msg.location中让它去计算geohash。location-preprocessor的代码：//这段代码的主要目的是从msg.payload中提取位置信息，然后将其放入msg.location中，得到计算出的geohash。varmessage=JSON.parse(msg.payload);if(message[0].location!==null){msg.location={"lat":message[0].location.lat.toString(),"lon":message[0].location.lon.toString(),"precision":"8"};//msg.location=message;}returnmsg;得到有效的geohash码后，将msg.location.geohash的值复制到msg.payload中，此时数据就有了geohash码。然后新建一个mqtttopic，通过mqttbroker发布处理后的数据即可，Node-RED的配置到此结束。location-afterprocessor的代码：//此代码段的主要目的是将geohash属性放入msg.payload中，然后由mqtt-broker通过特定的topicif(msg.location.geohash!==null){varmessage=JSON.parse(msg.payload);message[0].geohash=msg.location.geohash;msg.payload=JSON.stringify(消息);msg.topic="sensors/wrap_geohash";}返回消息;3。检查数据库中的数据格式是否正确【注意】使用telegraf接受数据前，必须将geohash项设置为标签，才能被Worldpanel识别和使用。同时，如果你使用mqtt的新主题，记得把配置文件中的相关项修改到这里，运行telegraf和influxdb，数据应该被telegraf安全地处理并存储在数据库中。这时候对数据库进行一个简单的操作，检查数据是否按预期写入了指定的数据库。现在我们已经确保数据库中有可用数据，让我们开始设置WorldmapPanel工具吧！喜悦伴随着绝望。又开始研究文档了T.T.环顾四周，文章中关于配置的最重要的段落在这里：一个表数据的例子将使用InfluxDB，然后将度量查询返回的数据格式化为表。类似于上面的Elasticsearch查询，需要3个字段（2个字段它们是强制性的）字段名为metricgeohash标签名为geohashan可选位置名称（在鼠标悬停时显示）。这个位置名称也必须在世界地图设置选项卡中指定。这段话我简单翻译一下意思：老子WorldmapPanel只认两个兄弟，一个叫metric，一个叫geohash！地名人可以考虑，但可有可无。把剩下的都让开！Geohash是个暴徒。WorldmapPanel告诉它想去哪里就去哪里，并且应该给它那个地理位置；公制是大师。基于geohash的定位，每个点显示的值取决于提供的metric。但像石爷这样的人，聪明绝顶，行走江湖，很容易被人暗算，所以公制就是一个别名。真名是什么主要看数据库给的值。简而言之，他在世界地图上被称为公制。这样我们就可以设置数据集按照geohash定位，每个geohash点显示的值由metric决定。例如，从我的需求出发，我需要在地图上显示我的每个设备的位置，并让用户看到每个设备的当前工作温度，所以我应该这样设置我的查询。同时在worldmap栏设置地图数据选项：location数据必须选择table，一般table字段名设置为geohash；5.Demo在这里应该可以看到漂亮的demo！世界地图面板终于来了！Chapter.4面带微笑听着发自内心的新年总结，心里真是mmp！朋友们，填坑不易，填坑珍惜！不知道还能填多久，路漫漫其修远兮！最后，要不要祝小伙伴们元旦快乐呢？虽然我知道最后看到的基本都是真爱，而且和这个现实世界一样，真爱的概率基本为0。
