Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

gnat (29)

  (email not shown publicly)

Journal of gnat (29)

Friday April 12, 2002
05:30 PM

Commercial Web Services

[ #4163 ]
Microsoft has announced MapPoint.NET, a web service interface to geospatial data:

MapPoint .NET is a programmable XML Web Service hosted by Microsoft. Within the hosted domain, Microsoft has aggregated valuable data such as cartographic data (the detailed maps and routable streets), points of interest (landmarks, hotels, restaurants, etc.), road construction and in the future up-to-the-minute and historical traffic information, demographic data, real-time location and more. The data is then accessible through a SOAP API that allows you to calculate point-to-point driving directions, render a map, find or geocode a location, and search nearby places. Companies that want to run a proximity search or query on their locations can leverage the MapPoint .NET Customer Services Site to upload their POI (points-of-interest). This highly secure Extranet provides an easy to use interface for updating your location data and managing your MapPoint .NET subscription.

The MapPoint .NET programmable XML Web Service was built using Visual Studio .NET and leverages the .NET Framework. MapPoint .NET can be easily integrated into other Web Services. With a detailed WSDL (an XML description document) and Visual Studio .NET, it is as simple as knowing the following URL and creating a Web Reference.

The full text of the announcement is here.

That's cool and useful and something MapQuest should have done a long time ago. What's really interesting is the pricing:

$15,000 for 2 Million Transactions (Flat rate)
$299 per user for you to build an internal application
Per transaction of $0.01 (Have to purchase in blocks of transactions like Cell Phone Minutes)
Negotiated rate for larger usage

This is why Google released their SOAP interface. If they don't service the market, someone else will do it. As has been recently pointed out, Google's toughest search is for a business model. (see the google blog for various google news) If charging for high-volume access isn't already part of Google's terms and conditions, it will be soon.

Google's been good and offered limited use of their service for free (1000 queries/day). Other free services will only follow if there's public pressure and support for the free services. That brings me to the main point of this essay.

I'm reminded of Laurence Lessig's call to develop software that implements the kind of world we want. Right now there is a lot of useful free content on the web, and very few useful web services (free or otherwise). One future I can easily see developing is the migration from free content in HTML to paid access to the content via SOAP.

If no-free-access web services become the norm (and content providers would love this--they are struggling to stay alive with free content and paid advertising) we could easily see a lot of the good, interesting, and fun free content disappear from the net.

So we have a two-fold obligation: to build our own free web services, and to support free services such as google. The alternative is a massive migration from free content to subscription-only services.

I used to think that my glorious leader was off-base in his insistence that web services was anything but a stupid idea. The massive takeup of google's automated search, and the obvious steps Microsoft are taking to make money off them, suddenly made me realize that Tim was basically right. I hate it when that happens :-)


The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I never thought web services was a stupid idea. I just thought it wasn't a *new* idea. Still don't. There's nothing in web services that couldn't be done almost as easily with straight HTTP requests, like this []. Web services just make it a little bit easier (OK, in some cases, a lot easier; but in some cases, considering the learning curve for the server side, a bit harder, too).

    That said, I've always like getting little snippets of data from the web such as the above Yahoo! request, and SOAP/XML-RPC, b