[postgis-users] point to raster conversion

Pierre Racine Pierre.Racine at sbf.ulaval.ca
Thu Dec 19 11:11:12 PST 2013


Try adding a "rid" column to your raster table. The GDAL driver was until recently dependent on rid.

> -----Original Message-----
> From: postgis-users-bounces at lists.osgeo.org [mailto:postgis-users-
> bounces at lists.osgeo.org] On Behalf Of Rémi Cura
> Sent: Thursday, December 19, 2013 12:06 PM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] point to raster conversion
> 
> QGis 2.0.1.
> I tried as well to convert to UINT16
> no sucess
> 
> 
> 2013/12/19 Rémi Cura <remi.cura at gmail.com>
> 
> 
> 	Is there a special trick to display the raster in QGIS?
> 	I do
> 	db manage/right click on the raster table/add to canvas
> 	Seems like there is nothing in it afterward.
> 
> 	Thanks again,
> 
> 	Rémi-C
> 
> 
> 	2013/12/19 Rémi Cura <remi.cura at gmail.com>
> 
> 
> 		Buffering make it works.
> 
> 		Cheers,
> 		Rémi-C
> 
> 
> 		2013/12/19 Rémi Cura <remi.cura at gmail.com>
> 
> 
> 			Hey, thanks for the answer, and nice catch !
> 			I'll try to simply buffer points,
> 			then try th eother method to count
> 
> 			About performance :
> 			this is not about plpgsql or C.
> 			I did quit the same processing when importing files
> of 3 millions points to split into small 1*1*1 m cubes.
> 			There were a lot of cubes (around 2k for 3 millions
> points), a lot of points (3 millions) with a lot of attributes (around 20
> flaot/double per point), and it was around 60 sec/ file (for the data
> processing. Data reading from disk was little longer).
> 
> 
> 			For a 50x50 pixels and a few thousand points I
> would expect around 200ms.
> 
> 
> 			I suspect it all boils down to current pixel access
> mechanism.
> 			Can you please confirm if there is or isn't a method
> to set/get several pixels at a time?
> 
> 			Thanks anyway,
> 			I wouldn't have found =)
> 
> 			Cheers,
> 			Rémi-C
> 
> 
> 			2013/12/19 Pierre Racine
> <Pierre.Racine at sbf.ulaval.ca>
> 
> 
> 				"MEAN_OF_VALUES_AT_PIXEL_CENTROID",
> which is the default ST_ExtractToRaster() method, search for geometries
> intersecting with the centroid of the pixel (a point). That's the method you
> use both calls to ExtractToRaster(). As it's almost impossible that a point
> intersects a point, this is certainly not the right method to get the value of
> points inside the pixel. A proper method would be
> "MEAN_VALUE_OF_POINTS" or "MEAN_VALUE_OF_GEOMETRIES" or
> "FIRST_GEOMETRY_VALUE" which are not implemented...
> 
> 				I suggest you try 'COUNT_OF_POINTS' for
> now which will set each pixel value to the number of point intersecting with
> it. If you get it to work and you're satisfied with the performance I could
> help adding a method for your specific need.
> 
> 				Can't do anything about the performance.
> All this is pure pl/pgsql and it's as fast as it can. 5 seconds to compute 2500
> pixels value using SQL is not that bad though if you're not on the web...
> Otherwise you should have a specific C function doing exactly what you
> want. Expect time and $$$.
> 
> 
> 				Pierre
> 
> 
> 
> 
> 
> 



More information about the postgis-users mailing list