[MapServer-OGR] Use C API in mapogr.cpp

[dmorissette]

In an email to mapserver-users, Frank suggested that we convert mapogr.cpp to
use the OGR C API to facilitate upgrades of OGR without recompiling MapServer. 
That could be a good idea for when we have time.  I'm filing this enhancement
bug so that we don't forget.

Frank wrote:
-------
This is something I would dearly like to fix in MapServers' windows build structure,
but to accomplish it (practically speaking) we almost need to rewrite the
mapogr.cpp module to use the OGR C API and to reexamine the use of some of the
style related definitions in mapogr.cpp.  The use of static OGR libraries in
MapServer causes me no end of headaches.
-------

[fwarmerdam]

I would note there are really two issues coming into play. 

One is to build mapserver on windows against the GDAL DLL instead of linking
in static libraries.  However, that is apparently currently impossible because
mapogr.cpp uses various OGR classes (I think it is the style related stuff)
that is not properly accessable from the DLL.  I'm not sure why, and it might
be possible to add CPL_DLL to some additional classes to get this working 
though I made one weak attempt at this and failed.  Building mapserver against
GDAL's DLL instead of statically linking in some stuff would make it much easier
for people to drop in new GDAL DLLs with bug fixes or different build options. 

The second issues is changing mapogr.cpp to use the OGR C API.  The main 
advantage of this is that it would be a much less fragile interface between 
mapserver and OGR.  The C++ interface signature tend to change from time to
time making it hard to upgrade an existing mapserver to use a new GDAL DLL
without recompiling everything against the new include files.  I already changed
OpenEV to use the OGR C API for this reason, and the GDAL C API is already used
on the raster side.  The biggest complexity in this area would once again be the
style classes which I think don't have good C wrappers though I am not sure. 

[dmorissette]

Setting FUTURE target milestone. This would be a nice thing to do, but
definitely can't be done for 4.4

[tylermitchell@…]

I see some talk about a 'plug-in' environment for GDAL/OGR.  Is this bug 
related to that new 'feature' - I mean, will it fix this bug?  Any ETA on 
squishing this one? 
 

[fwarmerdam]

Tyler, 

plugins for gdal/ogr are unrelated to this bugs issue (that MapServer's
OGR link would be less fragile if it used the C api). 

There is no eta for resolving this bug. 

[hobu]

The Windows Build Kit that I developed for MSVC 7.1 is *always* building MapServer against the GDAL dll 
dynamically.  Both Assefa and myself are now using this to create binaries.  So that problem has gone 
away.  

Still have the OGR C API think though ;)

[dmorissette]

Setting target milestone to 5.0 release. We should really switch to using OGR
via the C interface in MapServer 5.0.

[dmorissette]

Fixed. I have committed a new mapogr.cpp that uses the OGR C API in r7168 (will be in MapServer 5.2).

Versions of GDAL/OGR older than 1.5.0 didn't have C API functions for the style classes. This has been addressed in GDAL/OGR 1.5.0 with  http://trac.osgeo.org/gdal/wiki/rfc18_ogr_styles_c_api. This means that GDAL/OGR 1.5.0 or more recent is required to get full C API support. However, compatibility (using C++ style classes) has been maintained with older GDAL versions:

MapServer's updated configure script checks the GDAL version and sets -DHAVE_OGRSTYLE_C if it finds GDAL 1.5.0 or more recent, which enables the use of the OGR C API for styles. With older GDAL versions, the C++ methods are still used (-DHAVE_OGRSTYLE_C won't be set).

Note that r7168 also fixes #697 if GDAL/OGR 5.0 is used.

[dmorissette]

Frank informed me that we can test on GDAL_VERSION_NUM instead of adding a custom HAVE_OGRSTYLE_C define, so I have removed HAVE_OGRSTYLE_C and updated mapogr.cpp to test on GDAL_VERSION_NUM instead. I have also reverted my changes in configure.in and nmake.opt since they are no longer required.

Committed to SVN trunk in r7171.

[warmerdam]

I discovered that OGRSpatialReference was still being used (r7172) and then defined CPL_SUPRESS_CPLUSPLUS (new in GDAL 1.5) to avoid dependencies on CPLString, and OGREnvelope (r7173).

With these changes the libmap.dll looks to be clean of C++ dependencies on win32 which seems more prone to picking up linkage dependencies just based on seeing a definition in an include file.