Polyline Clipping

[Tim G]

I'm having some issues with my polyline disappearing in certain
areas. The blue polyline represents the route and then the orange
highlight is my search area for POIs along that route. The orange
highlight is just a really thick polyline. The width is calculated
based on the search radius and zoom level. I have this app working
flawlessly in v2 but I'd like to move to v3 if I can get this sorted.

n the first example, you'll notice clipping right off the bat along
the bottom right and on the right side. Zoom in a bit and the line
turns into a giant square. Zoom in further and suddenly you start
losing entire sections of the line.

Example 2 is of a longer trip. From the higher zoom level the line
looks fine but as you zoom in you'll already start to notice some
clipping on the right side of the 'A' marker.

My code to make the line is pretty basic. I get the route polyline
points and feed them into the highlight polyline:

bufferPoly = new google.maps.Polyline({
path: highPoints,
strokeColor: '#FF6600',
strokeWeight: highlightWidth,
strokeOpacity: 0.15,
map: map
});

Any idea how to fix this? Is it a bug?

[Tim G]

Example 1 image: http://www.greatwarehouse.com/images/gmap_example1.gif
Example 2 image: http://www.greatwarehouse.com/images/gmap_example2.gif

[Chad Killingsworth]

That's interesting. I'm guessing that the clipping happens at the
bounds of the polyline tiles and it especially evident since you are
using a very large stroke weight A link to your map would help verify
this.

If true - it would be a bug (or an unintended side-effect).

Chad Killingsworth

[Tim G]

Chad, here is a link to the map:

http://www.dgcoursereview.com/google_example/beta_route_map.php

The highlight does go away once you zoom in beyond a certain point so
that is normal.

On Oct 5, 10:28 am, Chad Killingsworth

[Tim G]

Another example..

http://greatwarehouse.com/test.htm

That's the google complex polyline sample and I just bumped up the
width to 195. Very bizarre results when you start clicking around.

[Rossko]

I think it is a variation on this issue
http://code.google.com/p/gmaps-api-issues/issues/detail?id=2337
see also this thread
http://groups.google.com/group/google-maps-js-api-v3/browse_thread/thread/2b6f7d984072e663/e280e3f36eb82115

Problem seems to be the API 'forgets' to render polys crossing certain
tiles if no vertices lie on that tile

[Tim G]

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 <ros...@culzean.clara.co.uk> 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...

[Ben Appleton]

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

> --
> 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 google-map...@googlegroups.com.
> To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.
>
>

[Ben Appleton]

Update: to avoid these visual artifacts I have enforced the maximum
stroke weight. Polys with a higher stroke weight will be rendered at
the maximum supported stroke weight.

If there's a lot of demand we can look into allowing much higher
stroke weights, bearing in mind that this may slow down rendering.

- Ben

[geoco...@gmail.com]

On Oct 5, 4:25 pm, Ben Appleton <apple...@google.com> wrote:
> 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.

I don't think that is an acceptable solution, unless it is clearly
stated in the documentation, and even then it is a regression from
v2,.and I think you are going to run into problems with all kinds of
issues that you didn't consider (like this one).

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

Maybe you could implement it the fast way for sites that use stroke
weights of less than 10 pixels, but implement a fall back to the
slower rendering algorithm for sites that need the greater stroke
widths (will be slightly slower than assuming it will always be less
than 10, but at least it isn't broken). Obviously a general purpose
maps API has to support all (reasonable) stroke widths (and v3 needs
to support anything that v2 did or document the difference).

Just my 2 cents.

-- Larry

>
> - Ben
>
>
>
> On Wed, Oct 6, 2010 at 7:59 AM, Tim G <timgos1...@yahoo.com> 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 <ros...@culzean.clara.co.uk> 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 google-map...@googlegroups.com.
> > To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/google-maps-js-api-v3?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Tim G]

I agree with Larry, it would be nice if there was some alternate
solution that at least gave you something comparable to v2
functionality when you use similar classes.

[geoco...@gmail.com]

Based on Ben Appletons post:
+ If there's a lot of demand we can look into allowing much higher
+ stroke weights, bearing in mind that this may slow down rendering.

the best course forward is to create an enhancement request (although
I would probably class it as an issue/defect):
http://code.google.com/p/gmaps-api-issues/issues/list?can=2&q=apitype%3AJavascript3
and lobby developers for stars...

-- Larry

[Tim G]

Thanks Larry. I'm not sure what I can do on the lobbying front but
I'll at least put it in there and keep my fingers crossed.

On Oct 5, 9:14 pm, "geocode...@gmail.com" <geocode...@gmail.com>
wrote:

> I would probably class it as an issue/defect):http://code.google.com/p/gmaps-api-issues/issues/list?can=2&q=apitype...

[geoco...@gmail.com]

On Oct 5, 6:17 pm, Tim G <timgos1...@yahoo.com> wrote:
> Thanks Larry.  I'm not sure what I can do on the lobbying front but
> I'll at least put it in there and keep my fingers crossed.

First thing would be to post a link to the issue in this thread, like
this:
http://code.google.com/p/gmaps-api-issues/issues/detail?id=2764
(I gave it a star)

Then anyone that finds this thread can find the issue and star it if
they think it should be fixed or are interested in following it.

The development team is probably correct in their take that this isn't
a large use case, but they also want v3 to be the "official" Google
Maps API, so I think they can't arbitrarily drop functionality in
favor of performance, at least not without giving access to that
functionality for those willing to suffer the performance hit...

-- Larry

>
> On Oct 5, 9:14 pm, "geocode...@gmail.com" <geocode...@gmail.com>
> wrote:
>
>
>
> > On Oct 5, 5:56 pm, Tim G <timgos1...@yahoo.com> wrote:
>
> > > I agree with Larry, it would be nice if there was some alternate
> > > solution that at least gave you something comparable to v2
> > > functionality when you use similar classes.
>
> > Based on Ben Appletons post:
> > + If there's a lot of demand we can look into allowing much higher
> > + stroke weights, bearing in mind that this may slow down rendering.
>
> > the best course forward is to create an enhancement request (although
> > I would probably class it as an issue/defect):http://code.google.com/p/gmaps-api-issues/issues/list?can=2&q=apitype...
> > and lobby developers for stars...
>

> >   -- Larry- Hide quoted text -

[bratliff]

I have built a couple of demos using PolyCluster:

http://www.polylib.us/polycluster/coast/simple.html

http://www.polylib.us/polycluster/coast/advanced.html

The line width is essentially unlimited. It is never a performance
issue unless it exceeds twice the tile size. "weight:0" thru "weight:
511" incur the same overhead.

Double stroking requires the poly to be defined twice which is
unfortunate. If it is a common thing to do, I will add the ability to
clone another poly without actually loading it again. A poly might
have multiple aliases.

[Tim G]

Berry,

I'm trying to use polycluster to get the line going without much
success. I'm able to get the line initially (although at a high zoom
there are artifacts) but trying to zoom, move the map, etc. doesn't
work so well after the initial rendering. Any idea what I'm doing
wrong?

http://www.dgcoursereview.com/google_example/beta_cluster_map.php

[bratliff]

On Oct 6, 6:09 pm, Tim G <timgos1...@yahoo.com> wrote:
> Berry,
>
> I'm trying to use polycluster to get the line going without much
> success. I'm able to get the line initially (although at a high zoom
> there are artifacts) but trying to zoom, move the map, etc. doesn't
> work so well after the initial rendering. Any idea what I'm doing
> wrong?

I have to run but I will look at it tomorrow. If you can reduce it to
something very simple, it will help. It will load quickly. I will
have less to look at. The first demo might be a good place to start
with your map parameters.

[Tim G]

Berry,

Did you get a chance to look at this yet? All I'm doing is taking the
directions polyline point for point and feeding it into polycluster.
Perhaps it's too many points?

[bratliff]

On Oct 8, 12:58 am, Tim G <timgos1...@yahoo.com> wrote:
> Berry,
>

> Did you get a chance to look at this yet? All I'm doing is taking the
> directions polyline point for point and feeding it into polycluster.
> Perhaps it's too many points?

I did look at it but decided it contained too much unrelated code. I
could not find where you were using PolyCluster without looking at a
bunch of auxilliary JS files.

Can you simplify it to demonstrate just the PolyCluster error ? Do
you have a recent copy of polycluster.js which contains fixes to deep
zoom level bugs ?

For what it worth, PolyCluster allows you to specify a "weight" array
which means the pixel width of your polys can vary with zoom level.
Thus, your 10 mile band will be scaled according to zoom level.

[Tim G]

Ah, sorry about that. I have tried to simplify it a little more. You
can find my use of polycluster on line 331 of the file below:

http://www.dgcoursereview.com/google_example/templates/routemap_main_cluster.js

highPoints is the array of points from the directions polyline. I
convert them to the polycluster format using a function I found in
another thread in the group (toPolyCluster from
http://www.william-map.com/20100717/2/test.htm?polyline,0).

I am using the polycluster.js file linked from this example:
http://home.provide.net/~bratliff/polycluster/v3/hawaii.html

On Oct 8, 9:44 am, bratliff <bratl...@umich.edu> wrote:
> On Oct 8, 12:58 am, Tim G <timgos1...@yahoo.com> wrote:
>
> > Berry,
>
> > Did you get a chance to look at this yet? All I'm doing is taking the

> > directionspolylinepoint for point and feeding it into polycluster.

[bratliff]

On Oct 8, 2:01 pm, Tim G <timgos1...@yahoo.com> wrote:
> Ah, sorry about that. I have tried to simplify it a little more. You
> can find my use of polycluster on line 331 of the file below:
>

> http://www.dgcoursereview.com/google_example/templates/routemap_main_...

>
> highPoints is the array of points from the directions polyline. I
> convert them to the polycluster format using a function I found in

> another thread in the group (toPolyCluster fromhttp://www.william-map.com/20100717/2/test.htm?polyline,0).

>
> I am using the polycluster.js file linked from this example:http://home.provide.net/~bratliff/polycluster/v3/hawaii.html

Can you simplify it further with nothing except PolyCluster calls ?
"toPolyCluster" is unnecessary. Just use a double array of {x:,y:}
objects. Look at "hawaii.raw" for an example. The API requires every
vertex to execute a "new google.maps.LatLng()" constructor which seems
ridiculous to me. PolyCluster uses JavaScript arrays directly.

[Tim G]

Berry,

I think I've fixed a couple of errors on my own. One thing, is there
a way to remove the polycluster after creating it? I tried
polycluster.setMap(null) but it's throwing an error. Once I get that
sorted I should have some code to share with you.

- Tim

On Oct 8, 11:10 am, bratliff <bratl...@umich.edu> wrote:
> On Oct 8, 2:01 pm, Tim G <timgos1...@yahoo.com> wrote:
>
> > Ah, sorry about that. I have tried to simplify it a little more.  You
> > can find my use of polycluster on line 331 of the file below:
>
> >http://www.dgcoursereview.com/google_example/templates/routemap_main_...
>

> > highPoints is the array of points from the directionspolyline. I

[Tim G]

Berry,

I figured out I can just reload the polycluster object and it deleted
the old overlay. So with that sorted, everything seems to be working
well except at the higher zoom levels there seems to be issues
rendering the line similar to the problems I was having using the
Google's Polyline. Here is my example.. I tried to make it as simple
as I could while still having the code work:

http://www.dgcoursereview.com/google_simple/beta_cluster_map.php

Also, is there a way to remove the overlay? setMap(null) wasn't
working. Do I just set the color to be clear as you did on your
examples?

Thanks again,

Tim

On Oct 8, 11:10 am, bratliff <bratl...@umich.edu> wrote:

> On Oct 8, 2:01 pm, Tim G <timgos1...@yahoo.com> wrote:
>
> > Ah, sorry about that. I have tried to simplify it a little more.  You
> > can find my use of polycluster on line 331 of the file below:
>
> >http://www.dgcoursereview.com/google_example/templates/routemap_main_...
>

> > highPoints is the array of points from the directionspolyline. I

[bratliff]

On Oct 8, 4:15 pm, Tim G <timgos1...@yahoo.com> wrote:
> Berry,
>
> I figured out I can just reload the polycluster object and it deleted
> the old overlay. So with that sorted, everything seems to be working
> well except at the higher zoom levels there seems to be issues
> rendering the line similar to the problems I was having using the
> Google's Polyline. Here is my example.. I tried to make it as simple
> as I could while still having the code work:
>
> http://www.dgcoursereview.com/google_simple/beta_cluster_map.php
>
> Also, is there a way to remove the overlay? setMap(null) wasn't
> working. Do I just set the color to be clear as you did on your
> examples?
>
> Thanks again,
> Tim

Think of PolyCluster like an extension of the API rather than an
OverlayView object. You never have to remove it. You do not require
multiple PolyClusters. Just load your polys separately or together.
To destroy a poly, just reload it with an empty array. PolyCluster
will discard the related "cache" elements.

If you can eliminate the use of the "new google.map.LatLng()"
constructor, you will improve performance significantly. You will be
able to eliminate your "toPolyCluster" function too.

To simplify it to the point I can diagnose it, hard code your poly
array. It is really one array containing several other arrays.
Please remove all bells and whistles from your map. I have a limited
amount of time to spend looking at it. With nothing superfluous, I
will be able to examine the error. Thanks very much.

[Tim G]

Berry,

Here you go, as simple as it gets (hopefully!). I set the stroke to
300px. Typically I'd use a ~300px stroke when you're zoomed in pretty
close. Zooming in further, I'd just remove the poly so you get a
clear map view. Zooming out, I'd make the stroke more narrow,
eliminating the issue in most cases.

http://www.dgcoursereview.com/google_simple/beta_cluster_simple.php

I did notice the issues started to show up at 129px. At 128px you
could zoom in to any level without issue. 129px started to show
rendering issues.

[bratliff]

On Oct 8, 6:38 pm, Tim G <timgos1...@yahoo.com> wrote:
> Berry,
>

> Here you go, as simple as it gets (hopefully!). I set the stroke to
> 300px. Typically I'd use a ~300px stroke when you're zoomed in pretty
> close. Zooming in further, I'd just remove the poly so you get a
> clear map view. Zooming out, I'd make the stroke more narrow,
> eliminating the issue in most cases.
>
> http://www.dgcoursereview.com/google_simple/beta_cluster_simple.php
>
> I did notice the issues started to show up at 129px. At 128px you
> could zoom in to any level without issue. 129px started to show
> rendering issues.

Still much too complex. Please eliminate the stylesheets, the
templates, the meta tags, the footer, the page tracker, the facebook
stuff, the other decorative stuff not pertinent to the map. I could
do it myself but I am really busy. I agree it is a PolyCluster bug
but in order to fix it I must be able to run something very simple.

Thanks Tim.

[bratliff]

On Oct 8, 6:38 pm, Tim G <timgos1...@yahoo.com> wrote:
> Berry,
>

> Here you go, as simple as it gets (hopefully!). I set the stroke to
> 300px. Typically I'd use a ~300px stroke when you're zoomed in pretty
> close. Zooming in further, I'd just remove the poly so you get a
> clear map view. Zooming out, I'd make the stroke more narrow,
> eliminating the issue in most cases.
>
> http://www.dgcoursereview.com/google_simple/beta_cluster_simple.php
>
> I did notice the issues started to show up at 129px. At 128px you
> could zoom in to any level without issue. 129px started to show
> rendering issues.

I have a "stop-gap" fix. Set the tile size to 1024 pixels by adding
the following statement:

cluster.setPixel(10);

It is still a PolyCluster bug. I am working on correcting it.

[Tim G]

cluster.setPixel(10); seems to have done the trick as far as fixing
the rendering issues. I've also simplified the map quite a bit if you
still need that.

One thing I did add was a "Remove Polycluster" button for testing
purposes but I can't get it to work. I create an empty array as so
(shorttrip being the path I want to delete):

var empty_array = {};
empty_array.shorttrip = [];

and then I do cluster.load(empty_array);

You had mentioned I just needed to reload the cluster with an empty
array but I'm obviously doing something incorrectly.

Thanks again Berry, I appreciate you taking the time to look at all
this stuff.

[bratliff]

On Oct 9, 2:54 pm, Tim G <timgos1...@yahoo.com> wrote:
> cluster.setPixel(10); seems to have done the trick as far as fixing
> the rendering issues. I've also simplified the map quite a bit if you
> still need that.
>
> One thing I did add was a "Remove Polycluster" button for testing
> purposes but I can't get it to work. I create an empty array as so
> (shorttrip being the path I want to delete):
>
> var empty_array = {};
> empty_array.shorttrip = [];
>
> and then I do cluster.load(empty_array);
>
> You had mentioned I just needed to reload the cluster with an empty
> array but I'm obviously doing something incorrectly.
>
> Thanks again Berry, I appreciate you taking the time to look at all
> this stuff.

Thanks Tim,

PolyCluster itself cannot be discarded without total chaos.

I use:

cluster.load({shorttrip:[],othertrip:[], ... });

or

cluster.load({shorttrip:null,othertrip:null, ... });

to discard polys. What you are doing appears to be equivalent.

You may have to call "setColor" to flush the existing polys from the
screen.

cluster.setColor(["shorttrip","othertrip", ... ],{});

PolyCluster ought to do it for you. It is a bug. I will fix it.

I have found the other problem. I will have a solution soon.

Thanks for your help providing a test case.

Berry

[Tim G]

Berry,

You were right, I had to load the blank array and then run setColor
and it works like a charm. My app is 99% converted from v2 to v3
thanks to polycluster. Thanks so much for creating it, it is
incredibly useful to me. Is there someplace where you announce new
versions of polycluster so I can grab the one with the fixes when you
finish it up?

[bratliff]

On Oct 9, 7:28 pm, Tim G <timgos1...@yahoo.com> wrote:
> Berry,
>
> You were right, I had to load the blank array and then run setColor
> and it works like a charm. My app is 99% converted from v2 to v3
> thanks to polycluster. Thanks so much for creating it, it is
> incredibly useful to me. Is there someplace where you announce new
> versions of polycluster so I can grab the one with the fixes when you
> finish it up?

I will add a "Last Updated" tag to the page at:

http://www.polyarc.us

or

http://www.polylib.us

I will let you know when the bug you reported is fixed. Adding mouse
event handlers is also on the agenda. Thanks again for your test
case.

Berry

[bratliff]

Try:

http://www.polylib.us/polycluster/short

You will notice the weights are automatically adjusted for zoom level,
something you cannot do with the API.

It is not completely corrected but it ought to work for weights
between 1 and 256. If 256 is not enough, you can expand the tile size
with "setPixel()". The argument is the log base 2 of the desired tile
size.

Also, if you clear a poly, the residual junk will be automatically
cleared from the screen. I have to rework some other sections of code
which assume the weight will never exceed the tile size. I will let
you know when I am done.

[Tim G]

Berry,

I do need lines wider than 256 at times so I'll keep setPixel at 10.
The auto-adjusting of the weights based on zoom level is nice and
thanks for fixing the clean-up of the polys. It's allowed me to
simplify some of the code in my app quite a bit and the whole thing
works great.

Thanks again,
Tim

[bratliff]

I have made several improvements. It ought to work correctly
regardless of tile size.

I have added "click" / "cover" capabilities. Instead of individual
event listeners for every poly, you add a single event listener for
the entire PolyCluster.

For "mousedown" / "mouseup", use:

cluster.setClick(YourClickFunction);

It will be called with two arguments:

function YourClickFunction(polyname,flag)

The first argument is the name of the poly. The second argument will
be "true" for "mousedown" or "false" for "mouseup".

For "mouseover" / "mouseout", use:

cluster.setCover(YourCoverFunction);

It will be called with two arguments:

function YourCoverFunction(polyname,flag)

The first argument is the name of the poly. The second argument will
be "true" for "mouseover" or "false" for "mouseout".

http://www.polylib.us contains some demos.