Opened 14 years ago

Closed 14 years ago

Last modified 7 years ago

#493 closed defect (invalid)

[wktraster] ST_DumpValues to Dump Pixel values

Reported by: robe Owned by: pracine
Priority: medium Milestone: PostGIS Fund Me
Component: raster Version: master
Keywords: Cc:

Description

This is just a suggestion, and will probably become less useful as we build out the other functions.

I'm finding ST_Value to be the most useful function in the mix to build out all sorts of other plpgsql functions. The problem is that the multiple calls is killing speed.

One trivial reason making ST_Value slower than it should be is that echo NOTICE in there. Can we take that out or do I have some level of debugging enabled that I don't know about?

The other issue is the cost of going into the postgis raster layer. I think its the same issue with ran into with PostGIS why using ST_Dump was so much faster than doing the same thing with generate_series.

So anyway just thought I would throw it out there as a suggestion.

Now exploding out all values might be a bit too much — so might want to add an x y range.

Change History (7)

comment:1 by robe, 14 years ago

Summary: ST_DumpValues to Dump Pixel values[wktraster] ST_DumpValues to Dump Pixel values

comment:2 by pracine, 14 years ago

Could you describe a little bit how you use ST_Value? I was not thinking about implementing complex pixel value access functions. Normally you could access pixel values of any part of the raster with ST_AsText(ST_Clip(rast, geom)) which are not implemented yet. Would this fulfill your needs?

Remember also that WKT Raster main intented use it to work with huge tilled coverage. Every tile should be something like 128 x 128 pixels. The same way you don't use PostGIS to do analysis or publish small shapefiles (better do it with a desktop application), you don't normally use WKT Raster do work with small images but with complete coverages, and those are workable only when tiled.

I say that because you don't nesessarily access pixel values in a tiled coverage the same way you access them in an image. I would strongly suggest you experiment and build users cases with tiled coverages. This should have a major impact on the way you see WKT Raster and the function you think you need. You can build a coverage by importing images with the -k option of gdal2wktraster.py. I think working with tiled coverage is closer to what people will actually do with WKT Raster.

comment:3 by robe, 14 years ago

Pierre,

Let me think about this a bit more. It might be better served adding a range to ST_DumpPolygons or when you raster classification feature is implemented.

What I had invisioned is I would use your ST_Clip(rast,geom) to get a raster back and then I would use ST_DumpValues to polygonize how I preferred based on a range of DumpValues. This would probably be better if ST_DumpAsPolygons took a range of Pixel values of interest.

Here is my function to better demonstrate what I mean. Which would be used to form a multipolygon/polygon only for selected raster bands that have specified ranges and sampling every 5 pixels. In this example:

-- return a polygon formed 
-- from rast bands 1 and 3 
-- with band 1 pixel range 15 to 100 
-- or band 2 pixel range 20,30 and sample every 5 pixels across and down
SELECT rutility.upgis_rastertopolygon(rast,ARRAY[1,3], 5, 
	ARRAY[ARRAY[15,100], ARRAY[20,30]])
FROM pele;

The function looks like below

CREATE OR REPLACE FUNCTION rutility.upgis_rastertopolygon(param_rast raster, param_bands integer[], param_sampling integer, param_valrange float[][2])
  RETURNS geometry AS
$BODY$
DECLARE 
 var_rows integer := ST_Height(param_rast);
 var_cols integer := ST_Width(param_rast);
 var_pixsizex float := ST_PixelSizeX(param_rast);
 var_pixsizey float := ST_PixelSizeY(param_rast);
 var_pixpoly geometry := ST_MakeEnvelope(ST_UpperLeftX(param_rast),ST_UpperLeftY(param_rast), 
		ST_UpperLeftX(param_rast) + var_pixsizex*param_sampling, ST_UpperLeftY(param_rast) + var_pixsizey*param_sampling, ST_SRID(param_rast));
 var_result geometry;

BEGIN
	SELECT ST_Union(ST_Translate(var_pixpoly, x*var_pixsizex, y*var_pixsizey))
		INTO var_result
			FROM generate_series(1,var_cols,param_sampling) As x
					CROSS JOIN generate_series(1,var_rows,param_sampling) As y
		WHERE EXISTS (SELECT 1 FROM generate_series(1, array_upper(param_bands,1)) As i
				WHERE ST_Value(param_rast, param_bands[i],x,y) 
					BETWEEN param_valrange[i][1] AND param_valrange[i][2] ) ;
	RETURN var_result;
END
$BODY$
  LANGUAGE 'plpgsql' IMMUTABLE;

comment:4 by pracine, 14 years ago

Isn't the ST_SelectByValue(raster, ‘expression’) fulfilling this need:

ST_DumpASPolygons(ST_SelectBandByValue(raster,1, 'val ≥ 15 and val ⇐ 100'))

Then you can intersect the resulting geometries with any sampling assemblage you desire? Actually you don't have to call ST_DumpASPolygons() yourself as doing ST_Intersections() between your grid and the result of ST_SelectByValue(raster,'val ≥ 15 and val ⇐ 100') will do it for you.

Would that give approximately the same result? I`m just trying to see if there is enough tools in the planned function to provide you with what you expect.

comment:5 by robe, 14 years ago

Resolution: invalid
Status: newclosed

Oh yes that would work. Must have missed that one.

comment:6 by pracine, 12 years ago

Milestone: PostGIS Raster FuturePostGIS Future

comment:7 by robe, 7 years ago

Milestone: PostGIS FuturePostGIS Fund Me

Milestone renamed

Note: See TracTickets for help on using tickets.