Technical Archives

January 18, 2007

Douglas-Peucker Algorithm in Perl

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.

June 1, 2007

Google Location Based Ads Announced!

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, try this url:

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.

July 7, 2007

Doing a Radius Search - Code

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:


This is how it looks on a map:

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


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.

September 26, 2007

Rate increase announcement

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.

October 8, 2007

Google Polygon Encoding Algorithm in Perl

We've created a Google Polygon Encoding Algorithm in Perl released under GPL. This routine was ported from Mark McClure's work located at:

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. - A Perl module

November 23, 2007

New demo: Resizable/Movable Ground Overlay

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.

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> ) ;

sub RelPix
my $lat = shift ;
my $lng = shift ;
my $zoom = shift ;
my $e = 0 ;
my @d = ( ) ; # 0:x 1:y

my $PI = 3.1415926536 ;
my $bc = 2 * $PI;
my $Wa = $PI / 180;
my $cp = 2 ** ($zoom + 8) ;
my $pixLngDeg = $cp / 360;
my $pixLngRad = $cp / $bc ;
my $bmO = $cp / 2 ;

$d[0] = sprintf("%0.0f", $bmO + $lng * $pixLngDeg ) ;

$e = sin($lat * $Wa) ;

if( $e > 0.99999 )
$e = 0.99999 ;

if( $e < -0.99999 )
$e = -0.99999 ;

$d[1] = sprintf("%0.0f", $bmO + 0.5 * log((1 + $e) / (1 - $e)) * (-1) * $pixLngRad ) ;

return (@d) ;

November 24, 2007

Relative Pixel Location Algorithm in Perl

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 - A Perl Module

February 23, 2008

New Perl Module: Calculate Google Tiles

USNaviguide has just released a new Perl module ( 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...


New Javascript Class: ProjectedOverlay

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:

March 5, 2008

Workshop: Creating Custom Maps

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:

"Creating Custom Maps" on YouTube

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

December 16, 2008

FTP script for TIGER2008 download

By now, many know that the new version of the Tiger shapefiles, TIGER2008 has been released. The directory format of this version is quite complex and very difficult to automate a download. We've already done the hard work, and are making this script available for those who wish to use it.

To execute this script (from a Linux/Unix/Mac) simple key:

ftp < tiger2008-ftp-script.txt

Your ftp program will ask for a password, use your e-mail address. Once the program starts, be prepared to download 40,533 individual zip files with a total space of about 20 gigs. If the script aborts, check what's been downloaded, delete the last file, edit the script to start at that point and restart the process. It will probably take a couple of days to finish.

December 17, 2008

Tiger2007 vs. Tiger2008

Besides a couple of technical changes to the basic shapefiles released in the new Tiger2008 version, a lot more data has been included in Tiger2008 when compared to Tiger2007.

The two most important tables with Tiger are the edges (line segments like roads, rivers, boundaries, etc.) and faces (polygons made from edges). Here's a comparison count between the two versions:

edges 64,830,691
faces 19,814,918

edges 71,204,516
faces 21,576,497

As you can see, there are over 6,000,000 new edges in Tiger2008. That's a huge increase and represents new roads mostly that weren't in previous versions of Tiger.

May 8, 2009

Clarification of Hits Policy

This entry will clarify our policy on how long unused hits remain active.

There is an automatic process that purges any unused hits from our systems after one year.

This is official policy. There are no refunds for any reason.

-John Coryat

August 3, 2009

Permissions for our site content

For those that would like to use images from our website in their own non-commercial projects, please read the following guidelines that Google (link) uses. If your project falls within these guidelines, please e-mail (link) for permission.

Please include your name, location, link to your website, brief description of project and how you plan on using our images.


-John Coryat, President USNaviguide LLC

September 27, 2009

Problems using our Zip Code maps?

We've noticed a large number of errors in our logs in regard to tile servers. There is an issue with the way the tile servers function with proxy access, perhaps this is part of why there are errors.

We have an alternate version of the Zip Code maps that may work better for corporate users who have multiple IP proxy servers pulling tiles:
One Tile Server Version

Another issue is for users that have proxy servers that attempt to cache our content from our tile servers. We have an automated security system that will block IP's that exceed a certain threshold of invalid requests, and once blocked, the site will not appear to those domains. Companies and organizations that have this issue should configure their caching proxies to not cache the following domains:

If you've been blocked by our security system and would like to have the block removed, there is a $100 charge to do so. Please use this link to pay before contacting us:

Blocks will automatically be removed approximately 10 days after the proxy cache situation is corrected for a particular IP.

If you're still seeing tiles that have a contact message, please contact us so we can trouble shoot what's going on.

Contact Us

Note to those that are using IE8: There is a known problem with this browser and it can be addressed by switching on "Compatibility Mode" in the browser settings.

-John Coryat, USNaviguide LLC ( and

December 20, 2009

Cheap eyeglasses (not spam!)

On a whim, I thought I'd try ordering a pair of $8 glasses from an online optical outlet. After all, $8 is hardly a large outlay and I've been paying over $100 for each pair I've had for my entire lifetime.

Was I in for a surprise! I went to - home of the $8 glasses, ordered a pair from my prescription and they were perfect! The only difference between ordering online and in person from a local optical outlet was the choice of frames (more online) and the price.

Ok, the $8 aren't really $8, they're $12.95 with shipping. On the other hand, you can order 2 pairs for $16 plus the same $4.95 shipping.

Here's the hard part. You need to know your "PD" or Pupillary Distance. That's the measurement in millimeters between your pupils. Normally, this measurement is done by the optician who fits your glasses but it can also be done by your regular eye doctor if you ask them to do it. Next time you're in for an exam, ask! Also ask for it to be written on your prescription.

Once you have your PD, it's a snap to order your glasses online. There is one other drawback. It takes about two weeks to receive your new glasses. With a local optician, you can get them in half the time, but unless you have insurance paying the bill, it's going to cost you a bunch for that extra week.

I'm all for supporting the local economy and all, but these opticians take a huge cut. I'm guessing they pay about $8 for your single vision frames and lenses, so the rest is pure profit. It does cost a lot to keep an office, the lights on, etc., but enough is enough. I'm tired of paying too much for some plastic and a few metal bits. Ordering online makes sense to me.

If you feel timid about ordering a medical device online, get your next pair from the optician, get your PD and prescription and try one of these online dispensaries for an extra pair. You only have $12.95 to lose and having an extra cheap pair of glasses around might be a good thing, don't you think?

Android Market App Movement

I've been monitoring the Android market "News & Weather" category since we published our "Radar Now!" app and have noticed some interesting behavior in how the market moves apps to the top of the popularity tab. Most apps, like "Radar Now!" experience slow and steady growth, or none at all. Other apps zoom from nowhere to the front of the line. This graphic represents eight apps sampled over a little more than a month. The numbers on the left hand side indicate the app's overall placement in the market, the lower the better.

Android Market Sample Apps in the News and Weather Category

Click on the graphic for a full size image.

March 4, 2010

Why the USPS is running a deficit

The USPS is in the news lately, complaining they'll be running some 200+ BILLION in deficits in the next 10 years unless they cancel Saturday delivery, raise rates and do a number of unpleasant things, none of which entails laying off personnel or improving their service.

I had a taste of why the USPS is so inefficient recently that I wanted to share. The USPS, like all government agencies, is subject to FOIA (Freedom of Information Act) requests. The FOIA is a great tool for individuals and businesses to get information from their government.

I recently used FOIA to try and obtain the database that drives the USPS's mailing location website. I wanted the data to add to our sites to make it easier for people to find the "blue box" collection spots that are scattered about virtually every city in the country. There are hundreds of thousands of these collection points in total and the current USPS website is pretty poor and difficult to use. Adding this data to our sites seemed logical and productive.

I sent a FOIA requesting "a list of addresses and and last pickup times of all USPS collection box locations in the United States." - this is precisely the information that their website uses, so it has to be an existing, fairly easy to access table on a server somewhere.

Here's their response in a nutshell: (some verbiage left out for brevity)

Dear Mr. Coryat,
Our IT Department has estimated the computer processing and personnel costs associated with your request to be approximately $2,732.00

$1600.00 - 8 hours of IT specialist Time
$180.00 - 3 hours Operator Time
$100.00 - Electronic Delivery Set-up
$6.00 - 6 gigabytes data delivery
$140.00 - PC Usage
$706.00 - Mainframe/Open system usage
Paul C Sullivan
Delivery Systems
475 L'Enfant Plaza SW
Rm 5821
Washington, DC 20260-5821

8 hours of IT specialist time and all those other fees to extract a single, existing database that sits in a publicly facing webserver? 6 gigabytes of data? There are 238,000 (+/-) collection box locations in the US, at 6 gigabytes, that means each collection box location consumes a whopping 25,150 bytes! An address and a last collection time should require about 150 bytes at the most.

This is typical of the way the USPS does business. It's no wonder they can run a 200+ Billion dollar deficit over the next 10 years.

March 30, 2010

Google Device Seeding Program

Today I received a free DROID (Verizon) phone from Google's Device Seeding Program for Top Android Market Developers.

This is a great thing that Google is doing for developers. My first Android device, the Google ION was also a gift from last year's Google IO, which I used to develop "Radar Now!", "What Zip Code?" and two others. Without this seeding program, many developers, including myself, wouldn't have jumped onto the Android bandwagon.

Now all I need to complete the set is a nice Nexus One, which I hope to receive when I check in at Google IO 2010! Sorry to all of you who didn't pre-register!

I will be using this nice DROID to upgrade "Radar Now!" and also to work on adding AdSense into the app. USNaviguide was accepted into the AdSense Beta for mobile devices last month and I've been waiting on this device to include it.

Again, Thanks Google for being such a great company!

April 14, 2010

Telephone policy

We're often asked by potential customers to discuss our products, modifications or entirely new projects over the phone, our answer is always along the lines of "We prefer all discussions of projects, products or modifications to be in writing." While this policy is important to us, it rarely is palatable to the customer. We do this for many reasons, among them:

* It's impossible to remember everything said or agreed to on the phone.
* Misunderstandings of requirements are virtually always due to interpretations of what was said by who.
* Connection problems or language barriers are difficult to cross with a voice discussion.
* Voice conversations require all parties to be present and available at the same exact moment in time.
* Voice conversations are very time consuming and are often unproductive.
* The nature of a voice conversation leaves little time for thought, answers that come "off the top of one's head" are rarely the appropriate or optimum answer.
* Trade secrets can be easily divulged during a phone conversation.
* Having all communications in writing eliminate most of these problems.

Phone conversations can help ease a customer's concerns about their project, they can ask many questions and get quick answers, the problem is what are done with those answers. Often, the perception on one end of the phone is different than the other and those differences can lead to more problems than a quick call can solve.

We appreciate and value our customers but more importantly, we strive to accomplish what we state in a timely and accurate manner and phone conversations lead to confusion, misinterpretation and misunderstandings hence we prefer all communications to be in writing.

Thank you all for understanding this policy.

-John Coryat, President, USNaviguide LLC

About Technical

This page contains an archive of all entries posted to / USNaviguide LLC in the Technical category. They are listed from oldest to newest.

Reverse Geocoder is the previous category.

Zip Codes is the next category.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.31