Opened 12 years ago
Last modified 7 years ago
#2325 new enhancement
[raster]: ST_SetBandNoDataValue support setting multiple bands
Reported by: | robe | Owned by: | dustymugs |
---|---|---|---|
Priority: | low | Milestone: | PostGIS Fund Me |
Component: | raster | Version: | master |
Keywords: | Cc: |
Description
I find myself doing stuff like this:
st_setbandnodatavalue(st_setbandnodatavalue(rast,1,0),2,0) etc.
I feel like I've mentioned this before so this may be a dupe though I can't find it.
Not only is it slow because of the memcopy commands, but its pretty ugly to look at.
ideally:
ST_SetBandNoDataValue(rast,'{1,2,3}'::int[],'{0,0,0}'::int[] );
would have been even nicer if the rast,nodatavalue version just set all the bands to whatever value is passed in, but I guess that would be changing the semantics so maybe a nono - though we did it already with ST_Union
Change History (5)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Okay we can leave that one out. Though I think its the preferred behavior for people with multiple bands and what people would naturally expect. It wouldn't change the semantics for people having just one band which I think Pierre had intended as a short-cut for people with just one band to not have to specify the band
comment:3 by , 12 years ago
see #2328 I broke out the change behavior of no band specified option as separate ticket. I think that one since it doesn't change the API and is more in line with other 2.1 changes can be done in 2.1 (which would not make 2.1. obsolete). Your call though. I may not have thought of all the scenarios, but for my use cases its pretty debilitating.
comment:4 by , 10 years ago
Milestone: | PostGIS 2.2.0 → PostGIS Future |
---|---|
Priority: | medium → low |
Doing stuff in one pass sounds reasonable to me. I'd be against changing the current semantics though as that has too many opportunities to get oneself in trouble.
Making 2.1 obsolete already?