V3 Polyline Problems

[Kepesk]

Hey, I'm trying out the Google Maps API, but I've run into a nasty
polyline problem.

The maps I'm trying to generate are static and very simple. Just a
marker, a circle, and a small polyline (less than 100 coordinates).
However, I have found that when the polyline is displayed, parts of it
get cut off at random. After some investigation, I've found two
consistent aspects of this bug:

1. The polylines usually reappear after you zoom way out, but are cut
off again when you zoom in.
2. The polylines are always cut off at the border of a map tile.

I've searched various discussion forums about this, but I only found
one example of someone with the exact same issue, and that never got
resolved because they didn't provide an example. So I'm providing
one:

http://dragonbookstore.com/maptest/

Go to that web page, zoom in twice, and pan around the map. You
should see broken lines in at least two places.

I've tried everything I can think of to get this to work properly, but
I'm afraid I'm too new to the API to make much sense of the problem.
Could someone point me in the right direction?

Thanks!

[Miguel Angel Vilela]

Is this the same as issue #2337?

Issue 2337: Lost Polyline

http://code.google.com/p/gmaps-api-issues/issues/detail?id=2337

If it is, can you please add your example and findings on that issue?

Thanks,

Miguel

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

[Kepesk]

Well, I'm not sure. It looks similar, but not a lot of details about
the bug were posted. I'll add my information anyway. Anyone else
have any suggestions?

-Jacob

On Jun 9, 2:02 am, Miguel Angel Vilela <mig...@google.com> wrote:
> Is this the same as issue #2337?
>

> Issue 2337: Lost Polylinehttp://code.google.com/p/gmaps-api-issues/issues/detail?id=2337<http://code.google.com/p/gmaps-api-issues/issues/detail?id=2337&q=api...>

> > google-maps-js-a...@googlegroups.com<google-maps-js-api-v3%2Bunsu...@googlegroups.com>
> > .

[Miguel Angel Vilela]

At least you gave a working sample, thanks!

To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.

[Michael]

I've run into this problem as well. I connected 25 points and two
points did not get lines. Any news on a solution?

[William]

On Jul 16, 3:31 am, Michael <mdsh...@gmail.com> wrote:
> I've run into this problem as well. I connected 25 points and two
> points did not get lines. Any news on a solution?
>

what were the coordinates of points you were using?

to better illustrate the problem I've taken the original example and
added tile coordinates, so you can see where the polylines are being
clipped on tile boundaries. The V3 polys are tesselated into tiles, I
think for performance reasons, and also for browsers where CANVAS must
be used. So I've put another overlay of the complete polyline as a
single element in red, so it's clear where the line should be:

http://www.william-map.com/20100716/1/map.htm

...

[bratliff]

I suspect it is caused by "off-tile" verticies too distant from the
visible tile. It happens at deep zoom levels where the pixel distance
between verticies is large.

To maintain continuity of the poly, every tile must have every vertex
represented in its path. Fortunately, many "off-tile" vertices can be
relocated. If both neighbors of an "off-tile" vertex are also "off-
tile", the vertex can be moved to one of eight tiles adjacent to the
visible tile. Consecutive vertices moved to the same tile can be
summarized & reduced.

The only "off-tile" vertices which cannot be relocated are the ones
with one or both of its neighbors "on-tile". If the "off-tile" vertex
is too distant from its "on-tile" neighbor, it causes strange behavior
which is different in CANVAS & SVG. To avoid the issue, the
transitional "off-tile" vertex must be moved to an equivalent "off-
tile" location in one of eight tiles adjacent to the visible tile. It
must be on the interpolation line connecting the "off-tile" vertex to
its "on-tile" vertex neighbor. If both neighbors are "on-tile", it
may not be feasible to move the "off-tile" vertex to a single
equivalent vertex on both interpolation lines. The single "off-tile"
vertex must be split into two "off-tile" vertices, one on each of the
corresponding interpolation lines.

It is a bit ugly but the use of tiles really helps dragging /
panning / zooming performance.

[bratliff]

On Jul 16, 4:39 pm, bratliff <bratl...@umich.edu> wrote:

> I suspect it is caused by "off-tile" verticies too distant from the
> visible tile. It happens at deep zoom levels where the pixel distance
> between verticies is large.
>
> To maintain continuity of the poly, every tile must have every vertex
> represented in its path. Fortunately, many "off-tile" vertices can be
> relocated. If both neighbors of an "off-tile" vertex are also "off-
> tile", the vertex can be moved to one of eight tiles adjacent to the
> visible tile. Consecutive vertices moved to the same tile can be
> summarized & reduced.
>
> The only "off-tile" vertices which cannot be relocated are the ones
> with one or both of its neighbors "on-tile". If the "off-tile" vertex
> is too distant from its "on-tile" neighbor, it causes strange behavior
> which is different in CANVAS & SVG. To avoid the issue, the
> transitional "off-tile" vertex must be moved to an equivalent "off-
> tile" location in one of eight tiles adjacent to the visible tile. It
> must be on the interpolation line connecting the "off-tile" vertex to
> its "on-tile" vertex neighbor. If both neighbors are "on-tile", it
> may not be feasible to move the "off-tile" vertex to a single
> equivalent vertex on both interpolation lines. The single "off-tile"
> vertex must be split into two "off-tile" vertices, one on each of the
> corresponding interpolation lines.
>
> It is a bit ugly but the use of tiles really helps dragging /
> panning / zooming performance.

P.S.

"on-the-fly" point reduction improves performance by eliminating
intermediate points along the interrpolation line. Caching the path
also improves performance.

[Michael Short]

Here is the path I was using.

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

--
Michael Short
(901) 233-9926

[bratliff]

On Jul 16, 4:39 pm, bratliff <bratl...@umich.edu> wrote:

> I suspect it is caused by "off-tile" verticies too distant from the
> visible tile. It happens at deep zoom levels where the pixel distance
> between verticies is large.
>
> To maintain continuity of the poly, every tile must have every vertex
> represented in its path. Fortunately, many "off-tile" vertices can be
> relocated. If both neighbors of an "off-tile" vertex are also "off-
> tile", the vertex can be moved to one of eight tiles adjacent to the
> visible tile. Consecutive vertices moved to the same tile can be
> summarized & reduced.
>
> The only "off-tile" vertices which cannot be relocated are the ones
> with one or both of its neighbors "on-tile". If the "off-tile" vertex
> is too distant from its "on-tile" neighbor, it causes strange behavior
> which is different in CANVAS & SVG. To avoid the issue, the
> transitional "off-tile" vertex must be moved to an equivalent "off-
> tile" location in one of eight tiles adjacent to the visible tile. It
> must be on the interpolation line connecting the "off-tile" vertex to
> its "on-tile" vertex neighbor. If both neighbors are "on-tile", it
> may not be feasible to move the "off-tile" vertex to a single
> equivalent vertex on both interpolation lines. The single "off-tile"
> vertex must be split into two "off-tile" vertices, one on each of the
> corresponding interpolation lines.
>
> It is a bit ugly but the use of tiles really helps dragging /
> panning / zooming performance.

I forgot to mention another case. Two consecutive vertices may both
be "off-tile" but their connecting line may intersect the visible
tile. Both "off-tile" vertices will have to be moved into range along
their connecting line. Again, it is a lot of work but by doing it
once & caching the result, it does not have to be duplicated.

[William]

On Jul 17, 3:44 am, Michael Short <mdsh...@gmail.com> wrote:
> Here is the path I was using.
>

thanks Michael, it looks like a similar problem to the example by the
original poster. I think the problem sometimes happens when a path
crosses itself (self intersections). I'll make a test case with this
data and try to make some more similar test cases.

...

[William]

On Jul 17, 4:40 am, bratliff <bratl...@umich.edu> wrote:
> I forgot to mention another case.  Two consecutive vertices may both
> be "off-tile" but their connecting line may intersect the visible
> tile.  Both "off-tile" vertices will have to be moved into range along
> their connecting line.  Again, it is a lot of work but by doing it
> once & caching the result, it does not have to be duplicated.

thanks bratliff for the detailed explanations of the tile clipping
process, it's very interesting stuff. I've done this sort of thing
with conventional GIS, for example when shading land/ocean, if using
an entire continent boundary with millions of coordinates, then it's
much higher performance to tesselate the polygon. It's amazing that
it's now possible with javascript because I'm used to doing this stuff
with optimized C code on a dedicated workstation. Now it can be done
in javascript on an iPhone!

Today I'll try these problem polylines with PolyCluster to compare
with google.maps.Polyline.

...

[William]

On Jul 17, 11:17 am, William <william.g...@gmail.com> wrote:
>
> Today I'll try these problem polylines with PolyCluster to compare
> with google.maps.Polyline.
>

here's the two polyline examples in blue, with the reference lines
drawn in red, so you can see where the polyline should go.

Test A. Using google.maps.Polyline

(1) problems with horizontal lines east of Fremont Forest:
http://www.william-map.com/20100717/2/test.htm?polyline,0

(2) problems with vertical line north of Apartment Lane:
http://www.william-map.com/20100717/2/test.htm?polyline,1

Test B. Using bratliff.PolyCluster

(1) everything seems OK:
http://www.william-map.com/20100717/2/test.htm?polycluster,0

(2) major problems at high zoom levels:
http://www.william-map.com/20100717/2/test.htm?polycluster,1

...

[William]

On Jul 16, 3:31 am, Michael <mdsh...@gmail.com> wrote:

> I've run into this problem as well. I connected 25 points and two
> points did not get lines. Any news on a solution?

the status of the issue says it's been "fixed but not yet released",
so I added your test case to the issue and they should be able to
confirm whether the fix works on your data.

http://code.google.com/p/gmaps-api-issues/issues/detail?id=2337

...

[William]

FWIW it seems that the latest development version 3.1.7b has fixed the
problem reported by Michael Short:
http://www.william-map.com/20100718/1/test.htm?1

but there's still some remaining issue with the original problem
reported by Kepesk:
http://www.william-map.com/20100718/1/test.htm?0

...

[Ben Appleton]

I have just verified: http://www.william-map.com/20100718/1/test.htm?0 has been fixed internally.  The fix should be released this week.

Thanks

Ben

[William]

On Jul 20, 4:38 pm, Ben Appleton <apple...@google.com> wrote:
>
> I have just verified:
> http://www.william-map.com/20100718/1/test.htm?0
> has been fixed internally.  
> The fix should be released this week.
>

sorry Ben I don't quite understand what "fixed internally" means, when
the issue has been marked as Fixed in 3.1, and noted in the changelog
for 22/07/2010, but I still see a problem with this example?

...

[Ben Appleton]

There is some confusion because you added the
http://www.william-map.com/20100718/1/test.htm?0 test case after the
bug had been marked "FixedNotReleased". With the subsequent release
Luke updated the bug status to "Fixed".

We have also fixed http://www.william-map.com/20100718/1/test.htm?0,
but that was a later change which is due for the next release. If
you'd like, you can reopen the issue and we'll reverify your
additional case at the next release.

Cheers
Ben

[William]

thanks for the further explanation Ben, I understand that now. My aim
is to help ensure that any clipping problems with polys are fixed
before 3.1 is frozen, because that's the version I am targetting for
migration of v2 to v3.

...

[Ben Appleton]

Sure. Thanks for providing the additional test cases.

[Albert Sun]

Ben,

When is the fix for this bug going to be released?

http://www.william-map.com/20100718/1/test.htm?0

I'm seeing that bug in a project I'm working on and which I hope to
release soon.

Thanks,

Albert

On Jul 21, 11:44 pm, Ben Appleton <apple...@google.com> wrote:
> Sure.  Thanks for providing the additional test cases.
>

[William]

On Jul 23, 7:52 am, Albert Sun <Albert....@wsj.com> wrote:
>
> I'm seeing that bug in a project I'm working on ...
>

Hi Albert, do you have any data that can provide a new test case?
I think with more test cases there's a better chance of identifying
all reasons for the bug.

...

[Albert Sun]

Look at http://graphicsweb.wsj.com/documents/MARATHONS2010/info-MARATHONS2010.html

Looking at the San Francisco map, zoom in once towards the Golden Gate
bridge. The path north of a certain point on the bridge disappears.

[William]

On Jul 24, 3:10 am, Albert Sun <Albert....@wsj.com> wrote:
> Look at
> http://graphicsweb.wsj.com/documents/MARATHONS2010/info-MARATHONS2010...

>
> Looking at the San Francisco map, zoom in once towards the Golden Gate
> bridge. The path north of a certain point on the bridge disappears.
>

thanks Albert I can see it disappearing, it's like the description
given in this thread from October last year, where they talked about
"turnaround" roads disappearing:
http://groups.google.com/group/google-maps-js-api-v3/browse_thread/thread/7ade9f8c49fc4041

[William]

On Jul 24, 3:10 am, Albert Sun <Albert....@wsj.com> wrote:
>
> Looking at the San Francisco map, zoom in once towards the Golden Gate
> bridge. The path north of a certain point on the bridge disappears.
>

your map has 3 versions of the marathon path:
1. the full points version,
2. the simplified version
3. the version derived from elevation locations

on loading the path, the map first tries the full points version, and
if less than 320 points, switches to the simplified version.

Then it animates the path using the version derived from elevations.

After animation the path remains the one derived from elevation
locations, and it's this path that has the crossover.

So as a workaround, I'd suggest retaining the original polyline path
after animation:

function animateLine(line, path) {
function animateStep() {
if (curr+stepsize >= path.length) {
line.setPath(originalPath);
}
}
var originalPath = line.getPath();
}

...

[Albert Sun]

Thanks William,

That is quite perceptive.

Albert

[William]

On Jul 23, 7:52 am, Albert Sun <Albert....@wsj.com> wrote:
>
> When is the fix for this bug going to be released?
>
> http://www.william-map.com/20100718/1/test.htm?0
>

looks like it's fixed in the latest "3.1.8a" version that's available
now:

http://www.william-map.com/20100724/1/test.htm?2

...

[William]

On Jul 17, 2:39 am, bratliff <bratl...@umich.edu> wrote:
> If the "off-tile" vertex
> is too distant from its "on-tile" neighbor, it causes strange behavior
> which is different in CANVAS & SVG.
>

I've done some experiments with SVG/VML and it seems to me that Opera
has the smallest range before a point is "too distant" from another,
with maximum coordinates of 32768. The following example has a line
from (0,0) to (32769,32769) and it should extend beyond the bordering
box by 1 pixel, which it does on all browsers except Opera:

http://www.william-map.com/20100730/1/limits.htm

A similar test for IE produced a maximum coordinate of around 179000,
but in the first instance I'd implement SVG/VML clipping to ensure no
coordinates were greater than 32768.

However for CANVAS elements I guess they need to be much smaller for
performance, because they are a fully rendered bitmap and large CANVAS
elements would require a lot of memory.

...

[bratliff]

Thanks William,

I believe I have fixed it. Your test case triggered several errors.

Please grab a fresh copy of:

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

If it still fails, please let me know.

Berry

[William]

On Aug 7, 12:15 am, bratliff <bratl...@umich.edu> wrote:
> Please grab a fresh copy of:
>
>    http://www.polylib.us/polycluster.js
>
> If it still fails, please let me know.
>

One slight issue with IE8, it seems a line isn't drawn with full width
at certain zooms, see the vertical line in this map:

http://www.william-map.com/20100807/1/test.htm

also I noticed in Opera 10.6 (Windows XP) if you zoom in, the polyline
disappears, but if you load Dragonfly and reload the page, it displays
when you zoom in. Not sure if this problem can be replicated!

...

[bratliff]

On Aug 6, 10:45 pm, William <william.g...@gmail.com> wrote:
> One slight issue with IE8, it seems a line isn't drawn with full width
> at certain zooms, see the vertical line in this map:
>
> http://www.william-map.com/20100807/1/test.htm
>
> also I noticed in Opera 10.6 (Windows XP) if you zoom in, the polyline
> disappears, but if you load Dragonfly and reload the page, it displays
> when you zoom in. Not sure if this problem can be replicated!

Thanks William,

A son of a friend of mine is a Microsoft employee. He has
acknowledged several VML bugs in IE8 fixed in IE9 for future release.
If it is just cosmetic, I am not too concerned. Does it work in IE7 ?

Sorry, I do not have Opera 10.6 installed. I am using CANVAS in
Opera. The API uses SVG. Perhaps I ought to switch. Ben has
mentioned some clipping issues specific to Opera.

I assume you are aware you can use a simple array of {x:,y:} objects
in PolyCluster without the use of "new LatLng()" objects. For very
large polys, it makes a significant performance difference.

[William]

On Aug 10, 12:40 am, bratliff <bratl...@umich.edu> wrote:
> A son of a friend of mine is a Microsoft employee.  He has
> acknowledged several VML bugs in IE8 fixed in IE9 for future release.
> If it is just cosmetic, I am not too concerned.  Does it work in IE7 ?
>

yeah I just made a simple test case and it's a VML bug in IE6, IE7 and
IE8. I haven't checked the IE9 preview yet.

Here's a 3 point polyline with the problem:
http://www.william-map.com/20100810/1/problem.htm

You can see something strange at the top, so if you make the line 75pt
wide, you can see strange loops:
http://www.william-map.com/20100810/1/exaggerated.htm

Which suggests the problem relates to the default "round" line capping
when there's a 180 degree change in heading:
http://www.william-map.com/20100810/1/fix_miter.htm

To workaround this you can put another vertex so at the turnaround
there's two angles less than 180:
http://www.william-map.com/20100810/1/workaround_round.htm

Here's a demonstration using the V3 polyline:
http://www.william-map.com/20100810/1/test.htm

...

[bratliff]

Thanks again for your test cases. "Backtracking" confuses the "on-the-
fly" point reduction algorithm. The "before" / "after" slope
comparison is equal which causes the intermediate vertex to be
dropped. I will have to compensate for it.

[William]

On Aug 10, 10:50 pm, bratliff <bratl...@umich.edu> wrote:
>
> Thanks again for your test cases.  "Backtracking" confuses the "on-the-
> fly" point reduction algorithm.  The "before" / "after" slope
> comparison is equal which causes the intermediate vertex to be
> dropped.  I will have to compensate for it.
>

Also because these test cases are in pure VML, it's a problem that
affects both google.maps.Polyline and polycluster when backtracking.
Like you say it's most likely to happen during on-the-fly point
reduction, where the detail of a turnaround is reduced to a single
vertex (or as you said it might be removed altogether if the algorithm
isn't correct).

However regardless of on-the-fly point reduction, the original data
might also contain these backtracks and I think the only workaround is
to introduce an extra artificial point at the turnaround point when
rendering using VML.

...

[Ben Appleton]

Thanks for the demo, we'll look into it.  Please start a new issue if you'd like to track progress on this particular issue.

 

Ben

[bratliff]

On Aug 11, 1:46 am, William <william.g...@gmail.com> wrote:
> Also because these test cases are in pure VML, it's a problem that
> affects both google.maps.Polyline and polycluster when backtracking.
> Like you say it's most likely to happen during on-the-fly point
> reduction, where the detail of a turnaround is reduced to a single
> vertex (or as you said it might be removed altogether if the algorithm
> isn't correct).

I have fixed it to deal with other cases in which the area of the
triangle is zero but the vertex is valid.

Please grab a fresh copy of:

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

> However regardless of on-the-fly point reduction, the original data
> might also contain these backtracks and I think the only workaround is
> to introduce an extra artificial point at the turnaround point when
> rendering using VML.

PolyCluster uses a slightly different set of VML tags:

<v:shape
coordorigin=
coordsize=
filled='True'/'False'
stroked='True'/'False'
path=
>

<v:fill
color=
opacity=
>

<v:stroke
color=
opacity=
>

I do not know whether the results are similar because I cannot test
VML on my PC.

[William]

On Aug 11, 11:05 pm, bratliff <bratl...@umich.edu> wrote:
> I have fixed it to deal with other cases in which the area of the
> triangle is zero but the vertex is valid.
>
> Please grab a fresh copy of:
>
>    http://www.polylib.us/polycluster.js
>

Sure I'll continue doing IE testing and if I see anything I'll let you
know. Also next week I will try to set up IE9 prerelease on Win7
virtual machine and see if that issue is fixed.

...