On Mar 15, 2:46 pm, Marcelo <[email protected]> wrote:
> On Mar 15, 2:44 pm, bratliff <[email protected]> wrote:
>
>
>
> > V3 does not support encoded polys.
>
> Ha! I hadn't noticed that you cannot setPath(encoded), and I think
> it's curious because the DirectionsStep returns encoded_lat_lngs among
> other fields.
Ben admits it was a design mistake. If the API supported it, it would
be stuck with it indefinitely. With an optional "zoom string", it is
viable but not optimal. Use of the backslash character is a source of
confusion & error.
> >V2 encoded polys are confusing &
> > inadequate.
>
> I still think they'd be a better, more compact format to store than
> SVG, and the conversion utilities are readily available in various
> languages from Marc McClur's page.
Better than SVG but not better than JSON.
> > I believe his application involves floor plans which
> > cannot be described with five decimal places of Lat/Lon precision. I
> > believe it uses a Euclidean (flat) projection.
>
> You can use any precision. You're not limited to 5 decimals.
Check closely. Floating point Lat/Lon coordinates are converted to
integers by multiplying by 1e5. Fixed point numbers are compressed.
Anything beyond the fifth decimal place is discarded.
The file:
http://www.polyarc.us/polycluster/polypack.js
contains lossless compression functions accurate to the capacity of a
32 bit signed integer.
--
You received this message because you are subscribed to the Google Groups
"Google Maps JavaScript API v3" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-maps-js-api-v3?hl=en.
