[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