Update: I guess I jumped the gun a bit in assuming the international support went further then it did. It looks like only major roads are available internationally, and thus geocoding support is limited. Lets hope that they update again soon enough, aerial photos aren’t much good if you don’t know where to look!

Original Post:
Yahoo dropped a bombshell today announcing international data coverage support, a new and improved developer API, and the addition of aerial photos. You can read more about it here.

It might take me awhile to sort out all the areas that are covered by the new geocoder, but so far I have tested:

• France
• England
• China
• Australia
• Japan
• Germany
• Etc!

For me tracking down addresses in all those countries to test wasn’t easy, and Yahoo hasn’t come forward with the full list yet so it might take awhile to figure out what the coverage really is. The great news is that the batch geocoder was automatically updated with support for international addresses when Yahoo made the change. Please post any feedback here.

I should be able to fairly quickly update the other pages to reflect the other updates which include aerial photo support. This is really exciting!

I have no real way of knowing just how popular the “Download to Google Earth” option is on our geocoder. This because once you load the home page, you could request KMLs all day and I don’t see them as new page views in the logs. I have heard from several people who are using it successfully to create libraries of KMLs, which they then mix and match setting up different colors for different data. (If you want to add your colors, just add a “color” column to your source data and throw in an Hex RGB value for the color.)

KML is pretty cool. It lets you do some amazing things, with a very simple XML based syntax. The great thing about it, is unlike popular GIS formats like an ESRI shapefile, both the data and the rendering information are stored in the KML. This means when you send your KML file to your buddy, he can open it up in Google Earth and immediately visualize it in the same way you do. With classic GIS data, your buddy would need to set up his own rendering parameters, which probably are going to end up different than what you are looking at.

With ESRI’s Arc8 suite, there became a concept of the “layer file” and MXD, both store a pointer to the data as well as the rendering information, however neither store the data itself. ESRI gives you ways of storing information, and storing rendering parameters… but never together. There have been attempts to do this in the past, but they never seem to make it into the standard ArcMap. Word on the street is this will be changing in future versions of the Arc9 suite, but its funny its taken so long to get to that point.

Backwards compatibility are other big problems for ESRI data formats and MXDs. If I save an MXD in Arc9, you will not be able to read it in Arc8. Likewise if I have an ArcSDE 9 database, you will not be able to connect to it in Arc8. This presents huge problems for enterprise GIS users, who are forced to upgrade everyone at once or have dual environments for newer and older versions of the software. Unfortunately this seems to be a problem that won’t be fixed any time in the near future.

Google got it right the first time, whereas ESRI has been doing it for over 30 years now and they still aren’t there. So who is the real map expert?

Extra extra! Read all about it.

What’s nice:

• No more page view limits
• Some memory leak fixes
• A promise on warning before an ads launch, and promise to not have ads in the near future (though you can bet its coming)

I am a little disappointed (but not surprised) that they don’t have an answer to Yahoo’s geocoding features in their latest release. Maybe we’ll see them as part of some commercial package in the future.