Archive for the ‘ArcGIS Server’ Category

« Older Entries

Geocortex Essentials in the Cloud

May 3rd, 2010 by David Stevenson

I don’t need to give a preamble on the interest around cloud computing — it’s here now and organizations are using it in many different ways. ESRI is working with Amazon and offering ArcGIS Server solutions in the cloud. More specifically, there will be Amazon Machine Images (AMIs) with ArcGIS Server pre-installed and configured and ready to run. Details around licensing and support are coming at the 2010 ESRI International User Conference.

What about Geocortex Essentials in the cloud? Essentials REST Elements requires no special software other than a supported operating system. This is a recipe for success for pairing Essentials REST Elements with one of the many Amazon EC2 Windows offerings. To prove this, I fired up a basic Windows EC2 instance running IIS, made sure that port 80 was open, downloaded and installed Essentials REST Elements with all default settings, and everything was up and running as expected. I realize that EC2 is giving me basically a regular instance of Windows and so this isn’t totally surprising — but I found it pretty cool nonetheless given that it took me about 15 minutes.

So, bottom line is that Essentials REST Elements is more than happy to run on Amazon’s EC2 cloud offering. Keep in mind that this is a preliminary result, and is not saying we official support Amazon EC2. At least not just yet — we’ll keep this testing going and give an official green light soon.

Posted in ArcGIS Server, Cloud, Geocortex Essentials | No Comments »

ArcNews article on BP Azerbaijan

January 8th, 2010 by Rob Lenarcic

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 Blazey

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 Myhill-Jones

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 Blazey

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 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 | 5 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 »

ArcGIS Server 9.3.1 is shipping (and being received)

April 24th, 2009 by Steven Myhill-Jones

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 Rob Lenarcic

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 Rob Lenarcic

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

« Older Entries