Because we support multiple platforms (Windows, Solaris, Linux, Mac), our Decode SDK is written in C++.  Some years ago, our C++ APIs used to regularly lead to the question, “do you support Java?”.  The answer was always sorry, no, we’re not a Java shop and we don’t have any Java bindings… But we’ve always provided a relatively simple C API which we claimed could be wrapped using JNI, and for the most part that made people happy.

For the past year or so, though, all the Java requests seem to have disappeared, only to be replaced by the question, “do you support .NET?”  This usually means “do you have any C# bindings?”, although we do get the occasional VB.NET request.  Our response has been sorry, no, we’re not a C# shop and we don’t have any .NET bindings… But, again, we’ve told people that “it ought to be fairly easy to call out to our C API using P/Invoke, .NET’s Interop functionality”.

Well, recently some of the engineers here at LizardTech HQ have started programming in C# for reals, and so now we actually have just enough in-house expertise on the question to be able to provide some additional help on this one.  While the current DSDK release doesn’t provide any C# bindings, we have put together a very simple example app that shows how to use Interop to access the C API.

The code is, at heart, remarkably simple.  First, you declare your C functions so they can be accessed from within your C# class, like so:

      [DllImport("lti_dsdk_cdll.dll")] 
      static extern int ltic_openMrSIDImageFile(out 
            IntPtr image, string fileName); 

      [DllImport("lti_dsdk_cdll.dll")] 
      static extern uint ltic_getWidth(IntPtr image);

Then, you close your eyes, tap your ruby slippers together three times, and innocently call the functions just like they were real functions:

      // this is essentially our void* pointer 
      IntPtr image = IntPtr.Zero; 
      string infile = "..."; 

      sts = ltic_openMrSIDImageFile(out image, infile); 
      ... 
      uint width = ltic_getWidth(image); 
      ...

You can download the full example from here.

Yes, we know, it’d be nice to provide interop support for the C++ classes so as to give access to the whole SDK… but quite frankly, we’re not sure the market demand is really there yet.  At the very least, though, we’ll try to include interop support for the C API in the next release of the SDK.

Keep those cards and letters coming.

-mpg

Last week I had the pleasure of attending GeoWeb 2008 on behalf of both LizardTech and OSGeo. The conference was once again in Vancouver BC, at my favorite business hotel and conference venue. I’ve attended this conference for a number of years now, and it gets better every passing year.

Just a few highlights:

• The underlying theme running through the week was the integration (confluence? convergence?) of the GIS world with the worlds of CAD and BIM (building information model). Architects typically operate at a different scale than we’re used to, but increasingly they want to be able to envision and model their buildings in the larger urban landscape that we can provide for them. Kimon Onuma and his BIMStorm work demonstrated this integration very well. Going the other direction, traditional GIS folks are looking to things like CityGML to be able to improve the fidelity and add that 3rd dimension to their own models.

• I moderated a one hour discussion on Open Source Servers, ably assisted by panelists Paul Ramsey of Clever Elephant, Justin Deoliveira of OpenGeo, and Bob Bray of Autodesk. The attendance was good, and we had some good questions and discussions about the pros (and sometimes cons) of working in and with open source software.
• On behalf of Cody Benkelman of Mission Mountain Technology, I also presented a cool paper on using Amazon’s Mechanical Turk web service and Google Earth to solve a real problem for a real customer. I tried to get across two main ideas. First, Turks and Turk-like things can be seen as “outsourcing for the Web 2.0 generation”. Secondly, and possibly disconcertingly to some, complete “automation” is not always the best answer – us geeks think of it first, and yes, it’s usually the right move – but not always. Contact us for reprints.

• Dr. Michael Goodchild gave a great workshop on Data Quality – a topic which quite honestly sounded pretty dry and uninspiring, but which turned out to be both educational and interesting. He convinced me that LizardTech’s viewers are displaying lat/long incorrectly, at least from a data quality perspective.
• Michael Jones of Google keynoted again this year, and he once again made everyone stop and think deeply about the human impact the geo community can – and does – have on the world. Not the kind of talk you can summarize easily, you just had to be there.
• This year the conference held its first Student Competition. The competition required use of open source software for the projects; OSGeo was one of the sponsors and as such I was one of the judges. First prize went to Tobias Fleischmann (Paris Lodron University Salzburg, Germany) for “Web Processing Service for Moving Objects Analysis”, which was built using deegree. Second prize went to Tran Tho Ha and Nguyen Thi Thanh Thuy (Politecnico di Milano, Italy) for “e-Collaboration for DGPS/GPS data distribution and receiver device evaluation”, which used PostGIS, MapScript, and OpenLayers. Congratulations to both winners!

• GeoWeb is also famous for being scheduled during Vancouver’s annual “Celebration of Light“, an international

  

  fireworks competition held several evenings high above English Bay. As in previous years, the conference’s evening reception was turned into a sunset dinner cruise, after which we all went up on deck to oooh and aaah at the pyrotechnic ballet.

Finally, just for kicks, I’ll offer the following bits of geotrivia I collected during the conference:

• “A GPS with a bullet hole in it is a paperweight. A paper map with a bullet hole in it is a paper map with a bullet hole in it.” (attributed to the US Marine Corps)
• Tobler’s First Law of Geography: “Nearby things are more similar than distant things.”
• city furniture (noun): features of the urban landscape such as park benches, bus shelters, street lamps, etc
• “The amount of metadata needed for a piece of data varies with the ‘social distance’ from me to my data consumer.” (Michael Goodchild)
• For Amazon’s web services, 85% use the REST API and 15% use the SOAP API. (quoted by Satish Sankaran, ESRI)
• On the Vancouver transit system today, 100 of 144 bus routes are under detours, due to 2010 Olympics work. (Peter Ladner, Vancouver deputy mayor)
• Thirty percent of all 911 calls are not associated with a street address. (Talbot Brooks)

GeoWeb 2009 is already being planned, and will include special emphasis on both cityscapes and 3-D modeling.

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!