Over two weeks have passed since the 7.9 magnitude earthquake devastated Chengdu, China. The end of this tragedy is still hiding as aftershocks continue to ripple throughout the country. News feeds continue to stream from China as the recovery process continues. The most recent reports have the death toll climbing to 50,000.

The USGS keeps daily records of recorded earthquakes worldwide, and enables us to pinpoint earthquake locations by providing latitude and longitude coordinates. Within Finder we have made this data available for use in shape, kml, and CSV formats to the public.

The following Datasets can be found on Finder, and can be used to gain a spatial perspective on the current events in China.

USGS, M 1+ Earthquakes, World, 5.5.08 through 5.12.08
USGS, M 1+ earthquakes, World, 5.12.08 through 5.19.08
USGS, M 1+ earthquakes, World, 5.20.08 through 5.27.08
USGS, Earthquake Records, World, 1998-2007

Popularity: 12% [?]

Are paper maps no more? GIS Lounge reports that the cartography division of the California State Automobile Association is slowly being phased out. The cause for the demise is the widespread availability of online map directions and in-car navigation units which cut demand for the paper maps by 13% in 2007.

The Geospatial Semantic Web Blog shares some good news for the semantic web community. The U.S. Security and Exchange Commission recently proposed a timetable requiring 500 of the largest public companies to begin filling their financial data using XBRL (Extensible Business Reporting Language). This will create a mass amount of free and real-world data for research.

Speaking of data, Anand at DataWocky answers the question of why the world needs a new database system. He discusses high volumes of data that are not being utilized due to scalability. He points to the newly launched Aster Data which is a database system natively designed and architected from the ground up for a new hardware platform: commodity clusters.

Google Earth has a new browser plug-in, which continues its roll out of Google Map API for Flash and Google App Engine. Released with it is the very extensive Google Earth JavaScript API for writing 3D map applications. Moxie thinks that this has opened a new page for GeoWeb visualization.

Popularity: 17% [?]

With all the data we are pushing into Finder! sometimes it is easy to loose track of the interesting pieces unless you are searching for something specific. So, we thought it would be fun to post up a “dataset of the day” on the blog. The goal is to let folks know about new datasets or content that is relevant to a current event.

Since Memorial Day officially kicked off the summer driving season we thought it would be useful to map the current state of gas prices. We all know that gas prices are sky rocketing, but who is getting hit the hardest and suffering the largest increases. Today Bill (one of our resident data gurus) grabbed the latest data from AAA, calculated percent change from a year ago and loaded it into Finder! You can access the data here.

Next he took the data out as a shapefile and whipped up a quick thematic map in a GIS application. The first map is of prices with red being the highest and green being the lowest:

For the next map he took the percent change he calculated to illustrate the states with the largest increase in price (shaded red) and those experiencing the least price increases (green):

When it comes to the most expensive gas California, New York, Connecticut, Michigan and Illinois lead the pack and they are spread fairly evenly across the country. On the other hand if you look at percent increase in prices there is a large concentration of reds in the Midwest and South. This is especially stark in the manufacturing rust belt states of Michigan, Ohio, West Virginia and Indiana. The unfortunate things is these are the same places that have been hardest hit the recession and unemployment as you can see in the map below of percent unemployed for February 2008 (data here):

While there is no cause and effect between “percent unemployed” and “percent change in gas prices” it does illustrate the sad reality that those with the least ability to pay for an increase in their gas budget are being hit the hardest. Although if you wanted to run a correlation analysis you could pull the files out as .CSV and go to town.

Popularity: 9% [?]

Frank at the Google Earth Blog just leaked that Google will be announcing an API for Google Earth that will run in a browser. The short of it is you will be able to get GE’s 3D rendering capabilities and KML support to run in a browser. The first release will be just Windows, but will support IE, Firefox and other Mozilla flavors.

This looks to be a direct shot at Microsoft’s 3D Virtual Earth that also runs in the browser. The question mark in my mind will be if the Google Earth version has the same performance issues as MSVE. It is also interesting that Google released an API instead of a new version of GE that ran in a browser. Will this be a case of Google testing the waters with the API then releasing a product?

From a personal perspective I’ll be very interested to see how the new Google Earth API handles KML. Frank says the new API will be a, “subset of the Google Earth 3D graphics rendering engine and interfaces with KML support”. The question is will that KML support be robust like Google Earth allowing thousands of geometries to be drawn or less robust like Google Maps where you are limited to the low hundreds. I’m sure we’ll see soon enough, but congrats to Google on porting the technology to a browser, surely not an easy task. Although it begs one last question - does this herald the end of thick client geobrowsers?

Popularity: 14% [?]

We’ve been doing a lot of data migration and new data uploads with Finder! and often times our data team runs into data and mapping headaches. One that we commonly encounter are largish shapefiles that make for really bloated KML when we convert it (for instance a 2mb shapefile for US counties becomes a 5.4 mb KML file). The end result are big files that completely kill browser based applications like Virtual Earth and Google Maps, or load really slowly in thick client applications like Google Earth and ESRI AGX.

There are three factors that constitute file bloat for any vector based geospatial data:

1) The number of attributes (how many columns)
2) The number of features (how many rows)
3) The complexity of the geometry (how much needs to be drawn)

You can do some clever things to manage the first two at a low level - although you still are going to have bloat when you convert to a standard file format. The third factor, geometry complexity, is interesting because you can also do some low level tricks whose savings can be passed along to standard file formats. Reducing the complexity of geometry is often called “map generalization” in academic circles.

The general concept is that you remove details from the map without loosing the message and context of the map. All maps have some form of generalization otherwise it would be a perfect reflection of reality. Academics have used algorithms to heuristically derive a map generalization. This is probably best explained with a few examples. Below is a map of Europe in full detail:

Next is map generalization that removes some of the detail but still keeps the context of Europe and the country boundaries:

Last a more extreme example with even greater detail removed:

To pull off these nifty computational tricks used to require some fairly sophisticated desktop software, but Matt Bloch and Mark Harrower at the University of Wisconsin figured out a clever way to enable enable real-time WYSIWIG map generalization. The resulting application is called MapShaper. You can upload a shapefile and run different generalization routines (with high level of control if you choose) then export the result back out as a shapefile or an EPS file. The shapefile export is down at the moment, but hopefully will back in action soon.

I think these kinds of technologies and mathematics are going to be increasingly important as we need to make ever larger datasets available. Especially when the receiving devices are increasingly mobile with even smaller data handling capabilities.

Popularity: 23% [?]