[postgis-users] PostGIS Raster for Met Data

[Michael Akinde]

Hi,

> You can easily remove this limitation (this is true for geometry also)
> by removing the proper constraint. You could also decide to store
> different grid in different tables. Normally you want to store data
> with the same semantic (or theme) in the same table making sure they
> are all in the same srid.

Hmm... I've always assumed that the constraint was put there for a non-trivial reason (i.e., stuff might break if the table contains multiple SRIDs). Is this not the case?

In our case, we very rarely deal with databases that contain grids of just one SRID. Just for the basic weather forecast, we have to deal with three: a detailed high resolution grid covering Northern Europe, a slightly lower resolution grid for Europe, and a global grid (the weather forecast is then picked from whichever of the three data sets is "best"). For stuff like our ocean forecasts, we have about a dozen different grids (the Norwegian coastline poses some interesting issues for weather forecasters).

> > Does anyone have any experience with generating sub-tables to handle
> > this problem? I'm particularly interested in performance, of course.
> I don't.

Due to the number of grids I am somewhat leery of setting up (and tearing down) multiple tables on an operational database (data grids change over time). Keeping it in one table would presumably be better, assuming it is practicable.
 
> > - Is there an easy (and efficient) way to run a query to get all of
> > the coordinate  points (x,y index) from within a raster that are 
>> contained in a polygon? That
> > would be quite interesting for us if we still need to build our own
> > solution on top
> > of the existing functionality for performance purposes. Haven't
> > looked at the
> > source code yet.
> 
> You mean the raster values at those points? The points are contained
> in a polygon, the rasters are contained in the polygon or you speak
> about the vertexes of a polygon?

No, the former is handled quite nicely by ST_INTERSECT, if I've understood correctly. I was thinking of a function that returns the x, y offsets; i.e., 0 0 for the origin point, 1 0 for the next point along the x axis, and so on. Since we have our value data stored in files outside the database, the x,y offsets allow us to retrieve data points very rapidly. This is how we have it implemented in WDB today, but with our own very limited function for identifying those offsets.

Regards,

Michael A.