The problem is that the API assumes the maximum stroke weight is 10 pixels. Assuming a maximum stroke weight allows the API to render faster, by skipping polylines that are out of range.
We could enforce this maximum stroke weight. That would mean you can't render a polyline with a stroke weight greater than 10, so you wouldn't see these bugs. Or we could look into removing the maximum stroke weight limitation. That could slow down rendering for existing sites using stroke weights of less than 10 pixels. - Ben On Wed, Oct 6, 2010 at 7:59 AM, Tim G <[email protected]> wrote: > Ah... that's not too encouraging. Although in the second test url I > gave, if you make a large "C" using 4 markers, the line ends up > joining on itself in the middle of the "C" (in addition to lots and > lots of clipping). > > I was hoping to shift map development on my site to v3 but the wide > polyline is a pretty key component of my app so it looks like I'm > stuck with v2 for now. > > On Oct 5, 3:46 pm, Rossko <[email protected]> wrote: >> I think it is a variation on this >> issuehttp://code.google.com/p/gmaps-api-issues/issues/detail?id=2337 >> see also this >> threadhttp://groups.google.com/group/google-maps-js-api-v3/browse_thread/th... >> >> Problem seems to be the API 'forgets' to render polys crossing certain >> tiles if no vertices lie on that tile > > -- > 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. > > -- 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.
