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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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
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
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)
USING GEOMETRY_GRID WITH(
grids = (level_1 = medium, level_2 = medium, level_3 = medium,level_4 = medium),cells_per_object= 16);
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