Geometry Boost List: [ggl] Updating tests

Subject: [ggl] Updating tests
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-04-15 04:03:18

> I've updated the within_test.cpp so it compiles and runs.
> However, I had to disable multipolygon in circle test case because
> it seem multis are not supported by within, so calculate function can
> not be deduced. Perhaps, I'm wrong.
>
>   
A few pieces of history and comments here.
1) The within_test was one of the first tests I did, in january 2008. It 
has been ignored for a long while. So good you took it up!
2) The other tests are usually revised, working for more points then the 
default point. See e.g. simplify.cpp or wkt.cpp. They are also renamed, 
the _test suffix is dropped (actually because they moved to the test folder)
3) The multi*geometries were present in the first preview but because of 
the total rework in the design they were put aside for a while. They are 
still not published in boost. I updated them sometimes slightly because 
I'm using them myself (at least multipolygon). Last week(s) I revised 
them and I think they should take part of the new preview. However, the 
polygon-in-circle is still there but the file is moved to 
multi/algorithms/within.hpp
4) After the first test we also introduced strategies. There are more 
within algorithms implemented for point in polygon, actually they should 
be tested as well
5) The default one for point in polygon is the winding counting one, I'm 
quite satisified with it because it is "coordinate system agnostic", 
meaning that as soon we have a side-strategy implemented for latlong, 
the within-test will work in latlong as well. It also does not require a 
lot of calculations
6) There has been a problem with the point in polygon (solved now). This 
was the combination with the problem:
    from_wkt("POLYGON((146351 410597,146521 410659,147906 410363,148088 
410420,148175 410296,148281 409750,148215 *409623*,148154 409666,148154 
409666,148130 409625,148035 409626,148035 409626,148008 409544,147963 
409510,147993 409457,147961 409352,147261 408687,147008 408586,145714 
408840,145001 409033,144486 409066,144616 409308,145023 410286,145254 
410488,145618 410612,145618 410612,146015 410565,146190 410545,146351 
410597))", poly);
    from_wkt("POINT(146383 *409623*)", point);
    std::cout << within(point, poly) << std::endl;
(having the same y-coordinate and going back). This case should be 
added. There are more differences in the "comparisons" of US counties, 
they have to be checked, I think GEOS is wrong there and Terralib is 
also wrong.

OK, long story but I think it is useful to let this know.

Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090415/7ab3ced1/attachment.html