
Geometry : 
Subject: Re: [geometry] singlepoint polygons
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 20141013 11:02:03
Hi,
Volker Schöch wrote:
>
> It is now my understanding that WKT demands closing points for
> polygons. The following should be a wellformed polygon:
>
> POLYGON((2079 1968,2301 1968,2079 1968))
>
No, it should be invalid. A valid Polygon should have a non0 area. This
means that it should at least be a triangle  contain 3 points for open,
4 points for closed.
You may now call bg::is_valid() to check it however it is as
computionally expensive as set or relation operation, e.g. intersects().
> Calling remove_spikes on the resulting polygon, and outputting it as
> WKT, results in the following (boost 1.56.0):
>
> POLYGON((2079 1968))
>
> My questions:
>
> Is this expected (no closing point)?
>
> I presume that for some algorithms (which?) the position of the
> single point makes a difference while for others, like difference, any
> empty polygon should create the same result. Is this correct?
>
> A year ago I made a note in my code that some algorithms cannot deal
> with input polygons that contain spikes (Boost.Geometry Overlay
> invalid input exception results). Therefore I established an invariant
> for my own polygons, that requires all polygons to be free of spikes.
> Is this still necessary?
>
> How is a singlepoint polygon different from a spike?
>
> If spikes are not allowed, how should singlepoint polygons be dealt
> with? Should they be considered empty, and have their last remaining
> point removed before passing them to, e.g., the difference algorithm?
> Or is some wrapper code required that avoids calling certain
> algorithms with singlepoint polygons?
>
> My internal representation is oriented counterclockwise and not
> closed, my point type is based on int.
>
I'd say that remove_spikes() assume that the Polygon is valid and since
an invalid one is passed it treats it as a one spike which is removed.
I guess at the end we could check the number of Points and throw an
exception if the result contained too small number of Points.
In some cases numbers of Points are checked at the beginning of a
function, maybe for "mutable" functions we should also check this at the
end?
Regards,
Adam
Geometry list run by mateusz at loskot.net