Ticket #545 (closed enhancement: fixed)

Opened 4 years ago

Last modified 7 months ago

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

Reported by: dmorissette Assigned to: dmorissette
Priority: normal Milestone: 5.2 release
Component: OGR Support Version: 4.1
Severity: minor Keywords:
Cc: tylermitchell@shaw.ca, mapserver@geochem.de

Description (Last modified by 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.
-------

Change History

01/23/04 13:10:28 changed by dmorissette

  • cc set to warmerdam@pobox.com.

01/23/04 13:48:35 changed by 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.

10/27/04 21:00:16 changed by dmorissette

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

03/07/05 01:20:30 changed by tylermitchell@shaw.ca

  • cc set to tylermitchell@shaw.ca.
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?

03/07/05 08:33:42 changed by 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.

03/10/06 00:05:21 changed by 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 ;)

09/26/06 11:43:28 changed by dmorissette

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

09/26/06 13:09:50 changed by mapserver@geochem.de

  • cc set to mapserver@geochem.de.

08/01/07 14:58:43 changed by dmorissette

  • owner changed from mapserverbugs to dmorissette.
  • description changed.
  • milestone changed from 5.0 release to 5.2 release.

12/14/07 07:58:12 changed by dmorissette

  • status changed from new to closed.
  • resolution set to fixed.

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.

12/14/07 10:13:52 changed by 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.

12/14/07 13:46:14 changed by 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.