[postgis-users] Documenting performance tip
strk at refractions.net
strk at refractions.net
Fri Feb 4 01:32:40 PST 2005
On Fri, Feb 04, 2005 at 10:21:38AM +0100, Markus Schaber wrote:
> Hi, Strk,
>
> strk at refractions.net schrieb:
> > Markus, thanks for the insight.
> > A side-effect of your suggestion is that users will end up
> > actually using box2d type in their tables.
> > I think they should be warned that those column won't retain
> > their original precision between dump/reloads.
> > More so now that box2d canonical ascii output has been changed
> > to use default precision (%g).
> > What do you think ?
>
> Exactly for this reason, I actually try to store a geometry in the column.
>
> SELECT addGeometryColumn('mydb','mytable','bbox','4326','GEOMETRY','2');
> UPDATE mytable set bbox = setsrid(box3d(geom_column)::geometry, 4326);
>
> That creates a "geometry" column and inserts a box3d back-casted to
> geometry into it. PostGIS 1.0 stores a POLYGON with 5 Ordinates, while
> PostGIS 0.8.1 stores something that ouputs as "SRID=4326;BOX3D(...)"
> although the column is of type geometry. Both should be without loss.
>
> Markus
I see. Well, we can use Envelope(the_geom) then.
It's OGC-compliant and retains SRID.
SELECT addGeometryColumn('mydb','mytable','bbox','4326','GEOMETRY','2');
UPDATE mytable set bbox = Envelope(geom_column);
I'm not sure about dimensions. Currently both box3d->geometry cast and
Envelope return a 2d geometry, but both could change in the future.
Would a ZMpolygon be a problem ?
--strk;
More information about the postgis-users
mailing list