Brian Flood has a piece on mashup fragility, and in particular our plight after Yahoo’s recent updates to their geocoder api. Then there is the article on the risk of mashups that kicked things off.

I think I have already said all that needs to be said on the issue, or have I?

Mashups are built on the shoulders of data and service providers, which seemlingly will need to get something out of the relationship. In the case of map interfaces, that could mean ads. In other situations, where there is not the same opportunity, I think we will see the data providers getting more and more stingy about who they let do what.

Right now I think Yahoo is being the most liberal in their data API’s, so I can’t really fault them for rolling back functionality on a service that nobody else is daring to offer. Also I’d remember there is another player in this game besides Yahoo, their data providers. They want to protect the investment and value in the data products they have created.

No doubt its an on going tango between data provider, service provider, and application provider (in this case, the batch geocoder.) I like being the application provider, its the most fun…. and even though there is certainly less control at the end of the chain, there is also less expense, less risk, and most importantly less work!

As a result of Yahoo Maps rolling back some functionality in their geocoder, I have had to get rid of a couple of features on the batch geocoder.

First, you will no longer be able to lookup associated 9 digit zip codes for your address list. I am not sure how many of you were interested in this functionality, if you were a fan of it, I’m sorry. Of course you can always use single free zip+4 lookup services like this one.

Second, the exact precision of the geocoded addresses will not be reported any longer. To help deal with this I have added a new feature, it will let you view the street level location of any point on the map just by clicking on it. It be used in place of an image if you haven’t populated the Image URL field. So you can click on points to verify that they fall on the correct street.

Please feel free to post your feedback on these new changes.

Word is that Yahoo will soon disable the JSON output format for their geocoding API, the REST based geocoder will remain. What does this mean? Well the JSON api is what makes tools like our batch geocoder possible. Without it I would need to use a server side proxy, meaning requests going to Yahoo would be coming from our web server instead of the end-user IP. This means the 50,000 per day limit would be set on the server, only 50,000 geocodes total for batchgeocode.com.

Why can’t the the user’s browser communicate directly with the XML based REST geocoding API? Well despite being built with nifty XML enabling features like XMLHttpRequest, modern browsers are held back by security constraints that keep client side scripts from communicating with multiple domains. JSON gets around this problem by using ON-Demand JavaScript to dynamically load content through <script> tags that don’t have the same cross browser limitation. Why do the browsers limit your ability to make calls out using XMLHttpRequest but not by using the <script> tag? Who knows….

What I do know is that I did see this coming, no way is Yahoo going to throw out a free geocoding API with a JSON output format and not think about the possibility of turning it off someday. It was inevitable that a service like batchgeocode.com would be created, and that would inevitably mean that the data providers would complain about such a service. Perhaps this is why the JSON output format was never mentioned on the Yahoo geocoding API reference page?

Still Yahoo is interested in providing geocoding services in their maps, it’s what differentiates them from the competition. So geocoding isn’t really going away its just getting reworked a bit. The whole farm is no longer available for free, but the house still is.