[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 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.

 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.

 > There may be a difference in the case where you use where= when creating
 the virtual map and again when processing it (i.e. you'd have to "compose"
 the where= queries).

 That should not be a problem because the where constraints of the virtual
 map would need to be considered on library level whereas the where
 constraints provided as an option to the module would be processed on
 module level.

 For the implementation of virtual maps, it should IMHO be avoided that
 every single vector module needs to be modified. Vector modules use the
 vector library to retrieve a feature (point, line, boundary, centroid,
 area, island, face, node) from a vector. The library would then need to
 check if the feature matches the filtering criteria. This will require
 quite a lot of modification to the vector libraries, taking special care
 of boundaries and islands. For example, region constraints are already
 built in for sequential reading of lines, but unfortunately with a bug
 because boundaries are skipped if they are outside the constraint bounding
 box, even if one of the areas formed by this boundary overlaps with the
 constraint bounding box, resulting in corrupted areas.

 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.

 Markus M

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