Archive for the ‘ESRI’ Category

Jack Dangermond on the economy as it relates to GIS

February 25th, 2010 by Steven

Although the sound quality isn’t ideal, Directions Magazine has posted a video of an interesting interview with Jack Dangermond at ESRI’s Federal User Conference in Washington, DC last week.

Jack’s a guy who knows what’s up, so I was keen to hear his thoughts. The video includes Jack’s perspective on how economic conditions have been impacting organizations that use GIS and the vendors who serve them.

At the five minute mark he notes a trend around big custom one-off implementations done by integrators getting questioned these days, with COTS (Commercial Off the Shelf) solutions that do 90% of what folks want right out of the box being put in their place. Though we’ve observed it at a much smaller scale than what Jack is referring to, as a company that offers COTS solutions on top of ESRI’s COTS technology, this is a trend from which we’ve certainly been benefiting.

From global to sector-specific trends, the interview covers considerable ground. Definitely a worthwhile ten minutes.

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.

Wiki.gis.com

January 5th, 2010 by Stephanie

Launched by ESRI, and already “developing a community”, Wiki.gis.com is another great resource for GIS knowledge.

wiki.gis.com

2009 ESRI International User Conference Recap

July 21st, 2009 by Darin

Our team just got back from the 2009 ESRI International User Conference in San Diego – what a week! The sheer size of the conference (rivalling that of any major software vendor) always surprises me, but, given the crowds, its never been hard to find a friendly client, partner or conference goer eager to talk about mapping.

Our booth was well positioned this year, and we had some steady traffic. Its interesting to note that fewer people each year seem to wonder what Geocortex is – our multi-million dollar marketing campaign must be working. :) All kidding aside, I think the steady delivery of compelling software and services to organizations worldwide continues to propel our brand.

picnic2009The Geocortex Picnic set a high water mark of around 300 people – between the shaded location bayside and the ongoing struggle to find lunch in the Gaslamp district, many clients chose to join us for our annual hosted BBQ lunch. And our caterer, with mobile smokehouse and slow cooked BBQ in tow, makes for a good draw too.

Our latest work with the ArcGIS Server REST, Javascript, Flex and Silverlight APIs, showcased in the Geocortex Resource Center, seemed well received. The buzz on the exhibit hall floor seemed to suggest many organizations see significant value leveraging REST based development paradigms. I also noticed a number of demonstrations of Geocortex Optimizer happening, and early peeks at our mobile asset tracking solution for ArcGIS Server, Geocortex Fleet Tracker.

ESRI posts pre-conference Q & A

June 30th, 2009 by Steven

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.

ESRI posts pre-conference Q & A

June 30th, 2009 by Steven

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.

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.

The 2008 ESRI Southwest Users Group Conference

November 3rd, 2008 by Robert

Laramie, WY October 22-24, 2008

For the last six years, Latitude Geographics has attended every Southwest Users Group (SWUG) conference. From Jackson Hole in 2003 through to Laramie in 2008, the SWUG conference brings together GIS users from Arizona, Colorado, New Mexico, Utah, and Wyoming. This year’s high plains geospatial roundup offered up blowing snow and chilly temperatures – a big departure for a guy like me accustomed to Victoria’s moderate climate. But the warmth of the SWUG organizers (kudos to the entire organizing committee for an awesome job!) allowed the attendees to quickly forget about the cold temperatures, and settle into a dose (actually, many, many doses) of Wyoming hospitality!

geo_cortex_Rodeo_v1The SWUG event is not your regular, regional GIS conference. John Calkins, ESRI’s “Corporate Technical Evangelist” kicked things off with an interactive keynote session that engaged the group in a geographic approach to problem solving. Plenty of great user and vendor presentations followed, topped off with an evening keynote by Wyoming historian Bruce Blevins. Aside from all the interesting work-related stuff, I’d have to say that the highlight of the conference was the BBQ, Bluegrass, and Broncs event (disclosure: we were also a sponsor). This was not my first rodeo – but it was undoubtedly one of the most unique I’ve seen. The University of Wyoming Rodeo Team put on a presentation just for us, and we got to enjoy steer wrestling, calf roping, barrel racing and bull-riding. Yee-Haw! Later in the evening, we two-stepped to music served up by the Zarks, a local country-western band. I reckon the user sessions were a little subdued the next morning, but attendees (AKA SWUG-uhs) seemed to be wearing a collective grin.

It’s events like these that make me appreciate the industry we work in, given its great mix of knowledge sharing, professionalism, and appreciation for local cultural activities!

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.

Group Layers in Cached ArcGIS Server Map Services

September 12th, 2008 by Jade

Christian passed along a tip for when creating cached ArcGIS server map services that he picked up at this year’s ESRI International User Conference. When creating a cached map service, create an ArcMap “group layer” containing all the layers for each specific scale level.

By grouping layers by scale, you can quickly turn off and on the groups to define symbology and labels for each without concerning yourself with the other scale levels. You can also tell at a quick glance what information is available at each scale level.