[geos-devel] [GEOS] #609: GEOSPointOnSurface returns EMPTY for single-point linestring
strk at keybit.net
Mon Jan 14 03:29:42 PST 2013
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 ?
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
> >>> Now, the algorithm of InteriorPointLine  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.
> >>> 
> >>> 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
> >>No virus found in this message.
> >>Checked by AVG - www.avg.com
> >>Version: 2013.0.2805 / Virus Database: 2637/6000 - Release Date:
> >>Internal Virus Database is out of date.
> >geos-devel mailing list
> >geos-devel at lists.osgeo.org
> >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
More information about the geos-devel