[postgis-devel] point_in_multipolygon implementation

Mose Andre mose.andre at gmail.com
Thu Sep 11 13:18:35 PDT 2008


Regina:

Using ST_Contains(multipolygon, point) I am seeing ~950ms.

I believe this is because it's going to GEOS and computing the
intersection matrix needlessly.

Using ST_Contains(polygon, point) I am seeing ~50ms.

I believe we hit the point_in_polygon shortcut here.

Using ST_Dwithin(multipolygon, point, .001) I am seeing ~150ms.

This one I am less familiar with, but it looks like another
Postgis-side function that is avoiding GEOS.

The queries differ slightly to accommodate the necessary changes (e.g.
that the decomposed multipolygon may be multiple rows), but they're
all using an index on the point column.

-Mose


On Thu, Sep 11, 2008 at 12:56 PM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> Andre,
>
> Interesting - never noticed that was commented out and I was looking at
> that section.  That could answer another timing puzzle I had.  I'm not
> sure why it is commented out.
>
> Can you tell me how much of a speed difference you get by using
>
> ST_DWithin vs. decomposing your geometry to a single polygon and using
> ST_Contains
>
> Something like
>
> SELECT pt.gid as pointid, poly as polyid
> FROM
> poly INNER JOIN points pt
> ON ST_DWithin(poly.the_geom, p.the_geom, 0.001)
>
> Thanks,
> Regina
>
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mose
> Andre
> Sent: Thursday, September 11, 2008 3:35 PM
> To: postgis-devel at postgis.refractions.net
> Subject: [postgis-devel] point_in_multipolygon implementation
>
> In trunk, lwgeom_functions_analytic.c:1397 and thereabouts is a
> commented out point_in_multipolygon function.
>
> We have noticed a performance gain by convincing contains
> (lwgeom_geos_c:1388) to use the point_in_polygon shortcut, but our
> application uses a lot of multipolygons.  Rather than switch the
> client code to decompose multipolygons (most of them are a single
> polygon anyway) it would be nice to just implement this other
> shortcut.
>
> Does anyone know why it's not functional?  Or have any recommendations
> on how to fix it up?  I cannot find any discussion on the lists.
>
> Thanks,
> Mose
>
> >From lwgeom_functions_analytic.c:
>
> /*
>  * return 0 iff point is outside every polygon
>  */
>
> /* Not yet functional.
>
> int point_in_multipolygon(LWMPOLY *mpolygon, LWPOINT *point)
> {
>        int i;
>
> #ifdef PGIS_DEBUG_CALLS
>        lwnotice("point_in_multipolygon called.");
> #endif
>        for(i=1; i<mpolygon->ngeoms; i++)
>        {
>                if(point_in_polygon((LWPOLY *)mpolygon->geoms[i],
> point)!=0) return 1;
>        }
>        return 0;
> }
> */
>
>
> >From lwgeom_geos_c.c:
>
>        /* Not yet functional
>        else if(type1 == MULTIPOLYGONTYPE && type2 == POINTTYPE)
>        {
>                POSTGIS_DEBUG(3, "Point in MultiPolygon test
> requested...short-circuiting.");
>
>                mpoly = lwmpoly_deserialize(SERIALIZED_FORM(geom1));
>                point = lwpoint_deserialize(SERIALIZED_FORM(geom2));
>                if(point_in_multipolygon(mpoly, point) == 0)
>                {
>                        PG_FREE_IF_COPY(geom1, 0);
>                        PG_FREE_IF_COPY(geom2, 1);
>                        lwgeom_release((LWGEOM *)mpoly);
>                        lwgeom_release((LWGEOM *)point);
>                        PG_RETURN_BOOL(FALSE);
>                }
>                else
>                {
>                        PG_FREE_IF_COPY(geom1, 0);
>                        PG_FREE_IF_COPY(geom2, 1);
>                        lwgeom_release((LWGEOM *)mpoly);
>                        lwgeom_release((LWGEOM *)point);
>                        PG_RETURN_BOOL(TRUE);
>                }
>        }
>        */
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>



More information about the postgis-devel mailing list