Archive for May, 2009

Caching at a specific extent

May 22nd, 2009 by Stephanie Blazey

Fully or partially caching your map service can be an effective way to improve performance when you have a lot of detailed data or imagery. Caching works well for layers that are not frequently updated, as it can take a considerable amount of time to cache or re-cache your map service, based on layer complexity, the number of layers, and the extent of your map.

One time-saving option is to cache or re-cache your map service at a specific extent, which is great when you are only updating one area of your map, or when your detailed data/imagery does not cover the full extent of your map.

When you are ready to create your map cache in ArcCatalog, and you have set your tiling scheme and image settings, click the “Create Tiles…” button (Note: this button will say “Update Tiles” if the map service is already cached)

cache1

This will launch the “Manage Map Server Cache Tiles” window, in which you have the option to choose a dataset to set the Update Extent (circled in red, below), or manually enter the Top, Bottom, Left and Right extents (circled in blue, below).

cache2
You will also have the option to choose an Update Mode (red arrow, below) if you are updating your cached map service, including:

Recreate Empty Tiles – recreates tiles that are empty (because they have been deleted on disk), or tiles that are new (because the cache extent has changed or because new layers have been added to a multi-layer cache). Old tiles will be left unchanged.

Recreate All Tiles – replaces all tiles, and new tiles are added if the extent has changed, or if layers have been added to a multi-layer cache.

Delete Tiles – deletes all tiles from the cache. (Only tiles will be deleted and not the cache folder structure. There is a “Delete Map Server Cache” tool available if you wish to delete the entire cache, including folder structure.)

cache3

Another caching option is to update specific areas using a feature class (blue arrow, above), where you can use a polygon feature class to manage tiles (create/update/delete) based on the extents of features of a feature class. For example, if you are caching a country, you might supply a feature class of major urban areas. By doing so, you are requesting that the server only pre-create tiles that cover those urban areas. The rest of the areas can be cached on demand when requested by clients. This can save you time and disk space that would be consumed by creating unneeded tiles in rural areas.

Here are some more helpful links related to caching from ESRI:
Tutorial for Creating a Cached Map Service
Creating Cache Tiles
Using a Map Cache
Tips and Best Practices for map caches
Overlaying Map Caches in the .NET web ADF

Posted in ArcGIS Desktop, Caching, Performance | No Comments »

Geocortex Essentials Compatible with ArcGIS Server 9.3.1

May 15th, 2009 by Drew Millen

The Geocortex Essentials development team had been working with the pre-releases of AGS 9.3.1 prior to our release of Geocortex Essentials 1.5.2 Service Pack 1, so we were pretty confident that things would go off without a hitch when ArcGIS Server 9.3.1 was officially released.

We’ve now wrapped up a thorough round of testing using Geocortex Essentials 1.5.2 SP1 and 2.0 Beta 2 with ArcGIS Server 9.3.1.

Our test results are very positive. Essentials 1.5.2 SP1 and 2.0 Beta 2 did not reveal any issues specific to AGS 9.3.1 when using either MXD-based services, or the new MSD-based map services with one exception:

  • Using the ArcMap Layout print functionality (which uses layouts defined in MXDs), will not work when using the new MSD-based map services. The template-based printing feature is still fully functional when using MXD and MSD-based services.

If you are eager to upgrade or have already upgraded, feel free to run your Geocortex Essentials 1.5.2 SP1/2.0 Beta 2 applications on the 9.3.1 release of ArcGIS Server.

Posted in Geocortex Essentials, Products | No Comments »

Build Your JSAPI Applications for Performance

May 12th, 2009 by John Fletcher

When you begin creating a mapping application using the ESRI JavaScript API, there’s a good chance that you will choose Dojo as your framework, since the ESRI JS API is built on top of Dojo anyhow. Whether you begin with the Sample Viewer from ArcScripts or decide to roll your own solution, you will quickly encounter dependencies on Dojo files which are not “baked in” to the core ESRI JS API build.

How Dojo handles dependencies beyond those satisfied in the original JS imports is a topic for another post, but suffice to say that it creates a blizzard of HTTP requests that slows down the loading of an application. What we want to do is use Dojo’s build system to concoct a single (generally) JavaScript file that has all of the dependencies included by default.

This turns out to be a bit complicated for a couple of reasons:

  • the ESRI JS API already includes much of the Dojo code we need in a packaged form, and we don’t want to duplicate that code in our build.
  • Dojo cannot resolve any dependencies on ESRI core modules, since we don’t have access to the JS source.

To tackle the first challenge, we can use the concept of discardable layers in our Dojo build profile. Our first layer (compiled JavaScript file) in the Dojo build is going to be exclusively comprised of Dojo modules that are already included in the core ESRI JS API build. We add this first layer as a dependency of our main layer to ensure that we don’t duplicate code. This unfortunately requires a bunch of manual CRTL-F work inside the ESRI JS API to actually find out what they’ve included in their build, but it’s not all that bad. It would be nice to see their Dojo build profile…

The second problem is resolved in a way that seems non-intuitive at first, but makes sense when you think about how Dojo loads required modules. We need to REMOVE all Dojo.require statements that reference core ESRI JS API classes. Commenting them out is nice since it preserves the original Dojo.require’s as code documentation. You might think this would cause the application to stop working entirely, but that’s not the case. When working with the ESRI JS API, all of the core modules are imported into your page with the initial script import, so there’s nothing Dojo needs to do when you specify your require. It’s generally still good practice for a few different reasons to continue using Dojo.require statements, but the core ESRI requires will prevent your build from running.

Have a look at the integration of Geocortex Essentials 2.0 with the JavaScript sample viewer on resources.geocortex.com if you want to see the pre-built application in action. I’ve left out many gory details, so feel free to contact me if you’d like to get some more detailed info, or even a sample Dojo build profile.

Posted in ArcGIS Server, Dojo, ESRI, JavaScript | 10 Comments »

Distributing Geocortex Optimizer

May 11th, 2009 by Kevin Rintoul

One of the well hidden yet most useful features of Geocortex Optimizer is its ability to be installed in a distributed environment. Geocortex Optimizer’s data collectors can be distributed throughout your network, logging performance data from multiple servers into a central repository. Optimizer’s “typical” installation path installs a predefined selection of collectors, a database module, and reporting application all on the same server. For most users, this will suffice, but this strategy breaks down when you wish to add more Optimizer-monitored servers. The good news is that installing another instance of Geocortex Optimizer is really easy to do, notwithstanding that it is not very well documented. To accomplish this, do the following:

  • Run the Geocortex Optimizer installation
  • Selected “Advanced Install”
  • Specify that you want to use a database module located elsewhere
  • Provide the name of that computer hosting the database module

That’s it. Our 1.3 admin guide will contain a lot more information regarding different installation scenarios as well as interpreting data collected by Geocortex Optimizer. Stay tuned.

Posted in General Discussion | No Comments »

Performance and Optimization

May 5th, 2009 by Stephanie Blazey

Having just given a presentation on Effective Web Based Cartography and Representation at our Geocortex User Conference, it became evident that people are very interested in the performance/optimization side of things.

ArcGIS Server 9.3.1 includes some great new features for this, and ESRI Canada is hosting some related webinars:

• Performance and Optimization Techniques for ArcGIS Server, May 14, 2009 and June 4, 2009
• High-performance Dynamic Map Publishing with ArcGIS Server 9.3.1, May 19, 2009

Also, Geocortex Optimizer is a product we have developed that provides a number of related and complementary features that help you ensure best possible performance (and monitor usage over time to create web-mapping applications better tuned to your users’ requirements).

Anyway, if you weren’t at the Geocortex User Conference and are interested in taking in my Effective Web Based Cartography and Representation presentation, you can catch the next webinar version on Wednesday, May 20th, 2009. I will be adding more content on the topic of initial design to maximize performance. Registration is here.

Posted in ArcGIS Server, Geocortex Optimizer, Performance | No Comments »