Hi Chad,

I have read all those discussions, and I never particularly used
encoded polylines for their speed benefits on the client, moreso for
their transmission benefits, they take a lot less to transmit.

Also, it's just plain messy to have a loop that steps over all the
points creating a new instance of a LatLng for each point, surely that
sort of drudgery should be hidden via a Google API call like
Polyline.setPathByPoints(pointarray); or similar, and all the looping
etc. can be done behind the scenes and in whatever optimised way that
google wants.

To go from one call like fromEncoded() to looping through setting
points just seems like a big step backwards.

To be clear, I have no particular issue with losing the encoded format
(it was problematic with backslashes and the like anyway), but just
some other concise form of passing points would have been sensible for
replacement. It's almost as is Google has just forgotten that some
people like to use Google maps to show some fairly complex polygons,
and that it's a very useful ability.

If there is no other method than what I've already seen I'll run with
what there is and just pass a list of points to the client and have it
iterate over them, I'm just a bit gobsmacked that it's the 'way' to do
it, that's all.

Simon

On Oct 4, 10:58 pm, Chad Killingsworth
<[email protected]> wrote:
> There are several discussions regarding this topic in the group. Here
> a just a couple:
>
> http://groups.google.com/group/google-maps-js-api-v3/browse_thread/th...http://groups.google.com/group/google-maps-js-api-v3/browse_thread/th...
>
> Basically it summarized down to encoded polylines don't really save
> you much except for transmission speed. If you have a HUGE number of
> points in your polys, you might want to look at Berry Ratliff's
> classes as they offer some pretty impressive performance for complex
> polys.
>
> I store mine as LatLng pairs and convert them to LatLng objects on the
> client.
>
> Chad Killingsworth
>
> On Oct 4, 1:00 am, spoco2 <[email protected]> wrote:
>
> > Hi all,
>
> > I am at a loss as to how to neatly define a complex path polygon/
> > polyline (think a postcode boundary) in V3 of the API compared to V2.
>
> > We have an app that currently uses the V2 API to draw about 50 complex
> > polygons at a time on a map. This we do using encoded polygons. So one
> > complex polygon could be represented as:
>
> > "d{xefubzsz`bquxn{hlzu`...@jfcuro@c...@jn@b...@prbo@y|
> > @l[ygi...@zat@mnq^diqiblzas...@}erf}eaho@kUrAdH"
>
> > for example. That's a lot of points in a nice, concise string.
>
> > Now, in V3 I see there is no such GPolygon.fromEncoded() method, and
> > instead we are supposed to define polygons via code like:
> >  var coords= [
> >         new google.maps.LatLng(25.774252, -80.190262),
> >         new google.maps.LatLng(18.466465, -66.118292),
> >         new google.maps.LatLng(32.321384, -64.75737),
> >         new google.maps.LatLng(25.774252, -80.190262)
> >     ];
>
> > Which, for that very example above turns out like as a few pages of
> > this editbox full of  'new google.maps.LatLng' definitions. This seems
> > horrendously inefficient.
>
> > I know I can send them as purely an array of points and then on the
> > client step over that doing the same, but that seems just as bad.
>
> > Surely there is a more effiecient way of defining a complex polygon
> > now?

-- 
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.

Reply via email to