Query choces on searching too small area

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Query choces on searching too small area

Arjen Haayman

Hi,

 

I’ve got this database that has photos that have a location and a table with key/value metadata. There are almost 450,000 photos and 5 million rows of metadata.

Searching on metadata alone always works, but when I add a spatial search to it the query freezes if the spatial component is too precise, i.e. if I search at a certain point or on a bounding box that is too small. My workaround now is to always extend to a bounding box with a minimum size.

 

I cannot find a way how to tackle this. EXPLAIN ANALYZE fails just as miserably as the original query. I’ve tried all kinds of indexes, but nothing works.

The queries have been running successfully for years but at a certain point in time the database got too big apparently and now this happens.

 

What I really don’t understand why it would fail when the query gets too specific, I mean searching on a point should be easier than searching a large bounding box. It usually is the other way around??

 

Here’s an example query:

 

SELECT

"id",

"filename",

ST_AsText("geometry") AS "geometry",

ST_AsText("center") AS "center",

"angle"

FROM "photo"

WHERE (ST_Intersects("geometry", st_GeomFromText( 'POINT(4.5063099203616 51.923602970634)', 4326)))

AND ("id" IN (

SELECT  "photoId" FROM "photoMetadata"

WHERE ("photoId" IN (

SELECT DISTINCT "photoId" FROM "photoMetadata"

WHERE ("value" = 'KADASTER') AND ("key" = 'source')))

                                             AND ("photoId" IN (

SELECT DISTINCT "photoId" FROM "photoMetadata"

WHERE (key = 'year' AND ( cast(value as int ) >= 1866 AND cast ( value as int ) <= 1981 ))))))

ORDER BY "filename" LIMIT 36

 

So this fails. This means that it takes way too long. And a few of these queries running at the same time completely clogs my machine.

 

When I change it to something like (ST_Intersects("geometry", st_GeomFromText( 'POLYGON((6.1444640338619 52.265808403464,6.1444640338619 52.281808403464,6.1496640338619 52.281808403464,6.1496640338619 52.265808403464,6.1444640338619 52.265808403464))', 4326)))

 

where the extent of the geometry needs to be large enough.

 

Does anyone have any clues how to tackle this?

 

 

 

 


_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Query choces on searching too small area

Martijn Meijers
What happens if you simplify the query. E.g. just using only geometry in
the where clause, or when you execute separately the subqueries inside
the where clause? Do these already take long to execute, do they use the
indexes defined (tables are recently vacuum'ed?) and do they give back a
sufficiently small number of ids to be selective?


M.


On 16-12-16 14:09, Arjen Haayman wrote:

>
> Hi,
>
> I’ve got this database that has photos that have a location and a
> table with key/value metadata. There are almost 450,000 photos and 5
> million rows of metadata.
>
> Searching on metadata alone always works, but when I add a spatial
> search to it the query freezes if the spatial component is too
> precise, i.e. if I search at a certain point or on a bounding box that
> is too small. My workaround now is to always extend to a bounding box
> with a minimum size.
>
> I cannot find a way how to tackle this. EXPLAIN ANALYZE fails just as
> miserably as the original query. I’ve tried all kinds of indexes, but
> nothing works.
>
> The queries have been running successfully for years but at a certain
> point in time the database got too big apparently and now this happens.
>
> What I really don’t understand why it would fail when the query gets
> too specific, I mean searching on a point should be easier than
> searching a large bounding box. It usually is the other way around??
>
> Here’s an example query:
>
> SELECT
>
> "id",
>
> "filename",
>
> ST_AsText("geometry") AS "geometry",
>
> ST_AsText("center") AS "center",
>
> "angle"
>
> FROM "photo"
>
> WHERE (ST_Intersects("geometry", st_GeomFromText(
> 'POINT(4.5063099203616 51.923602970634)', 4326)))
>
> AND ("id" IN (
>
> SELECT "photoId" FROM "photoMetadata"
>
> WHERE ("photoId" IN (
>
> SELECT DISTINCT "photoId" FROM "photoMetadata"
>
> WHERE ("value" = 'KADASTER') AND ("key" = 'source')))
>
>                                              AND ("photoId" IN (
>
> SELECT DISTINCT "photoId" FROM "photoMetadata"
>
> WHERE (key = 'year' AND ( cast(value as int ) >= 1866 AND cast ( value
> as int ) <= 1981 ))))))
>
> ORDER BY "filename" LIMIT 36
>
> So this fails. This means that it takes way too long. And a few of
> these queries running at the same time completely clogs my machine.
>
> When I change it to something like (ST_Intersects("geometry",
> st_GeomFromText( 'POLYGON((6.1444640338619
> 52.265808403464,6.1444640338619 52.281808403464,6.1496640338619
> 52.281808403464,6.1496640338619 52.265808403464,6.1444640338619
> 52.265808403464))', 4326)))
>
> where the extent of the geometry needs to be large enough.
>
> Does anyone have any clues how to tackle this?
>
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-users

_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Query choces on searching too small area

Arjen Haayman
Just geometry works just fine. No geometry also. It starts to act up when I use the spatial query in combination with at least 2 metadata queries.
Whether the sub-results are sufficiently small depends entirely on the metadata queried.

-----Original Message-----
From: postgis-users [mailto:[hidden email]] On Behalf Of Martijn Meijers
Sent: vrijdag 16 december 2016 15:01
To: PostGIS Users Discussion <[hidden email]>
Subject: Re: [postgis-users] Query choces on searching too small area

What happens if you simplify the query. E.g. just using only geometry in the where clause, or when you execute separately the subqueries inside the where clause? Do these already take long to execute, do they use the indexes defined (tables are recently vacuum'ed?) and do they give back a sufficiently small number of ids to be selective?


M.


On 16-12-16 14:09, Arjen Haayman wrote:

>
> Hi,
>
> I’ve got this database that has photos that have a location and a
> table with key/value metadata. There are almost 450,000 photos and 5
> million rows of metadata.
>
> Searching on metadata alone always works, but when I add a spatial
> search to it the query freezes if the spatial component is too
> precise, i.e. if I search at a certain point or on a bounding box that
> is too small. My workaround now is to always extend to a bounding box
> with a minimum size.
>
> I cannot find a way how to tackle this. EXPLAIN ANALYZE fails just as
> miserably as the original query. I’ve tried all kinds of indexes, but
> nothing works.
>
> The queries have been running successfully for years but at a certain
> point in time the database got too big apparently and now this happens.
>
> What I really don’t understand why it would fail when the query gets
> too specific, I mean searching on a point should be easier than
> searching a large bounding box. It usually is the other way around??
>
> Here’s an example query:
>
> SELECT
>
> "id",
>
> "filename",
>
> ST_AsText("geometry") AS "geometry",
>
> ST_AsText("center") AS "center",
>
> "angle"
>
> FROM "photo"
>
> WHERE (ST_Intersects("geometry", st_GeomFromText(
> 'POINT(4.5063099203616 51.923602970634)', 4326)))
>
> AND ("id" IN (
>
> SELECT "photoId" FROM "photoMetadata"
>
> WHERE ("photoId" IN (
>
> SELECT DISTINCT "photoId" FROM "photoMetadata"
>
> WHERE ("value" = 'KADASTER') AND ("key" = 'source')))
>
>                                              AND ("photoId" IN (
>
> SELECT DISTINCT "photoId" FROM "photoMetadata"
>
> WHERE (key = 'year' AND ( cast(value as int ) >= 1866 AND cast ( value
> as int ) <= 1981 ))))))
>
> ORDER BY "filename" LIMIT 36
>
> So this fails. This means that it takes way too long. And a few of
> these queries running at the same time completely clogs my machine.
>
> When I change it to something like (ST_Intersects("geometry",
> st_GeomFromText( 'POLYGON((6.1444640338619
> 52.265808403464,6.1444640338619 52.281808403464,6.1496640338619
> 52.281808403464,6.1496640338619 52.265808403464,6.1444640338619
> 52.265808403464))', 4326)))
>
> where the extent of the geometry needs to be large enough.
>
> Does anyone have any clues how to tackle this?
>
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-users

_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Query choces on searching too small area

Sandro Santilli-4
In reply to this post by Arjen Haayman
On Fri, Dec 16, 2016 at 02:09:01PM +0100, Arjen Haayman wrote:

> What I really don't understand why it would fail when the query gets too specific, I mean searching on a point should be easier than searching a large bounding box. It usually is the other way around??

It looks like a bug in the estimator, which somehow thinks that a smaller
bounding box is less selective than a larger one. You can check postgis
guess on selectivity using an internal function:

  -- Availability: 2.1.0
  -- Given a table, column and query geometry, returns the estimate of what proportion
  -- of the table would be returned by a query using the &&/&&& operators. The mode
  -- changes whether the estimate is in x/y only or in all available dimensions.
  CREATE OR REPLACE FUNCTION _postgis_selectivity(tbl regclass, att_name text, geom geometry, mode text default '2')

NOTE: EXPLAIN ANALYZE also runs the query, so just use EXPLAIN to know more
      about how the plan changes based on changed parameters.

--strk;
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Query choces on searching too small area

Arjen Haayman

QUERY PLAN

Limit  (cost=27753.88..27753.89 rows=1 width=819)

  ->  Sort  (cost=27753.88..27753.89 rows=1 width=819)

        Sort Key: photo."photoDirId", photo.foto_nr

        ->  Nested Loop Semi Join  (cost=23473.88..27753.87 rows=1 width=819)

              Join Filter: (photo.id = public."photoMetadata"."photoId")

              ->  Index Scan using photos_geometry_idx on photo  (cost=0.00..5.88 rows=1 width=819)

                    Index Cond: (geometry && '0101000020E6100000AE5F961B7606124045AE449F38F64940'::geometry)

                    Filter: (forsale AND _st_intersects(geometry, '0101000020E6100000AE5F961B7606124045AE449F38F64940'::geometry))

              ->  Hash Join  (cost=23473.88..27735.64 rows=988 width=12)

                    Hash Cond: (public."photoMetadata"."photoId" = public."photoMetadata"."photoId")

                    ->  Nested Loop  (cost=4655.84..8910.14 rows=1977 width=8)

                          ->  HashAggregate  (cost=4655.84..4657.29 rows=145 width=4)

                                ->  Bitmap Heap Scan on "photoMetadata"  (cost=423.06..4650.91 rows=1975 width=4)

                                      Recheck Cond: (((value)::integer >= 1866) AND ((value)::integer <= 1981) AND ((key)::text = 'year'::text))

                                      ->  Bitmap Index Scan on "photoMetadataYear_idx"  (cost=0.00..422.57 rows=1975 width=0)

                                            Index Cond: (((value)::integer >= 1866) AND ((value)::integer <= 1981))

                          ->  Index Scan using "idx_photoId" on "photoMetadata"  (cost=0.00..29.14 rows=14 width=4)

                                Index Cond: (public."photoMetadata"."photoId" = public."photoMetadata"."photoId")

                    ->  Hash  (cost=18806.70..18806.70 rows=907 width=4)

                          ->  HashAggregate  (cost=18788.56..18797.63 rows=907 width=4)

                                ->  Bitmap Heap Scan on "photoMetadata"  (cost=305.07..18757.68 rows=12352 width=4)

                                      Recheck Cond: (((key)::text = 'bron'::text) AND ((value)::text = 'KADASTER'::text))

                                      ->  Bitmap Index Scan on "photoMetadataKeyValueIndex"  (cost=0.00..301.98 rows=12352 width=0)

                                            Index Cond: (((key)::text = 'bron'::text) AND ((value)::text = 'KADASTER'::text))

 

What does this tell you?


_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Query choces on searching too small area

Sandro Santilli-4
On Fri, Dec 16, 2016 at 03:33:32PM +0100, Arjen Haayman wrote:
> QUERY PLAN

[...]

> What does this tell you?

That your query is too complex ?
Check out http://explain.depesz.com

--strk;
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Query choces on searching too small area

Rémi Cura
Hey, there is a dedicated "slow query" protocol on postgres user list, and its quite sane.
For instance, it would suggest you to give the version number you use, your hardware, etc etc.

About you query, I guess  your photo are geotagged (i.e. each photo is a point, and maybe you have a precision attribute).
Using ST_Intersects thus could be replaced by ST_DWithin with your precision / default tolerancey, which is safer.

Index not kicking may have many causes, such as outdated statistics (have you vacuum analyse -ed often?), wrong config regarding your hardware (seq_page_cost, and so),
poorly written query, etc.

Anyway your query should not freeze on only 500k geometries, so I'm also guessing that in the table "photo" you not only store photo point / geometry, but also the binary of the photo, which is bound to be dangerous.

So steps to fix your problem
 - update postgres / postgis if you can
 - check stats / vacuum
 - check postgres config
 - rewrite your query for a better form (see example 1 )
 - post on list, this might be a bug
 - rewrite query to force to perform first geometry test then the other (example query 2)
 - create a "proxy" photo_proxy table that contains only photo_id and photo.geometry
 - force use of index via settings (usually a very bad idea)
 - ...


Here is how your query could be simplified :

SELECT

"id",

"filename",

ST_AsText("geometry") AS "geometry",

ST_AsText("center") AS "center",

"angle"

FROM "photo"

WHERE (ST_DWithin("geometry", st_GeomFromText( 'POINT(4.5063099203616 51.923602970634)', 4326),your_precision))

AND "id" IN (

SELECT DISTINCT "photoId"

FROM "photoMetadata"

WHERE ("value" = 'KADASTER') AND ("key" = 'source')))

           AND ("photoId" IN (

SELECT DISTINCT "photoId"

FROM "photoMetadata"

WHERE (key = 'year' AND ( cast(value as int ) >= 1866 AND cast ( value as int ) <= 1981))
))
ORDER BY "filename" LIMIT 36


here is the query to force use of geometric index :

WITH photos_spatialy_close AS (
  SELECT id AS photoId
  FROM photo
  WHERE ST_DWithin("geometry", st_GeomFromText( 'POINT(4.5063099203616 51.923602970634)', 4326),your_precision)
  LIMIT 36
)
, photo_with_correct_metatadata AS (
 
  SELECT DISTINCT "photoId"
  FROM "photoMetadata"

  WHERE ("value" = 'KADASTER')

    AND ("key" = 'source')))

    AND ("photoId" IN (

SELECT DISTINCT "photoId"

FROM "photoMetadata"

       WHERE (key = 'year'
        AND ( cast(value as int ) >= 1866
        AND cast ( value as int ) <= 1981))
)
, keeping_photo_id_in_both_set AS (
  SELECT photoId
   FROM photos_spatialy_close
  INTERSECTS
  SELECT photoId
  FROM photo_with_correct_metatadata
)
SELECT

"id",

"filename",

ST_AsText("geometry") AS "geometry",

ST_AsText("center") AS "center",

"angle"

FROM keeping_photo_id_in_both_set LEFT OUTER JOIN photo ON ( photoId = id)

LIMIT ...




Cheers
Remi-C

2016-12-16 17:48 GMT+01:00 Sandro Santilli <[hidden email]>:
On Fri, Dec 16, 2016 at 03:33:32PM +0100, Arjen Haayman wrote:
> QUERY PLAN

[...]

> What does this tell you?

That your query is too complex ?
Check out http://explain.depesz.com

--strk;
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users


_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Query choces on searching too small area

Paul Ramsey
In reply to this post by Sandro Santilli-4
Two things:

(a) I'm curious what happens when you unroll all those embedded subqueries and let the planner try to do what it does best, something like this:

SELECT DISTINCT ON (photo.id)
  photo.id
  photo.filename, 
  ST_AsText(photo.geometry) AS geometry, 
  ST_AsText(photo.center) AS center, 
  photo.angle
FROM photo
JOIN "photoMetadata" meta
ON photo.id = meta."photoId"
WHERE (key = 'source' AND value = 'KADASTER')
AND (key = 'year' AND value::int BETWEEN 1866 AND 1981)
AND ST_Intersects(photo.geometry, ST_SetSRID(ST_MakePoint(4.5063099203616, 51.923602970634), 4326)) 
ORDER BY photo.filenam

(b) You should strongly consider changing your metadata table from the key/value table into a jsonb table, with the metadata in JSON. Then for things like date, and source, you can build functional indexes to allow fast filtering on those common metadata fields, while still allowing fully free-form metadata objects. This would make the whole thing both simpler and a lot faster.

P.



On Fri, Dec 16, 2016 at 8:48 AM, Sandro Santilli <[hidden email]> wrote:
On Fri, Dec 16, 2016 at 03:33:32PM +0100, Arjen Haayman wrote:
> QUERY PLAN

[...]

> What does this tell you?

That your query is too complex ?
Check out http://explain.depesz.com

--strk;
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users


_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Query choces on searching too small area

Arjen Haayman
In reply to this post by Rémi Cura

Yes, this works nicely. Thanks! Didn’t know about the ‘WITH’ statement

 

From: postgis-users [mailto:[hidden email]] On Behalf Of Rémi Cura
Sent: vrijdag 16 december 2016 18:33
To: PostGIS Users Discussion <[hidden email]>
Subject: Re: [postgis-users] Query choces on searching too small area

 

Hey, there is a dedicated "slow query" protocol on postgres user list, and its quite sane.

For instance, it would suggest you to give the version number you use, your hardware, etc etc.

About you query, I guess  your photo are geotagged (i.e. each photo is a point, and maybe you have a precision attribute).

Using ST_Intersects thus could be replaced by ST_DWithin with your precision / default tolerancey, which is safer.

 

Index not kicking may have many causes, such as outdated statistics (have you vacuum analyse -ed often?), wrong config regarding your hardware (seq_page_cost, and so),

poorly written query, etc.

Anyway your query should not freeze on only 500k geometries, so I'm also guessing that in the table "photo" you not only store photo point / geometry, but also the binary of the photo, which is bound to be dangerous.

So steps to fix your problem

 - update postgres / postgis if you can

 - check stats / vacuum

 - check postgres config

 - rewrite your query for a better form (see example 1 )

 - post on list, this might be a bug
 - rewrite query to force to perform first geometry test then the other (example query 2)

 - create a "proxy" photo_proxy table that contains only photo_id and photo.geometry

 - force use of index via settings (usually a very bad idea)
 - ...

Here is how your query could be simplified :

SELECT

"id",

"filename",

ST_AsText("geometry") AS "geometry",

ST_AsText("center") AS "center",

"angle"

FROM "photo"

WHERE (ST_DWithin("geometry", st_GeomFromText( 'POINT(4.5063099203616 51.923602970634)', 4326),your_precision))

AND "id" IN (

SELECT DISTINCT "photoId"

FROM "photoMetadata"

WHERE ("value" = 'KADASTER') AND ("key" = 'source')))

           AND ("photoId" IN (

SELECT DISTINCT "photoId"

FROM "photoMetadata"

WHERE (key = 'year' AND ( cast(value as int ) >= 1866 AND cast ( value as int ) <= 1981))
))

ORDER BY "filename" LIMIT 36

 

here is the query to force use of geometric index :

WITH photos_spatialy_close AS (

  SELECT id AS photoId

  FROM photo

  WHERE ST_DWithin("geometry", st_GeomFromText( 'POINT(4.5063099203616 51.923602970634)', 4326),your_precision)

  LIMIT 36

)

, photo_with_correct_metatadata AS (

 
  SELECT DISTINCT "photoId"
  FROM "photoMetadata"

  WHERE ("value" = 'KADASTER')

    AND ("key" = 'source')))

    AND ("photoId" IN (

SELECT DISTINCT "photoId"

FROM "photoMetadata"

       WHERE (key = 'year'
        AND ( cast(value as int ) >= 1866
        AND cast ( value as int ) <= 1981))

)

, keeping_photo_id_in_both_set AS (

  SELECT photoId

   FROM photos_spatialy_close

  INTERSECTS

  SELECT photoId

  FROM photo_with_correct_metatadata

)

SELECT

"id",

"filename",

ST_AsText("geometry") AS "geometry",

ST_AsText("center") AS "center",

"angle"

FROM keeping_photo_id_in_both_set LEFT OUTER JOIN photo ON ( photoId = id)

LIMIT ...

 

 

 

Cheers
Remi-C

 

2016-12-16 17:48 GMT+01:00 Sandro Santilli <[hidden email]>:

On Fri, Dec 16, 2016 at 03:33:32PM +0100, Arjen Haayman wrote:
> QUERY PLAN

[...]

> What does this tell you?

That your query is too complex ?
Check out http://explain.depesz.com


--strk;
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users

 


_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Query choces on searching too small area

Rémi Cura
In reply to this post by Paul Ramsey
@Paul, that's what I thought, but it seems querry can't be un-rolled like this,
because one row will have only one key.
(no one row will match all the conditions, you have to get several rows and perform intersection of results).

I fully agree this is totally bad for postgres, I would guess Arjen use a off-the-shelf module and as no choice over architecture.

Cheers,
Rémi-C

2016-12-16 18:59 GMT+01:00 Paul Ramsey <[hidden email]>:
Two things:

(a) I'm curious what happens when you unroll all those embedded subqueries and let the planner try to do what it does best, something like this:

SELECT DISTINCT ON (photo.id)
  photo.id
  photo.filename, 
  ST_AsText(photo.geometry) AS geometry, 
  ST_AsText(photo.center) AS center, 
  photo.angle
FROM photo
JOIN "photoMetadata" meta
ON photo.id = meta."photoId"
WHERE (key = 'source' AND value = 'KADASTER')
AND (key = 'year' AND value::int BETWEEN 1866 AND 1981)
AND ST_Intersects(photo.geometry, ST_SetSRID(ST_MakePoint(4.5063099203616, 51.923602970634), 4326)) 
ORDER BY photo.filenam

(b) You should strongly consider changing your metadata table from the key/value table into a jsonb table, with the metadata in JSON. Then for things like date, and source, you can build functional indexes to allow fast filtering on those common metadata fields, while still allowing fully free-form metadata objects. This would make the whole thing both simpler and a lot faster.

P.



On Fri, Dec 16, 2016 at 8:48 AM, Sandro Santilli <[hidden email]> wrote:
On Fri, Dec 16, 2016 at 03:33:32PM +0100, Arjen Haayman wrote:
> QUERY PLAN

[...]

> What does this tell you?

That your query is too complex ?
Check out http://explain.depesz.com

--strk;
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users


_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users


_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users