[GRASS-dev] [GRASS GIS] #1798: all relevant vector modules should have cats and where parameters

[GRASS GIS]

#1798: all relevant vector modules should have cats and where parameters
----------------------------------+-----------------------------------------
 Reporter:  mlennert              |       Owner:  grass-dev@…              
     Type:  enhancement           |      Status:  new                      
 Priority:  normal                |   Milestone:  7.0.0                    
Component:  Vector                |     Version:  svn-trunk                
 Keywords:  where cats parameter  |    Platform:  Unspecified              
      Cpu:  Unspecified           |  
----------------------------------+-----------------------------------------

Comment(by mlennert):

 Replying to [comment:11 mmetz]:
 > Replying to [comment:8 glynn]:
 > > Replying to [comment:6 mmetz]:
 > >
 > > > The advantage of a virtual map over using v.extract to get a
 "permanent" selection by cats/where is not clear to me
 > > Disk usage. A virtual map wouldn't require an extra copy of the
 coordinates and topology.
 >
 > With regard to vector processing, processing speed and memory
 consumption is in my experience more of an issue than disk space.
 >
 > >
 > > > because the result of v.extract can be processed faster than a
 virtual map.
 > > In the simplest case, a virtual map shouldn't be any slower than
 providing cats=/where= on the command line; they both do the same thing.


 Yes, but does it in an on-the-fly, through away the results way, while the
 other keeps the results. For me personally, I mostly need the on-the-fly
 way and this means that there is no advantage of virtual maps over
 cats/where parameters. I actually would have the extra step of creating
 and removing the virtual map after usage, i.e. 3 commands instead of 1.

 When I need to use the same extraction of a vector map over and over
 again, I prefer to use v.extract.

 >
 > The idea of a virtual map is to avoid adding cats/where options to all
 vector modules. For a vector module that does not have cats/where options,
 you would need to either create a virtual map or run v.extract. Then you
 would run a vector module without providing cats/where options, and using
 the result of v.extract would be faster.

 I see two advantages of virtual maps:

 1) When they are seen like views in databases, i.e. a filter allowing to
 view particular features of a constantly evolving vector map. In that
 sense they help you save having to type the cats/where option every time
 you need to work with the relevant features.

 2) That(If) they could allow to do more than where/cats parameters if
 virtual maps can also be created through v.select equivalents, i.e.
 selecting not only based on cats and attributes, but also based on
 location relative to another vector map. Then again, maybe it would be
 fairly straightforward to include a "vector_filter' option next to cats
 and where ?

 I've not encountered 1) very often in my personal work. 2) is a regular
 need.

 > For the implementation of virtual maps, it should IMHO be avoided that
 every single vector module needs to be modified.

 That was the main idea behind Glynn's proposal IIUC.

 > In short, I am not against virtual vector maps, but I am a bit
 intimidated by the estimated amount of modifications needed on library
 level, and because I am not sure if it can be avoided that every single
 vector module needs some modification.

 I cannot judge this, so I'll leave this reflection up to those who can.
 IIUC, you have some boilerplate code that can be inserted into vector
 modules quite easily to add cats/where parameters. If that is the case,
 and you can explain to me how to do it, then I can spend some time adding
 this to modules. We can then still discuss whether virtual maps are a good
 and feasible idea.

 Moritz

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1798#comment:12>
GRASS GIS <http://grass.osgeo.org>