Original URL: http://www.theregister.co.uk/2008/05/16/virtual_earth_visual_studio_20082/

Virtual Earth puts human face on data

Lightweight programming, minus Google

By Mark Whitehorn

Posted in Applications, 16th May 2008 05:02 GMT

Project Watch: Microsoft 2008 Those who have been following Project Watch will know that I have been leading the development in a large database project using SQL Server 2008, Windows 2008 and Visual Studio 2008.

Relatively heavy stuff. Part of that project, though, involves the creation of a mashup that displays our spatial data on a map - yes, I know, all very Web 2.0, but something that improves the experience for the user. People look at a web page and enter some value (a time period, or a location and a radius), click a button and lo, the relevant spatial data is displayed with points on a map.

In practice the web page talks to a web service, which talks to the database. That returns a data set to the service, which punts it up to the web page and the data is displayed on a map retrieved from Virtual Earth. Easy.

Why did we pick Microsoft's Virtual Earth rather than rival Google's offerings, which have been getting most play when people talk of map-related mashups?

Well, let's reverse the questions. Why Google? Why not Virtual Earth? Both are excellent mapping services. You might imagine that Virtual Earth would integrate better with Visual Studio but it's Just Another Programming Interface, or JAPI, as far as the code is concerned.

So, we could have chosen either but, since everyone is talking about Google, just to buck the trend, we decided to try out the underdog for our initial testing. It seems to be working fine, so we'll probably stick with it.

How did we get to this point? Starting with the web page, it needs some sort of interactive component that allows the user to enter input. In this case we've used a text box and a button. The text box lets the user enter the year for which data should be displayed and when the button is clicked, the contents of the text box are whizzed off to the web service.

The code below describes the user interface bits:

   <tr>
        <td colspan=2 align=center>
            <b>Locations in Year</b>
        </td>
    </tr>
    <tr>
        <td>Year:</td>
        <td><input type="text" id="yearTextBox" size="10"
                   maxlength="4" value="2008" /></td>
    </tr>
    <tr>
        <td colspan="2" align="center"><button onclick="getbyyear()"
          title="Find locations for the specified year.">Find</td>
    </tr>

Once the button is clicked, it calls a function called getbyyear:

    function getbyyear()
    {
        // fetch value from webpage
        var year = document.getElementById('yearTextBox').value;
   
        // use standard web service call
        microsoft.samples.com.ILocationDataService.GetLocationsForYear(
            year, onSuccess, onFailure); // Pass to web service
        
        document.getElementById('SearchingText').innerHTML =
          '<b>Searching...</b>';  // feedback to screen

Once the button is clicked, it calls a function called "getbyyear":

microsoft.samples.com.ILocationDataService.GetLocationsForYear(
    year, onSuccess, onFailure);

The function declares a variable called "year" and goes to the web page where it fetches the value in the text box called "yearTextBox" (say, 2004). A call to the web service is initiated by the following line:

microsoft.samples.com.ILocationDataService.GetLocationsForYear(
    year, onSuccess, onFailure);

This calls "GetLocationsForYear" in the web service and passes to it the value from the text box (2004). The web service sends the value to a stored procedure that in turn launches a query to fetch the data from the database.

The data set is returned to the method in the web service and, whilst this is happening, the text "Searching..." is displayed on the web page to provide feedback for the user.

If the transfer of data was successful, the function onSuccess is called.

    function onSuccess(result)
    {
        if (!layer)
        {
            layer = new VEShapeLayer();
            map.AddShapeLayer(layer);
            map.ShowAllShapeLayers();
        }
        
        layer.DeleteAllShapes();
        
        document.getElementById('SearchingText').innerHTML
            = 'Processing results...';
        
        for (var count=0; count < result.length; count++)
        {
            document.getElementById('SearchingText').innerHTML
                = 'Processing result ' + (count + 1)
                + ' of ' + result.length + '.';
            AddPoint(result[count].Name, result[count].Latitude,
                     result[count].Longitude);
        }

        document.getElementById('SearchingText').innerHTML
            = result.length + ' matches found.';
    }

The first five lines after the function name inquire if a layer is present: if there isn't, one is pulled in. Then any existing shapes superimposed upon the layer are erased.

Feedback ("Processing results...") for the web page user is provided again, and then a loop is entered that processes the returned data set row by row and adds a point for each location. Once each row has been processed, the number of matches found is displayed on the web page.

The mashup is now complete: data has been selected by the user, has been returned by the database and is displayed graphically on a Virtual Earth map.

The code needed to make this mashup work was easy to write using Visual Studio 2008. So are we trying to get you to use Visual Studio 2008? No. We don't care. The point isn't that it's any easier in any other code development tool of your choosing, but that it's easy to create mashups that provide useful interactive web-based tools.

If you are already writing web services, adding a mashup on top is trivial. Code for the web service ran to a mere 77 lines, not counting comments or lines containing a single bracket. (Although these are, of course, vital for the readability of code, they aren't exactly a taxing part of code writing and so they were ignored for the line count). The web page code was fractionally shorter at 75 lines, counted on the same basis.

So go on: create a mashup in your lunch break. You know it makes sense.®