Boost logo

Geometry :

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,
Charter Member of OSGeo,

Geometry list run by mateusz at