[GRASS-dev] where= and cats= to all vector commands

Hamish hamish_nospam at yahoo.com
Thu Nov 15 05:31:48 EST 2007


Wolf Bergenheim wrote:
> What do you people think of the idea to add where= and cats= parameters
> to all vector commands?

"all vector commands" is a big ask.

For some it makes no sense (v.clean, v.in.*, ...)
For others it is interesting (v.out.ogr, v.out.ascii, ...)

   [v.out.ascii columns= is also long time missing (v.out.ascii.db addon)]


Perhaps just do it for most important modules that use the input= option?
ie some of these:

cd $GISBASE/docs/html/

MODS=`grep input v.*.html | grep '<DT><b>input</b>=' | cut -f1 -d: | \
  sed -e 's/.html$//'`

for MOD in $MODS ; do
  if [ `grep -c '<DT><b>where</b>=' $MOD.html` -eq 0 ] ; then
    echo $MOD
  fi
done

v.buffer
v.build.polylines
v.category
v.centroids
v.convert
v.delaunay
v.dissolve
v.drape
v.extrude
v.hull
v.kcv
v.kernel
v.lidar.correction
v.lidar.edgedetection
v.lidar.growing
v.lrs.label
v.lrs.segment
v.neighbors
v.net.alloc
v.net
v.net.iso
v.net.path
v.net.salesman
v.net.steiner
v.out.ascii
v.out.dxf
v.out.ogr
v.out.pov
v.out.svg
v.out.vtk
v.outlier
v.parallel
v.patch
v.perturb
v.proj
v.qcount
v.reclass
v.sample
v.segment
v.split
v.surf.bspline
v.surf.idw
v.to.points
v.to.rast
v.to.rast3
v.transform
v.type
v.voronoi


These modules already have it:

$ grep '<DT><b>where</b>=' *.html | cut -f1 -d: | sed -e 's/.html$//'

d.vect
d.vect.thematic
db.copy
v.db.select
v.db.univar
v.db.update
v.edit
v.extract
v.in.db
v.in.ogr
v.label
v.surf.rst
v.univar
v.univar.sh
v.vol.rst
v.what.rast



> Also add any missing layer= parameter (like with v.voronoi).

that is an outstanding TODO left undone from the GRASS 5 sites port.


> What should be the case where both cats and where is supplied? Ideally
> merging it so that first do the where, and then limit the result to only
> cats in the given list? Or output a warning that where takes precedence
> over cats?

They should both be considered using an AND operator. There is no precedence.

You can't just feed the cats= option to a SQL query as it can include cat
ranges (1,3,5,7-13,21). I guess for cats=1-99999 if you parse to a lot of cat=a
OR cat=b OR .. the query would soon overflow a string buffer.

sometimes a cat structure is created from the SQL query first, and then it
loops through those cats, other times it loops through the cats and checks the
SQL for each one. (the first way being way more efficient)


Who is going to do the work? I'm not going to discourage anyone from doing lots
of work if they really want to, but given our limited peoplepower, I
(personally) prefer to things on a needs basis. Each module must be carefully
crafted & checked, there is not really a one-size-fits-all stamp solution.
A goal to work towards? Ok.  Short list of high priority modules added to a
wish in the tracker? Ok.

A similar task is to find all the d.* modules and ps.map instructions which
still don't support R:G:B for setting color.


Hamish


ps- Is v.label.sa written in a way in which it could be consolidated into a -s
flag & function for v.label? Does it share any of the same code? Even if not
"v.label" could be a wrapper which called either one or the other program
depending on that flag - if the other options are all the same. (see the
d.graph and d.mapgraph merge)
  (please remove C++ //comments from the source BTW)



      ____________________________________________________________________________________
Get easy, one-click access to your favorites. 
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs 


More information about the grass-dev mailing list