On Mon, Dec 15, 2008 at 9:07 PM, Kevin Webb <k...@cornell.edu> wrote: > At 03:03 PM 11/20/2008, Kevin Webb wrote: ... >> --The layer for which v.select, v.distance, and v.what results do NOT >> match-- >> > > I think the issue with varying results for v.select, v.distance , and v.what > as I > have experienced are due to an OGR 'relationship with' the GEOS library. > Tests I have run suggest the GEOS library should be an installation > requirement/prerequisite > for any user intending on executing operations on vectors imported using > v.external. > (The GEOS library may be an undocumented requirement for all OGR ops.) > > Note: I used the phrase "relationship with'" instead of "dependency". OGR > will certainly > compile without GEOS, but OGR operations without GEOS may yield suspect > results.
Isn't it then an OGR problem rather than a GRASS problem? We use the OGR and expect that OGR always delivers the same result (or issues a warning/error if not possible in absence of GEOS). > This discovery came about when I was testing code that calls the OGR library > directly. > Calls to OGRGeometry::Distance(OGRGeometry *) errored out because GEOS was > not installed. After installing GEOS and recompiling GDAL, > OGRGeometry::Distance() works > and I noticed changes in values for my test points previously run with > OGRGeometry::Intersects(). > > Thinking that GEOS may have an impact on Grass, I executed similar > before-and-after-GEOS > tests in Grass and observed the same improvement; points that resulted in > multiple FIDs > coming from v.select before-GEOS, yielded a single value after-GEOS. > v.select and v.distance > return the same value now that GEOS has been installed. May I ask you to bring this up on the gdal mailing list? Markus _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user