Getting Started with Virtual Earth

Getting started with the development of location based applications has never been easier than with Virtual Earth. You do not need to sign-up for a developer account; you can just visit the Software Development Kit (SDK) and start on your application immediately.

The “Interactive SDK” enables you to explore implementations of frequently used features. You can have a closer look at a real application in Virtual Earth and then flip through the tabulators to display the complete source code for this particular website or to review the reference for this feature. With just one mouse-click you can copy the complete source-code and with a second paste it into an empty HTML-document. Of course, there is also a traditional reference SDK available. There is an online version on the MSDN as well as a downloadable version in CHM-format. These resources as well as a forum and links to blogs and community sites can be found in the last tabulator.

The Application Programming Interface for Virtual Earth is an AJAX-Control and the coding is done in JavaScript. AJAX stands for “Asynchronous JavaScript And XML” and its main advantage is the partial page update. While a web service always requires a request and response for the complete page, an AJAX-enabled application allows you to refresh just parts of the website, e.g. you can pan and zoom the map without refreshing the content around the map or you can add and remove layers without reloading the background. The Virtual Earth map control is such an AJAX-control and it will access a number of different services in the Microsoft data canters for example to geocode addresses, search in business listings or calculate routes. It will also contact so called “tile servers” from where it retrieves small raster tiles with a side length of 256 pixels. These tiles can be pre-rendered roadmaps or imagery with different levels of detail and they always cover a fixed geographic area. The tiles are organized in a quadkey-structure which is further explained in a whitepaper on the Microsoft Developer Network. Basically, there is a distinct relationship between the name of the tile, the geographic area it covers and the zoom-level. The Virtual Earth map control will determine which area you want to display at what zoom-level and it will contact the tile servers to retrieve the necessary tiles and stitch them together in the client’s browser.

We have several ways to add content to Virtual Earth. Of course we can directly add addresses or business listings from a search within Virtual Earth but we can also add data from different sources. To do so we need to understand the objects in Virtual Earth. The top-level object is the VEMap. To a VEMap-object we can add one or more VEShapeLayers to which again we can add one or more VEShape-objects of type Pushpin, Polyline or Polygon. Each of these VEShapeLayers and VEShapes can have a z-index to control which one is on top, from a visual perspective.

Besides adding individual VEShape-objects to a layer we can also import complete datasets from GeoRSS-feeds or from KML, KMZ or GPX-files. GeoRSS is a modification to the well known Real Simple Syndication (RSS) which adds another tag for point, polyline or polygon information. The Keyhole Markup Language (KML) or the compressed (zipped) version of it (KMZ) had originally been developed for a product called Keyhole which is known today as Google Earth. This markup language is currently being standardized by the Open Geospatial Consortium (OGC) and is already very common. GPX is a XML format for waypoints, tracks and trails, used by many GPS (Global Positioning System) devices.

All of the above mentioned formats add vector data to the map, i.e. you define geometries by one or more pair of coordinates - in this case latitudes and longitudes. While this is often the preferred format it can have disadvantages when the number of points increases. For instance if you need a highly accurate representation of the coastline of Norway this will require at least some 10,000 points and the handling of this many points through JavaScript is very CPU-intensive (and in some cases just too slow). To overcome this limitation you can rasterize such complex data and add that data to Virtual Earth as a raster layer. Such raster data can come from your own tile data source or they can come from a Web Map Service (WMS) which is compliant to the Open Geospatial Consortium’s (OGC) standard.

The simplest way to create your own tile data source is to use the MapCruncher. It allows you to manually georeference an image by defining map-correspondence points. You load an image into the workbench and move a distinct point under the crosshair in the left window. Then you move the related location in Virtual Earth under the crosshair in the right window and once you have a few points (at least 3) you can lock the view which re-projects the image so that it fits to the geography. Now the MapCruncher can do its main work and cut down the image in pyramid layers and tile structures which follow the Virtual Earth naming convention.

Once you have the tiles you just have to put them into a virtual directory on your web server and then you can call the method VEMap.AddTileLayer to overlay these tiles on top of the Virtual Earth base-layers. Don’t worry about the details of this method for now - we will discuss that a little bit later in more detail when we actually use it. Below you find a graphics of the principle: When the application loads in the client’s browser it will get the skeleton of the website form your web server but it loads the Virtual Earth map control and the Virtual Earth tiles from the Microsoft data centers. To overlay your own custom tile layer it will contact your web server again and retrieve those tiles which have the same name as the ones which are currently displayed.

(to be continued)

*