[postgis-devel] [PostGIS] #1319: [raster] Make raster_columns a view and AddRasterColumn enforce more
PostGIS
trac at osgeo.org
Wed Nov 23 12:36:52 PST 2011
#1319: [raster] Make raster_columns a view and AddRasterColumn enforce more
----------------------------+-----------------------------------------------
Reporter: robe | Owner: robe
Type: task | Status: new
Priority: high | Milestone: PostGIS 2.0.0
Component: postgis raster | Version: trunk
Keywords: |
----------------------------+-----------------------------------------------
Comment(by dustymugs):
Replying to [comment:13 pracine]:
> Replying to [comment:11 dustymugs]:
> > The importer will call an update AddRasterColumn which only needs to
work on the table having the raster column added.
>
> I guess this is useless if we 'CREATE TABLE foo AS', right? This is why
we also need an equivalent of populate_raster_columns()?
>
Yes. AddRasterColumn adds a new empty raster column and constraints to an
existing table while populate_raster_column() only adds appropriate
constraints to an existing and populated raster column.
> > I'm planning on having the importer run by default in a strict mode
(where all rasters passed in when the importer is called have the same
scale x/y, srid and band types. There will be a set of flags to disable
specific constraints though.
>
> Why not automatically maintaining a set of 'samescalex', 'samescaley',
'samesrid' and 'samebandtype' flags as it loads many rasters so you can
determine at the end which constraint you can set. Actually this is
exactly what populate_raster_columns() would do... Again it is not wise to
do outside the database (like creating the overviews) what is useful to be
done inside (updating the constraints). I think AddRasterColumn() become
obsolete with 2.0 and should be replaced with the equivalent of
Populate_Raster_Columns() (or Apply_Raster_Constraints()?)
>
Sounds like a plan to me. The loader won't use apply_raster_constraints
(sounds more appropriate for the actions to be done) as that requires
another pass over the able while the loader has already looked at the
data. So the loader will set constraints as long as the import type isn't
append.
> > I don't know how useful nodatavalue is because there could be
different nodatavalues between two rasters' bands of the same index
because the values might be in different ranges. Say raster 1 band 1 has
values between 0 - 125 while raster 2 band 1 has values between 126 - 255.
Though the two rasters are aligned, they have different nodata values.
>
> I don't follow you. Why would two raster storing a different range of
values would have different nodata values?
>
Both rasters have the a band of same index of type PT_8BUI. All data in
raster 1 band 1 has values between 0 - 125. All data in raster 2 band 1
has values between 126 - 255. And both bands have nodata pixels. So,
raster 1 band 1 would need a nodata value greater than 125 while raster 2
band 1 would need a nodata value less than 126. Hence, same pixeltype for
both bands at same index but different nodata values.
> > Though extent might be valuable as it would be done using...
> >
> > {{{
> > SELECT ST_ConvexHull(ST_Collect(tile)) FROM tmax_2010
> > }}}
> >
> > It isn't fast though. On my tmax_2010 table with 36712 rows with tile
size of 100x100, it takes 1 second. So for every year between 1965 to
2011, the view would take 47 seconds (assuming 1 second for each table).
Add my tmin and precip datasets for the same years, we're talking 141
seconds.
>
> So we will tell people to query the specific table with
ST_Extent(rast::geometry) to get the extent...
Yes. There's no way around this limitation.
--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/1319#comment:14>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
More information about the postgis-devel
mailing list