Geocortex Blog

Geocortex Essentials allows administrators to add Bing Maps services to their applications, in both Web ADF Elements and in our REST Elements architecture. 

Traditionally connecting to Bing Maps was a bit of a headache since you (the administrator) had to acquire a Bing Maps token using a special Bing Maps username and password.  Also, the token would expire so application logic had to be written to re-acquire a token once it had expired.  There’s actually more details involved with tokens than I’d prefer to get into in this post – perhaps it’s enough to say it wasn’t entirely straightforward.

Well, recently Microsoft has “deprecated” the notion of Staging VS Production services, and access to Bing Maps can now be managed via a “Bing Maps Key”.  To acquire a Bing Maps Key, you use your Bing Maps Developer Account (which actually uses your Windows Live ID).  More information on acquiring keys can be found here: http://msdn.microsoft.com/en-us/library/ff428642.aspx

Access to Bing Maps via tokens is still supported by Microsoft.  They suggest that tokens are only required if you require transaction reporting (discovering how many requests your users are sending to Bing Maps).

To be honest, I was initially a bit frustrated with this change – particularly with the timing: right before the ArcGIS 10 final release (and the corresponding 2.0 client API releases), and therefore right before our Geocortex Essentials 3.0 release.  Changes in underlying architecture mean that we have to change our software to cooperate.  After implementing the change to ensure Geocortex Essentials and our client APIs will work with Bing Maps keys, my frustration melted away.  The keys are a much cleaner, easier way to work with Bing Maps, and they don’t expire.

For many years, Latitude Geographics has fielded various recreational sports teams for the simple pleasure of spending time with one another while we get some exercise and have some fun. We often played as part of University of Victoria intramural leagues, and we always got clobbered by athletic teams of 21-year olds. I mean, we got our butts kicked. Over and over, regardless of the sport.

This year (disclosure: as part of the VIATeC league, comprised of a comparable demographic of fellow IT professionals), our softball team is doing really well. In fact, with just a week to go in the league, we’re presently undefeated and sitting in the number one spot.

I’m Canadian, which disinclines me from even remotely acknowledging our present #1 standing. However, I’m also not on the team this year, and I’m excited by how well things are going for them.

Go team!

When creating a cached map, the extent of tiles built will be based on the full extent that you have set in the MXD.  Partial tiles will not be created.  This means that even if you set the top cache scale at 1:1 million, it will not necessarily create tiles for your entire visible map (in the MXD) at 1:1 million.  By this I mean that the tiles around the perimeter may get cut off.  For example, full tiles will be built starting from the middle of the map.  When you get to the edge of the map, the full extent specified in the MXD may run down the middle of a tile.  This tile will not be created, as it is “incomplete”.  This is why it may appear that some tiles are missing or have been cut off at full extent in the viewer.

One solution I have found is to set the MXD full extent wider than the extent of all data in the MXD (this is the default full extent).  Create the cache tiles at whatever your desired scales are.  When the tiles are finished, you can then go back to your MXD and set the full extent to your desired full extent (the extent that is used by the “full extent” button on the site).

We’re delivering a maintenance release of Geocortex Essentials today.  Like other maintenance releases 2.3.2 repairs a list of issues; however, it does not introduce any new features.

Consult the release notes to determine if this release contains updates that may be important to you.  The release and accompanying documentation can be found in the downloads section of our Support Center.

I’m working on a new feature for our client-side APIs and ran into a bit of an annoying behavior within Visual Studio. When debugging using a solution that contains multiple web applications, Visual Studio insists on starting up a development web server for each web application within your solution. After spending 10 minutes looking for a setting within Visual Studio and 15 minutes Googling around various development web sites, I came across the answer. There is a well hidden project-level property that controls this behavior.  To change it, click on the project in question within Solution Explorer.  Pull down the View menu and select Properties Window (which apparently is different from Property Pages).  The first property in the resulting list is Always Start When Debugging. Set that to False and you’re good to go.

A great article by Adena Shutzberg, over at Directions Magazine for folks involved in writing “local GIS” articles. If you ever forsee yourself needing to communicate what your organization is up to with GIS or web mapping for public consumption, definitely give this article a read. Better still, bookmark it or print it (and pop it in your Media folder).

With our virtual user conference coming up in early June, we’re discovering how different the online format is as we get into the nitty-gritty of hosting the event.

Undoubtedly, you just can’t beat face-to-face interaction and the energy of a live group. We know a live conference is better; provided that enough people will actually be there. However, our survey indicated that most would’ve been unable to travel to either Victoria or Seattle this year due to travel restrictions.

After deciding the show must go on, it became apparent an online conference would circumvent the core problem (travel) and is doable technology-wise. So we made the commitment, while making clear it’s a big experiment. I’m confident the content will be better than ever before, but I think we didn’t fully appreciate just how radically different a live in-person event is from a live online event. 

For example, think about time zones. When people fly here from Europe they usually have a day or two to recover from jet-lag, and they fully accept the conference schedule during Pacific Daylight Time. On the other hand, if you haven’t left your time zone, the idea of staying up until 2AM is utterly preposterous. Looking back, perhaps we should’ve scheduled sessions for two hours a day over two weeks. But even then, it’s always a lousy time somewhere in the world.

Our solution to the timezone challenge is to record every session and make the videos available for convenient later viewing by attendees, but those folks still won’t get to participate in live polls and other interactive components. Again, I’m confident we’ll deliver good value and hosting the event will be far better than the alternative (nothing), but my point remains… live vs. online conferences are very different animals.

Stay tuned for a candid self-assessment next month of how things go. And be adventurous… don’t forget to register.

Just a quick little tip I picked up for ArcMap: under the Tools > Options menu, on the General tab, you can uncheck the “Make newly added layers visible by default” box.  This is especially useful when you are adding many layers or large datasets to your map, because you won’t have to wait for them all to draw.

I’m pleased to announce the release of Geocortex Optimizer 1.4. We started working on 1.4 a few months ago and I’m very happy with the results.

Version 1.4 introduces a number of new reportlets that will give valuable insight into how your customers are using tiled map services. For example, we added an interactive heat map reportlet (shown below) that you can navigate to get some real insight into what your customers are actually looking at. We also created a reportlet that shows which tiled map service scale levels your customers are viewing. I bet that if you spend some time navigating these two reportlets, you might be surprised with what you find.

Optimizer 1.4 has a new collector that will help you monitor the availability of ArcGIS Server Geocode services – a great help to those who deploy highly available Geocode services. During the 1.4 release, we also spent some time ensuring compatibility with the soon to be released ArcGIS Server 10.0 and we spent a lot of time speeding up our reporting component which, for certain types of data, could be a little on the slow side. Once Essentials 3 is released, Optimizer 1.4 will also report on user activities within Geocortex Essentials. For example, it will show you which Essentials reports your users are printing, what feature hyperlinks they are following and what searches they are performing.

You can download Geocortex Optimizer 1.4 from the Geocortex Support Center.

Geocortex Essentials 2.3 continues to generate a lot of interest with users and the uptake has been strong. As with any major release, we weren’t surprised to learn that there were a couple of issues which have come to our attention.  At 2.3 we shipped a totally redesigned installer, which provides some huge improvements at upgrade time.  Of course, we thoroughly tested the new installer (for over four weeks actually).  Despite this, a few real world customers inevitably turned up a few bugs and oddities that required love. Sigh. I suppose with installation there’s always going to be some environments and unique scenarios that can’t be predicted… or perhaps we just missed a couple.  

Whatever the case, we packaged up these resolutions (and a couple other bug fixes) into a 2.3.1 maintenance release.  It’s available now, and as always the release notes are available on the Support Center.  Consult the release notes to determine if it makes sense for you to upgrade.

I’m pretty excited about this maintenance release since it’s our first release which will leverage the simplified upgrade capabilities of the previously mentioned installer.  Provided Geocortex Essentials 2.3 is installed, you can seamlessly upgrade (in-place) to 2.3.1.