Author: admin

I get quite a few questions related to how secure and private data ran through the bulk geocoder will be kept. The quick answer is: Your data never really leaves your computer.

To explain, here’s what happens when you use batchgeocode.com. You paste your data into the field on the screen and validate it. You then select which field is which and select what map options you want and so on. So far so good, you haven’t even accessed the internet since you loaded the page (you can prove this on your own by unplugging your network cable after loading the page.)

The step of actually running the geocoder (and drawing the map) is the only step that actually interacts with the internet. However the only data that is actually transmitted is your address data, and it is not attached to any other information you may have included. So if someone out there happened to be interested enough to sniff the HTTP traffic, all they would see is a bunch of addresses, with no contextual information to place them in.

Even the process of drawing the map keeps your data a secret. The only request that goes to the internet is to Yahoo to download the few map tiles that surround your geocoded points. So if our persistent GIS data hacker is still listening, all he sees is a few tiles fly by for Paris, Texas or Sacramento, California… Or wherever. Point is even when your little map points show up on the map, your data is still kept local to your computer. The entire process is just done in JavaScript client side in your browser.

Now, say you choose to use the “Save Map to Web Page” feature… Well this will actually send your data to our server where they will be saved. So if you just can’t have your data go over the Internet, stay away from this option. “Download to Google Earth” sends the data as well, but it is never saved, just put into a KML which gets sent back to you and then destroyed.

A bit more on “Save Map to Web Page,” doing this will not automatically publish your information to the Internet so to speak. It will be available to anyone who knows the URL, but guessing the URL is impossible. So unless you choose to share it with anyone, it will remain a secret. You can use it in this way to create maps that are of personal interest to you, but no one
else.

Hope that clears things up, if you have any questions please feel free to use the comments feature. If your one of those secretive types, you can even post anonymously.

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?