[GRASS-dev] Re: [GRASS-user] interactive multiple selection

GRASS GRASS developer
1

slightly-related, but before I forget, I had an idea about the "adding
where= SQL queries to all vector modules in gr7" wish. hijack the parser
with a semi-colon.

for example:
  v.module input="roads; WHERE surface IS 'gravel'"

the standard FS is a comma, but the semi-colon allows you still have
multiple inputs. I guess we'd need some new libgis function to tokenize
the option list (or can G_tokenize() be run nested with a programmer
specified delim? [upon quick look, yes, I think it can])

Glynn had a similar idea about the parser options for r.series(?) with
passing maps & methods with in=mapname1,method1,mapname2,method2[,...]
or so. I am not so sold on that idea, I would prefer like in=map1,map2,map3
meth=n,sum,mean as it is more clear.

Hamish

2

Hi,

2009/1/22 Hamish <hamish_b@yahoo.com>:

slightly-related, but before I forget, I had an idea about the "adding
where= SQL queries to all vector modules in gr7" wish. hijack the parser
with a semi-colon.

for example:
v.module input="roads; WHERE surface IS 'gravel'"

hm, this would complicate GUI dialog. I would prefer to add 'where'
parameter to the all modules (also 'cats', 'bbox') - similar to v.edit
selection parameters and not to mix map names with where statement. I
know more work, anyway some changes in the GIS and Vector library
would make it easier.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

3

On Jan 22, 2009, at 1:56 PM, Martin Landa wrote:

Hi,

2009/1/22 Hamish <hamish_b@yahoo.com>:

slightly-related, but before I forget, I had an idea about the "adding
where= SQL queries to all vector modules in gr7" wish. hijack the parser
with a semi-colon.

for example:
v.module input="roads; WHERE surface IS 'gravel'"

hm, this would complicate GUI dialog. I would prefer to add 'where'
parameter to the all modules (also 'cats', 'bbox') - similar to v.edit
selection parameters and not to mix map names with where statement. I
know more work, anyway some changes in the GIS and Vector library
would make it easier.

Martin

I definitely agree with Martin from a GUI standpoint.

Michael

4

On 22/01/09 21:50, Hamish wrote:

slightly-related, but before I forget, I had an idea about the "adding
where= SQL queries to all vector modules in gr7" wish. hijack the parser
with a semi-colon.

for example:
  v.module input="roads; WHERE surface IS 'gravel'"

In what ways do you feel this is superior to input= where= ?

Moritz

5

I guess it allows per-map WHERE clauses for those modules that take
multiple input maps (such as v.patch). The global "where=" option
does not and assumes that all input maps have the same attribute
table structure and data ranges?

Ben

Moritz Lennert wrote:

On 22/01/09 21:50, Hamish wrote:

slightly-related, but before I forget, I had an idea about the "adding
where= SQL queries to all vector modules in gr7" wish. hijack the parser
with a semi-colon.

for example:
  v.module input="roads; WHERE surface IS 'gravel'"

In what ways do you feel this is superior to input= where= ?

Moritz
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeology Ltd
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke@oxfordarch.co.uk

------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.

6

Hamish wrote:

slightly-related, but before I forget, I had an idea about the "adding
where= SQL queries to all vector modules in gr7" wish. hijack the parser
with a semi-colon.

for example:
  v.module input="roads; WHERE surface IS 'gravel'"

the standard FS is a comma, but the semi-colon allows you still have
multiple inputs. I guess we'd need some new libgis function to tokenize
the option list (or can G_tokenize() be run nested with a programmer
specified delim? [upon quick look, yes, I think it can])

Are you talking about making the module handle the query, or extending
Vect_open_old() to accept a map+query so that the module doesn't need
to do anything?

Glynn had a similar idea about the parser options for r.series(?) with
passing maps & methods with in=mapname1,method1,mapname2,method2[,...]
or so. I am not so sold on that idea, I would prefer like in=map1,map2,map3
meth=n,sum,mean as it is more clear.

Also slightly related, the interface used by g.copy and g.rename is
broken. They both use opt->gisprompt = "old,...", although the
destination doesn't exist.

In the absence of a real type system for options, the interface needs
to change from:

  g.copy rast=oldmap,newmap

to e.g.:

  g.copy type=rast from=oldmap to=newmap

so that from= and to= can be typed correctly.

--
Glynn Clements <glynn@gclements.plus.com>

7

On Jan 23, 2009, at 11:05 AM, Glynn Clements wrote:

Hamish wrote:

slightly-related, but before I forget, I had an idea about the "adding
where= SQL queries to all vector modules in gr7" wish. hijack the parser
with a semi-colon.

for example:
v.module input="roads; WHERE surface IS 'gravel'"

the standard FS is a comma, but the semi-colon allows you still have
multiple inputs. I guess we'd need some new libgis function to tokenize
the option list (or can G_tokenize() be run nested with a programmer
specified delim? [upon quick look, yes, I think it can])

Are you talking about making the module handle the query, or extending
Vect_open_old() to accept a map+query so that the module doesn't need
to do anything?

Glynn had a similar idea about the parser options for r.series(?) with
passing maps & methods with in=mapname1,method1,mapname2,method2[,...]
or so. I am not so sold on that idea, I would prefer like in=map1,map2,map3
meth=n,sum,mean as it is more clear.

Also slightly related, the interface used by g.copy and g.rename is
broken. They both use opt->gisprompt = "old,...", although the
destination doesn't exist.

In the absence of a real type system for options, the interface needs
to change from:

  g.copy rast=oldmap,newmap

to e.g.:

  g.copy type=rast from=oldmap to=newmap

so that from= and to= can be typed correctly.

--

I agree.

Michael

8

On 23/01/09 11:05, Benjamin Ducke wrote:

I guess it allows per-map WHERE clauses for those modules that take
multiple input maps (such as v.patch). The global "where=" option
does not and assumes that all input maps have the same attribute
table structure and data ranges?

I think this actually raises a question discussed two years ago [1], i.e. whether we would actually think of a way more SQL-centric way of dealing with maps.

At the time, I implemented a proof-of-concept version of d.vect.chart which allowed displaying the results of an arbitrary SQL-query, as long as these results contained cat values linked to the chosen map. [2]

The discussion died down after that, but maybe grass7 would be a good opportunity to wake it up.

Moritz

[1]http://lists.osgeo.org/pipermail/grass-user/2006-September/036414.html
[2]http://lists.osgeo.org/pipermail/grass-dev/2006-October/026625.html

Ben

Moritz Lennert wrote:

On 22/01/09 21:50, Hamish wrote:

slightly-related, but before I forget, I had an idea about the "adding
where= SQL queries to all vector modules in gr7" wish. hijack the parser
with a semi-colon.

for example:
  v.module input="roads; WHERE surface IS 'gravel'"

In what ways do you feel this is superior to input= where= ?

Moritz
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

9

Glynn wrote:

Are you talking about making the module handle the query, or extending
Vect_open_old() to accept a map+query so that the module doesn't need
to do anything?

vaguely thinking about ways to avoid having to custom code into each
individual module. So: extending Vect_open_old() to accept a map+query.
But that is perhaps a bit of an ugly mixing of libraries/serious task
so could well be more trouble than it is worth.

on the other hand, hand crafting each module ensures that only the modules
where it is useful will get done. ie not complicating modules where where=
is not relevant with unneeded junk in an across the board addition.

also, you probably want to have layer= before the where= query, which
further complicates the input= usage... yuck.

Glynn:

Also slightly related, the interface used by g.copy and
g.rename is broken. They both use opt->gisprompt =
"old,...", although the destination doesn't exist.

In the absence of a real type system for options, the
interface needs to change from:

  g.copy rast=oldmap,newmap

to e.g.:

  g.copy type=rast from=oldmap to=newmap

so that from= and to= can be typed correctly.

makes sense. (->trunk)

Hamish

10

Hamish wrote:

> Are you talking about making the module handle the query, or extending
> Vect_open_old() to accept a map+query so that the module doesn't need
> to do anything?

vaguely thinking about ways to avoid having to custom code into each
individual module. So: extending Vect_open_old() to accept a map+query.
But that is perhaps a bit of an ugly mixing of libraries/serious task
so could well be more trouble than it is worth.

on the other hand, hand crafting each module ensures that only the modules
where it is useful will get done. ie not complicating modules where where=
is not relevant with unneeded junk in an across the board addition.

also, you probably want to have layer= before the where= query, which
further complicates the input= usage... yuck.

Maybe we need "views" of a vector map?

--
Glynn Clements <glynn@gclements.plus.com>