Geocortex Blog

As a second post in a series describing my favorite features in Geocortex Essentials 2.2, I’ve decided to talk about the text markup enhancements.

The Text Markup Enhancements encapsulate 3 features in one… actually, the requirements were originally defined as 3 seperate features but the more we looked at it, the more it made sense to roll all of the requirements into a single feature which enhances the text markup tool.

The three features are:

1. Callout Markup: This allows users to place text markup on the map within a callout box which has a pointer to the specific location that the user clicked.  It can make text markup much more informative, and readable.
   
2. Feature Label Markup: This allows users to add text markup to the map, where the text is defined by the attribute values from a feature which intersects the point clicked.  For example, a user could add a label markup element to a parcel indicating it’s land value.
   
   
3. XY Coordinate Markup: This allows users to add text markup to the map which indicates the XY coordinate at the point clicked.  XY coordinates can be displayed in map units, decimal degrees, or degrees/minutes/seconds (DMS).
   

Having all 3 markup tools rolled into a single text markup tool provides the additional benefit of being able to combine these features.  For example, the markup output below is a callout markup which contains a feature label, and an XY coordinate, all created from the same text markup tool from the same point on the map.

Like all markup tools, once the markup has been added it can be printed in the map using the Print Templates feature, or exported with the Export Map Image feature.

I think these are great tools that will enable better collaboration between colleagues using Geocortex Essentials and I’m happy to see them in this release!

Following a beta period which extended through the holidays, yesterday we released Geocortex Essentials 2.2!

I’m particularly excited about this release – it knocks off a number of features we’ve had on our list for a while.  Over the next couple of weeks I’ll blog about some of my favorite features in this release.

As usual, the release notes for 2.2 are available on the downloads page on our Support Center.

Today we cut the 2.1.2 release of Geocortex Essentials.  Like other maintenance releases, we didn’t introduce new features; however, we did include a number of defect resolutions.

Head over to our support center downloads page to see the release notes for 2.1.2 to determine if you would like to upgrade.  There you’ll also find the 2.1.2 version available for download.

Today we’re announcing the release of Geocortex Essentials 2.1.1. This is our first official maintenance release. At the release of 2.0, the products team decided that we needed a way to deliver defect resolutions to customers quickly. Previously we would create patches, but patches have their own set of problems:

• Installation of a patch involves manual steps
• The version of the assemblies packaged with a patch are the same as the version of the release (the only way to determine if someone has a patch installed is by the timestamp and file size of the patched assemblies)
• Creation of a patch requires overhead

So, maintenance releases will allow us to deliver defect resolutions in a product release. The idea is that we will be able to frequently release maintenance versions of our Geocortex Essentials software. You can distinguish a maintenance release from a major or minor release by looking at the software version number – we will increment the build number for maintenance releases, the minor version number for minor feature releases, and the major version number for major releases (look here for more on version numbers).

Supporting the idea of frequent maintenance releases is the development of our new installer which will support in-place upgrades as well as the traditional side-by-side installation so that applying the fixes in a maintenance release will be easy. Look for the new installer in early 2010.

To determine if a maintenance release contains resolutions to defects you are experiencing, consult the release notes. Geocortex Essentials 2.1.1 and the release notes are available on our support center.

About 3.5 months have passed since our 2.0 release of Geocortex Essentials. Since then, we’ve been busy. We released a “dot” release (2.0.1) in late July but I have to admit that it’s more exciting to announce a major or minor release containing new functionality.

For Geocortex Essentials Web ADF Elements we’ve put a lot of work into features that our customers have been asking for like support for coded domains and subtypes, and identify on WMS and raster layers. There are a number of other features and quite a few bug fixes as well!

For Geocortex Essentials REST Elements we’ve focused our attention on extensibility and developer support. Specifically, we’ve added the ability for a developer to easily augment our REST API by standing up their own custom REST endpoint. Developers can also create custom Site.xml extensions to add functionality to sites.

We’ve included a lot more into this release than what I’ve mentioned here – for those interested I encourage you to review the 2.1 release notes on our support center download page.

If you’re familiar with the software history of Latitude Geographics, you’ll know that we used be a Java shop. Now, we still use Java for our ArcIMS generation products, while we’ve adopted .NET for our ArcGIS Server Generation products.

In contrast to Java, Microsoft .NET has a very explicit versioning scheme. From MSDN:

“Each assembly has a version number as part of its identity. As such, two assemblies that differ by version number are considered by the runtime to be completely different assemblies. This version number is physically represented as a four-part string with the following format:
…”
http://msdn.microsoft.com/en-us/library/51ket42z(VS.71).aspx

When we build our .NET products, we want our assembly versions to reflect the released product version, and vice-versa.

Most of the software industry is in agreement on the use of the first two digits of a software version (major and minor). Incrementing the major version is typically reserved for releases containing major new features, rewrites, new technologies or paradigms. Incrementing the minor version signifies a release containing new features. There is some discrepancy in the industry; however, over the use of the build and revision numbers. Indeed, our staff has had differing views on how to use these numbers as well.

At the release of Geocortex Essentials 2.0, we’ve decided to change our perspective on this so it’s worth mention.

Pre-2.0
Prior to 2.0, a build number increment could include new feature development. That is to say that 1.3 and 1.3.1 both introduced new features; however, 1.3 was probably more significant than 1.3.1 with regards to the features it introduced. A “Hotfix” typically embodied a release containing bug fixes only (e.g., 1.4 Hotfix 1). It is worth mention that revision number is automatically generated, and typically reflects the number of physical builds created on our build server since the increment of a build, minor, or major version number (i.e., we “zero” the revision number when incrementing any other version number).

We also introduced “Service Packs” when we felt that the changes didn’t warrant a version upgrade (e.g., 1.5.2 SP1). This was not a decision based on a “rule”. I’ve always been dissatisfied with this somewhat ad-hoc approach to versioning, so following 2.0 we’ve decided to be a bit more procedural.

2.0 and Beyond
As with prior to 2.0 the major and minor version number will be reserved for major product architectural or conceptual changes, and the revision number will reflect the number of physical builds created on our build server. The main difference is the way in which we will treat the minor and build numbers. Going forward, we will increment the minor version any time that a release introduces new features. We will increment the build number to signify a release which contains bug fixes. A few examples will help clarify.

It is worth mentioning that a goal we have in the near future is to better support version upgrades of our Geocortex Essentials software. If we can distribute “dot releases” frequently without causing our customers the hassle of migrations during upgrades, we are better equipped to provide faster turn-around times between defect detection and resolution.