Opened 23 months ago

Closed 5 months ago

#840 closed defect (wontfix)

PointOnSurface strange behavior

Reported by: sbe Owned by: geos-devel@…
Priority: minor Milestone: 3.6.4
Component: Default Version: 3.6.2
Severity: Unassigned Keywords: pointOnSurface
Cc:

Description

Hi all,

Using Postgis's ST_PointOnSurface, i've got some weird results in recent version of Postgis (> 2.0).

See that image : https://imagebin.ca/v/3YWtCXtT5lHs

I would like to know how the PointOnSurface? is calculated, and why there are so much differences between polygon A,B and C.

With Postgis 1.5 it was working fine (i.e. the PointOnSurface? for my polygons were at almost the same place than the Centroids)

Thank you.

Sylvain b.

Attachments (1)

point_on_surface.png (91.8 KB) - added by sbe 23 months ago.

Download all attachments as: .zip

Change History (8)

Changed 23 months ago by sbe

Attachment: point_on_surface.png added

comment:1 Changed 23 months ago by mloskot

WKT of your geometries would be helpful

comment:2 Changed 23 months ago by sbe

Here are the WKT:

A:POLYGON((182111.031940953 141935.935903267,181944.315698016 141813.663222482,181993.426552077 141735.161360171,182025.215323227 141755.058841504,182042.126877935 141723.338145732,182089.035943744 141755.453352846,182096.699289843 141744.892410235,182142.107084301 141773.967727472,182140.268233846 141825.482203511,182123.233970367 141827.369156254,182111.031940953 141935.935903267))

B:POLYGON((182512.231897141 141935.935903267,182344.315698016 141813.663222482,182393.426552077 141735.161360171,182425.215323227 141755.058841504,182442.126877935 141723.338145732,182489.035943744 141755.453352846,182496.699289843 141744.892410235,182542.107084301 141773.967727472,182540.268233846 141825.482203511,182522.034014178 141825.369229273,182512.231897141 141935.935903267))

C:POLYGON((182635.760119718 141846.477712277,182826.153168283 141974.473039044,182834.952846998 141857.67730337,182862.151853936 141851.277537031,182860.551912351 141779.280165725,182824.553226698 141748.881275618,182814.953577191 141758.480925126,182766.155358861 141721.682268681,182742.156235092 141744.881421657,182692.558045971 141716.882443927,182635.760119718 141846.477712277))

Projection: srid= 31370

Thanks.

comment:3 Changed 23 months ago by mloskot

FWIW, ST_PointOnSurface returns an arbitrary point. The only guarantee is that such point is located inside interior of a geometry, no more. Subsequent calls of ST_PointOnSurface for the same geometry might possibly return different points (all inside the interior, of course).

Last edited 23 months ago by mloskot (previous) (diff)

comment:4 Changed 23 months ago by mloskot

comment:5 Changed 12 months ago by robe

Milestone: 3.6.33.6.4

comment:6 Changed 5 months ago by mdavis

The reason for the discrepancy in computed interior points is due to how the Interior Point in Area algorithm works. It is designed to quickly find a point lying in the polygon interior, and is optimized for performance, not quality of point location. The two polygons just happen to be different enough that the algorithm chooses a different "band" of the polygon to place the interior point.

If a better quality location is desired, then there are other (less performant) algorithms to do this (e.g. computing the LargestInscribedCircle? AKA Pole of Inaccessibility). I'm hoping to bring this to GEOS soon. Or perhaps compute both the centroid and interior point and pick the best one (= furthest from polygon boundary AND in the interior)

@mloskot: the InteriorPointArea? algorithm is deterministic, so it does actually return the same point each time it is called.

Finally, there's a big performance improvement available for the InteriorPointArea? algorithm, and that should land soon in GEOS.

comment:7 Changed 5 months ago by mdavis

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.