ArcSDE and compiling versions of OGR / MapServer

[Howard Butler]

Mike,


>Our solution also uses the OGR tools and specifically ogrinfo to find out
>field names from ESRI shape files or MapInfo Tab files.  We have been quite
>fortunate in that we have been able to use the compiled binaries from
>FWTools (and another thanks to Frank for these!).  Unfortunately this method
>won't work for ArcSDE as FWTools doesn't support ArcSDE.  It got me thinking
>to how MapServer now works with the libmap.dll's for different input
>formats.

Actually, GDAL/OGR provides the elegant solution to this problem -- 
plugins.  In the latest MS4W, there is a dll called ogr_SDE.dll that 
when activated by some special environment variables provides the SDE 
driver to OGR.  Frank doesn't distribute the SDE plugin for OGR with 
FWTools because of the need for an SDK/SDE license, but I have been 
providing both the OGR plugin and the libmap.dll for SDE for MS4W 
because I do have access.  Note: to use the OGR SDE plugin, you need 
to be using the GDAL that MS4W provides.

Copying libmap.dll around and doing dll swapping is problematic for a 
number of reasons, but where we are currently with things like Oracle 
and SDE support in the Windows binaries for MapServer is much better 
than where we were before.  I don't like this solution as a long term 
one because it means additional compilation and steps to release the 
software, and folks can easily become confused as to what exactly 
they're using.  MapServer also supports the concept of plugins, and 
it is my hope that for MapServer 5.0, we provide the option to build 
and use the SDE driver as a plugin.  All that would be required to 
use the plugin is the SDK dlls, the plugin dll, and a libmap.dll that 
supports it.  This would simplify the usage of SDE in MS4W even further.


>As I don't have client libraries for ArcSDE (but our clients do on their
>networks) it may prove difficult to rebuild ogrinfo or even MapServer if say
>I wanted to have a higher MAX_SYMBOLS than the default with SDE support.

I believe MS4W already provides a binary with a higher than normal 
MAX_SYMBOLS defined.  Maybe this limit should be bumped up in the 
short term until we get dynamic allocation done (5.0 release is the 
target for this, I think).  This seems to be a common request...


>My question is this:  when compiling with ArcSDE support there is a need for
>the c header files or similar from ArcSDE.  Is there a need for the actual
>DLL's?

Yes.  The header files are included when libmap.dll is compiled and 
the .lib files are used to link libmap.dll to the SDE SDK dlls.

>   If there is couldn't an open source dummy set of DLL's with all the
>external c functions setup be built?  This could potentially allow for
>people to have their custom compiles work and also have a custom version
>that has been compiled for ArcSDE.  Obviously if anyone wanted to query
>ArcSDE in their development environment they would need real DLL's.

Plugins, in the form that GDAL supports and MapServer supports (but 
has not yet been implemented for SDE and Oracle) are the solution to 
this problem.  To compile your own plugin, you would need the SDE SDK 
DLLs, etc, but only one person needs to have that stuff to compile, 
and then everyone else can use it.



>Basically it would be great if one could do things how the MS4W works at
>present.  I think it is great that you can pop a different libmap.dll (and
>other supporting dll's) into the cgi directory and hey presto you have extra
>data format support.

MS4W's GDAL has the OGR SDE plugin. This will give you OGR read 
support from SDE for your data processing needs.

>Cheers
>
>Mike

Howard