Poly Encoding

[bratliff]

An open letter to Google:

Soon you will introduce GPolyline / GPolygon classes to V3. The old
"fromEncoded" standard has several weaknesses. Please consider
revising it.

The zoom "level string" is confusing. It adds 33% to the size of the
file. It requires a recursive point reduction algorithm like Douglas-
Peucker to generate it in real time which causes a delay. Adequate
point reduction can be performed without it. Please consider
eliminating it. Al lease make it optional.

The encoding strings should never contain the "\" backslash
character. Please consider a different alphabet.

Five decimal places of accuracy are not enough at deep zoom levels
(17-21). City streets look ragged. Property boundaries are
inaccurate. Building outlines cannot be placed properly.

Some polys may cross the International Date Line. Two points may be
just a few fractional degrees apart yet their longitude coordinates
are almost 360 degrees apart. +180 degrees & -180 degrees are really
the same point. Because the encoder deals with differences rather
than actual coordinates, it causes a huge spike in the chain. If the
poly crosses several times, it really disrupts the algorithm. Please
consider adding 360 degrees to points east of the International Date
Line. It can be detected by the decoded because it is out of range.
The decoder can adjust it back to its original value.

Finally, please consider encoding pixel coordinates rather than Lat/
Lon coordinates. A Mercator projection can be assumed in most cases.
The encoder will provide the zoom level. If a non-Mercator projection
is used, it requires a two step reprojection. If a Mercator
projection is used, it requires no projection. It is ready to go. In
99% of the cases, it will be faster. In 1% of the cases it will be
slower.

[Ben Appleton]

Thanks - I agree with your assessment of the problems with the old
encoding scheme, and we'll keep these in mind as we develop polys in
v3.

Ben