blankblank blank

Animating Sea Level Rise In San Francisco With Vector Overlays In Google Earth In One Word: Don't

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.

In theory, vector overlays should be superior to single-color raster overlays:

  • Raster overlays have limited resolution unless you use image tiling (which I’ll cover sometime in the future); vector overlays should allow high resolution over larger areas with sharp overlay boundaries
  • Vector overlays are created with the position data already embedded, so you don’t have to specify the latitude/longitude boundaries as you do with raster overlays
  • It’s easy to modify the color and transparency of a set of vector overlays, more difficult with raster overlays.

In practice, though, creating an animation with vector overlays turned out to take far more effort, and produce far inferior results. To start out with, you have to convert every raster flooding image in your desired animation to a vector overlay, using the process outlined in this post. This means converting the raster image to a vector shapefile, cleaning it up, simplifying it, then converting it to the KML format – about 10-15 minutes of work for every frame of the animation even if you know what you’re doing. With the raster animations, I was creating 61 frames for the total animation, which took less than an hour to do. It would have taken at least 10 hours of time with vector overlays; I cut that down to 24 vector overlays for animation, but even that took a ridiculous amount of time. I’m working on a revised animation process for raster overlays that should cut the total time to create a sea level rise animation down to 10 minutes, making the time differential even greater.

Then, after assembling the vector overlay animation, I discovered that there were weird interactions between the overlay and the terrain in Google Earth. If I set the height of an overlay to correspond to its flooding level, huge areas that should have been “flooded” by the overlay weren’t – I had to set the overlay height well above that of the terrain to make it visible (e.g. the overlay that showed flooding at a sea level rise of one meter had to be set to an altitude of 5 meters). Setting the overlays to be “clamped” to the ground made things even worse. And then, when running the animations, at certain zoom levels, the overlays disappeared completely. The animation at top is from a fairly high altitude in Google Earth; if I zoomed in just a little bit closer, or changed the angle too much, the overlays disappeared completely.

I suspect the problem is that, even though I simplified the original vector data down significantly, there’s still too many points in the resulting files to work correctly in Google Earth. At some future point, I may play around with simplifying these overlays and seeing if that doesn’t solve the problem, but for now I don’t want to look at these again for a while.

Don’t take my word for it – download the Google Earth vector overlay animation at this link and see for yourself. Then download the comparable raster animation available here, and see how much better the results are:

(Note: the streaks in the video are a capture artifact, and aren’t present in Google Earth).The raster overlays will occasionally act oddly, disappearing randomly at certain zoom levels or viewing angles, but typically they’ll re-appear quite quickly if you change the zoom level or viewing angle again. So if you’re going to create this kind of animation, stick with raster overlays – they’re faster and easier. Sometime in the future, I plan to post a modification of my original method that makes the whole process fast and easy, even if you have no experience working with terrain data or animated KML files.

Looking for something else? Enter some keywords below, then click "Search".    

2 Responses to “Animating Sea Level Rise In San Francisco With Vector Overlays In Google Earth In One Word: Don't”

  1. 1 Mark Ireland

    We (Safe Software) did a very similar demonstration at a recent GIS Day event.
    We used our software (FME) to convert some data to KML and duplicate it in a way that created a time-span and simulated flooding.

    I’d be interested to know what your KML technique was – we simply created a large vector polygon that spanned the entire area, then raised it up 1m per time frame. It’s what we’d use to create a 3d building, but in this case it produced the flooding effect we wanted.

    We had a similar problem where it didn’t flood when we thought it should, and we figured that it was caused by curvature of the earth using too large a polygon (what is 1m above sea level at the edge of the polygon was still underneath sea level at the centre where the curvature is highest), so we tiled it and it reduced the effect at the cost of a little performance.

    You can find what we did on (see workspace of the week for some screenshots) – or you can download the kml inside a zip file at

    NB: To give a greater effect we made the sea-level raise 40m and pretended it was caused by a tsunami. I guess in reality that would be a different type of flooding, but it was the method more than the reality that we were concerned with.

    Anyway – a cool article here and good to see great minds thinking alike(!) and using GE for the same demo. I shall have to investigate how you did the raster overlay to pick up some useful tips.


    Mark Ireland, Senior Product Specialist
    Safe Software Inc. Surrey, BC, CANADA
    Solutions for Spatial Data Translation, Distribution and Access

  2. 2 Leszek Pawlowicz

    Thanks for your comment. To create the flooding simulation, I used the freeware GIS MicroDEM to flood an area, then converted it into a KML overlay, either raster or vector. MicroDEM does a true basin flood of a DEM, so it doesn’t have the issues with approaches like yours, e.g. the earth’s curvature or flooding areas that would be kept from flooding in real life by the topography (like Death Valley). The downside is that it takes a lot more time and effort to create, and as a raster overlay it uses more memory (unless I convert it to a tiled overlay).

    The limited terrain resolution of Google Earth used to limit the accuracy of a generic “rising vector overlay” flooding approach, which is why I came up with my approach. But since I created my simulations, Google Earth has improved the terrain resolution in the US from 30 meters to 10 meters, which significantly improves the results you get from your approach, or similar ones like that of BZoltan’s worldwide sea level flooding KMZ file:

    With the old 30-meter resolution, BZoltan’s simulation was fairly inaccurate; with the 10-meter resolution, it resembles my results pretty closely. If you don’t have to worry about terrain effects on flooding, it’s a lot easier to use.

    I don’t know what the terrain resolution for Canada is in
    Google Earth, but I suspect it’s not at the 10-meter level. In any case, I think most people in Vancouver will be safe unless the Greenland and Antarctic ice sheets melt significantly. If they melted completely, the maximum rise would be about 65 meters.

Comments are currently closed; feel free to contact me with questions/issues.