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