2010/03/03: New Release
Luke (Google Employee)
We've recently pushed out a new version of the API. See the list of
changes below:
http://code.google.com/p/gmaps-api-issues/wiki/JavascriptMapsAPIv3Changelog
Changes Issues:
Issue 2136: MarkerImage properties obfuscated.
Issue 1801: zIndex can now be specified on polygon and polylines.
Noticable changes:
- Map jump-jump bug fixed.
- Zooming twice in succession has been improved.
- Marker drag event .latLng is no longer obfuscated.
Please test and provide feedback.
Thanks!
Luke
Luke (Google Employee)
Sorry for any confusion.
Luke
On Mar 3, 11:43 am, "Luke (Google Employee)" <lu...@google.com> wrote:
> Hey everyone!
>
> We've recently pushed out a new version of the API. See the list of
> changes below:http://code.google.com/p/gmaps-api-issues/wiki/JavascriptMapsAPIv3Cha...
bratliff
> Hey everyone!
>
> We've recently pushed out a new version of the API. See the list of
>
> Changes Issues:
> Issue 2136: MarkerImage properties obfuscated.
> Issue 1801: zIndex can now be specified on polygon and polylines.
>
> Noticable changes:
> - Map jump-jump bug fixed.
> - Zooming twice in succession has been improved.
> - Marker drag event .latLng is no longer obfuscated.
>
> Please test and provide feedback.
>
> Thanks!
>
> Luke
For V 3.0.1:
I am seeing "Sorry we have no imagery here" much less frequently but I
am still seeing it on a few stubborn tiles. Also, if I do consecutive
zooms without waiting for each to complete, the in transit tiles are
lost forever if I return to the intermediate zoom levels.
You guys really have to use a "mine sweeper" on a long fuse to retry
lazy tiles. It may be a rare event but it does occur. If everything
is intact, the "watch dog" has nothing to do. If anything is missing,
it is able to reissue the request.
this.src=this.src;
will do it. Perhaps alternating "mt0.google.com" with
"mt1.google.com" will circumvent a slow path.
Also, could you add something to the API to reload all tiles even
though you are convinced everything is already loaded correctly.
Switching zoom levels no longer does it. Once the API erroneously
believes a tile is loaded, I cannot force it to be reloaded. Clearing
the cache wipes out everything else.
Yanko Hernández
> I am seeing "Sorry we have no imagery here" much less frequently but I
> am still seeing it on a few stubborn tiles. Also, if I do consecutive
> zooms without waiting for each to complete, the in transit tiles are
> lost forever if I return to the intermediate zoom levels.
> ...
bratliff
dial-up connection. Preferrably not one with an ISP located just a
few miles away. A five minute cursory test is not enough. Clear
cache. Do a lot of dragging, panning , zooming & map type switching.
You will see lost tiles. Once a tile is lost the API will never
attempt to load it again. It is easy to detect. The DOM will contain
"transparent.png" rather than real images. If at least one valid tile
exists for a particular zoom level currently in view, you ought to
assume the other tiles are just "lazy" rather than missing.
Also, please provide a mechanism to revert to a known stable version.
I am not asking for access to every prior version just one good one.
Chris Apolzon
--
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.
bratliff
>
> We've recently pushed out a new version of the API. See the list of
>
> Changes Issues:
> Issue 2136: MarkerImage properties obfuscated.
> Issue 1801: zIndex can now be specified on polygon and polylines.
>
> Noticable changes:
> - Map jump-jump bug fixed.
> - Zooming twice in succession has been improved.
> - Marker drag event .latLng is no longer obfuscated.
>
> Please test and provide feedback.
>
> Thanks!
>
> Luke
Please roll back to V3.29. V3.0.1 is completely unusable. I cannot
drag or pan or zoom without "Sorry, we have no imagery here". I have
to wait for every tile to arrive. Some tiles never arrive.
Ben Appleton
bratliff
> I have attempted to replicate the issue you report in Google Maps API
> v3.0.1. I am using the Fiddler HTTP proxy's "Rules > Performance > Simulate
> modem speeds" which applies a bandwidth cap of 26.7 kbps to simulate a
> dialup modem. As a worst-case I viewed the hybrid map type (which loads 2
> images for each tile) and my map is 1400x800 pixels. I am using Firefox 3.6
> on Windows XP. After panning around a few dozen times I have seen 2 missing
> tiles out of more than 1000.
>
> Is this a reasonable simulation of your setup? Specifically, do you know
> the bandwidth of your internet connection during the periods when you see
> missing tiles? v3.0.1 fetches 8-12 images at a time and gives up on an
> image after 2 minutes.
Unless the view is exactly on a cusp, the presence of some tiles is a
good indication other tiles also exist. At the end of a reasonable
waiting perriod, can you retry the request ? Perhaps you could
alternate between "mt0.google.com" & "mt1.google.com" to circumvent a
slow path.
But what really frustrates me is the inability to force the API to
reload lost tiles. Once the API has decided a tile is missing,
nothing can be done to convince it to try again. Every zoom change or
map type change ought to try to refill the voids.
I am planning to build a "tile sweeper" unless something changes
quickly. It will clean up whatever missing tiles it might encounter.
It will not be in strict compliance with the TOS. If the API fails to
load good tiles, I do not know what else to do.
Connection speed is not the only influencing factor. In your office,
you may be just two or three router hops away from your tile server.
I am at least fifteen hops away. If any one of the routers is having
a bad day, a tile might not arrive in two minutes. Try again at least
once. Provide a way to force the API to retry even if you are
absolutely sure no such tile exists.
bratliff
change or map type change can trigger a couple dozen tile requests.
The browser will limit the number in flight at one time. The API
cannot control the time at which a request is dispatched once it is
submitted. A batch of twenty to thirty tiles could easily exceed two
minutes. It is OK to prioritize tiles if a preempted tile can be
fetched later. The API does not reload a discarded tile if it returns
to view. Once it is considered missing, it is lost forever.
Ben Appleton
A quick follow up. Two minutes is really not enough. Each zoom
change or map type change can trigger a couple dozen tile requests.
The browser will limit the number in flight at one time. The API
cannot control the time at which a request is dispatched once it is
submitted. A batch of twenty to thirty tiles could easily exceed two
minutes. It is OK to prioritize tiles if a preempted tile can be
fetched later.
- The bandwidth could be so low that loading 12 tiles x 25kB = 300kB takes more than 2 minutes.
- The internet connection could drop out temporarily.
- The page could be making many other HTTP requests, blocking our tile requests.
The API does not reload a discarded tile if it returns
to view. Once it is considered missing, it is lost forever.
bratliff
> We now queue image requests in JS, only fetching at most 12 images at a
> time. This allows to cancel requests if a tile falls out of view before the
> request has been forwarded to the browser, which reduces latency for a quick
> sequence of zooms. To recover from stalled tiles we abandon a tile fetch
> after 2 minutes.
>
> This can still fail in a few ways:
>
> - The bandwidth could be so low that loading 12 tiles x 25kB = 300kB
> takes more than 2 minutes.
> - The internet connection could drop out temporarily.
> - The page could be making many other HTTP requests, blocking our tile
> requests.
>
> I appreciate your feedback; we haven't finished optimizing tile loading yet.
>
> The API does not reload a discarded tile if it returns
But you agree the API should try again if the abandoned tile ever
returns to view - right ?
Please make at least one attempt to resuscitate a stubborn tile.
Please consider the tile to be just lazy if other tiles in the same
column or in the same row have been loaded successfully.
Please attempt to fill any missing tile voids if the user changes zoom
level or changes map type. It it the only way a user can override the
API if the tile is declared missing. It works in V2. It used to work
in V3 (3.29). A user will not repeatedly change zoom levels or change
map types if the tiles are indeed missing. I believe Einstein defined
an idiot to be a person who repeats the same experiment expecting a
different result.
I used to be able to do several consecutive zooms without waiting for
completion, pour myself a cup of coffee, return five minutes later to
find everything loaded. If an occasional tile failed to load,
returning to the same zoom level caused it to be reloaded.
Please provide a way to access 3.29 or some other last known good
version.
Thanks very much.
bratliff
> On Mar 8, 5:50 am, Ben Appleton <apple...@google.com> wrote:
>
>
>
> > We now queue image requests in JS, only fetching at most 12 images at a
> > time. This allows to cancel requests if a tile falls out of view before the
> > request has been forwarded to the browser, which reduces latency for a quick
> > sequence of zooms. To recover from stalled tiles we abandon a tile fetch
> > after 2 minutes.
>
> > This can still fail in a few ways:
>
> > - The bandwidth could be so low that loading 12 tiles x 25kB = 300kB
> > takes more than 2 minutes.
> > - The internet connection could drop out temporarily.
> > - The page could be making many other HTTP requests, blocking our tile
> > requests.
>
> > I appreciate your feedback; we haven't finished optimizing tile loading yet.
>
> > The API does not reload a discarded tile if it returns
I am experiencing approximately 10% to 15% failure rate. I wonder if
my ISP is throttling my requests. Perhaps HTML & JS files receive
priority over JPEG & PNG files. Perhaps too many requests to the same
domain are demoted to lower priority. I agree dial-up is a relic of
the past. I have learned to live with slowness but not
unreliability. For now, I am forced to use V2.
Ben Appleton
--