Jan Hartmann wrote:
Is that so? Reading the OGR API tutorial (http://www.gdal.org/ogr/ogr_apitut.html), I see that all geometries, frowm whatever input source, are represented internally as a generic OGRGeometry pointer, which is a virtual base class for all real geometry classes (http://www.gdal.org/ogr/classOGRGeometry.html). Most of the GEOS functionality can be implemented on OGRGeometries, so in principle the same could be done with indexing libraries (GIST, b-tree, quadtree, etc). Such indices should be written out to disk to be of any use at all, of course, like shptree does.
Jan, I have had trouble keeping up with this spirited discussion, but I wanted to note that it is not intended that alternate implementations of geometries would be derived by OGRGeometry. There are many places for instance that assume an OGRGeometry can be cast to OGRLineString if it's type is wkbLineString. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
