New Xcode project to build GRASS.app from source [download link fixed – oops]. Currently for 6.3 CVS, but one that works for 6.2 release source is on its way.

Also, new 6.3 CVS binary, built using said Xcode project.

GRASS 6.2.1 released. Plus a small change for the Mac app – since the Aqua TclTk GUI has cosmetic and other problems, GRASS.app will always use the builtin X11 TclTk.

Catching up on some Universal stuff – the nad2bin utility now always generates little-endian NAD files, whether run on a PPC or Intel Mac. This is important for building GRASS, since it generates its own copy of the NAD files. The Xcode project has also been updated to apply the endian patch to the source.

GDAL internal restructuring broke QGIS – specifically the Postgres support. New QGIS 0.8 preview 2 fixes that.

For GDAL itself, I patched the PGEO driver so it would work without the MDB Tools Access ODBC driver. It should now work with Actual’s Access driver again.

I also restored the GDAL documentation (dropped during the restructuring). In addition, the GDAL help is now conveniently available from the Mac OS X Help Viewer!

Baka, baka, baka… [stupid, idiot, … for the non-Japanese readers]

In setting up the Xcode project for GDAL, one of the GRASS libraries was left as a duplicate of another GRASS library. Thus the db drivers for GRASS wouldn’t link or load no matter what I tried. (That means attributes couldn’t be accessed from OGR or QGIS.)

This has been fixed in today’s GDAL framework. The Xcode project has also been updated to match.

I removed a couple unnecessary GRASS libs from the GDAL framework. These where not needed for the GRASS plugin to work, but QGIS links to one of them directly.

For now I restored the missing GRASS library in the GDAL framework, but I want to get away from linking to internal bits of the frameworks. QGIS doesn’t use GDAL for the GRASS formats, so in future QGIS builds I’ll have to think about including it’s own copy of the GRASS libraries.

PS. Xcode is having problems linking the GRASS db drivers. I just found that dynamic lookup doesn’t help, so OGR can’t read GRASS vector attributes. Damn.

There was a problem with GeoTIFF in the last GDAL framework, the embedded CSV option for the GeoTIFF library caused crashes. Fixed.

I am now building the whole thing, including dependency libraries, in an Xcode project (which I’ve also made available). In a further cleaning up of the internal organization and to facilitate building optional formats in Xcode, many formats are now plugins.

For UnixImageIO, when I made that Xcode project, I forgot to release the built framework from that, which the recent PHP builds were based on. This created a version mismatch with the old UnixImageIO that broke PHP. Nothing changed in PHP, you just need the new UnixImageIO framework.

Oh, yeah, there’s also a PROJ Xcode project.

Either only one person is using MapServer on Panther, or only one is willing to say something ^_^ (Sorry Jonathan, my email replies keep getting bounced with address not found.) Or only one person has upgraded to 4.10 – 4.8 is OK.

Anyways, MapServer should now work again on Panther. I had switched back to using the system CURL, which is incompatible between Tiger and Panther. I think that happened as a part of my GDAL framework simplification (it had a copy of CURL).

Yay, I finally got around to this! For now it’s just PHP5 CGI, I’m having trouble getting the Apache module to work. To go along with PHP5 is a MapServer MapScript extension, and an updated PHP Enabler that knows about the new PHP5.

Also, PostGIS has been updated to 1.1.6 in the Postgres+PostGIS package.

I fixed a couple GDAL framework problems.

One from the most recent update – I messed up the PPC build, forgot an endian patch.

Another that has probably been around a while – the GRASS support was missing a file that affected QGIS’ ability to open mapsets (but not GRASS data directly).