maps.huge.info

The Douglas-Peucker line simplification algorithm has been around for more than 25 years, yet is still is the best method of polygon and line simplification available.

We are proud to announce the release of Open Source code for this routine written in Perl. This has been done before, but not a port that doesn't require any additional modules. This code should run on just about any version of Perl without modification.

See Douglas-Peucker for the code and a sample driver program.

During the Google Developer Day 2007 in San Jose (and around the world) a very exciting and profitable announcement was made regarding the optional addition of location based advertising in the map viewport. These ads will appear as pseudo (my word) markers and when clicked will bring up an add that if clicked on, will generate revenue for the AdSense partner.

These ads are 100% optional and can be omitted simply by not acting. Once they are activated with a couple of Javascript lines, they will appear on the map but not before. All the fear of ads appearing on maps without any choice seems to be unfounded, although this hasn't been discussed much recently.

You can get a taste of how location based embedded ads will work by going to maps.google.com, try this url:

maps.google.com

Check out the BART stations, you'll see that when you hover over them your mouse changes to indicate a hot spot, clicking on it brings up an infowindow just like a marker. In fact, it isn't a marker but a "pseudo" marker that causes a round trip request to the Google server to get the meta data for the infowindow. Very clever, very efficient,
very fast.

The rollout of this feature will be sometime in the month of June.

I've been asked a number of times how to construct a radius search in miles for point coordinates. This is a pretty simple thing to do once it is realized that true circles are hard to deal with using latitude and longitude coordinates. I've found the best method is not to use a circle and a radius but instead construct a circular polygon using a haversine formula to compute the verticies of the polygon from a center point. Here's an example using Perl to compute such a polygon for a radius of 20 miles with a zip code of 38654 as the center point (centroid courtesy of Google Map API Geocoder).

#!/usr/bin/perl -w
use strict ;

my $radius = 20 ;
my $clat = 34.918 ;
my $clng = -89.8215 ;
my $PI = 3.141593 ;
my $d2r = $PI/180 ;
my $r2d = 180/$PI ;
my $lat = ($radius/3963) * $r2d ;
my $lng = $lat/cos($clat * $d2r);
my @points = ( ) ;
my $i = 0 ;
my $x = '' ;
my $y = '' ;

for ($i = 0 ; $i < 13 ; $i++)
{
$y = sprintf("%0.6f",$clng + ($lng * cos($PI * ($i/6)))) ;
$x = sprintf("%0.6f",$clat + ($lat * sin($PI * ($i/6)))) ;
push( @points, [$x,$y] ) ;
}

foreach $x ( @points )
{
print "$$x[0],$$x[1]\n" ;
}

Results of this calculation:

34.918000,-89.468862
35.062577,-89.516106
35.168414,-89.645181
35.207154,-89.821500
35.168414,-89.997819
35.062577,-90.126894
34.918000,-90.174138
34.773423,-90.126894
34.667586,-89.997819
34.628846,-89.821500
34.667586,-89.645181
34.773423,-89.516106
34.918000,-89.468862

This is how it looks on a map:

The same basic code in Javascript can be found in this example page:

dragcircle2.htm

Once the polygon has been constructed, the search method depends on the database being used. I prefer Postgres or PostGIS, both of which have exceptional spatial functions built in.

Due to excessive demand and limited supply, we are forced to raise our hourly rate from $125/hour to $175/hour effective 09/26/2007. Customers with existing contracts will continue to be charged $125/hour for the duration of their contracts, new customers with outstanding quotes will be honored at the original rate. New customers without a quote will be charged at the new rate.

We take this very seriously and wish this wasn't necessary, but the laws of supply and demand must be satisfied. Thank you for your cooperation.

We've created a Google Polygon Encoding Algorithm in Perl released under GPL. This routine was ported from Mark McClure's work located at: http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/

There is a slight difference to our routine, the choices as to which points to drop at certain zooms was made using the Douglas-Peucker routine instead of the distance method employed by the original routine. This allows the polygon to maintain its shape better at the lower zooms plus allows specifying the tolerance in meters instead of radians. The performance of our routine is less due to the additional math from the Haversine formula embedded in our D-P, but this is offset by the easier to understand code that was produced.

We are open to suggestions on how this routine can be improved, so please send any suggestions our way.

USNaviguide_Google_Encode.pm - A Perl module

This Google Maps API demo is a modification of Pam's example that adds a few things such as being movable and the image is created on the fly based on the SW and NE corner coordinates.

On the server, the coordinates are transformed into pixels and the image is generated. The image contains the size in pixels and a square to indicate if there is any stretching of the image.

The purpose of this demo is as a starting point for generating an image with POI's, polygons and other information that can substitute for a tile overlay. It's much easier to implement and also can yield real time results if the underlying data is subject to change.

http://maps.huge.info/goverlay.htm

Here's the Perl module that calculates a "relative pixel:" (a modification of Ian Dee's PHP script)

# Calculate Relative Pixel...

To execute:

my @d = &RelPix( <latitude>,<longitude>,<zoom> ) ;

return (@d) ;
}


We've added a new Perl module that calculates the relative pixel location on the "Google World" for the Google Maps API. This module will return a pixel coordinate when passed a latitude, longitude and zoom factor that can be used to correctly locate objects in an image used as a GGroundOverlay object.

This module is based on Ian Dee's excellent work to calculate tile names for custom tile layers. There are some differences, mostly in how the calculation is performed and rounding, but essentially, it is the same calculation found in Google's Javascript API code. An example has been added to demonstrate this routine in action: goverlay.htm

USNaviguide_Google_RelPix.pm - A Perl Module

USNaviguide has just released a new Perl module (USNaviguide_Google_Tiles.pm) that calculates just about everything you'd want to know about tiles including:

Tile name for a coordinate (lat,lng)
Tile name for a pixel location (x,y)
Tiles for a bounding box of coordinates and zoom
Bounding box for a tile in coordinates
Bounding box for a tile in pixel locations
Coordinates to pixel
Pixel to coordinates
and a bunch of other stuff...

GPL

http://www.usnaviguide.com/google-tiles.htm

USNaviguide has just released a new Javascript class that works like GGroundOverlay in the Google Maps API except it doesn't attempt to stretch the overlaid image into the Mercator projection. This results in faster response and more predicable results.

Here's a demo of this class in action:

http://www.usnaviguide.com/projectedoverlay.htm

John Coryat presented a workshop at the Googleplex in Mountain View, CA on the 27th of February called "Creating Custom Maps." This workshop covers the basics on how to go from an image or data to creating a custom image overlay in a Google Maps API based application.

Please see the presentation in the form of PDF at:

http://www.usnaviguide.com/ws-2008-02/presentation.pdf

The "Creating Custom Maps" presentation at the Googleplex workshop on the 27th of February is now online at YouTube