Developer Challenge: 100 Lines or Less

Esri UK have recently announced the 100 lines or less developer challenge. If you’re a developer, or know someone that could be interested, there are some great prizes up for grabs!

Using the Esri ArcGIS API for JavaScript, the challenge is thinking about something creative and small enough to keep within the requirements of the competition. Those being - 100 Lines or beautified JavaScript code with a 100 character limit per line.

You can find out more information, rules and full terms and conditions at

Last day to submit your entry is the 23rd of April 2017. Good luck! 

The science behind our Coastal Views map

The science behind our Coastal Views map

When you're at the coast and gaze off into the horizon, do you know which countries are directly across the sea from you? I recently tried to answer this question by creating a map that went on to be featured on The Telegraph, Mail Online, BBC News and, more recently, Esri's Maps We Love gallery. 

Read More


Earlier this month, 40 participants entered Inmarsat's offices on Old Street roundabout to participate in GeoHackDay. GeoHackDay was an opportunity for developers, designers and idea makers to get together to help build software applications and/or hardware integrations to tackle real life problems. 

Read More

A Desktop future for the JavaScript API?

Some important Windows 8 demos have come bursting onto the scene lately which have significant implications for the future of the JavaScript API (including the compact build).  With the release of this attractive demo of the new Windows 8 touch interface, there has been a lot of talk about the future environment for developing desktop applications for Windows.  

All that has really happend is the addition of a new API which is based on HTML5 and JavaScript.  For JavaScript API developers this is good news - the addition of what will inevitably become a broadly adopted platform means we can start writing apps that will have a desktop feel, much like we would for a Chrome OS app.  We'll have to get better at utilising touch gestures for desktop apps and it remains to be seen which additional tags Microsoft will decide are required, but the future looks interesting.

Speed up your tiled map services

I want to tell you about a simple trick that will speed up the loading of map tiles from ArcGIS Server tiled map services in all browsers. We’ve recently incorporated this into LocalView Fusion and it requires only a handful of ingredients:

  • A tiled map service running on a server you control.
  • A few lines of JavaScript
  • Some extra "A" records (subdomain names) for the domain name of your site (use your hosts file if you are developing this and wish to test it)

The problem: Blocking

Browsers can only make a limited number of HTTP requests at once. In modern browsers, like Internet Explorer 9, Chrome and Firefox 4, up to 6 HTTP connections can be made per host name (although in FF at least you can configure this). So if your tiled map service is running on a server with the address like, then these browsers can send up to 6 tile requests at once before they have to stop and wait for the responses to come back.

If more than 6 requests are sent to the same host name, the browser will wait for responses to be returned before sending requests 7, 8, 9 and so on. This is called “blocking”.

However, a browser will usually need to display more than 6 tiles at once to show a map. For larger resolution screens there may be 20 or 30 tiles making up the full map display. So after the first 6 tiles have been requested, the browser will “block” until it can send more tile requests.

The solution: multiple subdomains, and some code

Let me first make it clear that this is not a new trick, I just haven’t seen it implemented in an ESRI web API client yet. Google, Bing and Open StreetMap tiles are routinely requested from multiple subdomains in clients and APIs for those services: for example the OSM tile URLs are,, and so on. This allows 6 tiles to be requested from each subdomain: 18 at once. (Older browsers may have a lower concurrent connection limit: IE7 is limited to two per subdomain for example).

This trick can be applied to ArcGIS Server map services as long as you have control over the registering of the extra “A” records for your domain (, and so on). The rule of thumb is that 3 or 4 “A” records will speed up requests but beyond this diminishing returns apply due to the extra burden of DNS lookups.

So – step one: register 4 extra “A” records for the domain where your server is running. In our example these would be:

The code

My example here is based on the JavaScript API but there is no reason why the same approach wouldn’t work in Silverlight or Flex, as long as you can implement a custom layer type using those APIs. You can do this easily in the JavaScript API as described in this article on the ArcGIS Resource Centre.

It is easy to extend the ArcGISTiledMapServiceLayer class in the ESRI JavaScript API, thanks to the Dojo framework upon which the API is built. By defining a new class that inherits from a base class, and implementing an override for the properties and methods you wish to change, the amount of code required can be kept to a minimum.

To make multiple requests to the same map service, the code will need to do the following:

  •  Read the service metadata from the “normal” map service URL as usual. This is the URL passed into the constructor method of the ArcGISTileMapServiceLayer class.
  • Define new properties for the list of server URLs to use, and to keep count of which one each tile request is using.
  • Override the getTileUrl method, to loop through the list of subdomains in turn and make a request from the next one in the list.

Here is a code sample of the custom layer class as used in LocalView Fusion:


dojo.provide("CustomLayer"); //define the namespace and class
dojo.declare("CustomLayer", esri.layers.ArcGISTiledMapServiceLayer, {

    /* Extends the ESRI class by adding a list of servers. 
    /* This needs to be manually populated when 
    *  the object is created.

    servers: [],
    serversLength: -1,
    serverIndex: 0,

    getTileUrl: function (level, row, col) {
        var idx = 0; 
        //check how many URLs there are.
        if (this.serversLength < 0) { 
            this.serversLength = this.servers.length;
      //if there is more than one URL, get the next in the list.
      if (this.serversLength > 0) { 
            // Multiple urls
            idx = this.serverIndex++ % this.serversLength;
            return this.servers[idx] + "/" 
                   + this.url + "/tile/" 
                   + level + "/" 
                   + row + "/" 
                   + col + ".png";
      //if we don’t have extra URLs, just use the default one.
      else { 
            // Original single url
            return this.url + "/tile/" 
                   + level + "/" + row + "/" 
                   + col + ".png";



And here is a sample of how it might be used in an application:

var basemap = new CustomLayer(
basemap.servers = [
map.addLayer(basemap); //assuming "map" is the name of our map object.

To conclude

In our testing, using a modern browser like Firefox 4, Internet Explorer 9 or Chrome, the effect is that ArcGIS Server tiled maps load in the browser much faster than before, up to 24 tiles coming in at once compared to the batches of 6 you would normally get with those browsers.

If you use IE7 this will be less impressive as it uses a strict implementation of the HTTP 1.1 spec, and can only make two requests per host - even so, this will fetch 8 tiles at once using this method.

If you're using IE6, well....I don't suppose faster tile loading is going to make much difference as the general HTML rendering and script execution performance is so bad to start with!

This functionality will be in the next release of LocalView Fusion, but if you are running ArcGIS Server with a registered domain name and can make the edits I've described here to your application, then there's nothing stopping you implementing it right now.

HTML5 support in the JavaScript API

Well, the wait is over. 


HTML5 is creeping into the JavaScript API & esri are aggressively propagating new HTML5 components in the API.  With the release of version 2.2 of the API we saw a set of experimental samples released using Canvas raster layers, file drag & drop, feature collections in local browser storage and tile caching in local storage in the browser. 

With the release of version 2.3 of the JavaScript API we will see support for IE9 which will overcome the longstanding issue of vector graphics performance in all versions of IE.  IE9 has implemented SVG as the new vector graphics language, bringing it in line with all other modern browsers.  This represents a significant speed performance upgrade for graphic display between IE9 & earlier versions which used the long-neglected VML technology for displaying vector graphics.