Geocortex Blog

Our products team has been working for months with today’s date looming on our calendars. Earlier this year, we committed to delivering a Geocortex Viewer for Silverlight 1.0 by the end of the 2010. And we took that commitment very literally.

I’m happy to announce that our collective fear of December 31st coming too soon has been by replaced by excitement and celebration: today we released version 1.0 of our Geocortex Viewer for Silverlight. It has been a huge project, and I think it’ll be well received by users of Esri’s ArcGIS Server.

Oh yeah, the Geocortex Essentials 3.3 beta ships today too. Thanks to the team that has worked so hard to ensure all this comes together, as well as to everyone who has provided input during the development iterations.

Lot’s more information to come including feature tours and UX design discussion. Until then, happy new year… we’re taking tonight off.

There’s a lot of cool features in the 3.2 release of Geocortex Essentials we just announced, but I’d like to focus on one in particular.  We’ve made some architectural changes to our printing so that we can now support the generation of really, really big printed maps.

Geocortex Essentials has included printing from JavaScript, Flex, and Silverlight since its first release for REST technology.  The print template designer allows authors to add multiple map services, a legend, an overview map, a north arrow, corporate logos or images, titles, copyright messages, client graphics, scale and projection information and all the other stuff you would want on a printed map.  Now, authors have the freedom to make their templates as big as they like, and allow users to run print jobs with them at high resolutions!

There’s a few printing solutions on the market, but I don’t know of any others that can create a 36×44 inch print at 600 DPI from a Flex or a Silverlight-based application.  The image resulting from the above specs is around 570 million pixels.  At 32 bits (4 bytes) per pixel, we’re looking at about 2.3 gigs of images (more if you count the tiles requested from every map service before they’re blended together into a single image).

Here’s an example of a 42×36 inch PDF generated at the 300 dpi.  It shows the effect of the bark beetle within the douglas fir habitat on the North Fraser river in BC.

WARNING:  It’s a ~40MB download (which is still big, but a lot smaller than several gigs thanks to JPG compression).  The preview image below links to the file – considering the file size you may want to “right-click, save as” instead of loading the PDF into your browser.  Also, make sure to “zoom in” once you’ve opened it up!

This morning I attended an Esri caching webinar where they discussed the new enhancements in ArcGIS Server 10.  With 10, it is easier to copy your cache between machines, it takes less time to build a cache, you can mix file types, and merge tiles from different sources into a collaborative cache.

Compact vs Exploded Caches

AGS 10 offers a new “compact” cache storage format, as well as the original “exploded” format.  The exploded format creates caches as you saw with previous versions, where your cache is comprised of 1000s of image tiles organized in folders.  The new compact format groups a large number of files into a .bundle file.  Each cache scale now consists of at least one .bundle & .bundlx file (the tiles are indexed by the bundlx file).  Each bundle covers a specific map extent and can hold ~16000 tiles.  This means that the number of files in your cache is hugely reduced, and you have a much smaller number of files to copy.  An example in the webinar referred to an exploded cache of 3.8 million files which took 9 hours to copy, compared with the same map service using a compact cache which took only 8 minutes to copy. 

Exploded caches can be converted to compact caches, and vice versa, using the Export Map Server Cache tool.  You can also convert your 9.3.1 caches to compact caches.  Esri recommends you use AGS 10 SP1 for cache conversion.  The compact cache will build “several times faster” than an exploded cache.  There should be a negligible difference in performance between a compact and exploded cache as well.

Mixed Caches

Mixed caches are another new feature available with AGS 10.  This enables you to have both PNG and JPG tiles in the same cache.  Ordinarily when overlaying caches you would see a white boundary with a purely JPG service.  In a mixed cache, only the images that require transparency (touch the boundary) are PNG.  The interior tiles that don’t have to be transparent are JPG.  This means you use less disk space and still get the benefit of transparency when overlapping map services.  For imagery caches, keep JPG quality above 60, and for non-imagery use a higher quality JPG (90+) in order to see near seamless quality between the PNG and JPG tiles.

Collaborative Caching

Collaborative caching starts with a regional base map that covers the whole extent of your area.  You can then import data from different sources into your cache, providing they use the same tiling scheme.  You can merge data by scale, extent or feature class boundary.  If you had higher resolution imagery available within a city boundary, you could import it using the city boundary feature class – it even imports down to the pixel so you get an exact boundary.  In this example, you no longer have to overlay two separate services.  Likewise you can export by scale, extent or feature class boundary if you just want to use part of a cache.

A recording of the webinar will be available in a few weeks on the Esri training website, or you can catch the live version again today at 3pm PST.

I trust most readers recognized immediately that my HTML5 is dead post last week was laden with irony. This week, I want to take a step back and put this important standard in proper context (which is ultimately more helpful for decision makers). And since this blog is geared towards organizations deploying Esri web mapping technology like ArcGIS Server, I’ll get a bit more specific to our domain.

I’ll first acknowledge a personal bias; I’m biased against plugins and always have been because they can act as barriers to use (I still have nightmares about trying to deploy the Java client for ArcIMS in 2001). This is a reason why I’m excited about HTML5.

While I’ve been vocal about my general disdain for plugins over the years, I recognize that not all plugins are created equal and the benefits can outweigh the costs sufficiently to warrant their use for certain types of applications (read, in lots of situations that hundreds of our clients have requirements for).

Especially when used for internal apps and/or more feature-rich apps, I think that Flash/Flex and Silverlight remain highly relevant and appropriate for several reasons:

• As far as plug-ins go, Flash is ubiquitous (98%) and Silverlight (presently ~65%) will likely be there soon.
• They’re from major vendors that people know and trust.
• Esri is placing considerable focus on their Flex and Silverlight APIs.
• They are well-suited to web GIS. As unfashionable as feature rich ArcView 3.x surrogate apps are these days, orgs quickly discover you can’t take functionality away that users have become accustomed to as part of their ArcIMS-generation apps. Users can get pissed when you take stuff away that they’re used to having.
• They deliver a consistent user experience assuming your device supports that plugin (the latter is important, which I’ll discuss later). There are foibles with JavaScript across different browsers (for our product/project development, vastly more testing has been required), which slows development.
• You can accomplish things (non-trivial things) that you likely won’t be able to with HTML5 any time soon, which is pertinent to certain types of apps.
• They’re really starting to hit their stride productivity-wise for Esri technology, whereas HTML5 is probably a couple years off before we can start to get going in earnest for many common use cases. Note: We’re releasing Silverlight and Flex technology that allows people to start migrating/replacing their ArcIMS apps and Web ADF apps in earnest in 2011. While we think we’ve got a smart, realistic HTML5 strategy rolling, it’d be way premature to be attempting any of our product development using HTML5.
• It’s possible to leverage these platforms now, and tie in HTML5 naturally over time, reusing much of the same architecture.

Here’s why I particularly like Silverlight:

• The Silverlight development experience is integrated with excellent Microsoft development technology which allows orgs to get more done, faster. Our development pace with Silverlight far outstrips our output with Esri’s JavaScript API and Flex API. We’ve done lots of product development with all three, and our team prefers Silverlight by a significant margin (followed by Flex).
• Silverlight seems to be gaining lots of traction, and there’s a huge talent pool of Microsoft developers. I have a hunch Esri is going to continue getting behind Silverlight in a significant way.

Here’s why I’m excited about HTML5:

• It requires no plug-in, which removes a potential hurdle in front of the map counter for end-users. I consider this significant.
• Not proprietary; this is usually key for any true web standard.
• Ideal for apps that receive massive traffic (e.g. hurricane evacuation apps).
• One app that serves multiple platforms is preferable to developing different apps for different platforms, provided interactions aren’t substantially different between your small touch screen vs. desktop screen/mouse which they often are.
• All the big vendors are getting behind HTML5, and I have minimal concerns it’ll suffer from a failure to launch. There will be tremendous competition to implement it well.
• Every time I hear the word “Flash” I think of splash pages, and every time I hear “Silverlight” I picture a silverfish zipping across my old kitchen floor.

People should default to the simplest solution that meets their requirements. I doubt anyone would argue that, all things being equal, not requiring a plug-in is superior to requiring a plug-in. If you’re in a situation now where you think a plug-in jeopardizes your maximum user base and you can deliver an app that doesn’t require a plug-in and it delivers the goods without increasing your work significantly, definitely do it. A common candidate for this is a simple, targeted app intended to answer one or two questions for lots of people. Esri’s JavaScript API will be your go-to technology right now (which is what we use) but cool stuff with HTML5 isn’t that far off (which is what we will be using, and are doing early-stage R&D with now).

Technologies like Flex and Silverlight have an essential role to play for quite a while; especially over the next few years and likely much longer for heavier/richer applications. HTML5 will provide tremendous value as it matures in the years ahead, and will inevitably replace many types of apps for which it is fundamentally better suited.

That’s right, you heard it here first. HTML5 is dead. Here’s why: HTML6 is going to be way better. It’ll overcome the things that the HTML5 standard is missing and better integrate with the technology of tomorrow. It’ll provide the kind of development tools and rich user experience that we all wish HTML5 included.

Sound ridiculous?  It is, except that it’s ridiculous because we’ve simply added an extra 5-10 years or so onto the correct but unhelpful declarations opinionati make all the time in the tech sector. If we all listened to these folks, nothing would get done. By the time a technology reaches the plateau of productivity, they consider it irrelevant.

What’s my point? Build for the era you’re in. Choose the development technology of today that you envision best fitting your needs now and for the next while (whether that be Silverlight, Flex, or JavaScript). The evolution of technology is inexorable, so make your plans assuming and embracing change over time. Educate yourself about what’s coming, and then make decisions that keep you as aligned with the future as possible. Fight against the paralysis of inaction caused by future technologies that are still too far off to wait for.

Picking a technology that’s out of favor in five years isn’t a screw-up if you made the best decision from among available alternatives to actually get stuff done. That such a choice will eventually be obsolete (and sometimes sooner than you really have the stomach for) doesn’t represent failure on your part. On the contrary, it shows that you understand the importance of delivering value to end users in the present.

Microsoft recently held their annual PDC (Professional Developer’s Conference) during which Steve Ballmer and Bob Muglia (President, Server and Tools business) made comments regarding a shift in Microsoft’s strategy on Silverlight as well as a concerted focus on HTML5.  A subsequent article surprised the tech community around the future of Silverlight.  There was a lot of speculation and confusion last Friday; some people were suggesting that Microsoft was winding down Silverlight and others suggested that Microsoft simply screwed their messaging up.  On Monday arrived a clarifying blog post from Bob Muglia explaining that Microsoft is in no way backing away from Silverlight, and that it will remain a core technology well into the future.  Similar messages from Microsoft followed.  Another one worth reading came from Scott Guthrie a few days later.

Here’s my take on the situation.  First, it’s unfortunate that Mr. Muglia’s message was delivered and quoted the way it was.  Microsoft is now taking steps to try to undo the understandable surprise Mr. Muglia caused in the developer community. For some, regardless of all subsequent clarifying communication from Microsoft, they’ll still perceive it as simply kicking sand over Mr. Muglia’s unwanted and premature reveal of the truth. Some people have a thing against Microsoft, and they’ll pick the reality that conforms to their desires.

Silverlight is valuable, fills many of the gaps that HTML currently has and might always have, and continues to be a core Microsoft web development technology. The community uproar from the events of last Friday support this.  While there were PDC sessions on Silverlight and other established technologies, Microsoft focused their marketing machine on new technologies; Windows Phone 7, Azure, IE9 (with a lot of HTML5 focus), and other offerings for which they want to increase their exposure and market share. Remember that the PDC is as much about marketing Microsoft’s new and emerging technologies as it is about educating developers on the existing, successful ones!

The reality is that HTML5 is important and it’s still really early in its evolution. Microsoft, along with the rest of the world, realizes that the standard for the open web is moving toward HTML5.  HTML5 clearly strives to do what technologies like Silverlight and Flash already can, and for true standardization to occur it is essential outside any proprietary plug-in. The race between the giants like Microsoft, Apple, and Google is only just beginning, and a lot of the recent messaging from Microsoft around HTML5 can simply be seen as declaring their intent to be at the forefront of that race.  However, HTML5 has a long way to go before it meets the functional and development productivity levels of Silverlight, not to mention overcoming the browser compatibility issues that we still face with HTML4.  I, like anyone else, can only speculate, but it appears to me that truly pervasive use of HTML5 is still years away. In fact, the W3C is going so far as to suggest to the tech community to hold off on HTML5 deployments until the spec settles more.  Until that time, technologies like Silverlight will remain the go-to technologies for efficiently building rich, interactive applications that run across multiple browsers on multiple platforms.

For our customers that are building or are considering building Esri ArcGIS Server applications using Silverlight, my recommendation is to not let the recent articles and discussions cause undue concern.  Of course assimilating new information in order to make sensible, informed decisions remains paramount and I’m not suggesting simply disregarding recent news.  Rather, don’t be paralyzed by HTML5’s future potential and realize that Silverlight continues to remain a great option for efficiently building and delivering value to your customers today and for years to come.

Have you been missing all of the geocoding locator styles that were available in ArcGIS 9.3.1 that we no longer have in 10?  Well, pine for them no more.  You can download the 9.3 locator styles here and use them in 10.  This may also help fix a bug that you may have seen when building locators without City, State, or Zone information.

A helpful tip from the ESRI Support Services Blog: 

We have all been there…you kick off a large process, and while waiting for it to complete, you start to wonder, “Is this process still running?”

Many geoprocessing tools are memory intensive, and depending on the size of the input datasets and the type of computation, it can take hours to run.

If you find yourself staring at the computer screen after your 10th cup of coffee and still wondering, “Is this thing still working!?”, there is a quick and easy way to tell.  Read more…