[GRASS-dev] [release planning] 7.4.0

[Maris Nartiss]

2017-11-10 19:39 GMT+02:00 Moritz Lennert <mlennert at club.worldonline.be>:
> Hi Maris,
>
> v.profile still uses the old buffering library methods which has quite
> a lot of issues.

The best question then is why we are still shipping library methods
that are *known* to be broken? If they are so broke, they must be
changed to fail all the time to prevent end-users from getting wrong
results.

> As an example, I attach the output map of the following example:
>
> v.profile input=geonames_NC at PERMANENT output=- separator=comma dp=3
> buffer=500 profile_map=roadsmajor at PERMANENT profile_where=cat=193
> map_output=test_profile
>
> I also attach the equivalent v.buffer output:
>
> v.buffer -c roadsmajor where=cat=193 dist=500 out=buff500
>
> Would it be possible for you, Maris, to change to the GEOS method used
> in v.buffer in order to get the same buffering output ?

I can take a look at v.buffer to see how GEOS is used. Still I don't
know how soon I'll have time for it :(

> This is not only formal as you can see when you use the following
> vector points as input:
>
> v.in.ascii in=- out=test_points << EOF
> 626382.68026139|228917.44816672|1
> 626643.91393428|228738.2879083|2
> 626907.14939778|228529.10079092|3
> EOF
>
> v.profile then misses out on point 2, even though it is within 500m:
>
> v.profile input=test_points output=- separator=comma dp=3 buffer=500
> profile_map=roadsmajor at PERMANENT profile_where=cat=193
> Number,Distance,cat,dbl_1,dbl_2,int_1
> 1,2102.114,3,626907.14939778,228529.10079092,3
> 2,2960.822,1,626382.68026139,228917.44816672,1

I see. I would +1 for setting current GRASS buffer functions to call
G_fatal_error till they get fixed or replaced by GEOS version. I also
would +1 to block 7.4.0 release till a final action is made (fatal
error or a fix). Quality (correctness) should be our priority.

> Moritz

Māris.