Directions how to clear maps?

[maciekS]

Hi

How to clear maps (directions polyline) from Map?

I use code from official API doc.
http://code.google.com/intl/pl/apis/maps/documentation/v3/reference.html#DirectionsRenderer

[Esa]

I don't see access to directions polylines or markers at the moment.
However I understood they are coming by comment of Susannah in this
thread:
http://groups.google.com/group/google-maps-js-api-v3/browse_thread/thread/ee7ce7cf8a872268

Meanwhile we can clear the polylines by brute DOM destruction:

function clearPolylines(){
var pane = document.getElementById("pane_1");
while(pane && pane.firstChild){
pane.removeChild(pane.firstChild);
}
}

For markers you have to do the same for "pane_5" and also for "pane_3"
to clear "shadows".

By the way, shadows of the direction markers are actually second
marker icon images.

[bratliff]

On Nov 4, 4:32 pm, Esa <esa.ilm...@gmail.com> wrote:
> I don't see access to directions polylines or markers at the moment.
> However I understood they are coming by comment of Susannah in this

> thread:http://groups.google.com/group/google-maps-js-api-v3/browse_thread/th...

>
> Meanwhile we can clear the polylines by brute DOM destruction:
>
> function clearPolylines(){
> var pane = document.getElementById("pane_1");
> while(pane && pane.firstChild){
> pane.removeChild(pane.firstChild);
> }
>
> }
>
> For markers you have to do the same for "pane_5" and also for "pane_3"
> to clear "shadows".
>
> By the way, shadows of the direction markers are actually second
> marker icon images.

Very bad idea. It will cause memory leaks. Also, "pane_?" may not
unique if you have multiple maps. Shame on you Google.

[Esa]

On Nov 4, 6:44 pm, bratliff <bratl...@umich.edu> wrote:

> Very bad idea.  It will cause memory leaks.  Also, "pane_?" may not
> unique if you have multiple maps.  Shame on you Google.

I agree. You could minimize the memory leaks by first running a
directions call from a known place A to place A. That will make API to
clear internal references to the long polyline points. Even more
hacky;)

[bratliff]

FWIW, other memory leaks exist. I do not believe Google cleans up old
dynamically generated <script> DOM elements. Function closures also
remain forever. I prefer to use a static function with optional
arguments passed in a "this" variable. A single function can service
several routes.

[bratliff]

whatever.setMap(null) will clear the poly.

I have built an example:

www.polyarc.us/colorado

[Esa]

On Nov 5, 12:16 am, bratliff <bratl...@umich.edu> wrote:
> whatever.setMap(null) will clear the poly.

Thanks Bratliff. I apologize that I was presenting some desperate hack
when there is a clearly documented method for the purpose.

@ maciekS: You can clear directions polyline and the markers by .setMap
(null) method of the DirectionsRenderer().

Documentation says about .setMap():
"This method specifies the map on which directions will be rendered.
Pass null to remove the directions from the map."

Still we don't have a known method to access polyline or markers
separately.

[Michael Ring]

To access markers separately, for instance, create an array of markers:

markers = [];

Every time you add a marker to the map, add it to the array:

markers.push(marker);

To clear a particular marker, use:

markers[i].setMap(null);

[Esa]

On Nov 5, 1:47 am, "Michael Ring" <michaeljr...@gmail.com> wrote:

> Every time you add a marker to the map, add it to the array:

Right, but I meant markers and polylines created and added by
DirectionsRenderer().

Nevermind, I just decided that the only way to have full access to
those is to write a custom directionsRenderer. I think Google people
also encourage that by splitting directions to separate service and
renderer objects.

@ Bratliff. You probably have something similar in mind because I can
see that you already decode the polylines. I was going to borrow the
decoder from Google Polyline Utility
http://code.google.com/apis/maps/documentation/polylineutility.html
Your decoder looks more sophisticated. Is it explained anywhere.

[bratliff]

On Nov 5, 12:33 am, Esa <esa.ilm...@gmail.com> wrote:
> On Nov 5, 1:47 am, "Michael Ring" <michaeljr...@gmail.com> wrote:
>
> > Every time you add a marker to the map, add it to the array:
>
> Right, but I meant markers and polylines created and added by
> DirectionsRenderer().
>
> Nevermind, I just decided that the only way to have full access to
> those is to write a custom directionsRenderer. I think Google people
> also encourage that by splitting directions to separate service and
> renderer objects.
>
> @ Bratliff. You probably have something similar in mind because I can
> see that you already decode the polylines. I was going to borrow the

> decoder from Google Polyline Utilityhttp://code.google.com/apis/maps/documentation/polylineutility.html

> Your decoder looks more sophisticated. Is it explained anywhere.

Clearly, a "backdoor" "fromEncoded" method does exist but I believe
Google has made the right decision to not release it. It is a
horrible kludge which Google would have had to support indefinitely.

http://groups.google.com/group/google-maps-js-api-v3/browse_thread/thread/140a06c9a7441c84/8bb2955c99dc704b

You are welcome to use the following poly decoder:

www.polyarc.us/polyextract.js

Unfortunately, every point must be passed into "new google.maps.LatLng
()" which adds a lot overhead. Google could offer an alternate call
using an array of {x:,y:} objects.

I might do something with PolyCluster which is designed for multiple
polys without multiple OverlayView instances.

[Esa]

Thanks, superb.

>
> Unfortunately, every point must be passed into "new google.maps.LatLng
> ()" which adds a lot overhead.  Google could offer an alternate call
> using an array of {x:,y:} objects.
>

I agree. v2 accepts GPoint arrays for polylines.

I will modify Douglas-Peucker script to use {x:,y:} objects instead of
lat() and lng() function calls, and convert points to LatLng() only
for setting Polyline path.

[bratliff]

Why bother with Douglas-Peuycker ? The direction service already
provides very clean polys. The "levels" string is just worthless
junk.

The API already does point reduction based on zoom level. I believe
PolyCluster demonstrates the futility of point reduction on very clean
polys. Also, assymetrical point reduction prevents adjacent polys
sharing a common boundary from fitting together snuggly.

I do drop redundant pixels but I make no effort to eliminate the very
few points falling on the line connecting their immediate neighbors.
I am sure both CANVAS & SVG do their own point reduction at compiled C+
+ speed rather than at interpreted JavaScript speed.

[Esa]

On Nov 5, 8:40 pm, bratliff <bratl...@umich.edu> wrote:

> Why bother with Douglas-Peuycker ?  The direction service already
> provides very clean polys.  

Yes they do, but I have an idea to control the number of vertices.

> The "levels" string is just worthless junk.

True.

>
> The API already does point reduction based on zoom level.  

You mean that Polyline class includes a point reduction. Actually I
presented that theory when polyline was introduced but I never proved
that. Now my theory (yours too) was shut down when encoded polyline
level strings were put on line. Would they download 'levels' strings
if there was a built in point reduction.

[Ben Appleton]

Yes: we have client point reduction, but in the slowest browsers this accounts for 40% of the time to first render a polyline.  By reusing the server-computed level string internally we can save some time on those browsers.

 

[bratliff]

On Nov 6, 2:29 am, Ben Appleton <apple...@google.com> wrote:

> Yes: we have client point reduction, but in the slowest browsers this
> accounts for 40% of the time to first render a polyline. By reusing the
> server-computed level string internally we can save some time on those
> browsers.

In my tests, the overhead to find a few points along the interpolation
line exceeded the savings from a slightly reduced number of calls to
"lineTo / moveTo". Duplicate pixel elimination is beneficial. It is
also adds a trivial amount of overhead. A much greater performance
improvement can be achieved by combining "off-tile" pixels to reduce
the number of calls to "lineTo / moveTo". I never make more than
eight such calls per tile.

[bratliff]

On Nov 5, 5:06 pm, Esa <esa.ilm...@gmail.com> wrote:

Hi Esa,

I have updated:

www.polyarc.us/polyextract.js

It is nothing significant, just trimmed a bit of fat.