[geos-devel] [GEOS] #609: GEOSPointOnSurface returns EMPTY for single-point linestring

[Martin Davis]

Ergh.  Yes, you're right, there isn't a test case showing the failure.  
In fact, the test case I added for this (a) isn't the right geometry to 
test the code and (b) the code seems to have a bug in it anyway.  Back 
to the drawing board...

A geometry which shows the problem is an upside-down L shape:

POLYGON ((0 2, 0 4, 3 4, 3 0, 2 0, 2 2, 0 2))

The interior point is computed as POINT (1 2) - but this point actually 
lies on the boundary of the polygon, which breaks the contract of 
InteriorPoint.  An acceptable answer would be POINT (2.5 2) - which is 
completely inside.  The SafeBisector was introduced to get this second 
result - but isn't working for some reason.

So stay tuned for further fixes.

On 1/14/2013 3:29 AM, Sandro Santilli wrote:
> Thank you Martin, I've started the port.
>
> One question: while porting InteriorPointArea I realized that GEOS
> and JTS are not in sync with reguard to the horizontalBisector method,
> but even if I copied the InteriorPointTest.xml test from JTS there are
> no failure in GEOS. Does it mean there are no test in JTS showing the
> need for using the private SafeBisectorFinder class (which is only
> in JTS) ? Can you think of any case that would fail with the old
> (as in GEOS) implementation of that ?
>
> --strk;
>
> On Fri, Jan 11, 2013 at 04:39:58PM -0800, Martin Davis wrote:
>> Fixes to JTS Centroid and InteriorPoint have been committed to SVN
>> (along with appropriate unit tests)
>>
>> On 1/11/2013 9:45 AM, Martin Davis wrote:
>>> I just realized some corner cases, which require some
>>> clarification to deal with.
>>>
>>> One is geometries with multiple zero-length lines.  In this case I
>>> think the geometries should be treated as points, and the centroid
>>> and interior point computed accordingly.
>>>
>>> A similar situation exists for polygons with no area (which are
>>> invalid, but it's still nice to return a sensible answer).  A
>>> similar strategy should work - treat them as points.  Polygons
>>> with extent but no area (eg POLYGON ((200 200, 200 300, 200 200,
>>> 200 200))) can be treated as if they are lines.
>>>
>>> In all cases, if geometry components of higher dimension are
>>> present, the lower-dimension geometries are ignored.
>>>
>>> This is going to require more significant change to handle - in
>>> particular, it points toward having single class for Centroid to
>>> handle all geometry types.
>>>
>>> On 1/11/2013 9:32 AM, Martin Davis wrote:
>>>> Just to clarify my original response, the primary constraint on
>>>> functions that return geometry values is that they return a
>>>> valid geometry that makes some sort of sense.
>>>>
>>>> So in the case of centroid, regardless of what is
>>>> "mathematically correct" a valid sensible geometry should be
>>>> returned (as opposed to a meaningless geometry with NaN
>>>> ordinates, as now happens).
>>>>
>>>> In the case of interiorPoint the situation is even more clearcut
>>>> - obviously the interior point should be one of the points in
>>>> the geometry.
>>>>
>>>> On 1/11/2013 6:01 AM, GEOS wrote:
>>>>> #609: GEOSPointOnSurface returns EMPTY for single-point linestring
>>>>> ------------------------+---------------------------------------------------
>>>>>
>>>>>   Reporter:  strk        |       Owner:  geos-devel@…
>>>>>       Type:  defect      |      Status:  new
>>>>>   Priority:  major       |   Milestone:  3.3.7
>>>>> Component:  Default     |     Version:  3.3.6
>>>>>   Severity:  Unassigned  |    Keywords:
>>>>> ------------------------+---------------------------------------------------
>>>>>
>>>>>
>>>>> Comment(by strk):
>>>>>
>>>>>   So for GEOSCentroid the answer is correct, in that by definition the
>>>>>   CentroidLine class computes the centroid of all segment's midpoint
>>>>>   weighted by segment length, so a zero-length segment is not
>>>>> considered.
>>>>>
>>>>>   Now, the algorithm of InteriorPointLine [1] is:
>>>>>
>>>>>      - Find an interior vertex which is closest to the centroid of the
>>>>>   linestring.
>>>>>      - If there is no interior vertex, find the endpoint which
>>>>> is closest to
>>>>>   the centroid.
>>>>>
>>>>>   [1]
>>>>> http://www.vividsolutions.com/jts/javadoc/com/vividsolutions/jts/algorithm/InteriorPointLine.html
>>>>>
>>>>>
>>>>>   But if there's no interior vertex both endpoints are
>>>>> equidistant to the
>>>>>   centroid, aren't them ?
>>>>>   Martin: am I missing anything ?
>>>>>
>>>> _______________________________________________
>>>> geos-devel mailing list
>>>> geos-devel at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>>
>>>> -----
>>>> No virus found in this message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 2013.0.2805 / Virus Database: 2637/6000 - Release Date:
>>>> 12/31/12
>>>> Internal Virus Database is out of date.
>>> _______________________________________________
>>> geos-devel mailing list
>>> geos-devel at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2013.0.2805 / Virus Database: 2637/6000 - Release Date: 12/31/12
>>> Internal Virus Database is out of date.
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2805 / Virus Database: 2637/6000 - Release Date: 12/31/12
> Internal Virus Database is out of date.