Hi developers,
What do you people think of the idea to add where= and cats= parameters
to all vector commands? Also add any missing layer= parameter (like with
v.voronoi).
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?
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
On 15/11/07 10:09, Wolf Bergenheim wrote:
Hi developers,
What do you people think of the idea to add where= and cats= parameters
to all vector commands? Also add any missing layer= parameter (like with
v.voronoi).
+1
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?
I would go for the second. If people really need to merge the two, they can use cats=X in the where clause.
Moritz
+1
I think it would be really useful and standardize the inputs for vector commands.
I agrre that if one want to merge cat and where he can add in the where clause.
At this point is cats necessary?
Maxi
Moritz Lennert wrote:
On 15/11/07 10:09, Wolf Bergenheim wrote:
Hi developers,
What do you people think of the idea to add where= and cats= parameters
to all vector commands? Also add any missing layer= parameter (like with
v.voronoi).+1
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?I would go for the second. If people really need to merge the two, they can use cats=X in the where clause.
Moritz
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
-----------------------------------------------------
Dr. Massimiliano Cannata
Environmental & Geomatic Engineer
Institute of Earth Scences - SUPSI
Trevano, C.P. 72, CH-6952 Canobbio, SWITZERLAND
Tel: +41 (0)58 / 666 62 14 Fax: +41 (0)58 / 666 62 09
E-mail: massimiliano.cannata@supsi.ch
Web: http://www.ist.supsi.ch
http://istgis.ist.supsi.ch:8001/geomatica/
-------------------------------------------------------
Hi,
maybe connected, should be vector modules (except of selected modules
like v.build, etc.) region sensitive similary to raster modules (for
GRASS7)?
Martin
2007/11/15, Massimiliano Cannata <massimiliano.cannata@supsi.ch>:
+1
I think it would be really useful and standardize the inputs for vector
commands.I agrre that if one want to merge cat and where he can add in the where
clause.
At this point is cats necessary?Maxi
Moritz Lennert wrote:
> On 15/11/07 10:09, Wolf Bergenheim wrote:
>> Hi developers,
>>
>> What do you people think of the idea to add where= and cats= parameters
>> to all vector commands? Also add any missing layer= parameter (like with
>> v.voronoi).
>
> +1
>
>>
>> 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?
>
> I would go for the second. If people really need to merge the two,
> they can use cats=X in the where clause.
>
> Moritz
> _______________________________________________
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>--
-----------------------------------------------------
Dr. Massimiliano Cannata
Environmental & Geomatic EngineerInstitute of Earth Scences - SUPSI
Trevano, C.P. 72, CH-6952 Canobbio, SWITZERLANDTel: +41 (0)58 / 666 62 14
Fax: +41 (0)58 / 666 62 09
E-mail: massimiliano.cannata@supsi.chWeb:
http://www.ist.supsi.ch
http://istgis.ist.supsi.ch:8001/geomatica/
-------------------------------------------------------_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
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
Massimiliano Cannata wrote:
+1
I think it would be really useful and standardize the inputs for vector
commands.
+1
I agrre that if one want to merge cat and where he can add in the where
clause.
At this point is cats necessary?
Yes. If the vector has no table, the features can still have
categories (they usually do).
Maciek
On Thursday 15 November 2007, Maciej Sieczka wrote:
Massimiliano Cannata wrote:
> +1
> I think it would be really useful and standardize the inputs for vector
> commands.+1
> I agrre that if one want to merge cat and where he can add in the where
> clause.
> At this point is cats necessary?Yes. If the vector has no table, the features can still have
categories (they usually do).Maciek
This is a good point. I am all for standardizing... however Hamish's qualms
are an important issue. We should come up with an organized approach to
testing and re-testing these large-scale changes so that we aren't faced with
a pile of non-working but standardized modules.
This brings up a related topic: a complete GRASS test suite. I know that Soren
(?) had something like this going -- however work on the test suite might be
of higher importance than features.
Thoughts?
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341