Tag Archives: JavaScript

Some thoughts on the direction of the ArcGIS web mapping APIs (JavaScript, Flex, and Silverlight)

With Adobe’s announcement of discontinuing support for Flash on mobile device browsers, industry rumors on the lifespan of Silverlight, and the growing future of HTML5, many users have asked for Esri’s perspective on this news.

Esri continues to fully support four distinct patterns of application development:

  1. JavaScript / HTML5
  2. Silverlight
  3. Flex
  4. Native device applications

We’re committed to providing the best technology for GIS developers and giving choices from the most widely used developer platforms in the market. By offering many options, we enable developers to address different customer needs and expectations. Our commitment is not based on a specific technology, but based on supporting the GIS developer regardless of the platform chosen. Each of these areas: JavaScript/HTML 5, Flex, Silverlight, and native application code, gain significant improvements in the upcoming ArcGIS 10.1 release.

We have been supporting HTML5 developers through the ArcGIS API for JavaScript for some time. HTML5 is leveraged internally by the API when supported by the browser. The ArcGIS API for JavaScript documentation includes a broad variety of developer examples using HTML5. Our agenda for supporting HTML5 developers will continue to be aggressive.

Adobe recently announced the discontinuation of support for Flash Player in mobile device browsers, however there is continuing commitment and development for Flash Player for browsers on desktops. In addition, Adobe is directing mobile developers to write native applications using authoring tools such as Flash Builder and AIR, and replace Flash-based web mobile browser applications with HTML5-based applications. Adobe is evolving its developer offerings to match this vision, and Esri’s ArcGIS API for Flex will continue to closely match them with upcoming releases. Outside the mobile space, Adobe continues playing a major role. We’re committed to supporting Flash/Flex for the foreseeable future as many of our customers have successful deployments using it.

EDIT: Adobe has released more information to clarify their recent announcement:

Some have asked about Silverlight support as well, given the various industry rumors on its lifespan. We work closely with Microsoft and will continue to support and advance this platform as demanded by our users. Several product updates and new releases based on Silverlight are scheduled for the upcoming months, including our ArcGIS API for Silverlight, ArcGIS Viewer for Silverlight, ArcGIS for Windows Phone, and ArcGIS for SharePoint. We’re committed to providing the Microsoft developer with the best GIS tools, and our offerings will closely match the latest trends promoted by Microsoft.

In addition, we are aggressively adding to our native application support by providing the new ArcGIS Runtime on multiple platforms. This technology will enable developers to leverage the native capabilities of various platforms and devices, and is supported across desktops (Windows and Linux), and mobile and tablet devices (Android, iOS, Windows Phone, and Windows Mobile).

Esri has always focused on computing and development platforms that are viable and demanded by our customers, and that focus has not changed. We have strong strategic alliances with organizations like Microsoft, Adobe, W3C, and others to ensure we are technically aligned and participating in the future directions of technology. This keeps our GIS offerings relevant in the fast-paced world of platforms, devices, and technologies.

Contributed by the Esri Product Management team

Posted in Services | Tagged , , , , | 8 Comments

ArcGIS API for JavaScript – Basic Viewer template now available

We recently added a new JavaScript application template to
ArcGIS.com called the Basic Viewer. Using ArcGIS.com and the Basic Viewer
template, you can quickly create and publish applications with commonly
requested functionality such as a legend, basemap gallery and print tools. The
template includes many out-of-the-box widgets from the ArcGIS API for
JavaScript including the Editor, TimeSlider and Measurement widgets.
The Basic Viewer template is a fully configurable application that you can configure in ArcGIS.com or via a configuration file if you choose to download the template and host it on your
web server.

How to make a web application with the Basic Viewer

Create a Web application based on the Basic Viewer template
by performing the following steps:

  1. Open an existing map (or create a new one) using
    the ArcGIS.com
    map viewer
    . Use the map viewer to add layers, set an extent, configure map popups and add map notes. All of these settings are honored by the template and will appear in the application built using the template.
  2. Click the Share button and choose who can view the map. To publish the map as an application, you need to make the map available to a group, your organization, or the public.
  3. Click the Make
    a Web Application
    option to display a gallery of templates.
  4. Select Basic Viewer and use the Preview
    option to view your web map in the Basic Viewer template. The preview option is a great way to determine which template works best for your map.
  5. Close the preview window and select the Publish option for the Basic Viewer
    template to create a custom application based on the template. This published
    application is added to ArcGIS.com and can be shared with the public or with
    users in your group or organization.

If you would rather host the application on your own
web server, you can select the download option and download a zip file
containing the full source code for the template. The zip file contains
instructions for installing and configuring the template.

Configure the published template

After publishing the web map as an application, use the Configure App option to modify the application’s tools, title and color scheme.

  1. The last step of the application publishing process displays a dialog with details
    about the newly published application, and includes a link so you can view the
    item. Click go to the item now to edit the application’s description, thumbnail
    image, tags, and to begin the configuration process. You can always access the
    application via the My Content tab.
  2. Click the Configure App button to display the application configuration page. This page displays a preview of your web map using the Basic Viewer template along with options that allow you to change the appearance of the application and specify the functionality you want to
    include.
    Basic Viewer Config Pane
  3. After making the changes, click Refresh to view the template with your new settings and click Save to apply
    the changes to your application. Note that you can return to the configuration panel at any time and modify the template.

Click here
to view an application created using the Basic Viewer template. We hope you enjoy using the new template and are excited to see applications you build!

Contributed by Kelly Hutchins of the ArcGIS API for JavaScript development team

Posted in Services | Tagged , | 6 Comments

Cross Origin Resource Sharing (CORS) with the ArcGIS API for JavaScript

HTML5 Powered with Performance & Integration Version 2.5 of the ArcGIS API for JavaScript introduced support for cross-origin resource sharing (CORS). CORS allows web applications to bypass a browser’s same origin policy and access resources or services on other servers/domains. CORS is supported in modern, non-IE browsers and is usually classified as a component of HTML5.

When both the web server and browser support CORS, a proxy is not required to do cross-domain requests to get around that same origin policy. CORS both simplifies application development and provides a performance boost. Development is simplified because it is no longer necessary to maintain a proxy page on your server. The performance boost comes from no longer using a proxy page. Instead of a web app sending a request back to its server, waiting for the server to access another resource or service, and then interpreting the result, the app just accesses the resource or service directly. Eliminating the server as a middleman makes apps faster and frees up resources on the app’s server.

To use CORS from an ArcGIS API for JavaScript application, add the root URL for CORS enabled servers to esri.config.defaults.io.corsEnabledServers, which is an array of strings. As stated previously, web servers must be pre-configured to support CORS. This is a straightforward, simple process and enable-cors.org has walkthroughs on how to enable CORS for popular web servers.

While additional server side configuration is required to use CORS with a 9.3 or 10.0 ArcGIS Server instance, 10.1 instances of ArcGIS Server will support CORS out of the box.

Within the ArcGIS API for JavaScript, the main use cases for CORS are sending large geometries to a geometry service and doing various editing operations. Both are done with HTTP POSTs, and would otherwise require a proxy page if the ArcGIS Server services being used were not hosted on the same domain as the requesting application.

To test CORS with the ArcGIS API for JavaScript, check out the sample CORS apps in the ArcGIS API for JavaScript documentation. If you’re using a browser that supports CORS, you will see cross-domain POST requests when monitoring your HTTP traffic using Firebug, Chrome Dev Tools or some other tool. If you hit the apps with Internet Explorer, you’ll see that a proxy is still used. You can also experiment with the ArcGIS Server services running on servicesbeta.esri.com as that server has been configured to support CORS. Enjoy!

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

Posted in Services | Tagged , | Leave a comment

Version 2.5 of the ArcGIS API for JavaScript released today

Version 2.5 of the ArcGIS API for JavaScript is now available! Highlights of this release include:

Identity Manager Widget

This new widget provides a streamlined experience for using secure services in the ArcGIS API for JavaScript. Secure services can now be consumed from a JavaScript application using a single line of code:

dojo.require("esri.IdentityManager");

When included in an app, the identity manager provides a basic sign-in form for secure services:

Identity Manager widget

Enhancements to KML Support

The KMLLayer class now supports more features of network links, extended data feature attributes, and time information. Also, the outSR parameter now supports well-known text (WKT) spatial references.

Bookmark Manager Widget

This widget allows the user to jump to map extents of particular interest (bookmarks). You can load bookmarks from an array on application startup, or you can allow users to create bookmarks on the fly. Two new samples show each use case:

Bookmark Manager  

Enhancements to Popups

The look and feel of the popup has been improved so that popups have a smaller footprint on the map:

New popups

Popups also have two new events: onMaximize and onResize that fire when a popup’s maximize or restore button is clicked. This allows an application to insert or remove content depending on the current size of the popup. Finally, popups are automatically attached to the map, making the following line of code no longer necessary:

dojo.place(popup.domNode, map.root);

Support for Cross Origin Resource Sharing (CORS)

Cross Origin Resource Sharing is a specification usually classified as an HTML5 technology that outlines how browsers can do cross domain requests. These are normally not allowed by browsers due to the same origin policy. Version 2.5 of the ArcGIS API for JavaScript supports CORS via an array of server URLs that you specify in esri.config.defaults.io.corsEnabledServers.

To successfully use CORS, web servers must also be configured to support it. enable-cors.org is a fantastic resource for enabling CORS. An additional blog post in the near future will go into greater detail about CORS support in the ArcGIS API for JavaScript. Refer to caniuse.com for a list of browsers that support CORS.

Additional API Enhancements and Bug Fixes

Please refer to the What’s New in Version 2.5 topic in the documentation for additional information about version 2.5 of the ArcGIS API for JavaScript.

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

Posted in Services | Tagged , , | 7 Comments

Esri Hydro Viewer

The Esri Hydro Viewer is a Javascript application built for the Esri Hydro Basemap that allows users to interact with the map, turning a static map into an interactive information center. The application has a user-friendly interface, and allows for easy navigation and visualization of hydrologic information. The Esri Hydro Viewer adds value to the Hydro Basemap by making the data contained within the map useful and easy to understand.  Both the Esri Hydro Viewer and the Esri Hydro Basemap were built using NHDPlus products.

What it does:  The Esri Hydro Viewer presents information about watersheds, including spatial information about contributing watershed area. For example, if you click on a watershed in Texas, the application presents a detailed report of information about the selected watershed, and highlights the larger hydrologic unit that it is contained within. The report tells you what category of watershed you have selected, and gives the names of the larger contributing units, as well as the HUC number, area, mean annual flow, cumulative drainage, and a brief description of the watershed. The application presents information about the watershed and helps you visualize how your selected watershed fits into the larger national context.

Esri Hydro Viewer with Subbasin Austin-Oyester in Texas selected.

Esri Hydro Viewer with Subbasin Austin-Oyster in Texas selected.

The application also has navigational functionality that makes it easy for you to zoom between region, subregion, and subbasin scale levels, illustrating to map readers the multi-scaled nature of the data, and making those relationships easy to understand—especially to someone who is does not know much about hydrology.

Zoomed to Subregion level, Galveston Bay – San Jacinto.

Zoomed to Subregion level, Galveston Bay – San Jacinto.

How it was built: The Esri Hydro Viewer is a relatively simple application and can be customized for other data or purposes with a basic understanding of Javascript and HTML. The application, along with the required files, are available for download HERE. The application was constructed using the ArcGIS Javascript API, along with the Dojo and ExtJS toolkits to help build the interface. We also used Google Charts for drawing the charts in the reports. The included HTML file has been annotated with comments so that it is easier to edit.

The application consists of four map services – the reference layer and terrain layer that make up the base map, along with the overview map and query layer. We also implemented two widgets into the application – the Overview Map, and the Legend widgets. You can find more documentation and instructions for both widgets in the ArcGIS Javascript API Resource Center. The Overview Map widget defaults to showing the first map layer added in the application. For this application, however, we used a map that was specifically designed to be used as an overview map instead. To do this, you need to set your custom Overview Map layer visibility to false, and make sure that it is the first layer added to your map. That way, it is not loaded as the basemap, but loads only in the Overview Map widget.

Custom Overview Map layer visibility to false.

First layer added to your map.

Even though the base map you see is our Hydro Basemap, we use Bing Maps for our search functionality. To do this, you need to hide the Bing Maps layer so the geocoding works, but the layer does not appear. Using Bing Maps requires a Bing Maps application “key,” which is packaged together with ArcGIS Server 10.0. You can obtain this by going into Server Manager – Settings – and Bing Maps Key. Further instructions on using Bing Maps can be found here.

Whenever you click on the map, two queries are executed (unless you are at the Regional scale level) – one for the selected unit, and one for the larger unit that it is contained within. It looks like the second query is done using a spatial relationship, but we actually used a “query.where” to query for the unit with the same name as the selected unit. By querying based on attributes, our queries run much faster.

To select the larger unit.

Query.where 

The charts in the reports were generated using Google Charts, which makes it very easy to create nice looking visual aids. As you can see in the figure below, not much code is required to build the charts. We used pie charts to represent our data, but there are many other different types of charts available for use as well.

Google Charts

Google Charts

Three different report templates are specified in the code – one for the Region level, one for the Subregion level and one for the Subbasin level. The formatting is mostly done using plain HTML so it would be easier to modify the reports.

The Esri Hydro Viewer is in the Hydro Resource Center Map & App Gallery, and on ArcGIS Online.

The Esri Hydro Viewer can be customized for other data or purposes. For questions or assistance with this please contact Mapping Center.

Special thanks to Kenny Ling for providing this post. Questions for Kenny: Kling@esri.com.
 

Posted in Hydro | Tagged , , , , , , , , , , , | Leave a comment

A server object extension for performing dynamic segmentation

This post explains how I extended an ArcGIS Server map service to calculate the location of mile markers along a user-submitted polyline. This type of calculation of measurements along a line is called dynamic segmentation.

You can try it out in this app by drawing a polyline. The mile markers will appear on the line when you complete your sketch. You can alternatively choose to place kilometer markers.

Example web app for placing distance markers along a line 

In order to get my server to perform dynamic segmentation, I had to write a server object extension (SOE). This post explains what an SOE is, and how I went about designing this particular extension. If you like, you can download the source code and follow along.

What is an SOE, and why is one useful for this particular problem?

ArcGIS Server map services have a list of methods that they can perform, such as drawing a map, querying geographic features, or returning a list of layers. These methods cover the most common things that someone might do with a map.

Sometimes you may need your service to do something that’s not available with one of these out of the box methods. SOEs allow you to extend the map service with methods that use ArcObjects, fine-grained programming components that expose ArcGIS functionality. This really opens up the realm of things you can do with a service, since advanced ArcGIS functions like dynamic segmentation can be achieved through ArcObjects.

ArcObjects has an extensive object model that can be daunting to beginning programmers. If you’re worried about writing ArcObjects, check whether you can put your workflow into a model in ModelBuilder and publish a geoprocessing service. This is sometimes an easy alternative to building an SOE. In my situation, I could not find an easy way in ModelBuilder to take a single input polyline, assign m-values to it, and locate the mile markers. I had a good case for an SOE.

Designing the REST schema

One nice thing about SOEs is that they can be exposed through REST web services, allowing them to be easily used by the ArcGIS web APIs for JavaScript, Flex, and Silverlight. The ArcObjects SDK contains templates (Visual Studio) or wizards (Eclipse) to help you get started writing a REST web service. I planned to write my SOE with C# in Visual Studio, so I started with a template. The first thing I needed to do was build the REST schema for the web service.

A REST web service SOE exposes both resources and operations. Resources are items of information that can be returned by the SOE. Operations are things that the SOE can do. When you write a REST SOE, you need to determine which resources and operations you are going to expose. The REST SOE template has some example ones stubbed out for you.

In my case, I kept it real simple. I had one resource (the required root resource) which did not return any information beyond the name of the SOE, and one operation which located the mile markers. I called this operation LocateMarkers. I also had to define the parameters that LocateMarkers would take, which were a polyline graphic and a segment length (allowing me to find kilometer markers, too).

Writing the resource and operation handlers

Each resource and operation in your SOE must have a handler function. A typical operation handler function for a REST SOE does the following things:

  • Deserializes the web service request, which comes in as JSON. Going from JSON to ArcObjects types such as IPolyline can be tricky, so an SOESupport library is referenced in the template that has some deserialization and conversion classes for you.
  • Calls into your ArcObjects code to perform whatever GIS functions you need.
  • Serializes your results into JSON for the web service to send back as a response. Again, you can use the conversion and serialization classes in SOESupport to help you with this.

If you want to watch a more detailed explanation of this process with an example, see the workshop Extending ArcGIS Server Services using .NET recorded from the 2011 Esri Developer Summit.

I followed these steps for my LocateMarkers operation handler. I began by deserializing the input polyline and segment length. I converted the polyline to IPolyline, assigned m-values to it, and added it to an in-memory feature class I had created. At that point, I was able to use methods in the ArcObjects Location library to find the marker locations given the input segment length. Finally, I had to serialize those locations into JSON so that they could be sent back as a web service response.

All of the above wound up taking a fair amount of code. I found that the ArcObjects Location library was well-documented when it comes to locating points with dynamic segmentation. Other things took longer to figure out, such as how to assign m-values to a single polyline. Thanks to the many generations of Esri developer documentation archived online, I was able to find answers to get past each hurdle. You might have a similar experience when developing your SOE.

Using the SOE in a web app

The most exciting thing about SOEs is that they allow your web applications to tap into advanced GIS functionality. With the flood of simple “points on a map” apps out there today, some may question whether any advanced GIS operations or analysis can be performed on the web. REST SOEs demonstrate that all the power of ArcObjects is accessible to your web apps.

Each web API has its own way of calling SOEs, but the common aspect of each technique is that they are making web service requests. The way to call an SOE from the ArcGIS API for JavaScript, for example, is to set up a JSON object with all the input parameters. Once you’ve got the parameters, use the esri.request() method included with the API to make the call to the SOE. You can then write handler functions to work with the response JSON. In my case, the handler function cycles through the returned JSON points and adds them to the map as graphics.

Using the ArcGIS API for JavaScript, I created the simple app mentioned at the beginning of this post. It allows the user to sketch a polyline on the screen and see the resulting distance markers. The app’s intent was to test the speed and usability of my SOE in a web setting.

I was pretty happy with how fast this SOE could place even hundreds of points. To test it yourself, zoom out until you can see the whole county, then sketch a very long freehand line (like a spiral). Usually the points are placed in under a second. (Note that I have placed a limit on this particular service to place only 500 points at a time.) This demonstrates that when ArcObjects code is invoked directly on the server through an SOE, it can run very quickly.

Download the example

There are a number of aspects of SOE development and deployment that I was not able to cover in this post, such as SOE properties and registration, and all the ArcObjects logic used in performing the dynamic segmentation. I have made all the source code of both the SOE and the JavaScript app available on ArcGIS Online so you can explore it yourself. The download comes with a detailed readme file.

Download the code

Contributed by Sterling Quinn of the ArcGIS Server software development team

Posted in Services | Tagged , , , | 3 Comments

Visualizing time-aware data in a web map

You may have heard that ArcGIS 10 is “time-aware”. This simply means that you can designate one or more fields in your data as containing date/time values, and then ArcGIS can play back the temporal progression of that data using a “time slider” bar. There are time sliders built into ArcMap and ArcGIS Online, but you can also add them to web apps that you build with JavaScript, Flex, or Silverlight. Showing the temporal progression of data like this was technically possible before ArcGIS 10, but it required a lot more coding.

To demonstrate one way that time-aware GIS data can be put in a web app, I created this JavaScript map of fish migration up the Columbia and Snake Rivers earlier this year. The dams along the river have fish ladders, where each fish is counted as it swims up the river. Visualizing the daily fish counts over time is an excellent way to see migration patterns. Take a few seconds to give the app a try.

Daily Fish Migration at Northwest US Dams

In this post I’ll explain a little about how I built this app and where you can get the code.

Getting the data and making it time-aware

The raw fish count data came from the Fish Passage Center website, www.fpc.org. Here I was able to download comma-separated value (CSV) files showing fish counts for each dam in 2011. These CSV files are similar to what you might be able to export from Microsoft Excel. To make this data work on a map, I also had to have the dam locations, so I created a point feature class and heads-up digitized each dam.

Digitized dams

Sometimes time-aware datasets are structured differently from traditional datasets you might use for a paper map. What I really needed for this web app was not one record for each dam, but rather, one record for each dam for each day. Thus, what looks like a simple dataset with only a handful of points, really contains over 800 records.

With a little bit of Python, I was able to read the fish counts out of the CSV files and write them as attributes for each dam for each day. Here’s a portion of the final table:

Attribute table of dams dataset

In order to make this type of data time-aware in ArcGIS, you have to add it to ArcMap. Then open the Layer Properties and click the Time tab. Here is where you tell ArcGIS about your dataset and how its time fields should be interpreted.

Time tab of Layer Properties dialog box

One of the first settings you need to choose is whether the layer has a single time field, or both start and end time fields. Some phenomena, like fish counts, are taken at one point in time and just have one field. Other things might have a field recording both the start and end time of an event, such as a wildfire that begins on June 9 and ends on June 13.

You can also indicate which field holds the time values, as well as the time extent and intervals that should be displayed in the time slider.

In my particular map, I wanted the same service to expose data about four fish types. So I made four copies of the layer, symbolized them with proportional symbols, and made them all time aware. Below is what the final map looked like. (It’s okay that all layers are turned on and overlap, because my app only requests one layer at a time from the map service.)

Map of dams in ArcMap before publishing

Exposing time-aware layers through a web service

At this point I was ready to publish the map as a service. I saved a map service definition (MSD) file (yes, these support time-aware layers) and published it to ArcGIS Server in the usual way. All of the time information saved in the map is accessible through the map service. You can verify this by looking at a layer in the Services Directory:

Time-aware properties viewed in the Services Directory

One easy way to view a time-aware map service is to add it to the ArcGIS.com map viewer (go to www.ArcGIS.com and click Map to get to this viewer). The viewer recognizes any time-aware services you add and automatically gives you a time slider. In my case, I wanted to go a little further and make my own web app with a time slider. I chose the ArcGIS API for JavaScript because I had a bit of previous experience with it, and my adjacent co-workers happen to know this API very well. (I can’t deny asking for the occasional hint!)

Building a time-aware web map with JavaScript

When you’re starting out with the ArcGIS web APIs, a good strategy is to find some of the online samples that do the things you want to do, combine them into an app, and then modify the result to fit your requirements. I decided I wanted to use elements from these two samples:

  • Overview map sample from the Layouts book. You’ll see this is where I got the overview map, color scheme, styling, and partitioning of the window.
  • Layer Definition sample from the Time book. This is where I got the time slider and the legend.

The fish counts update very quickly because the app uses client-side graphics to display them. In other words, the browser makes a request to the map service saying essentially: “Give me all the point vertices for the dams from April 17 – June 30, and their attributes. I’ll do the work of drawing them.” After the server sends the response, the browser can draw the points and their symbols without ever having to go back to the server for more information. Because I’m dealing with fewer than 1000 records, I don’t have to worry about hitting the map service’s default limit for how many features it will return, but at the same time I am not requesting an unreasonable number of points for the browser to display.

The key to displaying the graphics this easily is to use the FeatureLayer class. Here’s where I create it in my code:

var fishLayer = new esri.layers.FeatureLayer(initialFishLayerUrl, {
  mode: esri.layers.FeatureLayer.MODE_SNAPSHOT,
  outFields: ["*"]
});

When you connect a FeatureLayer to a TimeSlider, the time slider does all the work for you of requesting and displaying the appropriate features for the currently displayed time slice.

The time slider is a widget included with the ArcGIS API for JavaScript. To use it, I had to put the following at the top of my code:

dojo.require("esri.dijit.TimeSlider");

Then, I had to create the time slider and set some properties on it, such as the thumb moving rate (how fast the slider plays) and whether the time slider should replay itself when it gets to the end (accomplished with the setLoop method).

// Create and configure the time slider
var timeSlider = new esri.dijit.TimeSlider({
}, dojo.byId("timeSliderDiv"));
map.setTimeSlider(timeSlider);
timeSlider.setThumbCount(1);
var layerTimeExtent = results[0].layer.timeInfo.timeExtent;
timeSlider.createTimeStopsByTimeInterval(layerTimeExtent, 1, 'esriTimeUnitsDays');
timeSlider.setThumbMovingRate(350);
timeSlider.singleThumbAsTimeInstant(true);
timeSlider.setLoop(false);
timeSlider.startup();

If you use the time slider in the ArcGIS API s for Flex or Silverlight, you’ll see similar properties.

You can handle events on the time slider to control what happens when the “thumb” on the slider moves. The drawing of the fish counts is handled automatically, but I did add some code to change the date label that appears directly below the slider.

// Report the date whenever the time slider moves
dojo.connect(timeSlider, "onTimeExtentChange", function(timeExtent){
  map.infoWindow.hide();
  dojo.byId("timeSliderLabel").innerHTML = dojo.string.substitute("<b>${startTime}, 2011</b>", timeExtent, function(val) {

      return dojo.date.locale.format(dojo.date.add(val, "hour", hourOffset), {
      selector: 'date',
      datePattern: 'MMM dd' // http://www.unicode.org/reports/tr35/tr35-4.html#Date_Format_Patterns
    });
  });
});

The above code results in a label that changes as the slider moves:

Label that changes with the time slider

Conclusion and download link

This post has shown how you can start with raw tabular data and ultimately display it in a time-aware web application. The coding part is optional and can be eliminated if you want to use the time slider in ArcMap or in ArcGIS Online. However, because many of you may have to write similar types of web apps, I’ve made the complete application and a readme file available for download at http://esriurl.com/fish.

Contributed by Sterling Quinn of the ArcGIS Server software development team

Posted in Services | Tagged , , , | 4 Comments

Version 2.4 of the ArcGIS API for JavaScript released today.

Version 2.4 of the ArcGIS API for JavaScript is now available! Highlights of this release include:

  • Add KML files to your maps. A new KMLLayer class accepts a public URL for a KML file and provides full access to all features.

    WMTS Image

  • Mobile popup widget. A popup specifically designed for use on mobile devices.


    View Larger Map

  • Measurement widget improvements. New methods for fine grained control and projected coordinate systems are now fully supported.
  • Enhanced Web Map Tile Service(WMTS) support. A new WMTSLayer class makes it even easier to use WMTS in your mapping applications.

    WMTS Image

  • Bug fixes. See the What’s new in 2.4 document for more information.

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

Posted in Services | Tagged | 5 Comments

High performance web apps with big datasets as feature layers

High performance feature layer applicationDealing with big datasets is a frequent topic of discussion among web mapping app developers. The prevalence of huge, crowdsourced datasets ensures that big data will continue to be a common point of discussion when you get more than two web mapping geeks in the same room. The traditional approaches of generating a raster tile cache or using a dynamic map service work, but if you want any interactivity with the underlying data, it requires a server round trip. This post will discuss some of the key concepts behind building a web app that provides an extensive interactive experience while maintaining responsiveness and performance.

The main factor causing big data to be a tricky topic is that browsers cannot elegantly handle upwards of a few thousand features. Send more than a few thousand points, or a few hundred polygons to a browser and you can watch it grind to a halt, especially if you’re running a legacy version of Internet Explorer. This is a problem because slow performance is a death knell for web apps. If someone using your web app has to wait ten seconds, twenty seconds, or longer for five megs of JSON data to be retrieved and displayed, there’s a good chance they’ll just give up and move on. What good is a web app that no one uses?

At some point, you cross a threshold where it’s not practical to send all of your data across the wire and let the client sort it out. That threshold is an ambiguous one (and was explored in a previous post), but you know when you hit it. If you’re a JavaScript developer, how should you deal with big data? If you’ve read my recent posts, this answer will not surprise you: Feature Layers.

Building on the concepts discussed in the previous feature layer posts (generalizing features and vector tiling) and client side graphics performance post, I’ve put together an application that demonstrates how to use Feature Layers to set up custom scale dependencies and follow best practices to ensure performance does not suffer when querying, retrieving and displaying large datasets in an ArcGIS API for JavaScript application: High Performance Maps with Feature Layers.

The goal was to display appropriate US boundaries (states, counties or census block groups) for the current map scale. For example, trying to display census block groups for the whole US would overwhelm the browser with features. This app makes sure that only the states appear at the small scales, counties at the medium scales, and census block groups at the large scales. This ensures that a manageable number of features are always being transferred and displayed.

The app is simple, but the concepts can be applied to just about any web mapping app that has to deal with big data. The total size of the data used by the app is around a couple of hundred megabytes. This is accomplished through custom scale dependencies. This is as simple as creating a few feature layers, listening for their onLoad event and setting their minScale and maxScale properties. Here’s a simple code sample showing how this is done:

var fl = new esri.layers.FeatureLayer(url, options);
dojo.connect(fl, ‘onLoad’, function() {
fl.minScale = minScale;
fl.maxScale = maxScale;
});

The app includes a couple of other bells and whistles that demonstrate some of tools that are available when you have your features client side. The first is a rich Popup that displays feature attributes, as well as an option to zoom to the feature when you touch a graphic. The second is the ability to filter features based on population using a slider. Neither of these would perform nearly as well if features weren’t available client side.

The final point to drive home is that the app’s performance is kept snappy because only the required data is being sent to the client. For geometries, that means using maxAllowableOffset to generalize geometries on the server before they’re sent to the client (see my previous post on maxAllowableOffset and generalizing features on the fly for more info). For attributes, only the fields required by the Popup are sent across the wire.

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

Posted in Services | Tagged , , , , , | 2 Comments

Determining limits for map graphics

We’ve recently been talking about some of the benefits of Feature Layers. Since Feature Layers are a subclass of GraphicsLayer, we thought it was appropriate to spend a little time talking more about map graphics, limits on how many can be added to a map, and how to find the appropriate limit for your app/environment.

“How many graphics can I put on my map?” or “How many points can I put on a map?” are questions that continue to be asked. Probably because we keep saying “it depends.” While technically correct, “it depends” is not helpful on its own. So, with the lofty goal of providing some actionable guidelines, I’d like to discuss two scenarios: point graphics and polygon graphics. To aid in this discussion, I’ve put together a simple app for each scenario: Display an Arbitrary Number of Points and Incrementally Add U.S. County Polygons To a Map.

The objective of the point graphics app is to see how many graphics you can add to a map before performance starts to suffer. Since this is dependent on many factors (your browser, your hardware, your definition of “suffer”), it’s probably best to let you see for yourself how a map performs with 100, 1,000 and even 10,000 graphics. I wouldn’t try 10k in IE, but Chrome and even Firefox hold up well (at least on my machine, YMMV).

There is also an option to select symbol type. Not all point symbols are equal in terms of performance so it’s important to realize that 500 picture marker symbols might result in a more sluggish app than one with 1,000 simple marker symbols.

But wait, just because you can put 3,000 points on your map and not see a performance penalty, does that mean you should? My answer, nine times out of ten, is no. Performance is one thing but user experience is another. Does putting a map with thousands of point graphics on a 15” screen provide a meaningful user experience? Again, I would say no. Outside of looking for a general spatial distribution pattern, I don’t think you’re helping a user discover much or answer any particular question by showing thousands of point graphics at one time. If you find yourself in this situation, it’s a good time to consider using a raster surface (like a heatmap), filtering your data through queries, or maybe clustering.

The story for polygon graphics is a bit more complex. Not only do you need to worry about the number of polygons, but the number of polygon vertices is also an important consideration. More detailed geometries take longer to transfer to the client, and once they make it to the client, they require more resources to display.

Like the point graphic app, the polygon app linked above lets you add any number of polygons to a map (but you probably should keep it under 1000), and it also allows you to specify whether or not maxAllowableOffset should be used. If maxAllowableOffset is a new term for you, please read my previous post to catch up.

Let’s look at a couple of reasons to always use maxAllowableOffset. The image below shows geometries for some states in the Northeastern United States:

Northeast states graphics comparison

The geometries on the left were fetched using a query that set maxAllowableOffset appropriately. The geometries on the right are not generalized. The generalized geometries look nearly identical to the non-generalized geometries (maybe even better according to some) but they are less than a quarter of the size. That’s the key takeaway and why we use maxAllowableOffset: transfer the minimum level of detail required for effective display.

One more example:

Mississippi graphics comparison

I think this example really drives the point home. Using maxAllowableOffset, you’re transferring ~44KB to show the county boundaries for Mississippi. Without maxAllowableOffset, you push over 3MB across the wire. If you’re setting maxAllowableOffset correctly, you’re not likely to be sending more than 100KB (and usually a lot less) per query to the client regardless of the level detail present in your geometries.

The total number of polygon graphics on a map is something that you should experiment with but I would recommend to keep it below a few hundred.

We still don’t have a hard and fast rule for the number of graphics on a map (and probably never will), but hopefully this post along with the accompanying apps will make it easier for you to find your own answer.

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

Posted in Services | Tagged , , , , | 6 Comments