Geocortex Blog

2009 Geocortex Picnic at the ESRI International User Conference

Darin — Thu, 02 Jul 2009 22:01:00 GMT

We're coming up on another ESRI International User Conference in San Diego (but a week away!), which means its time to talk about our BBQ Picnic again...

Join us for sun, games and southwest BBQ at the 4th Annual Geocortex Picnic, Wedenesday July 15 from 12 - 2PM. Prior years have brought us a great seaside gastro-experience with Latitude staff, clients, partners and select prospective clients. Throw in some lunchtime relaxation and games (a welcome respite after two busy days of sessions) amongst the tree dotted enclave that is Embarcadero Marina Park South, and you've got the makings for a great lunch!

Registration is open and we're looking forward to seeing you there.

Geocortex Essentials 2.0 Released

Drew — Tue, 30 Jun 2009 21:08:00 GMT

Well, I just opened the gates for people to download Geocortex Essentials 2.0. Though it's been in beta since March, we're pretty pumped to be shipping the final. It has been a huge project that kept growing the more we delved into it.

At version 2.0, Geocortex Essentials is divided into two tracks: Web ADF Elements and REST Elements.

Web ADF Elements includes everything from Essentials 1.x, plus some new Web ADF-related stuff.

REST Elements is totally new and follows ESRI's RESTful development paradigm. Geocortex Essentials 2.0 introduces the Geocortex Essentials REST API. Using the REST API, developers can create JavaScript API, Flex API and Silverlight API applications that consume core Geocortex Essentials functions such as Data Linking, Template-based Printing and Reporting.

During the 2.0 beta period, Latitude product developers worked on documentation, defects, testing, the Geocortex Resource Center, and our associated client APIs (JavaScript, Flex and Silverlight).

Although ESRI released it not long ago, we also managed to squeak in support for Microsoft Bing Maps service types in both REST Elements and Web ADF Elements.

Yeah, we've still got lots of end-user features to port and/or create, but the final cut of Geocortex Essentials 2.0 is a major milestone for all of us on the Geocortex Essentials team and the underlying foundation is all there (along with several key initial features like data linking, reporting, and printing).

ESRI posts pre-conference Q & A

Steven — Tue, 30 Jun 2009 16:27:00 GMT

With less than two weeks before the 2009 ESRI International User Conference kicks off in San Diego, ESRI has posted responses to questions posed by people who filled out their pre-conference questionnaire.

I always find this annual Q&A to be an insightful run-down on all the latest regarding ESRI products, general strategy, and future direction.

Product Localization Simplified

Drew — Tue, 23 Jun 2009 22:28:00 GMT

We recently created and rolled out the Geocortex Localization Portal. This web site makes translation easy for our resellers and partners who are translating Geocortex products into other languages (currently Arabic, Dutch, French, Korean, Norwegian, Polish, and Spanish).

Translators can visit http://translation.geocortex.com/ and log in using their Support Center account.

The site is a nice example of business process automation. Previously, translating a version of Geocortex Essentials followed a workflow similar to this:

Previous Business Workflow

Step # Workflow Step Description Actor

1 Publish resources in languages requiring translation from a released version of Essentials. Latitude Geographics Products Staff

2 Distribute language resource “kit” to translator (via Support Center) Latitude Geographics Support Staff

3 Translate English values to language-specific values. Translator

4 Package and deliver translated resources to Latitude Geographics (via email) Translator

5 Include translated resources in Essentials product Latitude Geographics Products Staff

6 Fix errors caused by translation in Essentials Latitude Geographics Products Staff

7 Publish language-specific version of Essentials release containing translation to web for review. Latitude Geographics Products Staff

8 Review translation on published web site. Translator

9 Send feedback of changes required in translation (via email). Translator

10 Apply changes requested by translator to translation. Latitude Geographics Products Staff

11 Re-include updated translated resources in Essentials product Latitude Geographics Products Staff

12 Re-publish language-specific version for review. Latitude Geographics Products Staff

13 Repeat steps 8-12 as necessary (usually 2-3 times, over 5-8 business days) Latitude Geographics Products Staff / Translator

14 “Sign-off” on translation following review. Translator

15 Package production version of Geocortex Essentials containing the language specific resources Latitude Geographics Products Staff

16 Deliver production version of Essentials to translator Latitude Geographics Support Staff

This onerous process usually took a couple of weeks following a release of Geocortex Essentials, which meant that our translators would have to wait until they could use Essentials in their language. We didn’t want to begin the process using pre-releases or beta versions since there are sometimes changes between beta and release candidate versions of Essentials and the final release which would invalidate the translation.

Now, translation can be achieved by someone almost completely independently of Latitude Geographics, and without the issues described above. The new workflow looks something like this:

New Business Workflow

Step # Workflow Step Description Actor

1 Publish resources in languages requiring translation from a released version of Essentials. Latitude Geographics Products Staff

2 Download Initial translation Kit from Localization Portal Translator

3 Translate English values to language-specific values. Translator

4 Package and upload translated resources to Latitude Geographics via the Localization Portal Translator

5 Download Intermediate Testing Package and apply to installed Geocortex Essentials instance Translator

6 Review translation Translator

7 Repeat steps 3-6 as necessary Translator

8 Request Final Production Package Translator

9 Review translation, and approve production package Latitude Geographics Support Staff

10 Download Final Production Package from Localization Portal and apply to production Geocortex Essentials installation. Translator

I work on and/or manage lots of initiatives that take months to roll-out, so I appreciate the odd small project that nonetheless has a noticeable impact on efficiency.

Sharepoint tip: Sample data in the Data View Web Part

swoods — Wed, 17 Jun 2009 00:29:00 GMT

Over the past couple of months, I've been pushing the boundaries of the Data View Web Part (click here for a good "how to" if you're not familiar with it). It allows me to pull in data from multiple sources and present it on a page in tables that literally draw themselves.

The challenge is that data is data and the more you throw on the page, the slower the page gets. I've found that what only takes a few seconds to display when viewing the page on the web can take several minutes in Sharepoint Designer to load up to edit. That's a long time when you're cycling through a process of making small changes, saving, and viewing over and over again.

Luckily, I stumbled on a solution - when you click on the small arrow on the right side of the web part, it brings up a menu of common data view tasks. Simply check the box marked “Show with sample data” and the web part will use sample data while you’re in design view instead of connecting to and loading your actual data every time the page loads!

The only down side that I’ve discovered is that sample data won’t load for input boxes on the Data Form Web Part. Still, the load time on my page has improved considerably!

Suddenly ArcCatalog won't open...?

sblazey — Tue, 16 Jun 2009 15:32:00 GMT

The ESRI user forums saved the day once again. I couldn't get ArcCatalog to work all of a sudden - it was taking a very long time to open, and when it finally did open, it wasn't responsive and kept hanging. If you are experiencing the same problem, try renaming your Normal.gxt and ArcCatalog.gx and let ArcGIS recreate them on its next startup. The problem could be that they have become corrupt. You will find them in the folder C:\Documents and Settings\User Name\Application Data\ESRI\ArcCatalog - where User Name is the user name you use to log on to the computer.

I renamed both files, and ArcCatalog started up in no time.

Phantom Bugs: A Lesson in Troubleshooting

Drew — Fri, 12 Jun 2009 21:10:00 GMT

As part of the Geocortex Essentials product team, we have people who fix bugs. Typically we discover a bug ourselves or hear of the issue through a customer experiencing issues in their environment which we haven't seen before. We take measures to replicate the issue, get to the bottom of it, and fix it.

But what do you do when you have an issue being reported from a few disparate customers (thus confirming its existence) which can't be replicated in-house? Recently, our support department received screenshots from several different customers looking like this:

Locally, we've never seen Essentials do this - not on 64bit operating systems, not with IE6, nor in any combination of weird server environments we could concoct. So, we spent days trying to replicate this issue with a hunch it had something to do with the new CSS Multiplexer control we'd written for 1.5.2. This requires a bit of a tangent:

Certain versions of Internet Explorer prevent any one web page from adding references to more than exactly 32 CSS (cascading style sheet) pages. Don't ask me why, but that's the limit. Because Geocortex Essentials has a large number of web controls which are independent and modular, many of them come with their own CSS registration; thus, it didn't take long before we discovered this limit (now this was a bug we encountered which warrants its own blog post altogether). The solution: the CSS Multiplexer. A web control which combines all CSS style sheets referenced on the page into one gigantic style sheet. I won't get into the details, but it worked and improved performance as a side effect.

So when we see screenshots that look like CSS isn't doing its job, the natural inclination is to blame the CSS Multiplexer. Long story short... this inclination proved wrong and it was not a bug. After a few days of wrestling with the CSS Multiplexer, and delivering patches to customers who were experiencing the issue only to discover the patches didn't resolve the problem, it became evident that resolving issues using a black box approach wasn't working. Our support department got in touch with one of the customers who was experiencing this issue and asked if we could set up an online meeting where we could see the bug and troubleshoot onsite. They agreed. Within one hour we were able to determine that a setting in IIS was preventing the CSS Multiplexer from fetching the appropriate style sheets and the customer was up and running.

We're grateful to have customers willing to help us track down an issue like this. Of course, finding a resolution is of mutual benefit, but they could've just as easily asked us to investigate this with someone else. Moving forward, I think we'll be much quicker to go down the bug observation route much sooner if we're having trouble replicating it.

Incidentally, we'll be publishing a knowledge base article on our support center for those who are experiencing this issue, and our developers have some ideas of ways we can get Essentials to "trick" IIS into behaving correctly to prevent this from occurring in the future.

(The newly minted, Southern) California Geocortex User Group

Darin — Thu, 11 Jun 2009 23:13:00 GMT

Many thanks to our hosts (Los Angeles County), our presenters (Daniel, Flora and Sharon) and to the ~60 attendees who attended our second go-around for our first user group last Thursday (June 4th) in Alhambra, CA. Lively discussion continued around "web-GIS" vs. "web-mapping", along with a pair of insightful user presentations. The group adopted the "Southern California" title, as Napa County has recently offered to host a Northern California Geocortex user group this fall.

Geocortex Regional Training - Fall 2009

Darin — Tue, 09 Jun 2009 23:10:00 GMT

With the 2008/2009 Geocortex classroom training schedule all but wrapped up (we're conducting training at the ESRI regional office in Olympia, WA today and tomorrow), we're planning, and have dates set for the 2009/2010 training season. These courses will be added to the training section of our website shortly for review and registration. (Note that our Canadian-based training is being offered in conjunction with ESRI Canada.)

Based on feedback from clients and partners, we're expanding our classroom training to include a 1-day course on customizing Geocortex Essentials (focused on Web ADF Elements/Essentials 1.x as well as our newer REST and client API work shipping with Essentials 2.0) as well as a 1-day course on getting the most out of Geocortex Optimizer (read: configuration and interpretation). Dates are shown below:

San Antonio, TX: Sept 29 - Oct 2

Toronto, ON: Oct 14 - 16

Redlands, CA: Nov 3 - 6

Denver, CO: Dec 1 - 4

Vancouver, BC: Dec 8 - 10

Additional spring 2010 dates will be announced later this summer.

Better Unit Tests For Raised Exceptions

Kevin — Mon, 01 Jun 2009 17:20:00 GMT

A while ago, I wrote a blog post outlining a strategy using NUnit to test that methods raise exceptions when expected. At the time, I was surprised to discover that there seemed to be no good way to test this without resorting to a never ending list of try-catch blocks embedded within test fixtures. I wrote a method called AssertException to help in that regard and while it worked, AssertException used reflection and required you to pass parameters to methods being tested in a somewhat unnatural, type unsafe way.

I recently came across something in the NUnit framework that solved this problem nicely called Assert.Throws Using Assert.Throws is really easy. Pass it the type of exception you expect to be raised together with a code snippet that will raise the exception and it will test that the exception is actually raised. For example:

MyObject o = new MyObject();
Assert.Throws(typeof(ArgumentNullException), delegate() { o.MyMethod(null) }, "Argument null exception expected");

I'm not sure when Assert.Throws was added to the NUnit unit-testing framework, but it seems like a really useful addition that will really clean up many of our unit tests.

Caching at a specific extent

sblazey — Fri, 22 May 2009 17:47:00 GMT

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)

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).

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.)

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

Geocortex Essentials Compatible with ArcGIS Server 9.3.1

Drew — Fri, 15 May 2009 23:38:00 GMT

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.

Build Your JSAPI Applications for Performance

John — Tue, 12 May 2009 22:44:00 GMT

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.

Distributing Geocortex Optimizer

Kevin — Mon, 11 May 2009 18:04:00 GMT

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.

Performance and Optimization

sblazey — Tue, 05 May 2009 17:40:00 GMT

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.

Step #	Workflow Step Description	Actor
1	Publish resources in languages requiring translation from a released version of Essentials.	Latitude Geographics Products Staff
2	Distribute language resource “kit” to translator (via Support Center)	Latitude Geographics Support Staff
3	Translate English values to language-specific values.	Translator
4	Package and deliver translated resources to Latitude Geographics (via email)	Translator
5	Include translated resources in Essentials product	Latitude Geographics Products Staff
6	Fix errors caused by translation in Essentials	Latitude Geographics Products Staff
7	Publish language-specific version of Essentials release containing translation to web for review.	Latitude Geographics Products Staff
8	Review translation on published web site.	Translator
9	Send feedback of changes required in translation (via email).	Translator
10	Apply changes requested by translator to translation.	Latitude Geographics Products Staff
11	Re-include updated translated resources in Essentials product	Latitude Geographics Products Staff
12	Re-publish language-specific version for review.	Latitude Geographics Products Staff
13	Repeat steps 8-12 as necessary (usually 2-3 times, over 5-8 business days)	Latitude Geographics Products Staff / Translator
14	“Sign-off” on translation following review.	Translator
15	Package production version of Geocortex Essentials containing the language specific resources	Latitude Geographics Products Staff
16	Deliver production version of Essentials to translator	Latitude Geographics Support Staff