[GRASS-dev] Re: [GRASS GIS] #957: v.voronoi has extra lines in output

[GRASS GIS]

#957: v.voronoi has extra lines in output
-----------------------+----------------------------------------------------
 Reporter:  helena     |       Owner:  grass-dev@…              
     Type:  defect     |      Status:  new                      
 Priority:  major      |   Milestone:  6.4.2                    
Component:  Vector     |     Version:  svn-develbranch6         
 Keywords:  v.voronoi  |    Platform:  All                      
      Cpu:  All        |  
-----------------------+----------------------------------------------------

Comment(by mmetz):

 Replying to [comment:17 hamish]:
 > Replying to [comment:16 mmetz]:
 > > See comment:13 for a suggestion
 >
 > (thanks, I'd missed that)
 >
 > > > Therefore it may be a good idea to do the adjustment that
 > > > g.region currently does in trunk/general/g.region/main.c#L549
 > > > and following lines not only for window.north == window.south
 > > > etc. but always, to make sure that all vector features are
 > > > really inside the current region?
 >
 > By "always" you mean just when used with vect=, right? :)

 Sure :- no absolute always implied here.
 >
 > The idea to round out by 1/2 a grid cell in each direction seems ok at
 first, but I speculate about what the problems might be:
 >
 >  - as res= is typically not set with vect=, what happens if original res
 is quite large but vector bbox is very small? you get a big region as a
 result when you wanted one orders of magnitude smaller.

 Right, but that affects also the current behaviour of g.region
 >
 >  - what if you have a series of vector points broken up by region (lidar
 1km x 1km chunk files) and want to patch their bboxes together? would you
 be better/worse/no worse than now?

 The combination of g.region vect=myvect; v.in.region out=myvect_region can
 exclude features in the current behaviour (%.8f precision). In this case
 you could use the output of v.info -e plus v.in.ascii to get bboxes and
 then patch them together (v.info could also get a new output option box
 which writes the box to a vector).
 >
 >
 > perhaps it is better to expand by some other proportional amount? like
 the lesser of 1/2 a grid cell, or +/- (n-s)*1e-n ?  (where n=6..15), or
 +/- GRASS_EPSILON and change the WIND file (and thus all other
 G_format_*()) to record to useless/impracticable/wasteful precision?

 Does it harm to record .15g precision in the WIND file? Internally, it's
 always stored as double AFAICT.The only harm I can see is
 implying/suggesting a precision that is not justified by geospatial data.
 (Unless someone does spatial analysis on electron microscope scans with
 meters as unit, i.e. non-geo but spatial data).

 > or hardcode the +/- 0.00000001 with a note that it should match the
 precision in format_double()?
 >
 That one, hardcoding a fixed value matching the minimum precision in the
 WIND file, makes most sense to me. GRASS_EPSILON has no effect with %.8f
 since it's 1e-15.
 >
 > open to suggestions,
 > Hamish
 >
 > ps- it is wonderful that this longstanding v.voronoi bug is near to
 being fixed!

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