Google Earth Community sysop PenguinOpus has announced that the “Katrina” layer in Google Maps over New Orleans is now available as an experimental network link in Google Earth.

It’s a view-based refresh network link, which fetches the Digital Globe data 2 seconds after your motion over New Orleans stops. What’s innovative here is that the data consists of tiles, just as in Maps, and is delivered via a PHP script, with URL http://dev.keyhole.com/katrina/dg/tileserver.php

I’d love to know what that PHP does:-) It looks like it accesses the exact same tiles as Google Maps does, depending on what level you are zoomed in, no doubt determined by the bounding box of your view, which the PHP script receives. As those tiles are all just small jpegs, the script would need to decide how many to fetch and how to arrange them.

Indeed, if you look at what the network link delivers, it is a list of overlays, each containing one tile, and each one being independently adjustable on/off and for transparency. Very nifty.

Do read the whole thread. It contains interesting feedback.

PS. This of course means that the Google Earth team, should it want to, could now deliver the original Google Map tiles to Google Earth via such a network link/server solution. Unlike with Google Maps, however, Google Earth is able to drape these tiles over height information, which would definitely be worth a look just to see if it results in something cool and/or useful.

[Update 2005-09-05: This network link is now also available from Google Earth’s main Katrina page.]

It’s not showing up via my update functionality in Google Earth, but if you download a fresh copy from the home page now you’ll get version 3.0.0548 Beta, up from 3.0.0529 Beta. Running the installer asks you if you want to update.

So far, updates have shown up in increments of x.x.01, so this one looks to be a little irregular. The release notes also appear to be identical, and I can’t actually spot any difference between the two versions. (Was the Dining feature there in Layers previously?) (Alerted here.]

Digital Earth Weblog’s final installment of its Google Earth Wishlist is out. Andrew Hallam would like public WMS services to provide more complete and more user friendly metadata for mainstream users, and also have them provide KML files for accessing the data using Google Earth.

But above all he would like Google Earth to have native support for WMS. Given that WMS is not currently aimed at the layman user I’d expect such a feature to be reserved for the Plus version.

Andrew Hallam at Digital Earth Weblog writes his third installment in a detailed series on Google Earth. This time he posts on getting WMS servers to show up in Google Earth, and homes in on those places where both Google Earth and WMS protocols have room for improvement.

Some notes on his notes, then:

1. Finding a WMS: One place to look is Mapdex (no surprises there). Do a search for “WMS” in Service and you’ll get 394 services from 109 servers. That’s a good start for experimenting.

2. WMS Reflector Script: I like the “reflector script” (great name) that Andrew uses, as it is quite versatile and robust, certainly more so than the one I used when experimenting on Canada, in this post.

He notes of the script that he uses, however, that “the big limitation with this approach is that the user has no control over what gets displayed. They cannot turn the individual WMS layers on or off.” He proceeds to try to work around this limitation by constructing a KML document that contains multiple network links, all containing one layer. The end result is understandably a bit clunky looking.

Unless I’m mistaken, however, and perhaps Andrew has already considered this route but dismissed it for reasons I haven’t figured out, there is a conceptually simpler way to construct the reflector script, involving multiple <GroundOverlay> elements inside one folder (which is allowed), each of which holds an individual layer that can be turned on or off separately. This is what I did for the Canada reflector script [txt], and it means you only need one network link, and it can be at the top layer in your Places. (The full post, with KMZ network link)

As for HTML legends — these are nice, but if you’re not so wedded to it having to be HTML, then you’ve already done most of the work if you make a PNG out of it, and then display that as a ScreenOverlay. Here is an example using Andrew’s PNG [KMZ]. All we need then is a web service that turns HTML into a PNG and returns it, and we’ll suddenly have a nice pipeline for generating floating legends for Google Earth. Of course, there are no links this way, but you could keep those in the descriptions in the Places window.

7. The XSL Stylesheet is extremely cool, and it is exactly what WMS needs for automated delivery to Google Earth. Jeremy at Mapdex, is that something you could use to generate a network links with component &lt:GroundOverlay> tags for layers, much like you did with ArcIMS?

James Fee links to some more ESRI Shapefile => KML converters.

So now there is Shape2KML v 1.0, vba_ArcMap2kml (by the good people at Portland Metro) and, posted earlier, Safe Software’s FME application. Are we missing any?

Mark Bosworth, who does GIS at Portland’s Metro transportation planning agency, wrote in to clarify this earlier post on plans to integrate a bike trip planner for Portland with Google Earth:

At this point, Google has not responded to my inquiries, so I think it is fair to say that the solution will be to do the routing outside Google, and then display the results in either GoogleMaps or GoogleEarth. We have been talking with them since they were Keyhole Corporation, and hopefully will have a Fusion Server here at Metro to publish our own local data through the GoogleEarth interface. We are an ESRI shop, so we are also thinking of an ArcIMS route solution that would be distributed via a browser based application. Though, given the recent momentum in the open source community – propelled by the Google API – I’m pretty certain that an open solution will appear very soon. Hopefully driven in the Portland region by our better datasets.

Hope this gives you a little insight into what is happening here. I’m really excited by the potential for this type of application, and I think the enthusiastic response we have got from the community for just publishing the linework to LOOK at in GoogleEarth is an indication of how strong a demand there is out there for cyclists to be able to plan their rides, and explore bike routes from the Net.

danbri\s foaf stories point us in the direction of some great-looking screenshots of an upcoming open source client-side map editor, MozMapEditor. (It uses XULRunner, so it’s aimed at Firefox et. al.)

ETA is the beginning of September, as per the comment thread. Did I mention it looks great? The mozdev site explains,

Mozmapeditor is based on a new implementation in Mozilla, the Scalable Vector Graphics (SVG), and on an Open GIS Consortium (OGC) standard, the Geography Markup Language (GML).

Danbri hopes the results are exportable to KML, among other formats, and so do I. It shouldn’t be so hard, right?