This week, LizardTech released the latest version of it’s GeoExpress SDK — a set of C++ libraries designed to make it easy for developers to add MrSID and JPEG 2000 support to their applications. Aside from the usual round of bug fixes and such, the big draw for this release is the number of platforms we’re now (some might say “finally”) supporting:

Windows

• Win32, VC7.1/32-bit
• Win32, VC8/32-bit
• Win32, VC8/64-bit
• Win32, VC9/32-bit
• Win32, VC9/64-bit

Linux

• RHEL3, gcc3.2.3, 32-bit
• RHEL3, gcc3.2.3, 64-bit
• RHEL5, gcc4.1, 32-bit
• RHEL5, gcc4.1, 64-bit

Solaris (SPARC)

• Solaris 8, v11 compiler suite
• Solaris 8, v11 compiler suite (64-bit)

Mac

• Mac OS 10.4 (Darwin8) / Universal (32-bit)
• Mac OS 10.5 (Darwin9) / Universal

That works out to about 13 different build configurations — yow! Remind me sometime to blog about Bob, our automated 24×7 build system…

Oh, and actually there’s one more reason to like this release: the license agreement has been made simpler, shorter, and more friendly to open source developers. While our SDK is not open source, we know a number of open source packages that wish to link it in or redistribute it, and we want to make that as simple as our lawyers will let us.

The JPEG 2000 standard provides for a variety of encoding options available: depending on where you sit, this makes for either a very cool experience or a very daunting experience. For the geospatial realm, where we deal with very large images, this plethora of choices is particularly important, because the choices you make at encode time can significantly affect both encode and decode performance, for both memory usage and CPU time. And, unfortunately, it’s often the case that fast encodes can make for slow decodes, and vice versa.

We’ve designed GeoExpress to default to a reasonable compromise in its choice of encoding options, and we’ve also provided a few “profiles” (predetermined encoder settings) based on NGA’s recommendations for workflows with particular requirements. Nonetheless, I’d be the first to admit that the subtle tradeoffs among tile sizes, precinct sizes, codeblock size, progression orders, quality layers, ad inf., can be truly bewildering. I give talks and write high-level articles on this JP2 stuff pretty regularly, but I’ve never quite had the time to do a stand-alone white paper discussing specifically JP2 performance and profiles using the internal benchmarking we’ve done inside here at the LizardTech Labs.

Happily — for those technically inclined, anyway — Margaret Lepley of MITRE Corp. has just done the work for me, publishing an article showing some good benchmarking analyses of these performance issues at http://link.aip.org/link/?PSI/6943/69431B/1. It is not downloadable for free, but if you’re looking for a good read on the difference that tiles and progression orders can make, I’d strongly recommend it.

JPEG 2000: fast access to large grayscale images, Margaret Lepley, The MITRE Corp.,
Proceedings of SPIE — Volume 6943

JPEG 2000 image compression allows many formatting alternatives, but users frequently have insufficient knowledge or experience to direct the choice. At compression time many of these options may seem approximately equal, but during exploitation the file structure differences can have a huge impact on access speed. This is particularly true for very large images such as those regularly used in remote sensing and many defense systems. This paper examines the impacts of JPEG 2000 options such as tiling, tile-parts, precincts, and packet ordering on large single band images, particularly in relationship to random access speed.

This week LizardTech finally retired our worn-out old bug tracking software for something shiny and new.

Our old system, whose name I politely won’t mention, has done a fair job for several years now, but as our engineering practices have developed and matured the software just wasn’t able to keep pace with our needs. Oh, we did try – I’ve got the SQL scars to prove it – but we reached a point where we finally found something that seemed to do everything we needed without needing me to bolt lots of kludgy scripts on top of it.

You see, while the engineers here are really good at writing code and fixing bugs, us manager types have had an increasingly hard time keeping track of all the features and bugs being worked on, which release they are for, when they will be fixed, and so on. We wanted a tool that would allow us to do simple, lightweight, intuitive schedule estimation, as part of the normal bug tracking system, and we think we’ve found it.

We’ve been fans of Joel “Smart and Gets Things Done” Spolsky for a long time, and to varying degrees we’ve adopted his ideas for task estimation and hiring. And so when he came to Seattle last year on his World Tour a bunch of us Lizards hiked up the hill to see just what this FogBugz thang was all about – and we came away impressed.

You can find a lot online about FogBugz, both on the company’s website (they’re called Fog Creek Software) and on others’ blogs and such, so I won’t go into detail here. Instead, let me just point out three things that sets it high above other systems we’ve seen:

• The interface is only via the browser, which initially had me worried – until I started actually using it. Intuitive interface controls, sweet filtering options, flexible searching, very responsive feedback – one of us commented that this is one of the only Ajaxy apps he’d used that had actually got it all right.
• Project estimation is fun again. The “EBS” system they use for estimating ship dates may seem a little over the top when described in print – Monte Carlo methods? for project planning?! – but by golly in actual use It Just Works. Of course, the graphs produced are only as good as the data you’ve entered, but that entry process is clean and easy – and, most critical, it’s developer-friendly enough that the engineers need not stress out about careful time-keeping.
• Tech support is both responsive and helpful. Emails (and forum questions) are quickly and fully answered, with follow-ups welcome. Real, live, breathing humans on the other end of the line – how cool is that?

There’s a lot of other stuff in there we’re not using – Wiki, discussion groups, customer email, stuff like that – we’ll see, maybe later on. For now, it’s a system that gives us much better visibility and control over features and bugs.

Which makes for happy managers and developers.

How cool is that!

LizardTech isn’t in a position to be able to do the 20% Google thing, but over the past couple years here I have been fortunate to be able to spend a little of my time “giving something back” to the GIS community.

Back in February of 2006, I had the chance to spent a cold and windy day at an airport hotel in Chicago in a meeting with a couple dozen luminaries from the open source and activist wings of the geospatial world. The open source ecosystem for our industry was getting more attention and traction, and people were starting to form some sort of organization which could serve as a clearinghouse for these development efforts, promote the use of open source in industry, champion the use of free and open products in education, and so on. By the end of that day, the domain name “osgeo.com” had been registered and the Open Source Geospatial Foundation was born.

As a for-profit company, LizardTech and others have lots of reasons to support the open source movement. Esteemed coauthor Matt Fleagle and I wrote an article about this very topic last year.

This past year, OSGeo has seen the birth of a number of chapters, based around communities of regional interest or common language. The Cascadia Users of Geospatial Open Source (CUGOS) formed here in Seattle last spring, meeting every month here at our offices in Seattle – it’s nice to have a chance to meet other open source geo folks face-to-face for a change, instead of just trading emails and IRC messages.

We Lizards were also very fortunate this year to meet the up with the OSGeo tribes at the FOSS4G conference in Victoria. I and four other LizardTech engineers went up north for the week, and we all came home with a much better appreciation of the broad set of libraries and applications we can build on, as well as the people who work on them.

Speaking just as an individual, it’s been a great privilege to get to know and work with the people from across the globe that make up OSGeo – smart and principled people all, but with a refreshingly diverse set of backgrounds, skills, and passions.

For many years, LizardTech has relied on open source software as one of our strategies for more effective development of robust software. I’m proud that we’re able to associate ourselves with OSGeo, and we look forward to another year of collaboration and growth with the Foundation.