Category: mapping

The main goal of our batch geocoding service is not just to provide map coordinates, but also give a quick platform for those wishing to instantly plot map data on the web without any coding. There are several other sites out there that try to do the same. Wayfaring, MapBuilder, Platial, and so on.

I don’t work in a vacuum, I keep an eye on the competition. I really like the interfaces out there. To a certain extent, they all provide unique features that my service does not. My goal with the batch geocoder was to focus on making a tool that is fast, easy, and lets people work with data they already have.

Sitting down and creating a map by hand using one of these other tools takes quite some time. You must add locations one by one on a map. My service dumps the user name and password concept and lets people create and save maps instantly with no barriers.

Can you edit points one by one and move them around by clicking on a map? No you can’t do that. But I question how many people will create useful maps by creating points one by one. There’s only so many jogging maps, or bike ride maps, or maps to grandma’s house before you begin to question the value. Remember its all about the data… and for data to be useful you need lots of it. That’s why standardizing on formats like tab delimited is a good idea.

The user can keep their data in a file or in a database on their system, instead of on a server somewhere. They can easily edit their data, add/remove columns, etc.. No fussing about with some proprietary interface for editing it online.

Anyway, that’s my take on it. If you have feedback please let me know. I am not opposed to the idea of building in some of the tools that the “other guys” offer, but I could spend time in other areas too.

Yahoo needs international mapping to be a serious competitor to Google Maps in the long run, and recently there have been a few things that hint that international support may be coming.

First, an interesting post by Yahoo Employee Alan Brown, who points out that last year Yahoo acquired a company that provides geocoding on an international level.

Second, more recently, someone noticed that the Yahoo geocoding API is sporadically returning a number for the precision. The number appears to be the most appropriate zoom level for the geocoded point. This could be looked at as a way to make the interface more generic for international support.

Whatever all this means, my guess is just to stay competitive Yahoo will be going international soon. The question is will they be taking all their nifty geocoding features that make a service like ours possible. To stand above the rest, I’d say its probably a good idea.

Amazon recently launched their new S3 Storage service, and everyone seems to be clamoring to figure out uses for it. Well here is my contribution: map tile storage and serving.

Think about it: You want to create your own tile based map delivery (because your boss has been nagging you about it ever since the Google Maps launch), but where are you going to store those gigabytes and gigabytes of images. Not to mention how to deliver them? Stick them all in a database? Write a wrapper script to that? Sounds like an awful lot of bandwidth, cycles, and storage is going to be needed. Imagine every time there is a breakdown, pager goes off and you got to fix it.

Or, get an S3 account and blaze away. I’d bet dollars to donuts that S3 is a heck of a lot cheaper than your average “enterprise” network storage solution. In fact I’ll just tell you: it’s cheaper. The drawbacks, well you won’t have LAN speed access to it, but if your target is the internet who cares. Likely it will take just as long to generate all those tiles as it will to upload them anyway.

I’d also bet that Amazon’s delivery will be much faster with lower latency than what an average sized shop could do on a T1 with a weenie little 4 processor database server. Who knows what sort of super optimized proprietary network, hardware, and software architecture Amazon has put together to make their system work. More than likely its much better than what’s available off the shelf.

Did I mention scalability? Scalability in this matter is just sending more dollars off to Amazon. Assuming your business model has you making more for each visit than you need to spend, you will just keep making more and more profit, no matter how many users show up. Got Slashdotted? No biggie, the server capacity briefly expands to take on the Niagara falls sized volume, and then returns to normal when it has passed. Point is, you captured every bit of the revenue generated from that extra traffic.

So the next question is: after storage, what’s next? Application delivery?

Maybe instead of thinking in terms of racks of servers, we should be thinking of tracking cycles and storage down to smallest possible measurements and paying for only what we need, with endless ability to scale. Developers can add their applications to the Internet Borg cube, and after some marketing, expect to see a linear increase in profits along with traffic. No more hassling over rack space, load balancers, hard drive failures, backups, software licensing, and so on.

Here it comes, the infinitely scalable internet application model. Sustainable growth, just add water.