Tag Archives: JavaScript

Last week, we discussed vector tiling for improving performance of feature layers. While awesome in its own right, if you’re trying to push twenty megabytes of features over the wire, vector tiling isn’t going to save you. Your app will be slow.

How should complex geometries be handled/served? The intuitive approach is to use multiple layers in a service and, depending on the map’s scale, display different layers with varying levels of geometric detail. And why not? You have the tools and you know the API will let you easily craft a solution; it’ll just take a little time to code the thing.

Well, frankly, that’s a lot of work. Feature generalization is a common enough scenario that you would think the API should just know how to do this type of thing. Thankfully, it does.

When you create a Feature Layer, one of the options is maxAllowableOffset. You might recognize this parameter name from the ArcGIS Desktop generalization tools, where it’s been used for years. For more technical details, please refer to the Wikipedia page for the Douglas–Peucker algorithm. If this is new terminology, go check out the ArcGIS Desktop Help for the Generalize tool.

Another bonus is that the FeatureLayer comes with a setter method setMaxAllowableOffset that you can use to simplify features on the fly. Since the web APIs fire an event when the map’s extent/zoom level changes, you can listen for this event and use setMaxAllowableOffset to indicate an appropriate value.

OK, so now all we have to do is figure out a value for maxAllowableOffset. This can take some trial and error, but let me suggest a method: a feature’s geometry should not display more than one vertex per pixel. After all, a pixel is the smallest unit for our displays, so displaying more than one vertex per pixel is wasted effort. If we want to display no more than one vertex per pixel, we can take the map’s width in coordinate space divided by the map’s width in pixels and we have a reasonable value for maxAllowableOffset. With this method, you are telling your Feature Layer to make sure simplified features do differ from the original by more than the width of a pixel. In fact, this is exactly what happens in the Generalize Features JavaScript API sample.

But wait, there’s more! Because this is such a useful idea, ArcGIS.com does it for you automatically. Whenever you add a feature layer to an ArcGIS Online map, maxAllowableOffset is calculated and set appropriately. This results in a better performing map and feature layers that load faster than if complex geometries were sent across the network.

Finally, one caveat. You can’t specify maxAllowableOffset on layers that you allow users to edit. If you’re editing a feature, you need to see the true representation of that feature, including all its participating vertices. Editing a generalized feature and then sending it back to the server could wipe out detailed information that was meticulously created and maintained. We wouldn’t want that, so you can’t specify maxAllowableOffset on Feature Layers that are editable.

Contributed by Derek Swingley of the ArcGIS API for JavaScript development team

Feature Layers arrived with ArcGIS 10 and the 2.0 release of the ArcGIS web APIs. They provide a flexible way to retrieve (and optionally edit) vector features from a web service. To highlight some of the advantages and innovative aspects of feature layers, we’ll be sharing a series of blog posts about them in the weeks to come. The focus of this post (if you haven’t already guessed): vector tiling.

Vector tiling is a relatively new topic in the realm of web maps. Perhaps you’ve used the raster tiles that you can create en masse with ArcGIS Server to speed up your web app. Vector tiles are a little different. The underlying idea is that a static grid is used to issue a series of requests to retrieve vector features. The features are added to the map, but they are also stored in your browser cache.

What’s the motivation behind vector tiling? Some benefits include:

• Dynamic interaction with individual features to change feature symbols, make selections, or work with feature attributes without going back to the server
• Features are retrieved from the browser cache when the same request (URL) is issued more than once (think HTTP status code 304)
• Only features that are in the map’s current extent are automatically retrieved
• Improved user experience and performance by using multiple queries to retrieve features in reasonable numbers rather than a single query to retrieve all features

One key thing to point out, especially for veteran uses of ArcGIS Server that are familiar with traditional map caches, is that vector tiles are generated on the fly and they are not persisted on the server. For vector tiles, there’s no cache building and no additional server maintenance required. Vector tiles are only cached on the client and are used on a session-by-session basis.

As the title of this post says, you get vector tiling out of the box with ArcGIS Server and Feature Layers. To take advantage of a Feature Layer’s vector tiling capabilities, the key is to use ONDEMAND mode. The code to set this up can be as simple as:

var featureLayer = new esri.layers.FeatureLayer(layer_url ,{
  mode: esri.layers.FeatureLayer.MODE_ONDEMAND,
  outFields: ["*"]
});

Let’s look at a sample: JavaScript API Feature Layer ONDEMAND. If you look for it, you can see hydro features being drawn in chunks as you move around the map. These are the tile-based queries doing their thing. To explore further, pop open Firebug or the Chrome Developer Tools and take a look at the Net tab or the Network pane. Pan to get the feature layer to make some requests back to the server. Initially, you’ll see requests to the server to retrieve features. If the map ends up somewhere it’s been before, you’ll start seeing HTTP 304s being returned:

What does a 304 mean? In a nutshell, it’s the server saying it’s already responded to this request (URL) and that the browser should use the previous response. When this happens, the server doesn’t send any features over the wire and the browser uses the previous response by pulling it out of the browser cache. Pretty cool. Because the Feature Layer uses a grid to generate query URLs, and the browser caches responses to these URLs, the server doesn’t need to send the same features over the wire multiple times.

One issue that vector tiling doesn’t directly address is generalizing features. As a map scale changes, the amount of detail required for each feature changes. If you’re at a small scale, you need more generalized features. At larger scales, features need to show more detail. Feature Layers can handle this efficiently but that is a topic for another post. For those who can’t wait and want to explore on their own, have a look at the maxAllowableOffset property on the FeatureLayer.

Contributed by Derek Swingley of the ArcGIS API for JavaScript development team