[GRASS-dev] Re: [GRASS GIS] #426: v.in.ogr: split long boundaries

GRASS GIS trac at osgeo.org
Sun Mar 1 12:43:57 EST 2009


#426: v.in.ogr: split long boundaries
--------------------------+-------------------------------------------------
  Reporter:  neteler      |       Owner:  grass-dev at lists.osgeo.org
      Type:  enhancement  |      Status:  new                      
  Priority:  major        |   Milestone:  6.5.0                    
 Component:  Vector       |     Version:  unspecified              
Resolution:               |    Keywords:                           
  Platform:  All          |         Cpu:  All                      
--------------------------+-------------------------------------------------
Comment (by mmetz):

 Replying to [comment:7 mlennert]:
 > Replying to [comment:6 mmetz]:
 >
 > > want to ask first about how to implement it:
 >
 > Before being able to answer this it would help to know what the impacts
 of boundary splitting on any other vector operations might be. Speeding up
 import is good, but if it causes any disruptions (or slow-downs) further
 on, it might be preferrable to disable it by default.

 AFAICT there is one general trade-off: boundary splitting results in more
 boundaries -> more disk space needed and more memory needed, particularly
 for topology and the spatial index.

 I did not thoroughly test any disruptions (or slow-downs) further on, so
 far everything works. I'm also not sure if the speed gain is lost when you
 have to run v.build.polylines afterward. This new feature needs more
 testing with regard to its impact on other vector operations, therefore my
 favorite is 1), submitting to trunk only and see how it performs.

 Markus M

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


More information about the grass-dev mailing list