Geometry Boost List: [ggl] Updating tests

Subject: [ggl] Updating tests
From: Mateusz Loskot (mateusz)
Date: 2009-04-15 17:03:11

Barend Gehrels wrote:
> 
>> 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!

I just strongly believe in unit tests usefulness :-)

> 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)

I see.

Are the tests structured in any way or how new tests are added is a
matter of individual programmer choice?

As I see, test files are named after algorithms (intersection) or types
(point_ll or segment) or (probably) namespace or directories
(i.e. core, wkt). Is there any rationale behind this structure?

> 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

I see. I've checked, after adding this header, within_test.cpp compiles
and runs well:

#include <geometry/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

Do you mean that all types and algorithms under geometry/strategies
need to be covered with tests?

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

I see.

> 6) There has been a problem
> with the point in polygon (solved now). This was the combination with
> the problem:
>
> fromwkt("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.

That's interesting. I will see what I can find about that.

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

Yes, indeed, it's very useful to learn some details of background.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org