[GRASS-user] Varying results - v.select,v.distance,v.what

[Kevin Webb]

At 03:03 PM 11/20/2008, Kevin Webb wrote:
>At 12:15 PM 11/19/2008, Kevin Webb wrote:
>
>
>>--Workflow--
>>A LOCATION was created tailored to the specifics of the layer
>>I am processing. The layer itself was imported using:
>>v.external, followed by v.category, followed by v.db.connect.
>>
>>
>>Am I doing this incorrectly?
>>Should I expect the three methods to yield the same result?
>>Which method is suggested to be the most reliable?
>>
>>Thank you.
>>
>>
>>KFW
>
>I decided to run v.select, v.distance, and v.what comparisons on another
>layer that I have imported using v.external. The 3 query techniques all
>returned the same value which lead me to believe that it was something
>I had done improperly on the import sequence for the layer that was giving
>me erroneous results; investigation yields more questions.
>
>--The layer for which v.select, v.distance and v.what results match--
>
>GRASS 6.4.svn (PREC0101):~ > v.db.connect -p PREC0102_EXT
>Vector map <PREC0102_EXT at PERMANENT> is connected by:
>layer <1> table <PREC0102> in database 
></home/kfw4/dev/grass_db/climate/prec/PREC0102.SHP> through driver <ogr> 
>with key <>
>GRASS 6.4.svn (PREC0101):~ > v.info -c PREC0102_EXT
>Displaying column types/names for database connection of layer 1:
>INTEGER|ID
>INTEGER|GRIDCODE
>CHARACTER|INCHES
>
>Supposedly, queries are NOT supposed to work on this layer because v.category
>has not been run - there is no category (cat) field, yet v.select, 
>v.distance, and v.what all
>work and result values are the same.
>
>Why do queries on this layer this work?

Classes in the OGR library have member objects and methods for accessing the
FID attribute (Feature ID is a key field in shapefile attribute tables and 
is analogous
to the CAT attribute in Grass). Grass code that references the fid works 
correctly
on v.db.select operations without having to execute v.category to prepare a 
vector
that was imported using v.external.

g.region vect=EXT_CENSUS
v.proj single_point location=lat_lon mapset=PERMANENT --overwrite
v.db.addtable single_point --q
v.select ainput=EXT_CENSUS binput=single_point output=single_select 
--overwrite --q
v.db.addtable single_select --q
fid=`v.db.select -c single_select --q`

if [ -n "$fid" ]; then
    result=`v.db.select -c EXT_CENSUS column=POP00_SQMI where=fid=$fid --q`
fi



>--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.

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.



KFW