创建具有GISCloud等渲染性能的矢量多边形？

{"width":256,"height":256,"tile":
{"pixels":
[0,6461,-1,0,5,148,0,509,-1,10715,-1,1,-1,251,-1,1,-1,1,-1,251,-2,3,-1,255,-1,249,-2,5,-2,247,-1,509,-3,251,-1,2,-2,253,-2,252,-2,254,-1,255,-1,254,-1,255,-1,1276,-2,13,-1,233,-1,2,-1,253,-1,1,-1,255,-1,247,-1,1306,-1,1533,-1,1269,-1,1276,-1,2303,-1]},

"styles":
[{"f":"rgb(99,230,101)","s":"rgb(5,148,0)","lw":"0"}],

"geom":
[
{"s":0,"p":[4,143,5,144,3,146,1,146,2,143,4,143],"c":"layer1156_5098"},
{"s":0,"p":[-2,143,0,140,2,141,2,144,1,146,-2,144,-2,143],"c":"layer1156_5067"},
{"s":0,"p":[7,143,5,144,4,143,2,143,2,141,5,138,6,139,5,141,7,143],"c":"layer1156_5051"},
{"s":0,"p":[10,141,11,137,12,137,14,137,12,142,9,143,9,142,10,141],"c":"layer1156_5041"},
{"s":0,"p":[1,136,0,140,-2,143,-2,136,1,136],"c":"layer1156_5038"},
{"s":0,"p":[8,143,5,141,5,137,8,136,10,137,10,141,8,143],"c":"layer1156_5033"},
{"s":0,"p":[5,137,2,141,0,140,1,136,1,136,2,135,3,136,5,137],"c":"layer1156_5028"},
{"s":0,"p":[10,134,12,136,11,138,8,135,10,134],"c":"layer1156_5020"},
{"s":0,"p":[-2,133,0,136,-2,136,-2,133],"c":"layer1156_5005"},
{...}
...
]
}

#1 楼

我已经看到了过去使用的这种技术。 Zain Memon（来自Trulia）向我解释了这一点，他在Michal Migurski创建TileStache时提供了一些帮助。 Zain在一次较早的SF GeoMeetup会议中解释了使用此技术的Trulia演示时，仔细研究了它。实际上，如果您下周在SF（这是我la脚的尝试，他会尝试解决，请随时露面：）

确定，现在开始解释。

首先，当您查看上面的json文件时，您看上去在错误的位置。

让我解释一下（为什么可以），为什么。

这些瓦片正像常规渲染的瓦片一样通过，在那里没什么大不了的，我们知道该怎么做，所以我不需要解释。

如果您在Firebug，您会看到还得到了一堆看起来像是空白的图像，就像这样。

为什么空白？它不是。像素包含数据-只是不包含传统的可见图像数据。他们正在使用一种非常聪明的技术来传递像素本身编码的数据。

过去十年来，人们一直在以牺牲格式的可读性和可移植性数据为代价来取舍存储效率。

以xml示例数据的示例为例：

<data>

  <feature>
    <point>
      <x> -32.1231 </x>
      <y> 10.31243 </y>
    </point>
    <type> 
      sold
    </type>
   </feature>

  <feature>
    <point>
      <x> -33.1231 </x>
      <y> 11.31243 </y>
    </point>
    <type> 
      available
    </type>
   </feature>

</data>

好，要传输多少位？前提是我们是utf8（处理此内容时每个字符1个字节）。好吧，我们大约有176个字符（不包括制表符或空格），这使这176个字节（出于各种原因，我对此很乐观，为简单起见，我将省略它）。请注意，这是2分！

仍然，一些不懂他在说什么的聪明驴子，在某处会声称“ json给您更高的压缩率”。

好吧，让我们将与json相同的xml废话放进去：

{ "data": [
            "feature" : { "x" : -32.1231, "y" : 10.31243 , "type": "sold" },
            "feature" : { "x" : -33.1231, "y" :11.31243, "type": "avail" },
          ]
}

这里有多少字节？说约115个字符。我什至作弊了一点，然后变小了。

说我的区域覆盖256x256像素，并且我处于较高的缩放级别，以至于每个要素渲染为一个像素，而且我拥有如此多的要素，它已经满了。我需要多少数据才能显示65,536个功能？

每个“功能”条目的54个字符（或utf字节-我什至忽略了其他东西）乘以x 65,536 = 3,538,944或大约3.3MB

我想您已经明白了。

但这就是我们在面向服务的体系结构中传输数据的方式。可读的肿废话。

如果我想以自己发明的二进制方案传输所有内容，该怎么办？说相反，我将该信息编码为单波段图像（即黑白图像）。我决定0表示已售出，1表示可用，2表示我不知道。哎呀，在1个字节中，我有256个可以使用的选项-在此示例中，我仅使用其中的2个或3个。

那的存储成本是多少？ 256x256x 1（仅一个频段）。 65,536字节或0.06MB。而且这甚至都没有考虑到我从数十年的图像压缩研究中免费获得的其他压缩技术。

此时，您应该问自己，为什么人们不仅仅发送数据编码为二进制格式，而不是序列化为json？嗯，首先，事实证明，JavaScript在传输二进制数据上花了很多时间，因此这就是为什么人们从历史上就没有这样做过。

当HTML5的新功能出现时，一些人已经使用了很棒的解决方法出来了，特别是帆布。那么，这是什么很棒的解决方法？事实证明，您可以通过编码在看起来像图像上的电线来发送数据，然后可以将该图像推送到HTML5 Canvas中，从而可以直接操作像素！现在，您可以获取数据，在客户端将其解码并在客户端中生成json对象。

停下来思考一下。

您有一种方法可以以高度压缩的格式编码大量有意义的地理参考数据，其大小比Web应用程序中传统上做的其他任何事情都要小，并在javascript中对其进行操作。

甚至不需要使用HTML canvas进行绘制，它仅用作二进制解码机制！

这就是全部您在Firebug中看到的那些图像是关于的。一个图像，其中包含为下载的每个单个图块编码的数据。它们非常小，但它们具有有意义的数据。

那么如何在服务器端对它们进行编码？好吧，您确实需要在服务器端对数据进行概括，并为每个已编码数据的缩放级别创建一个有意义的图块。当前，要执行此操作，您必须自己动手-不存在现成的开源解决方案，但是您拥有执行此操作所需的所有工具。 PostGIS将通过GEOS进行归纳，TileCache可用于缓存并帮助您触发图块的生成。在客户端，您将需要使用HTML5 Canvas传递特殊的“假图块”，然后您可以使用OpenLayers创建真正的客户端javascript对象，这些对象代表具有鼠标悬停效果的矢量。

如果需要编码更多数据，请记住，您始终可以为每个像素生成RGBA图像（这样可以为每个像素提供4个字节，或者每个像素可以代表4,294,967,296个数字）。我可以想到几种使用方法：)

更新：回答以下QGIS问题。

与大多数其他桌面GIS一样，QGIS没有固定的缩放级别集。它们具有任意缩放比例和仅渲染的灵活性。他们可以显示来自WMS或基于图块的来源的数据吗？当然可以，但是在大多数情况下，它们确实是愚蠢的：缩放到不同程度，计算边界框，计算所需的平铺，抓取并显示它们。在大多数情况下，他们会忽略其他事情，例如将使之成为标头的HTTP标头缓存，因此他们不必进行重新提取。有时，他们实现了一种简单的缓存机制（存储磁贴，如果您要的话，请检查磁贴，而不要使用它）。但这还不够。

使用这种技术，需要在每个缩放级别重新提取图块和矢量。为什么？因为矢量已被通用化以适应缩放级别。

就将图块放到HTML5画布上以便您可以访问缓冲区的整个技巧而言，整个过程不是必需的。 QGIS允许您使用Python和C ++编写代码，这两种语言都对处理二进制缓冲区提供了出色的支持，因此，此解决方案对于此平台而言确实无关紧要。

* UPDATE 2 **：

首先存在一个关于如何创建通用矢量图块的问题（在将结果序列化为图像之前，请先进行第1步）。也许我还不够澄清。 Tilestache将允许您在每个缩放级别上为数据创建有效的“矢量图块”（它甚至具有一个选项，允许您在通过图块边界时剪切或不剪切数据）。这需要将向量分成各种缩放级别的图块。我会选择“不剪辑”选项（但是它将选择覆盖更多区域的任意图块）。然后，您可以通过GEOS一般化选项为每个向量提供大量的数字，实际上，您希望它足够大，以使折线和多边形折叠到其自身上，因为如果这样做，则可以将它们从缩放级别中移除，因为在该阶段它们是不相关的。 Tilestache甚至允许您编写简单的pythonic数据提供程序，您可以在其中放置此逻辑。在那个阶段，您可以选择将它们作为json文件（就像它们对某些非洲地图样本所做的那样）或作为序列化的几何图形服务到png中，就像它们在我上面给出的其他样本（或Trulia样本）中一样。 br />

#2 楼

直接由开发人员Dino Ravnic在最近的邮件列表中发布的：


我们如何做到这不是一个秘密，所以我很乐意与您分享。关键在于两件事：


从图块中删除所有较小的可见矢量
，即，以像素为单位计算的面积小于1px。因此，我们
删除了这样的向量，而不是放置一个像素，因此在我们的json磁贴中有
“ pixels”属性
可以实际看到的向量得到了一般化，
然后将其坐标以像素为单位写入图块

在客户端，我们在画布上渲染这些静态像素和可见的
向量。在向量之上，我们实现了鼠标事件处理以实现悬停（即交互）。就是这样。

我们的后端地图引擎完成了所有繁重的工作，因为我们不使用任何预缓存，并且所有瓦片都在实时生成。拥有可以快速刷新的地图对我们来说非常重要。


因此，听起来客户端很容易。令人印象深刻的是，无需任何缓存即可呈现数据。

他还提到了您可能感兴趣的托管服务。您可能要权衡尝试重新创建它的成本和使用现成服务的成本。

#3 楼

正如我在OSGeo列表中所述，关键是将数据作为矢量JSON切片传递，这些切片具有用于子像素几何的像素和用于那些在特定级别上实际可见的特征的广义几何。性能非常好，因为该技术消除了所有不必要的矢量信息，只保留了那些实际上会对地图产生视觉影响的矢量。像素在那里填补空白并被放置，而不是放置那些子像素向量。关于图块格式就是这样。

后端是真正的重物。我们没有使用TileStache或任何其他地图引擎，因为我们编写了自己的引擎，可以进行许多优化，以实时生成此类矢量图形。

首先，我们开始将地图图块作为SWF交付。最近，我们仅启用了对JSON的输出，因此我们可以使用HTML5 Canvas渲染图形。您可以找到一个基准，将这种矢量技术与栅格技术（mapnik）进行比较。为了公平比较，请仅在CGI模式下查找结果。

http://www.giscloud.com/blog/realtime-map-tile-rendering-benchmark-rasters-vs-vectors/

我们正计划提供这项技术，作为地图图块托管服务。想法是将您的地理数据托管在云上，并通过HTML5将其高速传输到任何地图客户端中，而无需预先缓存图块。如果您有兴趣加入此Beta，请随时与我们联系：http://www.giscloud.com/contact/

#4 楼

看起来最近在OSGeo开放层论坛上提出了一个非常相似的问题，GIS云开发人员描述了他们的方法，这是GeoJSON几何形状和静态像素的有趣组合。实际上，它们实际上是在动态生成所有矢量图块，而不是使用预先构建的GeoJSON文件缓存。

Esri使用ArcGIS Server和要素图层实现了类似的方法，可以在飞行并将其作为JSON通过网络发送。

对于现在可以实际实现的简单方法，您可以使用Tilestache（支持PostGIS）构建矢量图块，然后将其使用在Polymap中。 Polymaps使用SVG，但是性能非常好，并且CSS规则可以对地图元素进行样式设置，因此要素渲染完全取决于您。这是一篇博客文章，其内容与您的要求类似。

#5 楼

我在使用Canvas的OpenLayers上玩了游戏，并获得了合理的结果。

如其他答案中所述：实时传递和显示矢量-需要针对每个缩放级别和每个数据集将其通用化。另外，您可以使用Google折线编码来大幅缩减尺寸。

我使用了一种简单的投放机制。每个几何都是JavaScript HTTP响应中的JavaScript函数。

，它不像基于图块的矢量交付那样先进，而是简单且开源！我没有尝试使用Canvas尝试使用Google Maps v3，但是看到了《纽约时报》的几个演示给人留下了深刻的印象。 br />

#6 楼

我不确定该公司使用哪种解决方案（您可能会直接问他们），但我有个主意。

提高矢量数据网络传输和渲染速度的关键解决方案是根据缩放级别对其进行归纳：在高缩放级别下传输和渲染成千上万个为低缩放级别设计的对象通常非常耗时（并且也无用，因为最终的显示效果通常不清晰-例如，参见此图） 。为此，您的postgis服务器数据库必须是多尺度的：对于每个缩放级别，应该有一个适合该缩放级别的对象表示。可以使用归纳技术自动计算这些不同的表示形式。此外，服务器发送给客户端的矢量数据不仅应取决于空间范围，还应取决于缩放级别：服务器根据缩放级别发送合适的数据。这就是这篇优秀论文所捍卫的方法：-)

#7 楼

由Stanford Visualization Group开发的有趣的论文，演示和软件源代码，每个数据块都使用datacube，以便可视化和探索大型地理数据集。
它只能用于点数据集，但可以是一种有趣的方式。

http://vis.stanford.edu/papers/immens

Vizzuality的CartoDB平台和名为Torque的库也在尝试如何绘制大量数据。

http://cartodb.github.io/torque/https://github.com/CartoDB/torque/tree/new_torque