raster2pgsql, _add_raster_constraint_extent fails with "array size exceeds the maximum allowed"

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

raster2pgsql, _add_raster_constraint_extent fails with "array size exceeds the maximum allowed"

Avernar
I was importing a very large raster set and after a day it failed with
array size exceeds the maximum allowed when setting the extent
constraint.

I redid the import again by just doing the table create and then
adding the data and then doing the final bunch of sql statements
manually to avoid having the whole thing rollback again.

I first tried the fix discussed here
https://trac.osgeo.org/postgis/ticket/3501 and implemented here
https://trac.osgeo.org/postgis/changeset/15115 but that failed with
the array size error as well.  So I redid the constraints without the
extent one.

I would try ST_MemUnion but unfortunately that one is missing in my
installation.  I guess it's because it also handles 3D and the 3D
option is not compiled in by default on my platform.

So, what would a pl/pgsql script to do what MemUnion does, ie
accumulate one at a time, look like?

Also, what issues would not having an extent constrain have?
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: raster2pgsql, _add_raster_constraint_extent fails with "array size exceeds the maximum allowed"

Regina Obe

I'm a little suspicious you don't have ST_MemUnion.  That's been around for a while (since 1.* days) and hasn't been deprecated.  Which version of PostGIS are you using?  And did you upgrade from earlier versions?

 

Changing the logic to

 

SELECT st_ashexewkb(st_envelope(st_memunion(st_envelope(…

 

Should just work.  In thinking about this, what I really would have liked to do is just use ST_Extent which takes advantage that it's just collapsing boxes and needs to return a box

And does do it one at a time similar to ST_MemUnion, but it has a downside that it returns a box and not a geometry with SRID so we'd have to throw a ST_SetSRID in there to convert the box to a geometry with srid, but then we can dispense with the last ST_Envelope.

 

As far as whether you need an extent constraint, there is no harm in leaving it out in most cases.  Main reason it exists is for tools like QGIS that interrogate the

 

raster_columns table to be able to return a quick extent.  I think for geometry they use ST_EstimateExtent.

Even then with those tools, I think no biggie if you have another layer limiting the map extent.  If you have a table that big, using raster overviews is more important.

 

One annoying thing about having an extent constraint is you can't add more records without removing the constraint and recomputing.  So if you plan to add more records,

I would suggest A) dispense with the constraint  or B) Hand-code the extent constraint to cover the full area you expect your dataset to cover in future.

 

Question:  How many rows do you have and what is the pixel width height? 

 

Hope that helps,

Regina

http://www.postgis.us

http://postgis.net

 

 

 


--- ORIGINAL MESSAGE --

I was importing a very large raster set and after a day it failed with
array size exceeds the maximum allowed when setting the extent
constraint.

I redid the import again by just doing the table create and then
adding the data and then doing the final bunch of sql statements
manually to avoid having the whole thing rollback again.

I first tried the fix discussed here
https://trac.osgeo.org/postgis/ticket/3501 and implemented here
https://trac.osgeo.org/postgis/changeset/15115 but that failed with
the array size error as well.  So I redid the constraints without the
extent one.

I would try ST_MemUnion but unfortunately that one is missing in my
installation.  I guess it's because it also handles 3D and the 3D
option is not compiled in by default on my platform.

So, what would a pl/pgsql script to do what MemUnion does, ie
accumulate one at a time, look like?

Also, what issues would not having an extent constrain have?

 


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

Re: raster2pgsql, _add_raster_constraint_extent fails with "array size exceeds the maximum allowed"

Avernar
SELECT PostGIS_full_version();

"POSTGIS="2.2.2 r14797" GEOS="3.5.0-CAPI-1.9.0 r4084" PROJ="Rel.
4.9.2, 08 September 2015" GDAL="GDAL 2.1.0, released 2016/04/25"
LIBXML="2.9.4" LIBJSON="0.12" RASTER"

As I said, SFCGAL was not compiled by default.  The ST_MemUnion
function is listed as being a 3D function and from what I can figure
out that requires SFCGAL.  I'm building PostGIS 2.3.0 as it was added
a few days ago to the FreeBSD ports collection.  I've added the SFCGAL
compile option so I'll see if that gives me ST_MemUnion.

I do use QGIS but it's currently not showing me any raster tables so
I'll have to see what's up with that.  Maybe because I didn't make any
overview.  I use QGIS for editing the shape files I imported into
PostGIS.  The dem data is for looking up the elevation of various
lat/lon coordinates.

I'll look into the ST_Extent way of doing it.  I'm not worried about
adding more data as I've added the entire SRTM 1 arc-second data into
the table.  The row estimate for that table is 19,575,700.  Used the
usual 100x100 tile size.

John


On Sat, Nov 19, 2016 at 1:53 PM, Regina Obe <[hidden email]> wrote:

> I'm a little suspicious you don't have ST_MemUnion.  That's been around for
> a while (since 1.* days) and hasn't been deprecated.  Which version of
> PostGIS are you using?  And did you upgrade from earlier versions?
>
>
>
> Changing the logic to
>
>
>
> SELECT st_ashexewkb(st_envelope(st_memunion(st_envelope(…
>
>
>
> Should just work.  In thinking about this, what I really would have liked to
> do is just use ST_Extent which takes advantage that it's just collapsing
> boxes and needs to return a box
>
> And does do it one at a time similar to ST_MemUnion, but it has a downside
> that it returns a box and not a geometry with SRID so we'd have to throw a
> ST_SetSRID in there to convert the box to a geometry with srid, but then we
> can dispense with the last ST_Envelope.
>
>
>
> As far as whether you need an extent constraint, there is no harm in leaving
> it out in most cases.  Main reason it exists is for tools like QGIS that
> interrogate the
>
>
>
> raster_columns table to be able to return a quick extent.  I think for
> geometry they use ST_EstimateExtent.
>
> Even then with those tools, I think no biggie if you have another layer
> limiting the map extent.  If you have a table that big, using raster
> overviews is more important.
>
>
>
> One annoying thing about having an extent constraint is you can't add more
> records without removing the constraint and recomputing.  So if you plan to
> add more records,
>
> I would suggest A) dispense with the constraint  or B) Hand-code the extent
> constraint to cover the full area you expect your dataset to cover in
> future.
>
>
>
> Question:  How many rows do you have and what is the pixel width height?
>
>
>
> Hope that helps,
>
> Regina
>
> http://www.postgis.us
>
> http://postgis.net
>
>
>
>
>
>
>
>
> --- ORIGINAL MESSAGE --
>
> I was importing a very large raster set and after a day it failed with
> array size exceeds the maximum allowed when setting the extent
> constraint.
>
> I redid the import again by just doing the table create and then
> adding the data and then doing the final bunch of sql statements
> manually to avoid having the whole thing rollback again.
>
> I first tried the fix discussed here
> https://trac.osgeo.org/postgis/ticket/3501 and implemented here
> https://trac.osgeo.org/postgis/changeset/15115 but that failed with
> the array size error as well.  So I redid the constraints without the
> extent one.
>
> I would try ST_MemUnion but unfortunately that one is missing in my
> installation.  I guess it's because it also handles 3D and the 3D
> option is not compiled in by default on my platform.
>
> So, what would a pl/pgsql script to do what MemUnion does, ie
> accumulate one at a time, look like?
>
> Also, what issues would not having an extent constrain have?
>
>
>
>
> _______________________________________________
> 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: raster2pgsql, _add_raster_constraint_extent fails with "array size exceeds the maximum allowed"

Avernar
In reply to this post by Regina Obe
Oops.  I do have ST_MemUnion.  It's only under Aggregates while
ST_Collect and ST_Union are under Functions and Aggregates.  I was
just looking in Functions so didn't see it.  Will change
_add_raster_constraint_extent to use ST_MemUnion and give it a shot.

On Sat, Nov 19, 2016 at 1:53 PM, Regina Obe <[hidden email]> wrote:

> I'm a little suspicious you don't have ST_MemUnion.  That's been around for
> a while (since 1.* days) and hasn't been deprecated.  Which version of
> PostGIS are you using?  And did you upgrade from earlier versions?
>
>
>
> Changing the logic to
>
>
>
> SELECT st_ashexewkb(st_envelope(st_memunion(st_envelope(…
>
>
>
> Should just work.  In thinking about this, what I really would have liked to
> do is just use ST_Extent which takes advantage that it's just collapsing
> boxes and needs to return a box
>
> And does do it one at a time similar to ST_MemUnion, but it has a downside
> that it returns a box and not a geometry with SRID so we'd have to throw a
> ST_SetSRID in there to convert the box to a geometry with srid, but then we
> can dispense with the last ST_Envelope.
>
>
>
> As far as whether you need an extent constraint, there is no harm in leaving
> it out in most cases.  Main reason it exists is for tools like QGIS that
> interrogate the
>
>
>
> raster_columns table to be able to return a quick extent.  I think for
> geometry they use ST_EstimateExtent.
>
> Even then with those tools, I think no biggie if you have another layer
> limiting the map extent.  If you have a table that big, using raster
> overviews is more important.
>
>
>
> One annoying thing about having an extent constraint is you can't add more
> records without removing the constraint and recomputing.  So if you plan to
> add more records,
>
> I would suggest A) dispense with the constraint  or B) Hand-code the extent
> constraint to cover the full area you expect your dataset to cover in
> future.
>
>
>
> Question:  How many rows do you have and what is the pixel width height?
>
>
>
> Hope that helps,
>
> Regina
>
> http://www.postgis.us
>
> http://postgis.net
>
>
>
>
>
>
>
>
> --- ORIGINAL MESSAGE --
>
> I was importing a very large raster set and after a day it failed with
> array size exceeds the maximum allowed when setting the extent
> constraint.
>
> I redid the import again by just doing the table create and then
> adding the data and then doing the final bunch of sql statements
> manually to avoid having the whole thing rollback again.
>
> I first tried the fix discussed here
> https://trac.osgeo.org/postgis/ticket/3501 and implemented here
> https://trac.osgeo.org/postgis/changeset/15115 but that failed with
> the array size error as well.  So I redid the constraints without the
> extent one.
>
> I would try ST_MemUnion but unfortunately that one is missing in my
> installation.  I guess it's because it also handles 3D and the 3D
> option is not compiled in by default on my platform.
>
> So, what would a pl/pgsql script to do what MemUnion does, ie
> accumulate one at a time, look like?
>
> Also, what issues would not having an extent constrain have?
>
>
>
>
> _______________________________________________
> 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: raster2pgsql, _add_raster_constraint_extent fails with "array size exceeds the maximum allowed"

Avernar
In reply to this post by Regina Obe
I tried st_memunion first and aborted it after 8 hours.  Very little
disk activity during the process.  The data import including the other
constraints took 16-20 hours so that was way too long in comparison.

Then I tried your ST_Extent method.  Took 60 minutes total.  I ran the
two parts of _add_raster_constraint_extent manually to see how long
each took (and to verify the output of the first select).  The query

SELECT st_ashexewkb(ST_SetSRID(ST_Extent(ST_Envelope(rast)), (SELECT
ST_SRID(rast) FROM dem.srtm30 LIMIT 1))) FROM dem.srtm30;

took 30 minutes and 6 seconds to run.  The second part

SELECT _add_raster_constraint('enforce_max_extent_rast', 'ALTER TABLE
dem.srtm30 ADD CONSTRAINT enforce_max_extent_rast CHECK
(st_envelope(rast) @ ''010 ... 4CC0''::geometry)');

took 30 minutes and 3 seconds to run.  Much better.


On Sat, Nov 19, 2016 at 1:53 PM, Regina Obe <[hidden email]> wrote:

> I'm a little suspicious you don't have ST_MemUnion.  That's been around for
> a while (since 1.* days) and hasn't been deprecated.  Which version of
> PostGIS are you using?  And did you upgrade from earlier versions?
>
>
>
> Changing the logic to
>
>
>
> SELECT st_ashexewkb(st_envelope(st_memunion(st_envelope(…
>
>
>
> Should just work.  In thinking about this, what I really would have liked to
> do is just use ST_Extent which takes advantage that it's just collapsing
> boxes and needs to return a box
>
> And does do it one at a time similar to ST_MemUnion, but it has a downside
> that it returns a box and not a geometry with SRID so we'd have to throw a
> ST_SetSRID in there to convert the box to a geometry with srid, but then we
> can dispense with the last ST_Envelope.
>
>
>
> As far as whether you need an extent constraint, there is no harm in leaving
> it out in most cases.  Main reason it exists is for tools like QGIS that
> interrogate the
>
>
>
> raster_columns table to be able to return a quick extent.  I think for
> geometry they use ST_EstimateExtent.
>
> Even then with those tools, I think no biggie if you have another layer
> limiting the map extent.  If you have a table that big, using raster
> overviews is more important.
>
>
>
> One annoying thing about having an extent constraint is you can't add more
> records without removing the constraint and recomputing.  So if you plan to
> add more records,
>
> I would suggest A) dispense with the constraint  or B) Hand-code the extent
> constraint to cover the full area you expect your dataset to cover in
> future.
>
>
>
> Question:  How many rows do you have and what is the pixel width height?
>
>
>
> Hope that helps,
>
> Regina
>
> http://www.postgis.us
>
> http://postgis.net
>
>
>
>
>
>
>
>
> --- ORIGINAL MESSAGE --
>
> I was importing a very large raster set and after a day it failed with
> array size exceeds the maximum allowed when setting the extent
> constraint.
>
> I redid the import again by just doing the table create and then
> adding the data and then doing the final bunch of sql statements
> manually to avoid having the whole thing rollback again.
>
> I first tried the fix discussed here
> https://trac.osgeo.org/postgis/ticket/3501 and implemented here
> https://trac.osgeo.org/postgis/changeset/15115 but that failed with
> the array size error as well.  So I redid the constraints without the
> extent one.
>
> I would try ST_MemUnion but unfortunately that one is missing in my
> installation.  I guess it's because it also handles 3D and the 3D
> option is not compiled in by default on my platform.
>
> So, what would a pl/pgsql script to do what MemUnion does, ie
> accumulate one at a time, look like?
>
> Also, what issues would not having an extent constrain have?
>
>
>
>
> _______________________________________________
> 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: raster2pgsql, _add_raster_constraint_extent fails with "array size exceeds the maximum allowed"

Avernar
In reply to this post by Regina Obe
I made one last change.  I added ST_Transform in there just for the
case when the SRID constraint is not set and there are more than one
SRID in the raster column.  Only adds 9 seconds to the run time.
Here's what I have now:

CREATE OR REPLACE FUNCTION _add_raster_constraint_extent(
    rastschema name,
    rasttable name,
    rastcolumn name)
  RETURNS boolean AS
$BODY$
    DECLARE
        fqtn text;
        cn name;
        sql text;
        attr text;
        srid integer;
    BEGIN
        fqtn := '';
        IF length($1) > 0 THEN
            fqtn := quote_ident($1) || '.';
        END IF;
        fqtn := fqtn || quote_ident($2);

        cn := 'enforce_max_extent_' || $3;

    sql := 'SELECT ST_SRID('
            || quote_ident($3)
      || ') FROM '
            || fqtn
            || ' LIMIT 1;';
    EXECUTE sql INTO srid;

        sql := 'SELECT
st_ashexewkb(st_setsrid(st_extent(st_transform(st_envelope('
            || quote_ident($3)
            || '), '
            || srid
            || ')), '
            || srid
            || ')) FROM '
            || fqtn;
        EXECUTE sql INTO attr;

        sql := 'ALTER TABLE ' || fqtn
            || ' ADD CONSTRAINT ' || quote_ident(cn)
            || ' CHECK (st_envelope('
            || quote_ident($3)
            || ') @ ''' || attr || '''::geometry)';
        RETURN _add_raster_constraint(cn, sql);
    END;
    $BODY$
  LANGUAGE plpgsql VOLATILE STRICT
  COST 100;

On Sat, Nov 19, 2016 at 1:53 PM, Regina Obe <[hidden email]> wrote:

> I'm a little suspicious you don't have ST_MemUnion.  That's been around for
> a while (since 1.* days) and hasn't been deprecated.  Which version of
> PostGIS are you using?  And did you upgrade from earlier versions?
>
>
>
> Changing the logic to
>
>
>
> SELECT st_ashexewkb(st_envelope(st_memunion(st_envelope(…
>
>
>
> Should just work.  In thinking about this, what I really would have liked to
> do is just use ST_Extent which takes advantage that it's just collapsing
> boxes and needs to return a box
>
> And does do it one at a time similar to ST_MemUnion, but it has a downside
> that it returns a box and not a geometry with SRID so we'd have to throw a
> ST_SetSRID in there to convert the box to a geometry with srid, but then we
> can dispense with the last ST_Envelope.
>
>
>
> As far as whether you need an extent constraint, there is no harm in leaving
> it out in most cases.  Main reason it exists is for tools like QGIS that
> interrogate the
>
>
>
> raster_columns table to be able to return a quick extent.  I think for
> geometry they use ST_EstimateExtent.
>
> Even then with those tools, I think no biggie if you have another layer
> limiting the map extent.  If you have a table that big, using raster
> overviews is more important.
>
>
>
> One annoying thing about having an extent constraint is you can't add more
> records without removing the constraint and recomputing.  So if you plan to
> add more records,
>
> I would suggest A) dispense with the constraint  or B) Hand-code the extent
> constraint to cover the full area you expect your dataset to cover in
> future.
>
>
>
> Question:  How many rows do you have and what is the pixel width height?
>
>
>
> Hope that helps,
>
> Regina
>
> http://www.postgis.us
>
> http://postgis.net
>
>
>
>
>
>
>
>
> --- ORIGINAL MESSAGE --
>
> I was importing a very large raster set and after a day it failed with
> array size exceeds the maximum allowed when setting the extent
> constraint.
>
> I redid the import again by just doing the table create and then
> adding the data and then doing the final bunch of sql statements
> manually to avoid having the whole thing rollback again.
>
> I first tried the fix discussed here
> https://trac.osgeo.org/postgis/ticket/3501 and implemented here
> https://trac.osgeo.org/postgis/changeset/15115 but that failed with
> the array size error as well.  So I redid the constraints without the
> extent one.
>
> I would try ST_MemUnion but unfortunately that one is missing in my
> installation.  I guess it's because it also handles 3D and the 3D
> option is not compiled in by default on my platform.
>
> So, what would a pl/pgsql script to do what MemUnion does, ie
> accumulate one at a time, look like?
>
> Also, what issues would not having an extent constrain have?
>
>
>
>
> _______________________________________________
> 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: raster2pgsql, _add_raster_constraint_extent fails with "array size exceeds the maximum allowed"

Regina Obe
I've reopened the ticket you noticed and will use ST_Extent for the fix.

I think we should avoid using transform though.

I've put my notes on ticket.

https://trac.osgeo.org/postgis/ticket/3501

Thanks for the benchmarks,
Regina

 

-----Original Message-----
From: postgis-users [mailto:[hidden email]] On Behalf Of Avernar
Sent: Sunday, November 20, 2016 2:36 PM
To: PostGIS Users Discussion <[hidden email]>
Subject: Re: [postgis-users] raster2pgsql, _add_raster_constraint_extent fails with "array size exceeds the maximum allowed"

I made one last change.  I added ST_Transform in there just for the case when the SRID constraint is not set and there are more than one SRID in the raster column.  Only adds 9 seconds to the run time.
Here's what I have now:

CREATE OR REPLACE FUNCTION _add_raster_constraint_extent(
    rastschema name,
    rasttable name,
    rastcolumn name)
  RETURNS boolean AS
$BODY$
    DECLARE
        fqtn text;
        cn name;
        sql text;
        attr text;
        srid integer;
    BEGIN
        fqtn := '';
        IF length($1) > 0 THEN
            fqtn := quote_ident($1) || '.';
        END IF;
        fqtn := fqtn || quote_ident($2);

        cn := 'enforce_max_extent_' || $3;

    sql := 'SELECT ST_SRID('
            || quote_ident($3)
      || ') FROM '
            || fqtn
            || ' LIMIT 1;';
    EXECUTE sql INTO srid;

        sql := 'SELECT
st_ashexewkb(st_setsrid(st_extent(st_transform(st_envelope('
            || quote_ident($3)
            || '), '
            || srid
            || ')), '
            || srid
            || ')) FROM '
            || fqtn;
        EXECUTE sql INTO attr;

        sql := 'ALTER TABLE ' || fqtn
            || ' ADD CONSTRAINT ' || quote_ident(cn)
            || ' CHECK (st_envelope('
            || quote_ident($3)
            || ') @ ''' || attr || '''::geometry)';
        RETURN _add_raster_constraint(cn, sql);
    END;
    $BODY$
  LANGUAGE plpgsql VOLATILE STRICT
  COST 100;

On Sat, Nov 19, 2016 at 1:53 PM, Regina Obe <[hidden email]> wrote:

> I'm a little suspicious you don't have ST_MemUnion.  That's been
> around for a while (since 1.* days) and hasn't been deprecated.  Which
> version of PostGIS are you using?  And did you upgrade from earlier versions?
>
>
>
> Changing the logic to
>
>
>
> SELECT st_ashexewkb(st_envelope(st_memunion(st_envelope(
>
>
>
> Should just work.  In thinking about this, what I really would have
> liked to do is just use ST_Extent which takes advantage that it's just
> collapsing boxes and needs to return a box
>
> And does do it one at a time similar to ST_MemUnion, but it has a
> downside that it returns a box and not a geometry with SRID so we'd
> have to throw a ST_SetSRID in there to convert the box to a geometry
> with srid, but then we can dispense with the last ST_Envelope.
>
>
>
> As far as whether you need an extent constraint, there is no harm in
> leaving it out in most cases.  Main reason it exists is for tools like
> QGIS that interrogate the
>
>
>
> raster_columns table to be able to return a quick extent.  I think for
> geometry they use ST_EstimateExtent.
>
> Even then with those tools, I think no biggie if you have another
> layer limiting the map extent.  If you have a table that big, using
> raster overviews is more important.
>
>
>
> One annoying thing about having an extent constraint is you can't add
> more records without removing the constraint and recomputing.  So if
> you plan to add more records,
>
> I would suggest A) dispense with the constraint  or B) Hand-code the
> extent constraint to cover the full area you expect your dataset to
> cover in future.
>
>
>
> Question:  How many rows do you have and what is the pixel width height?
>
>
>
> Hope that helps,
>
> Regina
>
> http://www.postgis.us
>
> http://postgis.net
>
>
>
>
>
>
>
>
> --- ORIGINAL MESSAGE --
>
> I was importing a very large raster set and after a day it failed with
> array size exceeds the maximum allowed when setting the extent
> constraint.
>
> I redid the import again by just doing the table create and then
> adding the data and then doing the final bunch of sql statements
> manually to avoid having the whole thing rollback again.
>
> I first tried the fix discussed here
> https://trac.osgeo.org/postgis/ticket/3501 and implemented here
> https://trac.osgeo.org/postgis/changeset/15115 but that failed with
> the array size error as well.  So I redid the constraints without the
> extent one.
>
> I would try ST_MemUnion but unfortunately that one is missing in my
> installation.  I guess it's because it also handles 3D and the 3D
> option is not compiled in by default on my platform.
>
> So, what would a pl/pgsql script to do what MemUnion does, ie
> accumulate one at a time, look like?
>
> Also, what issues would not having an extent constrain have?
>
>
>
>
> _______________________________________________
> 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