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

[Sandro Santilli]

For the record, the SafeBisectorFinder was recently also improved with 
changeset r717:

Date:   Wed Dec 19 20:02:16 2012 +0000

    Fixed Geometry.interiorPoint() to compute a true interior point in certain cases

But that changeset also came with no testcase

--strk;

On Mon, Jan 14, 2013 at 12:29:42PM +0100, 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 ?