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

Mathieu Basille basille at ase-research.org
Thu Nov 29 10:30:04 PST 2012

Dear Pierre,

Thanks for the detailed information. This makes perfect sense now. But as 
you rightly guessed, I was misled by the loader tiling possibility. With 
the loader, the tiling appears to be a mere feature of the raster, just as 
the SRID for instance. But in the end, it is not just a feature of the 
raster, as it gives a completely different object! Maybe this should be 
emphasized in the documentation, to make things clear: tiling a raster can 
dramatically improve performance, but this results in a different object (a 
raster coverage of many rasters), hence possibly different code -- I insist 
on the code, since this is what the user really sees and uses. Given your 
explanations, it also makes sense to have different versions of the same 
raster layer for different tasks, e.g. one non tiled (i.e. a raster 
coverage with only one raster/row) to get the polygon, and one tiled (i.e. 
a raster coverage with multiple rasters/tiles/rows) for intersections...

I'll try to repost a reproducible example of the ST_Union problem as soon 
as I get some time for it!

Thanks again,

Le 28/11/2012 20:04, Pierre Racine a écrit :
> Mathieu,
>> 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.
> Pierre
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users


~$ whoami
Mathieu Basille, PhD

~$ locate --details
University of Florida \\
Fort Lauderdale Research and Education Center
(+1) 954-577-6314

~$ fortune
« Le tout est de tout dire, et je manque de mots
Et je manque de temps, et je manque d'audace. »
  -- Paul Éluard

More information about the postgis-users mailing list