[postgis-devel] [PostGIS] #497: [raster] Start testing displaying PostGIS raster with Mapserver
PostGIS
trac at osgeo.org
Wed Feb 16 08:46:24 PST 2011
#497: [raster] Start testing displaying PostGIS raster with Mapserver
----------------------------+-----------------------------------------------
Reporter: robe | Owner: robe
Type: task | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis raster | Version: trunk
Keywords: |
----------------------------+-----------------------------------------------
Comment(by pracine):
1) There is a confusion here with srid. srid have nothing to do with
regular blocking or irregular blocking. The driver should assume that
every row is in the same srid. You REALLY don't have to fetch all rows to
know this. If by bad table design or error one or many raster get in a
different srid, meaning the georeference would be in different unit or
just very far from where it should be, then the extent of the whole table
might be wrong and those rasters certainly will be wrongly geolocated.
That`s life, we can do nothing againts it and the same happen with a
geometry table with different srid. We do not support this because it is
very bad user design... The same idea apply for pixelsize.
If really we want to support these kind of stupid arrangement (with
different srid or different pixelsize) later then we will have to have
really good reason to do so.
2) There are two ways to know the global extent or a table. a) Fetch the
raster_column table b) Query the table with ST_Extent
Method a) is becoming less and less reliable. See ticket #542.
Method b) is very fast when there is an index on the table (which we
should also assume since creating a table with many tile without creating
an index would be foolish)
3) In mode = 2, the driver should first query the extent with ST_Extent
and then just query all the tiles accompanied by their respective metadata
in a unique query
4) You certainly don't need everything provided by ST_Metadata. You should
query every metadata item with their respective function. ST_Metadata by
itself is slow because the whole tile has to be red. If you get metadata
items while you fetch the tiles it should be much faster since the server
has to load the tile anyway. It will give you the metadata item for free =
no time
5) To know if the table is regularly blocked is another story. From the
beginning I have been against this concept for reason examplified by
ticket 542. My point is: Just fetch the tile you need alltogether and burn
them in your raster buffer using the georeference. If this is not possible
with RasterBlock, then do it with RasterIO...
I think we need a clear an detailed specification document for the driver
that we can discuss on. We haven't got one yet...
--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/497#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