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.