PrintEarlier in the lesson, we saw how a vector feature could be added to a map as a graphic. That method of hard coding coordinates into the script works for a small number of features, but is impractical for large numbers of features. There are a few approaches that can be used in such situations. The approach to use depends on how much the data change and the functionality needed in apps that use the data.
First, you should keep in mind that it is possible to read in and overlay data stored in non-Esri formats (like delimited text) using a methodology similar to the one used in the last lesson with the Google API. You could even store your data in Fusion Tables, though you would not be able to add the features as a layer (i.e., the Esri API has no FusionTablesLayer class). But it is possible.
That said, Esri's API is really geared around consuming services that were published through ArcGIS Server. These services allow for building more sophisticated GIS-like functionality than what is possible with a Google Maps app. Because of time constraints, this lesson focuses on consuming services that have already been published (by someone else). However, if you are interested in building a map using your own services, perhaps for your final project, that is an option you can choose to pursue. Here are the details:
Esri has partnered with Amazon Web Services to provide a "sandbox" for people to experiment with ArcGIS Server. The basic idea is that you request a sandbox, Amazon sets it up for you (a virtual server running ArcGIS Server), you log in to the server remotely and experiment, then Amazon charges you for the time the server was running. If you are interested in trying, please send me an e-mail and I will point you to a tutorial from our Cloud/Server GIS course.
As I said, this lesson only requires you to consume existing services. However, the discussion below goes over some of the considerations a service publisher must take into account when making services available to developers who might use the service in a web map. In other words, whether or not you decide to play with ArcGIS Server, these are issues you need to be aware of.
Datasets that rarely change lend themselves to being served as pre-made (or cached) tiles. The advantage to cached tiles is a faster drawing speed, particularly noticeable as the number and complexity of features increases. The disadvantage is that the tiled layer is a "dumb" picture of your data. Users will not be able to interact with the features depicted in the layer (e.g., to view attribute values in an info window).
For datasets that change more frequently, creating cached tiles is a less desirable option because keeping the service up to date requires frequent re-creation of the tiles. Tile creation involves some manual work to initialize the process (though this can be automated). This may only take a few minutes, but waiting for the software to churn out the tiles may take hours.
For this reason, frequently changing datasets are often published as dynamic services. When a dynamic service layer is requested, the server generates images of the data on the fly and streams them to the client app making the request. This on-the-fly work can take longer than simply serving up pre-made tiles, so dynamic services typically do not draw as quickly as tiled services.
However, what makes dynamic services an attractive option in spite of the performance issue is the ability to allow interaction with the features (e.g., pulling up info windows). Prior to the release of ArcGIS 10, a JavaScript API developer's only choice for consuming this type of service was to use the ArcGISDynamicMapServiceLayer class. This class allows for specifying which layers in the service are visible and also which subset of features are shown by the layer (e.g., show only the Pennsylvania counties from a national counties layer).
With the release of ArcGIS 10, the FeatureLayer class can be used to stream the actual geometries of the features to the client machine and draw them using the web browser. In order to not overwhelm the browser with too much data, the geometries streamed to the machine are filtered based on queries constructed by you, the application developer.
Downloading feature geometries to the client machine's memory opens up more possibilities because it reduces the frequency and size of data transfers needed between the server and client. Among these possibilities are the ability to select features to be used as inputs to geoprocessing tasks, the ability of the user to perform edits on the underlying data, and the ability of the application developer to re-style the features on the fly based on hovering the mouse or clicking a feature or color ramp.
Any app that involves user interaction with the map is especially suited to using a FeatureLayer because of this in-memory geometry factor.
Given our limited time, let's focus on using a FeatureLayer to display a large set of clickable features. A FeatureLayer has a mode property that is used to specify how features are retrieved from the server. Acceptable values for this property are:
- MODE_SNAPSHOT - all features are retrieved
- MODE_ONDEMAND - only those features found in the current map extent are retrieved; i.e., panning or zooming the map retrieves a new set of features
- MODE_SELECTION - only the selected features are retrieved
In most scenarios, the choice is between the SNAPSHOT and ONDEMAND options. ONDEMAND is especially appropriate when retrieving all features would result in poor drawing performance.
As with the ArcGISTiledMapServiceLayer and ArcGISDynamicMapServiceLayer classes, the FeatureLayer class constructor has a URL parameter and an optional options parameter. The options set most commonly are mode (set to one of the values described above), outFields (set to a comma-delimited list of field names; specify only those fields needed by the app to maximize performance), and infoTemplate (set to an object of the InfoTemplate class, which we saw in the hometown example earlier in the lesson).
Another important property to set for a FeatureLayer is its Renderer. A number of renderer classes exist, with the most commonly used including SimpleRenderer (all features drawn using the same symbol), UniqueValueRenderer (features are drawn using different symbols for different categories; e.g., land use types), and ClassBreaksRenderer (features are drawn using different symbols based on ranges of values in a numerical field; e.g., population density).
Refer to this example adapted from two Esri samples and pay particular attention to the following key aspects:
- The FeatureLayer's mode, outFields and infoTemplate options described above are set via the class constructor.
- The setDefinitionExpression() method is used to limit the features retrieved to Pennsylvania counties rather than the full national dataset.
- A SimpleFillSymbol object is used in the creation of a SimpleRenderer, which in turn is used to set the Renderer property of the FeatureLayer.
Now that you've learned a bit about streaming feature geometries to the client machine using FeatureLayers, let's look at how to display associated attribute data alongside the map.