IONCANNON » gis

The Search for Timezone Maps

carson — Fri, 17 Oct 2008 03:25:46 +0000

For a while I had been casually searching for a way to overlay US time zones over a map for a project I was working on. It was never important enough to have a solution that required paying for something so I was searching for some type of government data source.

My first attempt was to use this large international timezone map, this wikipedia map or the list of US states by time zone and then trace and outline over the states. This turned out to be a non-starter because the maps aren't detailed enough and the list of states doesn't give you enough information.

I figured I would end up looking for ESRI shape files at some point and that is where I turned next. An initial google search got me to a post that led to a link to what should have been a set of shape files. Of course the link was dead so I turned to archive.org and found that the archive was incomplete.

I reverted back to looking for another source and found a set of shapes that ended up being just a bunch of squares. At this point I had gone over a lot of random links that didn't get me anything and I was about to give up for good when I finally found the USGS atlas site's time zone data. This was the jackpot, not only do they have time zone shapefiles but they have a large number of other shapefiles that could come in handy some day. This quest has made it apparent to me that the government doesn't do a great job of getting their data found.

One helpful tool in my shapefile search was ESRI's free Arc Explorer. It was a quick way to validate the shapefiles where or where not what I was looking for before landing on a set of files that would work.

Now that I had a valid set of time zone shapes I created a simple java application using geotools to read the files in and generate a resulting map graphic that I could overlay in the project. The shapefiles are easily converted to lat/lon polygons so using this data to overlay on something like a google map would be even easier.

Free geocoding

carson — Sat, 20 May 2006 23:13:50 +0000

I've had opertunities to work with a number of different GIS packages in the past (see my post comparing a few). Most of them are great but they all cost a lot of money to use. If you trying to get your feet wet and don't want to spend money on one of the real services there are a number of places where you can start like yahoo or ESRI. These free services however have strict rules about using them for any commercial venture. So if you wanted to do geocoding for something that you charge for you need something else.

That something else could be one of the few open source applications that have sprung up. The first one has been around for a good while: geocoder.us. geocoder.us is has a free web service you can use to do your geocoding and they also give away the software they use to do it for free. The code they use to do all the work is in perl so it should work on a number of platforms (they also have a blog with some PHP examples). The second choice would be a newer entry SRC Open Source Explorer Geocoder. The code for SRC Open Source Explorer Geocoder is windows only for now but maybe someone will come along and port it to Unix. Now for the bad new. Both of these applications need a source of data and the most likely source of data for the average joe would be the US TIGER data. The TIGER data isn't too bad but it isn't great and not nearly as good as a purchased dataset. But you can't get better than free so if you are interested in a way to do free geocoding without comercial use restrictions then geocoder.us or SRC Open Source Explorer Geocoder are good places to start.

Tags: geocoding, geocode, tiger, esri, mapping

Good Techcrunch review of mapping apis

carson — Tue, 18 Apr 2006 18:06:21 +0000

Techcrunch has a good review by Frank Gruber of the look and feel of mapping services. I think it is notable that ESRI's service is not included in the review. I think it is at least as good as the mapquest service. I may have to find time to redo my review of the acuracy of each again and a more technical evaluation of each.

Tags: gis, esri, geocode

Approximating a circle with a polygon

carson — Tue, 18 Apr 2006 06:36:18 +0000

I recently had an opportunity to use ESRI's ArcSDE again. It is a spatial database interface and in this instance I was using the java api. I wanted to change what used to be a query using a rectangle into a query using a circle. For some reason parts of the java api for ArcSDE require a C library or something. I gave up pretty quickly on trying to make their arc function work since the documentation wasn't very clear on how it worked. Instead I decided to figure out how to approximate a circle with a polygon and use that instead. Here is the result of that research.

First it helps to have a little background. Most people are familiar with latitude and longitude but you may not be familiar with their exact definitions. I have included the links to the wikipedia pages for both so you can research them more if you want. The main things to know are: latitude runs north/south and each degree of latitude is about 111 km; longitude runs east/west and is 111 km times the cosine of the latitude. The next thing that is helpful to know is the radius of the earth: 6,378.135 km in this case I'll just use the equatorial radius.

Now that we have the earth taken care of we need to go back to basics. We start by looking at the definition of a circle and the unit circle. The mathematical definition of a circle is the important part here. The following equations will play an important part: x = a + r cos(t) and y = b + r sin(t) where a,b are the center of the circle, x,y are points of the unit circle, r is the radius of the circle, and t is the angle of a line from the origin to x,y in radians. It helps to think of the circle as broken up into triangles.

The last thing to keep in mind is that latitude and longitude are in degrees but when working with cos and sin you need to use radians and not degrees. The conversion between radians and degrees is easy: radians = degrees * (PI / 180) and degrees = radians * (180 / PI).

So now for the main formula in pseudocode:

earths_radius =3963// number of miles in the radius of the earth

 longitude =80// longitude of the center of the circle

 latitude =90// latitude of the center of the circle

 points =32// number of points in the polygon

 circle_radius =1// miles of radius
 // find the raidus in lat/lon, units per latitude, units per longitude

 r_latitude = radius_to_degrees(circle_radius / earths_radius)

 r_longitude = r_latitude / cos(degrees_to_radius(latitude))
 // create a point for each edge, we need one extra point to connect the

 // end to the begining

 for point_count = 0 to points + 1

 {

    theta = PI * (point_count / (points / 2))    // find the angle for the current triangle

    circle_x = lng + (r_longitude * cos(theta))  // center a + radius x * cos(theta)

    circle_y = lat + (r_latitude * sin(theta))     // center b + radius y * sin(theta)
    // circle_x, circle_y represents a point on the circle

 }

That is all there is to it. In this example I just picked 32 points for the circle but you may want more or less depending on how large your radius is and how closely you want to approximate the circle. One thing to note about this function is that it produces the points in a counter-clockwise direction.

Now for an example using google maps to display a circle around a point with a radius of one mile:

Missiondata World HQ, Louisville, Ky

And here is the javascript source you need to do it:

var d2r = Math.PI/180;// degrees to radians
var r2d = 180 / Math.PI;// radians to degrees
var earthsradius =3963;// 3963 is the radius of the earth in miles
var hqpoint = new GPoint(-85.578852, 38.215601);

var map = new GMap(document.getElementById("map"));
map.addControl(new GSmallMapControl());

map.addControl(new GMapTypeControl());

map.centerAndZoom(hqpoint, 4);

map.addOverlay(new GMarker(hqpoint));
drawCircle(-85.578852, 38.215601, map);
function drawCircle(lng, lat, map)

{

   var points = 32;

   var radius = 1;             // radius in miles
   // find the raidus in lat/lon

   var rlat = (radius / earthsradius) * r2d;

   var rlng = rlat / Math.cos(lat * d2r);
   var extp = new Array();

   for (var i=0; i &lt; points+1; i++) // one extra here makes sure we connect the

   {

      var theta = Math.PI * (i / (points/2));

      ex = lng + (rlng * Math.cos(theta)); // center a + radius x * cos(theta)

      ey = lat + (rlat * Math.sin(theta)); // center b + radius y * sin(theta)

      extp.push(new GPoint(ex, ey));

   }
   map.addOverlay(new GPolyline(extp, "#000000", 2));

}

Tags: gis, esri, arcsde

GIS Geocoding experiments

carson — Thu, 09 Mar 2006 07:39:31 +0000

I've been evaluating a couple different mapping software packages recently and the other day I noticed that the same addresses geocoded (for those who don't know what geocoding is you can find out more about it here) to different locations. They are mostly the same but I figured it was interesting enough to do some more digging and see how different mapping services compared.I looked at the following services. Some of them are commercial services with open apis (ESRI and mapquest) and some of them are non-commercial services with open apis (yahoo and google although google does not have a geocoding api).

For google I viewed the resulting values for latitude and longitude that were generated from a search for the address. For yahoo and ESRI I used their REST geocoding apis and for mapquest I used their java api to their commercial service since their openapi service is only in beta currently.I took 5 addresses located at different points in the US and one in Canada and mapped the returned latitude and longitude from each service. Here are the results:

Missiondata, 2300 Hurstbourne Village Drive, Suite 1100, Louisville, KY, 40299
mapquest: 38.215303, -85.578698
google: 38.215601, -85.578852
yahoo: 38.215496, -85.578669
esri: 38.216273, -85.579028

Googleplex, 1600 Amphitheatre Parkway, Mountain View, CA, 94043
mapquest: 37.4238, -122.0901
google: 37.422845, -122.085035
yahoo: 37.42386, -122.090332
esri: 37.42386, -122.090332

IBM New York, 590 Madison Ave, New York, NY, 10022
mapquest: 40.7623, -73.972399
google: 40.762267, -73.972535
yahoo: 40.762245, -73.972644
esri: 40.762245, -73.972644

Lockheed Martin, 6304 Spine Rd, Boulder, CO, 80301
mapquest: 40.0672, -105.206711
google: 40.067084, -105.206555
yahoo: 40.067063, -105.20654
esri: 40.067063, -105.20654

Red Hat Canada, 2323 Yonge Street, Suite #300, Toronto, Ontario M4P 2C9, Canada
yahoo: none
mapquest: 43.708137, -79.3985
google: 37.062500, -95.677068
esri: 79.398592, -43.7081

For the most part all of the services provide very similar results for geocoding in the US. From the limited number of locations I tested it seems that the larger cities have a more reliable set of outputs. In NY for example they almost completely stack on top of each other. I find it interesting too that in 4 out of 6 cases yahoo came back with the exact same results as ESRI provided.

The last thing to notice of course is that the results for Canada are not as good. First off I couldn't get yahoo's service to work with a Canadian address for some reason. Also notice that the ESRI latitude and longitude results are swapped. And viewing the results from google for latitude and longitude gave me some wildly incorrect values but the map was actually correct (thus the two maps). The only completely reliable service for Canada was mapquest and google (although google doesn't do geocoding) with ESRI coming in next just because the results were swapped. All in all I think all 3 did a good job.

I'm not sure why google hasn't produced something in the way of geocoding yet. I think they have the mapping nailed down but their lack of geocoding will put them at somewhat of a disadvantage at some point since the other 3 services are in the open now and both ESRI and mapquest already have commercial versions of their services that people use widely.

Tags: gis, geocode, esri, map