Jeremy Cothran, sensor web innovator, has been hard at work making it easier for ocean data platform operators to georeference their online data in Google Earth. He’s managed to automate the process by turning it into a free HTTP web service. Jeremy Explains:

I’ve put together a google based visualization tool for a basic observation catalog visualization via kml/google earth. Folks can either download and modify the base scripts or use it as an http service which when supplied a basic CSV file and observation types list produces a KML file. More technical details are listed here. [Just cancel out of the password request, twice.]

Might be useful for encouraging/engaging other observation systems to list their assets via KML. We are struggling as a community to provide some consistent metadata (xml schemas, controlled vocabularies/codelists, web services) across our organizations and I’m hoping KML and its easy visualizations can help provide some incentive (a carrot) towards this.

Here is a sample by Jeremy of his web service (hover over the link to see its guts), made from two referenced content files. Very smooth indeed. And so is this: That exact same link can be pasted into Google Maps to produce a Maps version of the KML. I’m still amazed Google Maps can do that. It doesn’t get much easier than this:-)

Both Chris Holmes and Brian Timoney wrote in to make sure I blogged the release of GeoServer 1.3.2 today (press release). As I’m easing back into the blogging after that lovely little break, I thought I might let them do the explaining, as their emails are succinct and articulate:

Chris Holmes writes:

I work on GeoServer, an open source server of geospatial information. I noticed you caught the KML support in our last release. I was wondering if you might post a bit more about our latest release. The thing of note is obiously KML/KMZ output, so you can connect with a network link. This work was actually partially sponsored by Google themselves, in order to make life easier on people looking to expose data on Google Earth. Instead of having everyone write their own network link software from scratch it made sense to just fund an existing, solid open source server.

GeoServer has been around for a few years, and the community has written connectors for PostGIS, ArcSDE, DB2, Oracle Spatial, MySQL, Shapefiles and more. It produces maps and raw spatial data in a variety of formats through open WFS and WMS standards. The Google Network Link works quite well with WMS, so we just made things easier to connect with a built-in KML reflector, and made KML/KMZ as one of the output formats. So it’ll be most useful for power users, who have lots of data to get out, where a single KML file might slow GE too much.

There is also a feature to let users decide if they want Placemarks or Ground Overlay representations of the same data. So we’ve put a good amount in to making it easy to make network links, and as an open source project others can help contribute to grow even more advanced GE capabilities, such as 2.5d and 3d data serving, and support for streaming in KML 2.1

I work for a non-profit called The Open Planning Project, and we basically do this to make spatial information more available, for things like urban planning and beyond. Google Earth is obviously a great visualization engine, so we’re excited to interoperate with it. Anyways, I hope this might be of interest for your readers.

Brian Timoney makes these points in his email:

Other than GE 4/KML 2.1 I think this is a very important development for the following:

1. The implementation of KML as an output combined with the number of enterprise back-ends that it connects to: Oracle, DB2, PostGIS, and most intriguingly–ArcSDE.
2. A tighter connection between KML and the WMS/WFS standards.
3. The fact that Google contributed $$$ to the latest development effort

Between Google kicking money GeoServer’s way along with the added functionality of KML 2.1, I’ve been heartened by the attention to enhancing the abilities to stream ‘big data’ through the interface without resorting to the Enterprise/Fusion options…

It leaves me wondering how GeoServer compares with ESRI’s ArcIMS. It’s an honest question — is GeoServer now good enough for a good chunk of the server needs that were previously met by ArcIMS? Any GIS pros care to weigh in?

I ask only because Google’s support for GeoServer looks like a similar competitive play to ESRI making ArcGIS Explorer free. With a free ArcGIS Explorer, Google can’t really develop an entry-level analysis tool and expect to charge for it. With a free GeoServer, ESRI might find it hard to continue asking money for ArcIMS. (That’s my theory — in fact, it was touched upon in this post from February 2006 that is worth rereading — especially Brian Timoney’s comment, where he wrote, (prophetically?), “For me though, the real breakthrough coming up in the next 18 months is the direct linkage of interfaces (such as Google Earth) to backend spatial database.”)

One feature request people have had in the year since the introduction of Google Earth is the ability to visualize vertical data. With the introduction of textures in Google Earth a few weeks ago, I suspected that this would now be possible, but it took a weekend morning away from the distractions of internet connectivity to finally find out.

A few weeks before the launch of Google Earth 4 beta, CloudSat was successfully activated. This satellite takes vertical cross-section images of clouds, and the raw data is published on the internet, annotated with coordinates. This would make its dataset an excellent candidate for this kind of visualization, I thought.

Alberto, June 12, 2006. Click to enlarge.

Of the images available, I chose the snapshot of hurricane Alberto over the Gulf of Mexico, taken on June 12. I converted the image to PNG format, with the gray made transparent. In SketchUp, I then created a vertical surface, imported the image as a texture, and hid the boundaries.

I knew the coordinates of the image’s ends, so I tried to use the integration feature between Google Earth and SketchUp. Unfortunately for this project, the scale is far too large — the applications only work together at neighborghood-level scales, for reasons that soon became apparent.

Instead, I exported manually from SketchUp. I opened up the KMZ file (on the Mac, change the “.kmz” to “.zip”, then double-click) and altered the doc.kml file for scale and location.

While this let me set the starting coordinates and scale properly, it turns out that objects imported into Google Earth from SketchUp don’t use the polar coordinate system, but true 3D, as the imported object looked like this:

This presented a challenge that I might have been able to try to solve in a number of ways: Using an image manipulation tool to manually curve in the image and then orienting the resulting structure so that slices into the Earth slightly; figure out a way of converting the 3D to polar coordinates; or cutting the image into smaller segments, and importing each individually, so that the lack of curvature in the image is less apparent.

As I was on an internetless island (I thought), I did not have access to the tools for pursuing the first two solutions, so I cut the image into fours component parts and imported them separately, with some overlap. Here is the resulting KMZ file. It looks like this:

In sum, it works, though there is plenty of opportunity for automating this proof of concept, so that manual tweaks become part of the production pipeline. Ideally, too, we’d get to choose which coordinate system to import objects to — that would make the process a whole lot smoother.

Also, it’s pretty clear that CloudSat’s data has a vertical exaggeration, but I left it as is as I don’t know what the accurate scale is. Finally, This data is painted onto straight planes, when in fact the satellite’s path curves slighly over the surface of the Earth, so the coordinates I used are not exact. These are all solvable issues, however. It would be quite a coup should CloudSat’s scientists ever end up publishing such vertical data live as a network link in Google Earth.

[Posted as a result of the island I’m on playing host to the Gotland Runt classic sailing race this weekend, with as consequence that the entire main village has been thoroughly wimaxed. (Live tracking of yachts, though not with Google Earth, inexplicably.) It’s getting harder and harder to get away from technology these days.]

• Directions magazine has a first look at the upcoming SkylineGlobe, an in-browser 3D virtual globe.
• Microsoft platform evangelist Vic Gundotra jumps ship to Google, reports Business 2.0. Of interest:
  

  Gundotra had been leading an effort to persuade developers to build software on top of Microsoft’s MSN and Windows Live online services instead of Google’s platform.

I’ll be travelling the coming week, spending a very long weekend in the Stockholm Archipelago with barely a television and certainly no broadband, so if ESRI ArcGIS Explorer were to go public beta by Friday June 30, as promised, then you’ll read about it here last, as I’ll probably be in a hammock. I’m very curious to finally see it in action, however.

• Had enough of Géoportail yet? Of course not. A quick synopsys from French blogs:

  Louis Naugès reports that IGN’s base imagery of France is not actually new or fresh for Géoportail, and that hence the ‚Ǩ6-8 million rumored to have been spent on Géoportail’s development was only for the web and (upcoming) 3D application. He also points to a quote from an IGN official to 01net to the effect that they “couldn’t really justify spending money on infrastructure capacity, as it is public money” they are spending. Louis Naugès quite rightly finds that to be a remarkable statement, and proof, if any more was needed, that IGN’s priorities are skewed away from providing an actual service to consumers, preferring instead to focus on acquiring fun bits of technology. Scalability is too vulgar, presumably, for state enterprise.

  One blogger would like to see accountability at IGN, with an explanation for the rationale behind the resource distribution decisions for the Géoportail project. After all, it’s his money IGN spent.

  (All French blogs covering Géoportail report huge spikes in their readership. This “launch” has turned into a big discussion topic in the French blogosphere, and quite the viral marketing success for Google Earth.)

• Noel Jenkins at Juicy Geography comes out with a new education resource for Google Earth — this one is on the global diamond trade.
• World Wind Science Suite is a collection of science add-ons, for NASA World Wind. Sources include NASA, NOAA, USGS and the National Snow and Ice Data Center (NSIDC). Science visualizations are a Good Thing.
• James Fee and All Points Blog pick up the story of Dell giving its large customers Google Earth Pro for tracking service calls. Makes sense too — send your business intelligence all the way back to the customer, so that they can make better informed decisions, and you don’t have to become a clearing house for such information, with all the costs that implies.

The New Yorker, current issue (July 3), p.24. Click to enlarge.

Consider this blog flattered:-)

For the past 72 hours, my newsreader has been polluted by the laziest rewrites in quite some time, all of them concerning the Géoportail launch. Most of them contain a majority of the following “facts”:

• Géoportail rivals Google.
• At least in France.
• You can zoom in to 50cm from the ground.
• That’s less than 20 inches.

Things to take away from this:

The general public, including journalists, is still not at all sure what a geobrowser is. There is no distinction made between 2D web mapping applications, and 3D virtual globes. Curiously too, only Google Earth is featured as some kind of mythical competitor. Google Maps, Yahoo! Maps and Microsoft Live Local aren’t mentioned, nor is the only competitor currently in Google Earth’s space, NASA World Wind.

I suspect, ironically, that many of these early uncritical rewrites of Géoportail’s press release were published because the rewriters (can we really call them journalists?) couldn’t get into Géoportail to see for themselves. If they had done so, they would have noticed that even the claim of superior imagery inside France is looking rather spotty.

For example, have a good look at the comparison images on this blog posted by a user who was able to get in, of Mont St. Michel and the Eiffel Tower. Granted, these are two places that Google Earth has in high resolution, but that is the case for all of France’s most interesting cultural spots. Even more interesting is the comparison shots of IGN’s data served by Pages Jaunes, compared to the same data served by IGN itself: Géoportail actually does a worse job.

I bet Google is noticing a nice little surge in downloads of the French localized version of Google Earth right now as frustrated Géoportail would-be users get curious about that Anglo-saxon program that was so good it needed to be bested by the French state.

Finally, one commenter on Ogle Earth expressed the hope that other countries would emulate Géoportail. (Ogle Earth previously reported on such efforts in India and Thailand, also spurred on by the arrival of Google Earth.) I cannot agree. Consumers are not best served by maps that end at national borders. This is one reason why I think national geographic and cadastral agencies should not get into the business of trying to serve their data directly to the end user — certainly not since the arrival of the geobrowser. Instead, outsource that functionality; let others add value by amalgamating data, and focus on your core competency — quality data for your jurisdiction.