Tuesday, March 13, 2007

Finally got 3D colors working!

Thanks to the very first (and still only) comment left so far on CensusKML I have finally gotten good (well, maybe just bright) colors working when extruding the Census data out on Google Earth. I admit that I am terrible at picking color schemes, so please forgive the white-to-red one I'm using here. The trick was relatively simple: the coordinates must be listed in counter-clockwise order in order for Google Earth to properly draw the colors. I don't understand why this is the case, but it is. The Census boundary files list the coordinates for each polygon in clockwise fashion. Ruby made it very simple to reverse the coordinates. The coordinates are initially stored in an array in the order they are read from the Census files - when it comes time to read them out and put them into the KML file, all you have to do is call reverse! on the coordinate array and the array is reversed in place.

The following is a screen shot of the population data from the 2000 Census, broken out at the County Subdivision level. The height of each subdivision is equal to 1 meter for every 10 people. The colors also represent population, but use the state's max county subdivision population as the denominator, meaning they are only relevant within the state, not comparable across states. The largest subdivision will be bright red and the small ones will be white. I'm experimenting with this to try and get data on two levels - national and state. Among all of the data, note Boston on the upper-left, Florida on the upper-far-right in the distance, and Chicago on the bottom-right. Here you go:


You can compare the previous picture to this one to see how big a difference it makes to list the coordinates in a counter-clockwise fashion:

2 comments:

Imran Haque said...

Hi Aidan,

I'm the author of gCensus (gecensus.stanford.edu) - I think you ran into my posts on the GE forums. I was wondering if you'd be interested in collaborating; it looks like we're working on very similar sorts of things and might have good advice for each other. My contact info is listed on the gCensus site.

PS - the polygon vertex ordering matters because it's how 3D apps calculate whether your shape is facing "up" or "down". To be a bit more technical - a cross product is used to calculate the normal vector to the polygon surface, but this normal is determined only to within a sign - which is affected by your choice of ordering. If the vertices are in the wrong order, GE thinks you're drawing things upside down and shades them accordingly.

You can look up the term 'winding order' if you're curious. I ran into this same problem myself when I wrote my shapefile->KML generator :).

Anonymous said...

I'd love to have the KMZ files posted as you continue to work on this project. Great stuff!