Archive for the ‘ArcGIS Server’ Category

« Older Entries

ArcNews article on BP Azerbaijan

January 8th, 2010 by Robert

Latitude assisted BP Azerbaijan with a project that’s profiled in the Winter 2009/2010 edition of ESRI’s ArcNews publication.  The printed version of ArcNews is the most widely distributed publication in the GIS industry—something like 800,000 people receive it (not including online readers).

It’s nice to see BP Azerbaijan profiled because they’ve had a great vision and did an excellent job spearheading this project. Also, I’m their account manager. ;)

You can read an online version of the story here.

Posted in ArcGIS Server, ESRI | No Comments »

Caching Imagery with a Raster Catalog

September 18th, 2009 by Stephanie

One way to increase the performance of imagery in your map service is to cache it. Since it greatly reduces the amount of time required to render the imagery on your map, caching will allow you to show your imagery at a far greater extent than you could if it were being brought in dynamically. While imagery may lend itself to caching, I find on occasion it can be a bit troublesome to get the caching going. I had a bout of Error 999999 with my latest caching project – turns out 1400 sid images covering an entire county was a little more than ArcCatalog could chew. Fair enough, I had experienced similar issues before where I couldn’t even get my ArcGIS Server map service to start because I was throwing too much imagery at it.

Enter the Raster Catalog. Using an unmanaged raster catalog as opposed to a managed raster catalog saved me a bundle of raster catalog loading time. While the managed raster catalog can take as long, or longer, than your cache creation time – so in my case, a day or two – the unmanaged raster catalog takes far less time to create and load – for me, under two hours.

And thanks (many, many thanks) to ESRI Support and the Color Balancing option in ArcMap, my previous misconception that raster catalog image quality had to be poor compared with the original imagery, is a thing of the past – and I have the completed cache to prove it.

Posted in ArcGIS Desktop, ArcGIS Server, Caching, Tips | No Comments »

Web ADF vs. RESTful APIs? Not as black and white as some might like…

August 31st, 2009 by Steven

People frequently ask us about our take on ESRI’s RESTful APIs in the context of Web ADF. Basically, the RESTful APIs are an important and needed technology. They also aren’t a cure-all, and sometimes Web ADF is the right path (despite its flaws, there are lots of organizations satisfied and successful with Web ADF). We consider REST and Web ADF to be complementary technologies that we envision many folks will choose to run in parallel.

I like the following analogy:

I have five deliveries for you to make. Which of the following two vehicles is better?

apis_vs_adf

Folks that don’t suffer the unfortunate predilection to gravitate permanently to a black and white answer might observe that it depends. If the deliveries consist of envelopes within a ten block radius, the small delivery van is the right choice. On the other hand, if there is two hundred miles between deliveries of heavy crates, then you’re going to want the rig. Which vehicle is better for deliveries? It depends.

Prior to the final release of Geocortex Essentials 2.0 (which ships with REST, JavaScript, Flex, and Silverlight APIs), we were reticent to be too vocal in our situational defense of Web ADF lest anyone accuse us of being biased out of self-interest. However, with Geocortex Essentials 2.0 out the door we now support both platforms; every Geocortex Essentials license includes both our REST Elements and our Web ADF Elements.

Now we can be more vocal about this topic. It isn’t about categorically picking one or the other. ESRI’s RESTful APIs and Web ADF both have their place. The right choice depends on the nature of your app and likely evolution of that app.

Posted in API, ArcGIS Server, Geocortex Essentials, Web ADF | 1 Comment »

Performance Evaluation Tools

July 7th, 2009 by Stephanie

When considering layer performance, our usual goal is to have a layer render in under 2 seconds, and simple layers can often render in under 1 second. When setting up an MXD in ArcMap, the user can get a rough idea of how long layers take to render by turning them on and off to see how long they take to render on the desktop. Any complex layers (parcels, local streets, detailed coastlines) should be limited to a closer zoom, and any general layers (county boundary, highways, large polygons) can be available at full extent.

If you are using ArcGIS 9.3.1, there is a performance analysis tool available on the “Map Service Publishing Toolbar”. Right-click the main menu in ArcMap to access the Map Service Publishing toolbar. This is helpful for overall map service performance, and can also give feedback on layers that should be limited to a larger scale. More info and instructions on how to use the Map Service Publishing Toolbar from ESRI here.

If you are using ArcGIS 9.2 or 9.3, there is a great script available called MXDPERFSTAT. The script is a free download from ESRI ArcScripts and it works with 9.2, 9.3, and 9.3.1.

MXDPERFSTAT is fairly straightforward to run, you launch it from a command prompt and it will give you feedback on your MXD performance for ArcGIS Server. It analyses your MXD at different scales and locations, which you can set yourself or accept the defaults. It goes through and turns on each layer of your MXD one by one and assesses it for performance. When complete, it outputs an XML file which shows the refresh time in seconds at each scale for the whole map, and then more detailed information for each layer at each scale, including warnings, recommendations to improve performance, number of features and vertices drawn, and layer spatial reference, to name a few. I found it took approximately 15 minutes to run the script on a site with 50 layers. The more complex layers (parcels, streets) took noticeably longer to process than the simple layers.

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

Build Your JSAPI Applications for Performance

May 12th, 2009 by John F.

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 | 3 Comments »

Performance and Optimization

May 5th, 2009 by Stephanie

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 »

ArcGIS Server 9.3.1 is shipping (and being received)

April 24th, 2009 by Steven

We recently heard that ESRI would start shipping ArcGIS Server 9.3.1 on April 27, but one of our licensees just posted on the Geocortex Essentials discussion forum that they received it today.

Exciting news! With dramatic performance improvements and a number of other additions, this is the release that I’ve been waiting for since 2005.

Posted in ArcGIS Server, Geocortex Essentials | 1 Comment »

Geocortex & Silverlight at PUG 2009

March 11th, 2009 by Robert

A couple weeks ago during the plenary session at the Petroleum User Group Conference (PUG) in Houston, the ESRI Energy Team presented an ArcLogistics solution that included mobile and AVL (automatic vehicle location) viewer components.

At the invitation of ESRI, Latitude created the AVL viewer component using ESRI’s new Silverlight API. Although our team is slammed right now, helping build the demo tied in nicely with the work we’re doing with Geocortex Essentials 2.0. I was in the audience, and I thought the ESRI team did a great job in presenting a complete workflow from start to end (we also appreciated them acknowledging our contribution on stage).

The purpose of the demonstration was to illustrate the power of ArcLogistics to optimize the processing of oil field production maintenance orders. The scenario is built using maintenance orders with the Rocky Mountain Oilfield Testing Center field data in Wyoming. Maintenance orders are taken from SAP, loaded to ArcLogistics and optimized between a small fleet of contractor vehicles. Diagnostics indicate the expected savings in time and mileage. The routes for each truck are dispatched by wireless to a simulated in-car station that informs the driver of his schedule for the day and provides an advised route generated by ArcLogistics. Through a lightweight mobile app, the contractor indicates that he has completed a job, posts it back to the dispatch desk, and then continues to his next job. Using a Geocortex tracking viewer (via ESRI’s Silverlight API), we then simulated the dispatch center’s view; real-time tracking of multiple fleet vehicles on an interactive map.

I expect that ESRI’s ArcLogistics tied in with a mobile solution has a bright future (and not just in the petroleum industry).

Posted in .NET, API, ArcGIS Server, GPS, Geocortex Essentials, User Conference | 3 Comments »

Geocortex & Silverlight at PUG 2009

March 11th, 2009 by Robert

A couple weeks ago during the plenary session at the Petroleum User Group Conference (PUG) in Houston, the ESRI Energy Team presented an ArcLogistics solution that included mobile and AVL (automatic vehicle location) viewer components.

At the invitation of ESRI, Latitude created the AVL viewer component using ESRI’s new Silverlight API. Although our team is slammed right now, helping build the demo tied in nicely with the work we’re doing with Geocortex Essentials 2.0. I was in the audience, and I thought the ESRI team did a great job in presenting a complete workflow from start to end (we also appreciated them acknowledging our contribution on stage).

The purpose of the demonstration was to illustrate the power of ArcLogistics to optimize the processing of oil field production maintenance orders. The scenario is built using maintenance orders with the Rocky Mountain Oilfield Testing Center field data in Wyoming. Maintenance orders are taken from SAP, loaded to ArcLogistics and optimized between a small fleet of contractor vehicles. Diagnostics indicate the expected savings in time and mileage. The routes for each truck are dispatched by wireless to a simulated in-car station that informs the driver of his schedule for the day and provides an advised route generated by ArcLogistics. Through a lightweight mobile app, the contractor indicates that he has completed a job, posts it back to the dispatch desk, and then continues to his next job. Using a Geocortex tracking viewer (via ESRI’s Silverlight API), we then simulated the dispatch center’s view; real-time tracking of multiple fleet vehicles on an interactive map.

I expect that ESRI’s ArcLogistics tied in with a mobile solution has a bright future (and not just in the petroleum industry).

Posted in .NET, API, ArcGIS Server, GPS, Geocortex Essentials, User Conference | 3 Comments »

Geocortex Essentials 2.0 and ESRI’s Developer APIs

October 16th, 2008 by David

UPDATE: This message was originally posted for our customers on the Geocortex Support Center on October 6, 2008 and is posted here for folks who don’t have access to the Geocortex Support Center. Also, here’s the link to the Geocortex Essentials: The Road Ahead webinar.

I’m posting to provide some insight into current and upcoming Geocortex Essentials development, as it relates to ESRI’s new and emerging developer APIs.

It is clear to us that these APIs will have an integral role to play (alongside Web ADF) for many customers in the years to come and so we are actively engineering Geocortex Essentials 2.0 to encompass these developer technologies.

Agnostic support and integration for various ESRI developer technologies (as they come into existence) has always been part of the long-term vision for Geocortex Essentials and so our work has always been designed to be exposed in an agnostic way at some point in the future. With the intense demand for Web ADF features and the absence of other APIs, Geocortex Essentials development has been focused on the Web ADF realm for the 1.x product generation, while ensuring we we could make the core elements generic once warranted. And that’s what we’re doing right now.

We’re currently working on a Geocortex Essentials REST API to initially expose search, reporting, data linking and printing via a RESTful interface. This functionality can then be leveraged by either Javascript or Flex API applications—or any other application that connects RESTfully to our API. We decided to expose these particular core elements because they’re needed at the heart of many real-world ArcGIS Server implementations. Let us know if other features are a priority to your organization.

Before long, we’ll also get behind one or more lightweight viewer APIs by developing software to streamline and enhance the development and management of applications built on them. While we’re working with each and may provide sample Javascript and Flex API template applications on which to base development, we have yet to “pick a pony” regarding technological emphasis on the lightweight viewer/application development side. We don’t think all the information is available yet to ensure the correct decision, and we’re confident our customers won’t want us to risk going down the wrong path by making a premature choice.

We’re anticipating a Q1 2009 release of version 2.0. Finally, because Geocortex Essentials is about success with ArcGIS Server, everything we’re talking about here will be delivered to you as part of regular product updates.

Posted in API, ArcGIS Server, ESRI, Flex, Geocortex Essentials, JavaScript | No Comments »

« Older Entries