[gdal-dev] Berkeley DB OGR "driver"

Jeff McKenna jmckenna at gatewaygeomatics.com
Wed Mar 13 12:52:15 PDT 2013


Hi Ivan,

I'm interested, but I have no solution.

I also now compile BerkeleyDB on Windows, as part of the
MapServer/MapCache process, and I would be curious how to add BDB
support in my GDAL build.

Maybe we can start a BuildHints page for this as we travel down this
path? http://trac.osgeo.org/gdal/wiki/BuildHints

-jeff


-- 
Jeff McKenna
MapServer Consulting and Training Services
http://www.gatewaygeomatics.com/



On 2013-03-13 3:11 PM, Ivan Lucena wrote:
> Hi there,
> 
> Although it is pretty simple to build support for Berkeley DB it is a little bit confusing since it used the SQLITE driver.
> 
> After downloading and installing the software, all we need to do is to change the nmake.opt (or nmake.local) variables to point to the Berkeley DB folders and rebuild GDAL.
> 
> SQLITE_INC  = -I"C:\Program Files (x86)\Oracle\Berkeley DB 11gR2 5.3.21\include" -DSPATIALITE_AMALGAMATION
> SQLITE_LIB  = "C:\Program Files (x86)\Oracle\Berkeley DB 11gR2 5.3.21\lib\libdb_sql53.lib"
> 
> Berkeley DB comes with SQLite API out of the box. You can also add the Spatialite if you want/need too.
> 
> Does anybody have ever tried something like that before?
> 
> The problem is that you cannot have "both" SQLITE driver build at the same time and the "ogrinfo --formats" will not going to tell that this SQLite is using Berkeley DB. One would *not* be able to pass data from a SQLITE file to a Berkley DB in one ogr2ogr step.
> 
> The only solution I can think about would be that for Berkeley DB we would build the driver as plugin and add a compiler variable to tell that the SQLITE driver should be registered with another name. I believe that by building the driver as plugin we would avoid collision between the two SQLITE API that would happen if we build it on the same library (Thanks Evens for point that out).
> 
> Would that be a reasonable solution? Any suggestion?
> 
> Best regards,
> 
> Ivan
> 
> 




More information about the gdal-dev mailing list