[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