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_...@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
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
