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

GRASS GIS trac at osgeo.org
Mon Mar 2 02:43:53 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: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>

More information about the grass-dev mailing list