#545 closed enhancement (fixed)
[MapServer-OGR] Use C API in mapogr.cpp
Reported by: | dmorissette | Owned by: | dmorissette |
---|---|---|---|
Priority: | normal | Milestone: | 5.2 release |
Component: | OGR Support | Version: | 4.1 |
Severity: | minor | Keywords: | |
Cc: | tylermitchell@…, mapserver@… |
Description (last modified by )
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 (12)
comment:1 by , 20 years ago
Cc: | added |
---|
comment:3 by , 19 years ago
Milestone: | → FUTURE |
---|
Setting FUTURE target milestone. This would be a nice thing to do, but definitely can't be done for 4.4
comment:4 by , 19 years ago
Cc: | added |
---|
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?
comment:5 by , 19 years ago
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.
comment:6 by , 18 years ago
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 ;)
comment:7 by , 18 years ago
Milestone: | FUTURE → 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.
comment:8 by , 18 years ago
Cc: | added |
---|
comment:9 by , 17 years ago
Description: | modified (diff) |
---|---|
Milestone: | 5.0 release → 5.2 release |
Owner: | changed from | to
comment:10 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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).
comment:11 by , 16 years ago
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.
comment:12 by , 16 years ago
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.