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