Best Practices - Bing Maps development

    General discussion

  • This thread is meant to discuss and build a list of best practices for developing Virtual Earth applications. Feel free to add any best practices or "common gotcha's" below for any flavour of Virtual Earth (AJAX control, VE Web services, 3D control, Silverlight control) or MapPoint Web Service.
    Wednesday, May 6, 2009 11:33 PM

All replies

  •  Best Practices for Virtual Earth development (AJAX control)



    1.       To ensure proper rendering of the map use the following meta-tag and DOCTYPE:

      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd ">

    2.       Always specify a position, width, and height style property for the map div.

    3.       If possible specify starting coordinate and zoom level in the VEMap.LoadMap method. This will reduce the number of unneeded tiles that are loaded.

    4.       If a lot of panning is expected then set the tileBuffer property of the VEMap.LoadMap method for better user experience.

    5.       Minify JavaScript files and CSS style sheets.

    6.       If making multiple Find calls in sequence use recursion: http://rbrundritt.spaces.live.com/blog/cns!E7DBA9A4BFD458C5!739.entry

    7.       Use VEMap.SetCenterAndZoom function instead of two separate function calls to VEMap.SetCenter and VEMap.SetZoom.

    8.       Use VEMap.Dispose map on page unload to release browser resources.

    9.       If loading multiple shape layers and allowing user to switch between layers then hide/show layers rather than deleting and reloading.

    10.   UseVEMap. onLoadMap property to process post map load functions: http://msdn.microsoft.com/en-us/library/bb412504.aspx

    11.   Hide birdseye pop-up for better user experience:

      document.getElementById(‘MSVE_obliqueNotification’).style.display = “none”;

    document.getElementById(‘MSVE_obliqueNotification’).style.visibility = “hidden”;

    12.   Create custom navigation dashboard rather than modifying the existing one. This will make it easier to migrate to newer versions of the map control.

    13.   If 3D is not required then disable hotkeys (the number 3), and hide the 3D button. This will ensure that the user will not accidentally navigate into 3D.

    14.   If expecting user to only search within one country then append the country’s name to the end of all addresses being used in find searches if the user has not already specified the country. This will prevent Virtual Earth from searching against the worldwide data and will increase the chances of relevant results being returned. The same applies for addresses being used for driving directions.

    15.   If user is required to scroll the web page to see the map, then consider disabling the mouse scroll wheel event on the map. This will keep the user from accidentally zooming the map.

    16.   Disable the VE disambiguation box that occurs for find searches and create your own. This will give you the developer greater control over its functionality.

    17.   Ensure to enable printing for maps that the users may print. http://msdn.microsoft.com/en-us/library/cc469977.aspx


    Shapes only in 2D:


    1.       add pushpins to a div rather than a VEShapeLayer for performance increases:   http://blogs.msdn.com/virtualearth/archive/2009/04/09/virtual-earth-api-release-information-april-2009.aspx

    2.       If you need a custom pop-up, overlay an absolutely positioned div over the map and move it around. Otherwise use the custom the VEMap.ClearInfoBoxStyles method and specify your own styles. http://msdn.microsoft.com/en-us/library/bb412441.aspx

    3.       Disable shape display threshold when working with only a few polygons/polygons so that there is no loss in shape precision: http://msdn.microsoft.com/en-us/library/bb964367.aspx


    Shapes in 3D


    1.              1.       Always use the VECustomIconSpecification for custom pushpins.




    1.               1.       Use an absolute path for icon images.

    2.               2.       If not using the TextContent property of the VECustomIconSpecification, add a space character instead of an empty string. This is a work around for a bug in VE.




    1.       Ensure that client data is in the proper projection system, WGS84. NAD83 will also work (~1m offset from WGS84 in certain areas of the world).

    2.       Use AJAX to retrieve data rather than post backs. This will allow you to retrieve your data without having to reload the map. This is much faster.

    3.       When working with latitude and longitude coordinates only six decimal places are needed. Any more decimal places will not change the pixel position on the map. This will reduce the overall size of the data being retrieved.

    4.       If there are a lot of pushpins (20+) on the map then clustering should be used.

    a.         If there is 100 of less pushpins then use the VEClusterSpecification: http://msdn.microsoft.com/en-us/library/bb412546.aspx

    b.      If there are 100 – 1000 pushpins use custom client side clustering algorithm: http://msdn.microsoft.com/en-us/library/cc161072.aspx

    c.       If there are 1000+ pushpins use server side clustering  (many algorithms exist)

    5.       Watch for floating point issues when doing calculations with coordinates. http://en.wikipedia.org/wiki/Floating_point#Problems_with_floating-point

    6.       When there is a lot of data, only load data for the current map view. Update data as the user navigates the map.

    7.       If possible run ESRI shapefile polygons/polyline data through a reduction algorithm to reduce the number of coordinates used to represent the shapes. ESRI shapefiles typically are large and use multiple coordinates (20+) to represent a straight line when only two are needed.

    8.       Polygon and Polyline data can be encoded to reduce its size: http://www.soulsolutions.com.au/Articles/Encodingforperformance.aspx


    Wednesday, May 6, 2009 11:34 PM
  • Great idea Richard!

    My favourite - make sure your page accepts compressed content to cut down the size of the VE API download:

    Add the following to the <head> of your web page:

    <meta http-equiv="Accept-Encoding" content="gzip, deflate" />

    This will also help when you're serving vector data via AJAX - but don't forget to set your web server compression on.
    Thursday, May 7, 2009 12:12 AM
  • Excellent list! You've certainly covered 90% of the most common rules. To the 'data' section, I would add:

    - "If plotting complex shapes that are relatively static, and which you don't need to be able to interact with, use a tile layer rather than a shape layer."

    - "To generate your own background tiles you can use MSR mapcruncher. If you want to replace the default VE tileset completely with your own tiles then set the LoadBaseTiles map option to false when calling the LoadMap method"

    Also just to provide a few additional comments on the existing rules:
    "....13.   If 3D is not required then disable hotkeys (the number 3), and hide the 3D button."
    Rather than hide the 3D button (using CSS), you should set the showSwitch parameter of the LoadMap() method to false. (I'm sure this is what you meant, but just to clarify)

    "... 1.       Ensure that client data is in the proper projection system."
    Absolutely! It might be worth mentioning that if you do have data projected in NAD27, or the British National Grid, for example, then you can reproject it into WGS84 using freely-available FWTools (http://fwtools.maptools.org/)

    "...7. ...ESRI shapefiles typically are large and use multiple coordinates (20+) to represent a straight line when only two are needed.
    I agree with the comment that shapefiles should be reduced, but we need to be careful about the concept of 'straight lines' and how many coordinates are needed... because I would argue that it is Virtual Earth that handles these incorrectly rather than shapefiles.
    Consider an ESRI shapefile with a single 'straight' linestring drawn between two coordinates at (34, -118) and (52 ,0), representing a route between Los Angeles and London. These coordinates are measured in WGS84, which uses geographic coordinates on an ellipsoidal model of the Earth. The shortest 'straight' line route between these two points, when projected onto a Mercator map, is therefore:

    Howevever, when you plot the Polyline in Virtual Earth you don't get this route, but rather you get the 'straight' line connecting the two points in the Mercator projection, as follows:

    To make sure that the polyline on Virtual Earth actually follows the great circle arc representing the true shortest route between these points, you have to add in additional anchor points along the line. So, although it may seem to be 'unnecessary' to have multiple points lying along a straight line, it is required because Virtual Earth does not truly handle geodesic shapes.

    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Thursday, May 7, 2009 7:42 AM
  • Great Post Ricky!
    Friday, May 8, 2009 4:56 AM
  • Nice list guys, I would also:

    Load the map on demand:

    When storing latitude and logitude in a SQL database use "Float".

    In SQL2008 although you can store a Point as a geography if your simple going to query on a rectangular bounds then two floats (lat, long) and a between where clause is faster.

    The combination of removing comments and compressing your javascript file is plenty to minify it, don't waste your time replacing varible names with shorter ones etc. One image tile from VE is likely to be larger then any saving you will make!

    If your serving from HTTPS then use the SSL version of the API.

    Save the state of the map (centre, zoom, mode, style) to a user's cookie to return them to where they left off next time.

    Only create the map after the document body has fully loaded:
    Jquery example here:
    and generic one looks like this:
    //set page event handlers
    if (window.attachEvent) {
     window.attachEvent("onload", Page_Load);
     window.attachEvent("onunload", Page_Unload);
    } else {
     window.addEventListener("DOMContentLoaded", Page_Load, false);
     window.addEventListener("unload", Page_Unload, false);

    For commerical applications you set a token, remember to use the ontokenerror and ontokenexpire events wisely.

    Handle known non-supported browsers gracefully, give them a text interface or use static maps from VEWS.

    When geocoding use the country code if known at the end.

    When building a VE application for a customer give them an option for a yearly upgrade to the latest version.

    And lastly....
    If you override/change/use an undocumented feature, expect it to break in the future. Some times you have to do this but factor in some maintance when it happens.

    Windows Live Developer MVP - www.soulsolutions.com.au - follow http://twitter.com/virtualearth for latest VE news.
    Friday, May 8, 2009 9:42 AM
  • Some great responses thus far.

    Another best practice when dealing with any of the services that require credentials is to not store your credentials directly in the source code. For security reasons, you should move these string values to a protected data store.

            - For a desktop environment, you can leverage the Cryptography Application Block and DPAPI to properly secure the sensitive information. http://msdn.microsoft.com/en-us/library/cc511731.aspx

            - For web applications you can store your credentials in a protected configuration file.

    A general best practice is to log any exceptions that occur in your code behind. This will make it easier to track down bugs in the future.
    Friday, May 8, 2009 3:44 PM
  • If Virtual Earth cannot handle geodesic, then they need to put in more work. That means they cannot use it for an airline flight tracking applications. Maybe it is time to check out the ESRI SDK.
    Sunday, May 17, 2009 12:09 AM
  • In Virtual Earth you can draw the geodesic path if you have the information for the path. ESRI shapefile tend to have enough points to draw such paths. However, geodesic paths are not always needed. If you only have the end points it is pretty easy to generate additional points to create a geodesic path. All that need to do is calculate multiple points along the path. Alternatively, the 3D control of VE already shows the correct geodesic path when only two points are used to draw a path.

    I do agree that ESRI does have it's uses but in a lot of situation it's overkill. When it comes to mission critical mapping situations where accuracy needs to be in inches ESRI is a much better solution than VE.

    Windows Live Developer MVP - http://rbrundritt.spaces.live.com
    Thursday, May 21, 2009 2:12 PM
  • Back to Best Practices:

    1) Use the content delivery network of VE for better performance:

    2) Use the Chinese API for applications in China:




    3) Use the India API for applications in India:




    Windows Live Developer MVP - http://rbrundritt.spaces.live.com
    Thursday, May 21, 2009 2:17 PM
  • Since I was in geomatics (Geodetic Survey to be specific) before changing career to software development; Virtual Earth is a "sexy" product much like Google Map that will appeal to the general public. It is not and never should be treated as a Geographic Information System, if you need GIS then you will need to use ESRI products. Unless you need a Virtual Map application that display aviation routes around the world, it is very unlikely IMO that you need to show the arc of the great circle (geodesic) on the screen.

    Calculating geodesic requires spherical trigonometry which is too complicated to most users. You can see the formula here: http://gc.kls2.com/faq.html#$gc-calc It is tough enough to explain that most people use grid coordinates instead of geodetic coordinates (lat / long) in everyday application. Then you have to explain to some of these people the Height you get in geodetic coordinates is measured from the center of the geodetic system and not the same as elevation from mean sea level.

    Saturday, May 23, 2009 3:09 AM
  • I disagree H Lo. We are using Virtual Earth to suppliment ESRI ArcGIS to bring the power of GIS to a broader audience within the organisation. Although the power users still need the full features of ArcGIS, business managers and many users like the simple and fluid interface, the instant access to all information from one place and the rendering.

    I believe that Virtual Earth will not replace desktop GIS anytime soon but it does make a great information system for many purposes and expands the audience. If you consider VE as the data visualisation front end to the GIS there is no reason why the calulation can't be made in SQL2008 or SDE and then shown in VE.
    Windows Live Developer MVP - www.soulsolutions.com.au - follow http://twitter.com/virtualearth for latest VE news.
    Friday, June 5, 2009 1:43 PM
  • I agree with SoulSolutions - VE and Google Maps are no longer the pretty 'spinny globes' that many GIS users used to dismiss them as - they are increasingly being used as front-ends for serious spatial applications.

    As for geodesic shapes - the point I was making (and the reason why it was relevant to this thread!) was that in order to plot geodesic lines on the map, you cannot simply state the start and end points - you need to include the relevant anchor points along the route to prevent the lines being plotted as simple straight line on the map projection. So it is not necessarily 'best practice' to remove seemingly unnecessary points. In geodesic terms, the shortest line connecting the points at lat/lon
    (30,0) and (30, 100) does not pass through (30,50), so if you remove that point you are altering the line.

    I agree that this may be a tricky concept for most users, but it's not users that need to worry about the details - it's developers. I posted a solution about how to plot great circle arcs on VE here: http://www.beginningspatial.com/plotting_geography_linestrings_google_maps_and_virtual_earth

    Apologies for taking the thread off-topic again. On with the best practices!
    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Friday, June 5, 2009 2:29 PM
  • Nice post... especially since the line looks so much better in Bing!

    Windows Live Developer MVP - http://rbrundritt.spaces.live.com
    Wednesday, June 24, 2009 10:18 AM
  • Hi ,

    I am working on microsoft virtual map control.

    how to zoom virtual maps when user select two cities with line mark.

    Could you help me on this? if you have any code, could you share to me



    Murali Krishna.Konanki
    Saturday, August 8, 2009 3:12 PM
  • Great thread - there really should be some way of making a few threads in this section of this forum "Sticky" - ie - always at the top of the list.

    Otherwise no-one will ever find stuff like this.
    Wednesday, November 4, 2009 4:12 PM
  • It was but sticky posts expire, I'll pop it back on again.
    Windows Live Developer MVP - www.soulsolutions.com.au - follow http://twitter.com/bingmapsdev for latest news.
    Wednesday, November 4, 2009 10:57 PM
  • Great Post Richard.

    This post may be useful for some one who wants to draw a shape on VE map and want to persist it into database which is SQL Server 08.

    The standard rule we follow is to persist all shapes in the form of SQLGEOGRAPHY in database. We take the shape from VEMap, load it into SQLGEOMENTRY first (as the virtual earth points are flat earth) and then convert it into SQLGEOGRAPHY. In the same way when accessing data from virtual earth, we take SQLGEOGRAPHY, convert into SQLGEOMENTRY and pass the points to VEMap. This helps us to maintain one standard on the database level and when we use FME or any other software to mine the data directly to databse, we does not need to worry about the projection as I guess that would be taken care for virtual earth while SQLGEOGRAPHY is converted into SQLGEOMETRY.

    The convertion is done on the C# level by using SqlServerSpatial.dll and Microsoft.SqlServer.Types.dll

    And this is where I got into this problem http://social.msdn.microsoft.com/Forums/en-US/sqlspatial/thread/bd5235f1-1ca7-4223-a3d4-b4eac3a70da8 

    Thats were Ed ask's us to use WKB for tranforming data between SQLGEOMETRY and SQLGEOGRAPHY. You can also see the link here http://blogs.msdn.com/edkatibah/archive/2008/08/19/working-with-invalid-data-and-the-sql-server-2008-geography-data-type-part-1b.aspx

    Wednesday, November 18, 2009 4:49 PM
  • For a web application using the AJAX control, what is the best way to store the credential key?
    Friday, March 19, 2010 7:24 PM
  • Best Practice: If you're using SQL Server and need to search for point location, be sure to create a US Geom Spatial Index.   I used the US max/min lat/longs (rounded values) to help with the grid bounding box.  The performance enhancement, well at least for my application, was amazing.

    CREATE SPATIAL INDEX si_ctsGEOM ON dbo.MyTable(MyGeomColumn)
    grids = (level_1 = medium, level_2 = medium, level_3 = medium,level_4 = medium),cells_per_object= 16);

    Hopes this helps your map application!

    Wednesday, June 2, 2010 4:11 AM
  • It's worth mentioning that the last post is only applicable if your data lies only in the mainland US.... ;)

    To generalise, having a tighter bounding box around your data will make each of the index cells more granular, leading to less false positives from the primary filter and more efficient querying.

    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Wednesday, June 16, 2010 9:19 AM