Earthware Blog

Over the past four years here at Earthware we have encountered a number of performance challenges when creating mapping applications on the web. We thought it might be helpful to bring together the 5 most common issues we’ve encountered, both when helping other developers or in some of our older mapping projects.

It’s unfair to call these mistakes, rather they are missed opportunities to make your mapping really fly. They are not exclusively focused on specific mapping API’s or web programming languages / frameworks so they should be applicable to the majority of web mapping applications with a little translation.

So in no particular order:

1. How accurate do you really need to be?

We often come across systems or code samples that both store, but more importantly transfer their position data (usually pairs of lat/lon) to very high levels of decimal places (often 13 or more decimal places). Did you know that 8 decimal places of accuracy is a real world value of 1.11 millimetre (at worst when on the equator). How many systems have you worked on that require you to map to 1.11 millimetre accuracy?

So assuming that for most of us meter accuracy is plenty enough we can reduce our values to only use 5 decimal places (1.11 metre accuracy). When transferring either points, or more importantly polygon data reducing your data from 13 to 5 decimal places is likely to decrease the amount of data you are transferring by at least half.

Typical speed improvement: 50%!

2. Load small, load often

Many mapping applications allow the user to drill into the detail of the data shown on the map. In the majority of cases the user does not require the full details of every single piece of data so why bother loading them all?

Typically in the mapping applications we encounter the initial view a user is presented with has a number of pushpins / polygons maybe with a text label and or an icon representing the ‘type’ of data shown (like a hotel, house, pipe etc). So the data we need to initially load for each point is a title, latitude, longitude, type and unique id. We don’t need to load all the description, photos, links or other data that will not be shown until the user clicks the icon/polygon.

At Earthware, the way we normally handle this is to have two services, one that returns the initial map data that matches our query, and one that returns the full details for a single selected entity. You can code your map so that it makes a call to the “full details” service when a user clicks a map entity and in our experience returning the data for a single entity is usually so quick the user doesn’t even notice the slight pause.

To see an example of this service architecture using asp.net and Bing Maps see http://bingmaps.codeplex.com/wikipage?title=Getting%20Started%20in%20Web%20Services&referringTitle=Home

Typical initial map load improvement: > 500%

3. Don’t repeat yourself

Often when helping developers improve their JavaScript map performance we come across an approach to loading the map data that we don’t recommend except in the most simplistic applications. That approach is to generate the JavaScript code on the web server that is used to create entities on the map and to pass this chunk of JavaScript back to the client and execute it there. For example, we see a service return the following JavaScript:

var pin = new Microsoft.Maps.Pushpin(52.011,-0.221, {text: '1'});
map.entities.push(pin);
pin = new Microsoft.Maps.Pushpin(53.011,-0.121, {text: '2'});
map.entities.push(pin);
pin = new Microsoft.Maps.Pushpin(51.011,-0.251, {text: '3'});
map.entities.push(pin);
pin = new Microsoft.Maps.Pushpin(50.011,-0.321, {text: '4'});
map.entities.push(pin);
pin = new Microsoft.Maps.Pushpin(54.011,-0.143, {text: '5'});
map.entities.push(pin);
pin = new Microsoft.Maps.Pushpin(55.011,-0.0123, {text: '6'});
map.entities.push(pin);

This approach seems to be popular with developers because it’s quick and simple to achieve. However, the downside is that you are constantly repeating the same long text phrases and transferring all these repeats to your user, thus slowing down their mapping experience to make it easier for you to code. This data could be sent in a simple data structure, like JSON, and with some simple code looped through and added to the map. The same data above in JSON would look like:

{points:{point:[{title:1,lat:52.021,lon:-0.211},
  {title:2,lat:53.011,lon:-0.121},
  {title:3,lat:51.011,lon:-0.251},
  {title:4,lat:50.011,lon:-0.321},
  {title:5,lat:54.011,lon:-0.143},
  {title:6,lat:55.011,lon:-0.0123}

]}}

To see an example of this data transfer architecture using Asp.net, JSON and Bing Maps see http://bingmaps.codeplex.com/wikipage?title=Getting%20Started%20in%20Web%20Services&referringTitle=Home

Typical map data load improvement: > 100%

4. Some data you just can’t load fast enough

As we have recently blogged the latest Bing Maps AJAX API is now even faster at showing pushpins on a map, but there is still a limit especially when you are working with older browsers. If your data consists of thousands of entities then it won’t take long before you either cannot transfer the data fast enough or the performance of your map is too slow.

So what can you do? Your users still need to be able to search all the data so you cannot just remove some. The most common solution to this problem is ‘clustering’ of map entities. This is where you group together nearby or overlapping entities and only show individual entities once the user has zoomed in. This can be achieved either using client side code (see http://rbrundritt.wordpress.com/2011/03/02/client-side-clustering-in-v7/) or on the server side before you transfer the data to the client (see http://www.viawindowslive.com/Articles/VirtualEarth/ClusteringVirtualEarthwithMSAJAXandC.aspx). The advantage of doing this on the server side is that you do not have to transfer the data for each individual entity but instead can just transfer the data required to show the ‘clustered’ entity.

There are other approaches to this problem including generating rasterised image tiles of your data and only showing interactive map elements once the user has zoomed in. This works just as well for pushpins as it does polygons. A good example of this ‘hybrid’ approach is the open source ajax map data connector project on codeplex: http://ajaxmapdataconnector.codeplex.com/

5. Transferring data as plain text is soooo slooowwwww

We have already discussed ways of optimising the data you send your clients (in 3.) above but that approach still ends up transmitting plain text data to your clients. There are much better binary formats you could transfer the data in that would massively reduce the size of your transfers.

The first and easiest of these is to use a compression format called Gzip that is seamlessly built into all modern web browsers and plugins (Flash and Silverlight). If on your web service you compress all your map data using Gzip your clients browser will be able to atomically decompress the data ready for you code to use without you having to change you client side code at all. Gzip compression is usually very simple to enable on your web service (see these links for apache, iis6 and iis7).

This approach doesn’t just apply to data transfer or mapping and (if you are not already) you should look at compressing other ‘static’ files like your JavaScript and css.

If you are using Silverlight to load data from WCF services then an even better solution is to use the built in binary http protocol.

There is usually a slight CPU cost to compressing the data but on a modern processor this is minimal and well worth the decrease in data transfer sizes.

Typical map data load improvement: > 50%

In Summary

Hopefully some or all of these issues might help you make a real, measurable difference to your applications performance and many of them are quick and simple to achieve. We would love to hear your real world performance improvements if you do use any of these tips so please feel free to share them in the comments section below.

We always say that displaying data on a map is one of the best ways to bring information to life, especially when the information has a geographical element. One obvious place where this is true is when looking at the pattern of earthquakes. The US Geological Survey publishes a list of recent earthquakes. However, a list doesn’t show the patterns or relationships in the same way that displaying this data on a map will.

Which is why, given recent events in Christchurch and Japan in particular, we have done just this – embedded USGS’s earthquake data in a Bing Map using Silverlight technology to create a mapped sequence of earthquakes between 7th and 11th March 2011 as recorded by USGS).

In the sequence you can clearly see the build up of earthquakes in the northern part of the Ring of Fire along the Aeultian Islands starting from the 7th of March 2011.

As well as watching the sequence of events from 7th to the 14th of March 2011, you can experience the last seven days earthquakes or just the last one:

Last seven days of earthquakes in mapped sequence

Last day of earthquakes in mapped sequence

For a more detailed view of the locations experiencing major earthquakes during this period watch our video of the sequence.

In the second part of our series we show you how to upload the xml data you created in part 1 using a simple console application.

The next and final part in this series will show you how to create a simple JavaScript map application that displays data from the Bing Maps Spatial Data Services.

We will release the full source code for these series as soon as the last part is complete.

Introduction

Twitter is a great service that has given the average person in the street a way to share his opinions and criticism of just about anything with the world. Receiving accurate and well thought out criticism is one of the best ways for companies to improve their products and services, at Earthware we have learnt a lot over the years by listening to what others think about what we do and trying to improve in those areas.

The problem with the two points above is that too often Twitter’s instant availability and it’s 140 character limit has made us all a bit lazy when sharing our opinions and criticism and made us tend to exaggerate or generalise our feedback.

The aim of this blog article is to explore this problem a little further, specifically relating to the opinions and criticism we see shared about two of the most popular mapping platforms Bing Maps and Google Maps.

Comparing apples & pears

Its often difficult to compare two things that arrive at very similar results but from different directions. As a simple example of this lets compare the following two cars:

Both of these are great sports cars and the result of talented engineers and designers but when comparing individual characteristics they are very different and it would be too easy to suggest one of them is much better than the other.

For example let’s compare the top speeds of both, without a doubt the Ferrari is by far the fastest almost 100% faster. However if we compare the emissions of both the Tesla Roadster, being electric, is by far the best performer (assuming you charge it from a zero emission source) and blows the Ferrari away.

If we say one car is better than the other, because one or more characteristic is better, does that mean the other car “sucks”? I think we can agree that’s not true, it’s just that one car or the other will suit the owner depending on what criteria they see as most important to them.

Bringing this back to the world of mapping hopefully you can see how untrue it is to say that one mapping platform “sucks” compared to another if you are only comparing one feature, for example road mapping styles.

Comparing building materials vs. the builder

So if it’s difficult to compare two products by only looking at one, or two, characteristics, or only those that apply to one person’s needs, how about comparing two products that set out to create the same result but one is clearly better? Again let’s compare two cars:

If someone offered you either of these cars for FREE I’d be surprised if anyone would take the Skoda. Skoda are not exactly know for creating the best build quality or the most stylish cars in the world (they are known for their value but we are talking about a free car). VW however are well known for their quality and reliability and have some stylish cars. Both these cars are created from the same raw materials in fact some models share the same engine and some of the same parts so why is the VW Golf a much more popular car, winning many more awards?

It’s a combination of factors potentially including the time spent building and designing the car, the quality of the tools used to build them and the talent of the engineering and design teams involved.

Brining this back to the world of mapping this means it’s often difficult for consumers to differentiate between how well a website has implemented and designed their mapping vs. how good the mapping platform they are using actually is.

Too often at Earthware we see users complaining about Google Maps or Bing Maps when actually it’s that the site they are using the maps on has either not spent enough time implementing their maps or their development team doesn’t have much experience creating mapping applications.

Taking a closer look at some common mapping criticisms

Here at Earthware we think both Google Maps and Bing Maps are great mapping platforms and we have used both of them in a variety of client’s mapping projects depending on which one fitted the client’s needs better at the time.

However both platforms are not identical, they have some features in common and some very different. Both platforms have areas in which they are better than the other for some, or all, of the specific client needs. Below are some of the more common criticisms we see and some insight into why these features may differ / ‘are perceived as better’ in one platform or the other.

• Bing maps road map/labels suck

  Recently Bing maps have released a new style for their road maps which have received some praise, and a lot of negativity. Why would Bing change their road map style to something that some people don’t like as much as their old style? Surely there is a reason or do they just not care?

  Digging a little deeper we can start to find the answer, and an angle that suggests Bing Maps may actually be on to something for that is actually better than Google for some uses. Bing actually spent a lot of time and money, and worked with some great talent at Stamen, to produce this new style, but they were aiming for a different goal than Google.

  Bing’s goal for the redesign was to help mapping developers, like Earthware, showcase their data on maps without the bright and colourful maps taking over the show. The new ‘muted’ colour scheme makes it easier for users to concentrate on pushpins and data shown on top of the map. The downside of this is that consumers who are trying to read the labels and roads on the map, without much or any extra data being shown, are now arguably finding it more difficult to read.

  So many peoples perception is that Bing Maps road style ‘sucks’ compared to Google’s. Hopefully you may now see that it does indeed ‘suck’… if you are using it in one particular situation.
  

• Bing/Google maps aerial imagery suck

  Another common complaint is that the aerial imagery available is much better in one platform than the other. The problem here is that it may indeed be worse on Google than Bing but is that just in the town/city/country you are interested in? Elsewhere in the world you will often find a different story.

  Also, you will often find it has a lot to do with when you are comparing them, Bing and Google release imagery at completely different times and have very different plans for when and where to take aerial imagery. You may find Google is better this month, but then Bing release more up to date imagery at the same location a month later.

  Again it’s perhaps easier now to understand why it’s not perhaps not a fair comparison of an entire mapping platform’s coverage if you are just focusing on where you want aerial imagery.
  

• Bing/Google birdseye/streetview is much better

  Users are often amazed by Bing’s birdseye imagery, or Google’s street view imagery and judge the other platform as ‘sucking’ because they either don’t have birdseye/streetview or don’t have the same coverage worldwide. 

  Both birds eye and streetview imagery are brilliant experiences and are useful in different circumstances. For example when searching for a new house streetview really gives you a clear indication of what the front of house looks like as well as the roads around the house. Birdseye however lets you see what the entire area looks like including the back garden and nearby parks. Both are useful if different ways and neither ‘suck’ compared to the other.

  The other common comparison we hear is the coverage Google have in streetview vs. the birdseye coverage Bing have. With Google having streetview over huge areas of Europe and North America it’s easy to think Bing’s Bird’s eye coverage of only major metropolitan areas in these countries is not as impressive an achievement. However consider the following as it might start to seem less of a valid comparison:

  1. Streetview can be taken on any day it doesn’t rain/snow, birdseye can only be taken on cloudless days
  2. Streetview is taken using any normal car, Birdseye is taken from a plane. Costs and laws applying to the use of these two is vastly different.
  3. Streeview required specialist cameras but they are nowhere near as expensive as the cameras and lenses required to take imagery from a plane.
  4. Capturing an entire city in streetview only captures the streets and the areas visible from the street, a small fraction of what birdseye captures with every square metre of the city.
  5. Streetview does not have to combine as many images, taken at different times, from different angles and heights. The sheer processing involved in producing quality aerial imagery let alone birdseye imagery is vast in comparision.
     

• TheWebsiteIUse.com’d new maps ‘suck’ because they have moved from Bing/Google to Google/Bing

  Lastly we often hear complaints from regular users of various websites when that website changes the mapping platform they use. Their complaints are usually a combination of the following factors:

  1. They were used to how the old mapping worked, no one likes change
  2. TheWebsiteIUse.com has not implemented all the features of the new mapping platform, or has implemented them in a worse way often because they try and replace like with like rather than creating a mapping experience that works best with the new platform.
  3. The new mapping platform doesn’t offer the same quality of imagery in their locations as the old platform. However it may now be vastly superior in other regions or the new platform brings ‘different’ types of imagery or data like birdseye or OS maps in the UK.

Enough preaching, what are we trying to say?

Maybe you found our blog today, or read it regularly, or someone sent this article to you after you expressed your opinion on a mapping platform. However you came to read this article, we hope it has inspired you to think a little more about giving a mapping opinion or criticism online. If you have just tweeted, emailed, blogged something maybe you would like to go and add more detail, or suggestions, to your comment and maybe even target it at someone who will gladly receive your feedback and have the power change things?

Why not share your new clearer opinion or criticism with the right people, so try the following twitter accounts in your tweet or tweet the website or product that you are using the maps on.

@bingmaps, @googlemaps, @mapquest, @openstreetmap, @ovimaps, @earthware

Yesterday, we were delighted to be invited to present at a workshop event held at Microsoft’s Victoria offices in London to an audience of approximately 60 people who were interested in exploring how Bing Maps can help them drive their business results.

The audience was a good mix of technical and non technical people representing many industries and specialisms with many of them looking at how to manage a migration from the Multimap APIs and MapPoint Web Services to services and APIs offered by Bing Maps.

We really hoped that the day would both demonstrate some of the “art of the possible” in mapping but also allow plenty of time for individual companies to ask specific questions and explore the challenges specific to their own situation.

The speakers included:

Steve Frost (Microsott) – Chair

Idit Gazit-Berger (Microsoft) – Introducing Bing Maps

Johannes Kebeck (Microsoft) – Integrating Bing Maps

Rod Plummer (Shoothill) – Getting the best out of Bing Maps

Neil Osmond & Brian Norman (Earthware) & Miranda Munn (NovaLoca)

- The Art of the Possible in Bing Maps

Mark Finch (Grey Matter) – Licensing

Philip Bull (Microsoft) – Bing Maps and Windows Azure

Alex Montgomery and Hayley Bass (Microsoft) – Bing Maps and Microsoft Dynamics CRM

In our session we were delighted to be joined by Miranda Munn, Founder and MD of NovaLoca (one of our most successful clients) who demonstrated how we had helped her use mapping to drive her business at multiple stages of its growth.  We were also delighted to be able to demo the new NovaLoca Windows Phone 7 app that we have developed that is due for release very soon.

In case you would be interested, we wanted to share the slides and the links (most images are links) on our blog.  Please see below for the slides: