> ----- Original Message ----- > > For sure doing overlay gis operations like st_intersection is not > > possible when the srid of the two geometries is different. In this > > case you would have to reproject (ST_Transform) the geometry so it fit > > the srid of right grid. But if your application is able to decide > > which grid it must query then it should also be able to decide which > > tale it must query and hence putting all your grids in different table > > should not be a problem. > > For the general case (particularly in the coast example, where the queries are > basically just Lon/Lat), we would not know which grid contains the answer. > Consequently we would have to do two queries (one to determine the grid to > query and one to query the specific grid), where today we make do with one. I > suspect that this would cost us a fair bit of performance.
You could have a table of the outlines of each dataset and use CASE to determine to which srid reproject your point. All that in one query. > > You can easily get the x,y upperleft corner of a pixel with the > > Raster2WorldcoordX(0,0) and Raster2WorldcoordY(1,0) functions. Is that > > what you need? > > Not quite - I was thinking more of World2RasterCoord, but using a geometry to > extract multiple raster points. Essentially, ST_INTERSECT, but returning > raster > coordinates rather than world coordinates and value. You can extract every point of a complex geometry using a mixture of ST_PointN(),ST_NPoints(),ST_NumGeometries() and ST_GeometryN(). Have a look in the PostGIS doc. Pierre _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
