[geos-devel] Fwd: Geometry/Rectangle Intersection: line touching rectangle

Sandro Santilli strk at keybit.net
Fri Sep 12 09:31:57 PDT 2014


I've made some progress, if not else by adding a couple more tests
and having them all pass the "point-set equality test" with the
expected result.

But distinguishing between which boundary lines will need to be
added to the result and which not is still not done explicitly.

I'll continue looking on monday and I hope you'll be able then
to help more with making this ready for merging into trunk.

If you want to squash some more cases there's an #if 0 to turn on in
tests/unit/operation/intersection/RectangleIntersectionTest.cpp
Seek for WARNING labels.

The disabled block checks if the actual result is a GEOMETRYCOLLECTION
and if so, it requires the expected result to also be such (in addition
to point-set equality). Enabling that define shows all exiting tests
for which the current RectangleIntersection code (as modified by me
in these days) ends up adding more components to the output than 
required (lines and points for polygon inputs).

Again, I won't touch that code till monday so feel like touching it
over the weekend don't be afraid of conflicts :)

--strk;

On Thu, Sep 11, 2014 at 07:30:45PM +0300, Mika Heiskanen wrote:
> On 09/11/2014 06:57 PM, Sandro Santilli wrote:
> >Did you take a look at the algorithm ?
> >It sounds like by the end of operations the class is left with a bunch
> >of lines to work with, not much to build a result w/out going back
> >to look at which sides of those lines are internal or external of the
> >originals.
> 
> At the time of insertion into the builder it is known for all
> linestrings whether they are part of a hole or the exterior of
> a polygon. This information can be inserted into the builder
> along with the linestring, and used in the rebuild phase. Currently
> the logic dictates that any clipped hole must necessarily become
> a part of the exterior of a polygon, and the linestrings are
> connected accordingly by traveling the rectangle clockwise to
> find the next linestring to connect to. Even though the orientation
> of the holes was counter-clockwise, connecting to the linestring in
> the original order is correct for building the exterior.
> 
> What should remain is how to detect in the reconnect
> phase the special case of a linestring traveling only on the edges
> of the rectangle, and to handle it accordingly. I'm not sure,
> but wouldn't the boolean passed along with the linestring
> (hole or not) be enough to decide whether to just throw the
> linestring away or keep it in the reconnect phase? Possibly
> such a linestring could be even detected during the clipping
> phase by keeping track on whether all the vertices so far have
> been on the edges without true intersections, and then the
> linestring would not be inserted into the builder at all if it is
> not of the correct type (hole/exterior).
> 
> Mika Heiskanen / FMI
> 
> 
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel

-- 

 ()  ASCII ribbon campaign  --  Keep it simple !
 /\  http://strk.keybit.net/rants/ascii_mails.txt  


More information about the geos-devel mailing list