Opened 12 years ago

Closed 12 years ago

#1519 closed enhancement (fixed)

[raster] ST_MapAlgebraExpr : provide more keyword substitution

Reported by: strk Owned by: pracine
Priority: medium Milestone: PostGIS 2.0.0
Component: raster Version: master
Keywords: Cc:

Description

In addition to the existing "rast" keyword substitution, which returns a pixels' value, it would be useful to have another keyword expanding to the pixel geographical location (a polygon) and maybe another couple for X and Y informations.

We may be still in time for 2.0, as it's probably an easy and safe addition.

Change History (4)

comment:1 by strk, 12 years ago

Oh, the same applies to ST_MapAlgebraFct, the user function should be able to access all informations related to the pixel.

Geographic location, I'm mostly interested in, but I guess if x/y are also given maybe we should also pass raster band metadata (pixelsizes, offsets, rotations).

comment:2 by strk, 12 years ago

As I'm aiming for speed, I've been thinking that X and Y would be good enough, after all. Maybe all keywords should also be protected, to allow using the labels outside the context of a keyword substitution..

comment:3 by strk, 12 years ago

Idea, since "RAST" is already being replaced, no matter what, we could append to it:

"RAST.x" and "RAST.y" would be substituted. "RAST.v" could be also substituted, for consistency.

Finally, "RAST" would be susbtituted for backward compatibility, but new code won't have any "RAST" label left by that time.

This approach is the least intrusive

comment:4 by strk, 12 years ago

Resolution: fixed
Status: newclosed

So, r8994 implements the idea in previous comment for ST_MapAlgebraExpr. Doesn't add the "RAST.v", to avoid an additional keyword substitution pass while still maintaining backward compatibility.

Didn't touch ST_MapAlgebraFnc, which would likely be nice to also get those additional params.

Surely the expression-based version is easier to expand in a backward compatible way.

Beside, the keyword substitution code may probably be faster than it is.

Note: See TracTickets for help on using tickets.