迈向将矢量数据编码为图像的协议

这是此问题的后续解决方案：创建具有渲染性能（如GISCloud）的矢量多边形吗？

Yagi在回答中概述了将地理信息编码为图像格式并在浏览器中对其进行解码的原理。他观察到“当前，要做到这一点，您必须自己动手”。他还指出，目前尚无此标准。

鉴于所展示的出色表现，社区似乎可以从标准中受益。根据我对问题的理解，这听起来像是可以实施的标准处理方式。称之为B-WFS。

那么我的问题是：将矢量数据编码为图像的有用协议是什么样的？是否有某种东西使它变得太复杂而无法有效地解决，还是仅仅是“还没有人这样做”的情况？

web-mapping vector

— 卡尼斯鲁弗斯
source

我为自己的无知感到抱歉，也许我没有明白这一点，但是，一个带彩色桌子的土工无法完成这项工作？

— 巴勃罗（Pablo）

抱歉，我也很无知；）我不确定颜色表是什么，但我不这么认为。目的不是传递带有相应元数据的图像。如您所述，这是一个已解决的问题。目标是以比人类可读的UTF-8更紧凑的格式传递带有元数据的矢量数据。鉴于JavaScript没有足够的能力来处理二进制数据，因此解决的方法是将数据编码为二进制图像，然后使用HTML 5 Canvas对其进行解码以对图像进行解码，然后将其转换为矢量对象。

— canisrufus

@Pablo假定网络I / O（而不是解析）是处理Web上矢量的瓶颈，因此拥有一种确定的方法来处理二进制编码矢量，应该可以更轻松地编写性能更好的Web地图。

— canisrufus 2011年

有趣的是，现在我明白了...我现在开始使用网络地图，并且仍在学习基础知识。顺便说一句，颜色表或颜色图是将栅格像元值与类联系起来的表。

— 巴勃罗（Pablo）

@monkut是的，这是不同的。:)光栅化一组矢量只是对其进行渲染。瞧光栅！我在这个问题上谈论的是不同的。您应该在我所链接的问题中阅读拉吉的答案；那应该开始解释我的意思了。如果您仍然不清楚，我将花一些时间提出一个真实的答案。

— canisrufus 2012年

Answers:

事实证明，这是不必要的解决方法。XHR2是javascript升级的一部分，将允许在不强制执行任何操作的情况下导入和解析二进制数据。

— 卡尼斯鲁弗斯
source

它不需要像这样单独的标准，因为WFS实施规范 04-094的第9.4节说：

其他输出格式（包括旧版本的GML，非XML，二进制和特定于供应商的格式）也是可能的，只要在功能文档中公布了outputFormat属性的适当值即可（第13节）。本规范建议在功能文档中为此处列出的每种输出格式包括一个描述性叙述[sic]。

添加二进制支持的最简单方法是仅对JSON流进行GZIP，大多数浏览器会在其中自动处理解压缩。就是说，我还没有尝试过，但是假设服务器和客户端都已经支持未压缩的JSON，那么在服务器和客户端这两个方面的工作量就最少。

— 默西·维京
source

+1表示标准。压缩不是同一意义上的二进制编码。有关这两种方法之间的性能影响的问题（压缩的geojson与图像中编码的几何形状）肯定值得探讨。

— canisrufus 2011年

没错，这可以减少网络瓶颈，但会给客户端和服务器带来更大的负载。但是，由于矢量数据的长度可变，因此在IMO中将图像编码为矢量数据是次优的方法。它还模糊了矢量数据的性质。更好的方法可能是具有两个并行数据流，一个用于矢量，一个用于栅格，可以由不同的服务器和存储设备处理，然后由客户端合并。

— MerseyViking

向量数据长度可变的问题可以用与网络处理发送数据包基本相同的方式处理。我同意它是次优的，但是我们似乎因为JS对二进制的处理不好而陷入困境。有空的时候，我将自己编写和实现一些东西。我可以在工作时将它放到这里...

— canisrufus 2011年

我真的认为Ragi在他的回答中清楚地定义了它。我同意我没有。:)可能二进制格式可能是整体上更快的数据传输格式的假设是错误的。差异可以忽略不计。我确实说过“性能影响……值得探讨”。显然，我不能只定义二进制格式然后声明胜利。我们拭目以待！

— canisrufus 2011年

@MerseyViking不必再次重复我的回答，而让我从CPU周期的角度出发（因为您的假设是过早的优化）。访问L1缓存= 1个CPU周期，L2 = 14个周期，RAM〜250个周期，磁盘= 41,000,000，网络（取决于带宽，因此请允许）= 240,000,000。无论是基于磁盘还是基于网络（在我们的案例中），I / O的速度都要慢几个数量级。如何将负载从频谱的最后部分转移到任何规模的第一个“过早”部分？

— Ragi Yaser Burhum 2011年