GoogleMaps changed format

CPAN::Forum

Thread

WebService-GoogleMaps [search.cpan.org] [Kobes search] [View and report bugs] [Ratings 5.0

5.0

(1) ]

[AnnoCPAN] [CPAN Tests results] [CPANTS]

Posted on Sat Jun 18 20:38:18 2005 by lunatic

GoogleMaps changed format

Hello,

I noticed that just in the last day or few that Google has changed their mapping formula (I believe they have increased the number of zoom levels, and now you can zoom-out to view the entire globe among other changes).

All new request for map pieces (as far as I can tell) don't work :-) I get maps full of water!

I've been looking around, only started to investigate what the changes are and what modifications might be necessary to make the module work with the new formatting. Anyone else interested? Karl, have you noticed this also and/or looked into how things have changed?

The module is great -- I use it internally for visualizing where member signups are coming on a community web service project I'm working on.

Also -- I've added some custom methods to the module to allow me to generate population-density-type maps. It'll draw heat-graph style circles on top of a map (where red thru yellow indicates more "people" in a given area). Anyone else interested? I can post the code.

Cheers,

-Michael Burns

Direct Responses: 632 | Write a response

Posted on Sat Jun 18 21:45:48 2005 by lunatic in response to 631

Re: GoogleMaps changed format

Hi,

I have an interim update on what seems to be changed with the Google maps.

First, there appear to be two possible acceptable version strings. One, that is otherwise compatible with the current GoogleMaps.pm, is to change line 57 from:

$self->{gm_version} ||= ".1";

$self->{gm_version} ||= ".3";

This change restores the GoogleMaps.pm to functioning properly.

HOWEVER...

It seems they are also accepting (and requiring, if you want world-wide maps) a new version identifier: "w2.4" ("w" for "World" perhaps?). The tile sizes have changed from 128x128 to 256x256, zoom range has expanded from 0-14 to 0-17, and additionally, the offsets for tile x=0,y=0 have changed (it seems to start 0,0 at long/lat at the dateline,north pole).

See for example, the whole world, or zoom in one level to get an idea of how the offsets have changed.

I'm currently working on changing the offset code to handle the new positions, otherwise the rest of the module I think should work fine with a few tweaks.

I'll post a patch file once it seems to be working.

Anyone else on this track?

Cheers,

--Michael Burns
Cosbit Technologies

Direct Responses: 634 | Write a response

Posted on Sat Jun 18 22:38:22 2005 by karl in response to 632

Re: GoogleMaps changed format

Hi Michael -

I guess this module has become pretty stale and needs to be freshened up a bit. Thanks for your help in determining what changes are necessary! I'll try to release a working version soon.

--Karl.

Direct Responses: 645 | Write a response

Posted on Wed Jun 22 02:59:46 2005 by lunatic in response to 634

Re: GoogleMaps changed format

Hi Karl,

My partner, Hussein Patni, and I have been hard at work trying to digest the new Google math!

The relevant Javascript code seems to be here:

http://maps.google.com/mapfiles/maps.8.xslt.js

(actually, there are a couple variations based on your browser, the appropriate file being chosen after a browser detect function runs. But, all the mapping math seems to be consistent (as makes sense) regardless of the exact Javascript file, so that one should work as well as any for "inspiration")

We determined that there is no scaling whatever on the longitude axis. There is a new style of scaling on the latitude axis, likely to handle polar-region "squishing" (since I work in Canada, Calgary specifically, I noticed the northern lats were way off right away ... the maps do seem to be nicer-looking than last generation).

Some rough pseudo-code for the new latitude scaling function looks like:

my $lat = shift; # contains desired latitude # scaling factor my $e = sin( $lat * pi/180 ); # bounds control if ($e > 0.9999) { $e = 0.9999; } elsif ($e < 0.9999) { $e = -0.9999; } my $bitmap_origin_y = GOOGLEMAPS_TILE_RES_Y * (0x20000 >> $zoom) / 2; my $pix_per_lon_rad = GOOGLEMAPS_TILE_RES_Y * (0x20000 >> $zoom) / (2 * pi); $ty = POSIX::floor( $bitmap_origin_y + 0.5 * log( (1+$e) / (1-$e) ) * -$pix_per_lon_rad ); $ty /= GOOGLEMAPS_TILE_RES_Y; # $ty now contains the tile-float-y value for the given latitude

At initial glance, this plus changing a few constants in the package to handle the newer tile size and zoom levels seems to be producing accurate results, at least for my datasets.

I'm just about to try it with non-North American lat/long points to verify that it works elsewhere on the globe (as it *should*).

Once I test it a bit more and clean up the code I've been mangling (!!), I'll submit a patch and we can get an updated version of this on CPAN that works with the global maps!!

Cheers,

-Michael Burns
Cosbit Technologies

Write a response

Service launched on 2nd of February 2005.
Comments, and other submissions on CPAN Forum are Copyright 2005-2007, their respective owners.
Site maintainer is not responsible for content. Privacy Policy

Maintained and hosted by Gabor Szabo at Perl Training Israel

See also World Wide Perl Training