Skip to content
This repository was archived by the owner on Oct 7, 2025. It is now read-only.

GEOS version conflicts

perrygeo edited this page Dec 19, 2011 · 2 revisions

GEOS version conflicts

Summary

starspan uses geos C++ api which is a moving target. Would need to rewrite to C API to ensure long-term compatibility. Instead, we compile against older versions of geos/gdal.

Details

There are some issues with GEOS 3.3 that, at the moment, have not been resolved:

src/traverser/traverser.cc: In member function ‘void Traverser::processPolygon(OGRPolygon*)’:
src/traverser/traverser.cc:407:71: error: cannot dynamic_cast ‘poly->OGRPolygon::<anonymous>.OGRSurface::<anonymous>.OGRGeometry::exportToGEOS()’ 
(of type ‘struct GEOSGeom_t*’) to type ‘class geos::geom::Polygon*’
(source is a pointer to incomplete type)

GEOSGeom_t is from the C-interface of GEOS while Polygon* is from the C++ interface. Seems OGR's exportToGEOS() followed the recommendation* and implemented the C-wrapper instead of the C++ library.

  • Peter *) the docs say, that the C-wrapper is recommended and the C++ interface is not, although I don't really know why.

Howard Butler via lists.osgeo.org to GEOS: Because the implied developer contract of GEOS, which you signed before you downloaded GEOS ;), is to do our best to preserve backward and binary compatibility in the C API through mostly additions-only, and reserve the right to change things drastically for the C++ API. There's one major technical reason for this -- ABI compatibility -- and it has a nice social benefit of saying to GEOS library users "if you want to write your code once and (practically) never worry about having to change it again in the face of continuing GEOS releases, use the C API".

C++ users are simply expected to keep up with changes to the classes as the code progresses and moves forward. If you don't want to bleed on this bleeding edge, use the C API.

SOLUTION

Freeze against older versions. Compile against geos 3.2.2, gdal 1.8.0 (a known working combination) and hide it from global env, only exposing through env vars when running starspan.

#geos 3.2.2 
./configure --prefix=/usr/local/starspan
make
sudo make install

#gdal 1.8.0
./configure --prefix=/usr/local/starspan --with-geos=/usr/local/starspan/bin/geos-config
make

#starspan 1.2.06
./configure --with-gdal=/usr/local/starspan/bin/gdal-config --with-geos=/usr/local/starspan/bin/geos-config --prefix=/usr/local/starspan
make
sudo make install

Now /usr/local/starspan/bin/starspan shell script should link against the geos and gdal libs in /usr/local/starspan/lib and fire off the starspan executable linked with the proper libraries.

Clone this wiki locally