2017-11-10 19:39 GMT+02:00 Moritz Lennert <mlenn...@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@PERMANENT output=- separator=comma dp=3 > buffer=500 profile_map=roadsmajor@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@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. _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev