Topojson：量化VS简化 [英] Topojson: quantization VS simplification
问题描述
quantization 和简化之间有什么区别？
是量化另一种简化的方式吗？
在某些情况下使用量化更好吗？
或者我应该使用两者的组合？
几何的总大小由两个因素：点数和每个坐标的数字位数（精确度）
。具有1,000,000点的大几何形状，其中每个二维点表示为±180°的经度和±90°的纬度：
[ - 90.07231180399987,29.501753271000098]，[ - 90.06635619599979,29.499494248000133]，...
任意精度（在JSON中;在JavaScript中，它们受到 IEEE 754 的精度的限制），因此无限数量的数字。但在实践中，上面是很典型的，所以说每个坐标有18位数。包括额外的符号（ [，] 和，每个点最多需要1 + 18 + 1 + 18 + 1 = 39个字节进行JSON编码，整个几何约为39 * 1,000,000≈39MB。
假设我们将这些实数转换为整数：经度和纬度都减少为整数 x 和 y ，其中0≤ x < y ≤99。实数点⟨λ，φ⟩和整数坐标⟨x，y A之间的简单映射是：
x = floor（（λ+ 180）/ 360 * 100）;
y = floor（（φ+ 90）/ 180 * 100）;
由于每个坐标现在最多需要2位数进行编码，每个点最多占用1 + 2 + 1 + 2 + 1 = 7字节以JSON编码，整个几何约为7MB;我们将总大小减少了82％。
当然，没有什么是免费的：如果删除太多信息，您将无法再准确显示几何。经验法则是，网格的大小至少是整个地图最大预期显示大小的两倍。例如，如果您在960×500像素的空间中显示世界地图，则默认的10,000×10,000（ -q 1e4 ）是一个合理的选择。 p>
因此，通过降低每个坐标的精度来量化信息，有效地将每个点都捕捉到常规网格。这减少了生成的TopoJSON文件的大小，因为每个坐标表示为具有较少数字的整数（例如在0和9,999之间）。
简化通过删除点来移除信息，应用试图测量每个点的视觉显着性并去除最不显着的点的试探法。有许多不同的简化方法，但TopoJSON参考实现中使用的Visvalingam方法在我的 Line Simplification文章中有所描述所以我不会在这里重复。
虽然量化和简化大多数是独立地处理这两种不同类型的信息，但还有一个复杂因素： 拓扑构建，而简化必须在之后应用于保留拓扑。由于量化频繁地引入重合点（ [24,62]，[24,62]，[24,62] ... ），并且去除重合点，
在构建拓扑之前应用量化的原因是几何输入通常不是拓扑有效的。例如，如果你获取内华达州的shapefile，并将其与Nevada状态边框的shapefile结合，则一个shapefile中的坐标可能与另一个shapefile中的坐标不完全匹配。通过在构建拓扑之前量化坐标，您可以将坐标捕捉到常规网格，并且可以获得更少的弧线的更清晰的拓扑，有希望正确识别所有共享弧线。 （当然，如果你过量化，那么你可能导致太多的重合点，并得到自相交的弧，这会导致其他问题。）
，也许1.5.0，TopoJSON将允许您在独立于输出TopoJSON文件的量化构建拓扑之前控制量化。因此，您可以使用更细的网格（或根本没有网格）来计算拓扑，然后进行简化，然后使用适合低分辨率屏幕显示的粗糙网格。现在，这些是捆绑在一起的，所以我建议使用一个更细的网格（例如， -q 1e6 ）产生一个干净的拓扑，牺牲一个稍大的文件。由于TopoJSON也使用增量编码坐标，你很少支付所有数字的全部价格！
What is the difference between quantization and simplification?
Is quantization another way of doing simplification?
Is it better to use quantization in certain situations?
Or should i be using a combination of both?
The total size of your geometry is controlled by two factors: the number of points and the number of digits (the precision) of each coordinate.
Say you have a large geometry with 1,000,000 points, where each two-dimensional point is represented as longitude in ±180° and latitude in ±90°:
[-90.07231180399987,29.501753271000098],[-90.06635619599979,29.499494248000133],…
Real numbers can have arbitrary precision (in JSON; in JavaScript they are limited by the precision of IEEE 754) and thus an infinite number of digits. But in practice the above is pretty typical, so say each coordinate has 18 digits. Including extra symbols ([, ] and ,), each point takes at most 1 + 18 + 1 + 18 + 1 = 39 bytes to encode in JSON, and the entire geometry is about 39 * 1,000,000 ≈ 39MB.
Now say we convert these real numbers to integers: both longitude and latitude are reduced to integers x and y where 0 ≤ x ≤ 99 and 0 ≤ y ≤ 99. A simple mapping between real-number points ⟨λ,φ⟩ and integer coordinates ⟨x,y⟩ is:
x = floor((λ + 180) / 360 * 100);
y = floor((φ + 90) / 180 * 100);
Since each coordinate now takes at most 2 digits to encode, each point takes at most 1 + 2 + 1 + 2 + 1 = 7 bytes to encode in JSON, and the entire geometry is about 7MB; we reduced the total size by 82%.
Of course, nothing comes for free: if you remove too much information, you will no longer be able to display the geometry accurately. The rule of thumb is that the size of your grid should be at least twice as big as the largest expected display size for the entire map. For example, if you’re displaying a world map in a 960×500 pixel space, then the default 10,000×10,000 (-q 1e4) is a reasonable choice.
So, quantization removes information by reducing the precision of each coordinate, effectively snapping each point to a regular grid. This reduces the size of the generated TopoJSON file because each coordinate is represented as an integer (such as between 0 and 9,999) with fewer digits.
In contrast, simplification removes information by removing points, applying a heuristic that tries to measure the visual salience of each point and removing the least-noticeable points. There are many different methods of simplification, but the Visvalingam method used by the TopoJSON reference implementation is described in my Line Simplification article so I won’t repeat myself here.
While quantization and simplification address these two different types of information mostly independently, there’s an additional complication: quantization is applied before the topology is constructed, whereas simplification is necessarily applied after to preserve the topology. Since quantization frequently introduces coincident points ([24,62],[24,62],[24,62]…), and coincident points are removed, quantization can also remove points.
The reason that quantization is applied before the topology is constructed is that geometric inputs are often not topologically valid. For example, if you takes a shapefile of Nevada counties and combine it with a shapefile of Nevada’s state border, the coordinates in one shapefile might not exactly match the coordinates in the other shapefile. By quantizing the coordinates before constructing the topology, you snap the coordinates to a regular grid and can get a cleaner topology with fewer arcs, hopefully correctly identifying all shared arcs. (Of course, if you over-quantize, then you can cause too many coincident points and get self-intersecting arcs, which causes other problems.)
In a future release, maybe 1.5.0, TopoJSON will allow you to control the quantization before the topology is constructed independently from the quantization of the output TopoJSON file. Thus, you could use a finer grid (or no grid at all!) to compute the topology, then simplify, then use a coarser grid appropriate for a low-resolution screen display. For now, these are tied together, so I recommend using a finer grid (e.g., -q 1e6) that produces a clean topology, at the expense of a slightly larger file. Since TopoJSON also uses delta-encoded coordinates, you rarely pay the full price for all the digits anyway!
这篇关于Topojson：量化VS简化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
