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,
Mathieu.
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@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
http://ase-research.org/basille
~$ fortune
« Le tout est de tout dire, et je manque de mots
Et je manque de temps, et je manque d'audace. »
-- Paul Éluard
_______________________________________________
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
