For those diehards out there, you can choose English units (feet) instead of meters, and modify the flooding level numbers and update the map quickly by clicking on the “Go” button. Leaving a level blank omits that color from the map. Here’s an image from south Florida that uses the numbers above:
As the mapplet and my earlier post on Flood Maps point out, there are limitations to this approach deriving from the data. The SRTM data used for this has a spatial resolution of 90 meters, so the results will have a comparable spatial resolution. And SRTM data includes the heights of building and vegetation in the terrain, so urban areas like Miami will have SRTM terrain heights that are higher than the true terrain level, and the flooding level there will be undermapped by this mapplet. You’ll need to use higher resolution data with building/vegetation effects for more accurate results, as is done in this post. But for a quick estimate, this Mapplet does a nice job.Two additional tips on Google Mapplets:
- Google Mapplets aren’t currently accessible from the main Google Maps page; use this Preview link to reach a Google Maps page with an Mapplets tab
- You can reach any Mapplet by creating a single link like this one:http://maps.google.com/ig/add?moduleurl=http://www.heywhatsthat.com/mapplets/sealevel.xml&pid=mpl&synd=mpl; to test it out, just click on the link, and you’ll be given the option of adding this mapplet to Google Maps MyMaps. To create a direct link to any other Mapplet, just replace the text “www.heywhatsthat.com/mapplets/sealevel.xml” with the address of the Mapplet you want to reach. Thanks to Mike Kosowsky of HeyWhatsThat.com for this tip.
LIDAR (Light Detection and Ranging) can be used to create high-resolution terrain data (sub-meter), detail good enough to show individual man-made features like buildings and bridges. It’s especially useful for analyzing terrain in areas that are in constant change, like coastlines. High-resolution coastal LIDAR data is available at this NOAA website for the entire US ocean coastline, and parts of the Great Lakes coastlines, for times ranging from 1996 to the present.
Last week, I posted the last in my series on animating sea level rise in Google Earth using raster overlays (the “Inconvenient Truth Effect”), and ended with the comment that I would do the same thing with vector overlays, and that doing it that way had some advantages over using raster overlays. Uh, maybe not.
For this effort, I decided to do a vector overlay animation that showed flooding in San Francisco instead of the previous one in Manhattan. Creating a raster animation was pretty straightforward:
Doing the same thing with vector overlays turned out to be a major pain, and even though at first glance the results might look comparable …
… if you look at the results in Google Earth itself, there are big problems with the way it’s rendered at various viewing angles and zoom levels. Read on to find out more.
Yesterday’s post showed how to create a sea level rise flooding animation in Google Earth, like this one:
But if you downloaded the KMZ file used to create this animation, and ran it with 3D buildings turned on at the tip of Manhattan, the final image you’d get with 12 meters of flooding looks like this:
And there’s a problem with the accuracy of this image: there’s no actual depth to the flooding, i.e. the lower levels of the buildings aren’t covered with water. In fact, some of the buildings you can see in the view above would be completely covered with water if this were a more realistic depiction. That’s because no absolute altitude was assigned to the image overlays used in creating the animation, so they are “clamped” to the terrain level. But by assigning a height to every overlay image in the animation, one can create a realistic effect where the flooding doesn’t just cover more area as the sea level rises, but covers the bottom levels of some buildings, and completely covers other ones. This would be similar to the animations shown in the movie“An Inconvenient Truth”, and in one sense even better. In that movie, the flooding was show in overhead views, while the Google Earth animation can be viewed at an oblique angle of your choosing, with 3D buildings.
The National Solar Radiation Database offers solar radiation data and limited meteorological data for 237 sites in the US over the period 1961-1990, and expanded data for 1454 sites from 1991-2005:
Data includes:
Hourly Solar Data
Statistical Summaries
Daily Statistics Files
Hourly Statistics
Threshold Files
Solar Radiation Data Manual for Buildings
Solar Radiation Data Manual for Flat-Plate and Concentrating Collectors
Typical Meteorological Year (TMY2) Files
User manuals in PDF format can be downloaded. Data is in text format, but can be converted to spreadsheet format with a bit of work.
Creating a high-resolution static sea-level rise image for a specific sea level rise value, and displaying it in Google Earth, is fairly straightforward (see thesethreeposts for the details):
But creating an animated version viewable in Google Earth, comparable to this animation created in MicroDEM …
… takes a bit more work, including diving into the KML code. But while it’s a bit time-consuming, it’s not that hard, and the results are worth it:
Addendum: Do read the rest of this post, but also check out the next post in the series as well for even cooler effects.
In the last post, a raster image overlay of 8 meters of sea level rise flooding was loaded and positioned into Google Earth:
But the white areas of the original raster image obscure the underlying aerial photography, even when the raster image is made partially transparent. It would be useful to make that original white area completely transparent, while preserving the blue areas that represent areas flooded by the sea, and that can be done in Google Earth.
Contents of the Free Geography Tools Blog copyright 2007-2010; all rights reserved.
Determining the accuracy, reliability, validity, or appropriateness of any of the software or data written about in this blog for any uses is the sole responsibility of the reader, not the authors of the blog posts. The blog authors have no liability for any uses of the software or data described here.