<HTML><FONT FACE=arial,helvetica><FONT  SIZE=2>Mark:

<BR> 

We have been using the original version of Proj.4 in our products for several years in our C/Unix-based software products.  A couple of years ago, we used the MKS Nutcracker software development environment to port our products to PC platforms.  Today, we are completing full conversion and testing of our products into native MS/C++/MFC versions for PC's.

<BR> 

From the beginning, Proj.4 worked as advertised, and we had very few problems with the library.  Programmer interface documentation was not real good, but enough to get Proj.4 working in our products. Gerald Evenden personally provided good support when needed, along with lots of great nostalgia.  Our prior experience was with GCTP, and we knew we didn't want to use that in our products.

<BR> 

With MKS, the original C/Unix source codes were compiled pretty much as is, including the Proj.4 library.  We mostly had problems setting up the X-Server part of NutCracker, but once those were solved, everything worked fine.  If you are a Unix person, MKS provides all major Unix functionality on a PC, concurrent with MS Windows, which is nice.

<BR>

We've had no formal training in using Visual C++/MFC, but got most of our new software working recently, except for integrating Proj.4.  We first tried to build the old library and integrate that into our products, but ran into a lot of problems that, with our lack of VCC experience, we couldn't easily solve.

<BR>

After a little research, we realized there were newer versions of Proj.4 available, including a makefile for VC++.  Here, we had two problems: The first was something about incompatible libraries, causing linking to fail.  The second was that the programmer interface to Proj.4 had changed.

<BR>

With tons of source code calls to Proj.4, a tight schedule, and what seemed to be an absence of documentation on the new programmer interfaces, we decided to tweak the makefile.vc and use that to compile the old library under VC++.  Surpassingly, it worked, and linked up OK.  All our old Proj.4 calls are functioning correctly.  We still have one little problem with competing C and VC++ libraries being incompatible in our release version, but we'll get that worked out.

<BR>

Our software products primarily support production mosaicking, transformation, quality assurance and keyword header editing of USGS DOQQs, and are used by the USGS, their contractors and DOQQ users for quality assurance and mosaicking of those products.  Besides marketing our software products, we use our mosaicking and transformation software in support of our in-house production contracts in support of the USGS IP program.

<BR>

Once we get all our products going with the old Proj.4 we intend to get smarter with both MS/VC++/MFC and the latest Proj.4 releases, upgrade our existing products to the latest Proj.4 version, and get on with seriously delayed new product development and production backlog.

<BR>

Bottom line is that the old Proj.4 stuff has worked just fine for us in covering all UTM and SPCS projections over the Continental US.  Proj.4 has a lot of usage history, reliability and credibility that a do-it-yourself package would take a long time to acqire and prove.  You also now have this user support group.

<BR>

Sorry this is so long.

<BR>

<BR>Jere Swanson

<BR>Hawk Imaging Technology</FONT></HTML>