[fdo-internals] RE: Create a branch for GDAL 1.9 upgrade

[Greg Boone]

I don't have any issues with rolling GDAL 1.9 into FDO 3.7 if...

1) The MapGuide OS PSC is OK with taking this change
2) It doesn't require any mandatory changes from clients of the GDAL provider, meaning that the default options/behavior remain as currently implemented.
3) It doesn't immediately affect the current FDO tar distribution files, which are generated through scripts run on build machines.
4) Unit testing and System testing on Windows 32/64 and Linux are ok.

If we have any concerns with the list above, we can discuss the specific issues at hand. 

A sandbox may be convenient, but if the changes are minor, might be unnecessary. I would think a sandbox would only be required if we changed the Thirdparty build/install procedure, which in and of itself would require further detailed discussions on how to appropriately retrieve, package and distribute the GDAL binaries.

Regards,
Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
Sent: Wednesday, January 04, 2012 5:01 PM
To: FDO Internals Mail List
Subject: [fdo-internals] Create a branch for GDAL 1.9 upgrade

Hi list,

As part of a minor "resample method" enhancement for the FDO GDAL Provider, I am in the process of upgrading Thirdparty/gdal to version 1.9.  Version 1.9 is in release candidate mode and RC1 may be the official 1.9.0 release http://osgeo-org.1803224.n2.nabble.com/gdal-dev-Motion-Promote-GDAL-1-9-0RC1-as-GDAL-1-9-0-Final-td7141429.html.

I would like to create a sandbox based on trunk "sandbox/gdal19" for getting these changes into Subversion without immediately affecting FDO 3.7.  Ideally, I would like to roll the GDAL 1.9 update into 3.7.  For now, I will be replacing the existing GDAL 1.7 sources with 1.9 sources and making minor modifications to some of the build control files (nmake.opt, vcxproj) to support the switchover.  The Windows compile seems to fairly clean - I haven't had to touch any .cpp or .h files to build 32 bit Windows.  I haven't run the unit tests to see if anything is broken with the FDO OGR or GDAL providers yet.

I am building with Visual Studio 2010 SP1 and expect the have the VC 2010 builds (32 and 64 bit) working and unit tested before the end of the month - probably sooner.

Please let me know if this is ok.  I can also write up an RFC for the GDAL 1.9 upgrade if necessary (didn't see any for previous GDAL upgrades).



>From the NEWS for GDAL/OGR 1.9, there are a number of new features/drivers over 1.7:

[For GDAL/OGR 1.9.0] 
* New GDAL drivers: ACE2, CTG, E00GRID, ECRGTOC, GRASSASCIIGrid, GTA, NGSGEOID, SNODAS, WebP, ZMap
* New OGR drivers:  ARCGEN, CouchDB, DWG, EDIGEO, FileGDB, Geomedia, GFT, IDRISI, MDB, SEGUKOOA, SEGY, SVG, XLS
* Significantly improved drivers: NetCDF
* Encoding support for shapefile/dbf (#882)
* RFC 35: Delete, reorder and alter field definitions of OGR layers
* RFC 37: Add mechanism to provide user data to CPLErrorHandler (#4295)
* gdalsrsinfo: new supported utility to report SRS in various form (supercedes testepsg)


[For GDAL/OGR 1.8.0]
* New GDAL drivers : GTX, HF2, JPEGLS, JP2OpenJPEG, JPIPKAK, KMLSUPEROVERLAY,
                     LOS/LAS, MG4Lidar, NTv2, OZI, PDF, RASDAMAN, XYZ
* New OGR drivers : AeronavFAA, ArcObjects, GPSBabel, HTF, LIBKML, MSSQLSpatial, NAS,
                    OpenAir, PDS, PGDump, SOSI, SUA, WFS
* Significantly improved OGR drivers : DXF, GML
* New implemented RFCs : RFC 7, RFC 24, RFC 28, RFC 29, RFC 30, RFC 33


There have also been improvements/bug fixes to some of the drivers in GDAL 1.7, including Oracle Spatial GeoRaster.


Regards,
Trevor