[postgis-users] Contours of rasters without or with tiles

Pierre Racine Pierre.Racine at sbf.ulaval.ca
Wed Nov 28 17:04:34 PST 2012


> I see now what you mean. ST_Envelope gives the behaviour you described
> (i.e. one polygon per tile, which is 9 lines). If I try to ST_Union them, I
> get the exact same problem I had before with ST_Polygon: not all
> polygon-tiles are unioned, as can be seen with a ST_Dump:
> SELECT ST_Dump(ST_Union(ST_Envelope(rast))) FROM test.raster_tile;
>                                           st_dump
> --------------------------------------------------
>   ({1},0103000020E6100000010000000900000024068...
>   ({2},0103000020E6100000010000000B0000009F1A2...
> (2 lines)
> With this line of code on the tile version of the raster, one would expect
> a single line as output (as is the case on the non-tiled raster).

This is a problem with ST_Union. The resulting polygon SHOULD be a single polygon. I suggest you create a minimal query not involving rasters reproducing the problem and that you submit it back to the list as a geometry only problem. I suggest you get the ST_AsText() version of your envelope and create a simple new self contained SQL query reproducing the problem. This way you will get attention from the right people.

While you get an answer... There are two ways to fix the problem:

1) Snap the geometries returned by ST_Envelop() (or ST_Polygon) to a very fine grid with ST_Snap(). ST_Union should work better.

2) Buffer each geometry returned by ST_Envelop() (or ST_Polygon) a little bit with ST_Buffer() before passing them to ST_Union and then remove the buffer from the result of ST_Union. For this to work properly you have to tell ST_Buffer 'endcap=square join=mitre' as the "buffer_style_parameters".

> 1) Is this a desirable feature that vector functions such as ST_Envelope or
> ST_Polygon behave differently on tiled and non-tiled rasters? From my point
> of view, it shouldn't be the case, as the decision to tile a raster should
> be transparent from a user point of view (it's just a trick to get better
> performance for most GIS procedures). The same code should run fine on both
> types of rasters in my opinion.

This depend on you definition of a raster... Apparently you decided that a whole table IS one raster. In PostGIS, one row is definitely a raster but a whole table can and can not be interpreted as something like a raster coverage and a raster coverage can still be quite different from a simple raster. It can be not rectangular, having missing tiles, overlaps, storing unrelated raster, etc... PostGIS API works on rasters. YOU work on a raster coverage (depending on the way you decided to store you rasters or your raster tiles and hence to interpret the meaning of a table containing rasters). It is then YOUR job to ST_Union the result of a query on a coverage.

So just keep in mind: one RASTER column in a row is a raster. A table containing a RASTER column is what you decide it to be. I agree however that the fact that the loader can "tile" a raster to many rows may let you think that a table is still a raster... I prefer to call that a raster coverage.


More information about the postgis-users mailing list