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

[GRASS GIS]

#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:9 hamish]:
 >
 > it would be nice to keep a method to import exact data, even if
 splitting will be the default.
 >
 Do you mean, don't split when polygons are not cleaned (-c flag)?

 > how would it be split? after a certain number of vertices of a polyline
 like v.split or every "n" map units in a grid like v.in.gshhs?
 >
 I'm currently using line length in map units. The threshold is guestimated
 from feature density in each layer. BTW, v.in.gshhs restricts bounding box
 dimensions, similar to every "n" map units in a grid, but better. Using
 line length is faster than using max bbox dimensions.

 I do the splitting during OGRFeature import in order to not to inflate the
 coor file size. Independent of splitting, after cleaning, more than 50% of
 the coor file are dead lines, IOW if you would copy only alive lines to a
 final output vector you could reduce the coor file size by more than 50%.
 Splitting so early means that final boundary segments are shorter than the
 threshold used because both "break polygons" and "break lines" break lines
 at intersections. That's the reason why I don't want to make splitting
 threshold a user option to avoid complaints.

 The alternative would be to split after "break polygons" and "remove
 duplicates", just before "break boundaries". Boundaries would then have a
 max length of threshold, but this further inflates coor file size. The
 reason why I don't want to further inflate the coor file size with more
 dead lines is missing LFS support in the vector libs...
 >
 > note v.generalize currently requires to run v.build.polylines first to
 get correct output. I don't know if that is a feature or a bug.
 > but if breaking polylines was the default for v.in.ogr it could become a
 widespread subtle problem for it.
 >
 Hmm, I think v.build.polylines should be run first anyway for
 v.generalize. The cleaning process in v.in.ogr usually generates boundary
 segments independent of whether boundaries are split.

 Markus M

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