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

[Sandro Santilli]

On Mon, Jan 14, 2013 at 11:08:04PM -0800, Martin Davis wrote:
> 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.

Ah, thank you for this case. Could you add it to the existing
TestInteriorPoint.xml file ? The change you made with r731 changes
an expected result which was also acceptable.

This one instead is a good one !

--strk;

> 
> 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.
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel