[GRASS-dev] [release planning] 7.4.0

[Moritz Lennert]

Le Sun, 12 Nov 2017 19:36:36 +0200,
Maris Nartiss <maris.gis at gmail.com> a écrit :

> 2017-11-12 14:27 GMT+02:00 Moritz Lennert
> <mlennert at club.worldonline.be>:
> > Another, intermediate option would be to use the functions in
> > buffer2.c, i.e. Vect_line_buffer2, which is what is used in
> > v.buffer if GEOS is not available. It has a slightly different API,
> > with some new outputs (holes), but shouldn't be too difficult to
> > use in v.profile.
> >
> > Do you think you have the time to work on v.profile these days ?  
> I spent some hours trying to understand how buffering works. It
> doesn't look good at the moment:
> #3439 #3438 and r71704
> 
> What is the current road map for buffering? Making GEOS a hard option?
> Fixing native version? Or should I try to mimic v.buffer and have both
> for 7.4.0 release (#3438 and #3439 doesn't affect v.profle use case)?

MarkusM is the one who really knows, but AFAIU, the GEOS implementation
of buffering is the best we have (or the only one without errors in
specific cases). There is not function for creating parallel lines in
GEOS, so for that the functions in buffer2.c are the best we have, but
they are pretty bad. Apparently, creating a parallel line is not as
simple as it would sound, and we are still looking for a correct
implementation, or rather to even see if such an implementation is
possible.

I would think that most GRASS installations today come with GEOS, but I
have no actual data on that. So, to be safe, the best would probably be
to mimic v.buffer.

Moritz