[raster] ST_AsRaster unexpected result

[jomarlla]

Hi,

create table rast2 as

select ((pol).geom)::geometry (polygon, 0) as geom,

(pol).val::integer as value

from (select st_pixelaspolygons (rast) as pol from

(select st_asraster ('POLYGON ((11 11, 21 11, 26 21, 16 21, 11 11))'::geometry,

1.5::double precision, 2::double precision, 11, 11, '8BUI', 100, -1, 0, 0, true

) as rast

) as tabla) as tabla1;

Im getting a cell which is not burned.

[jomarlla]

A pixel is not burned

[jomarlla]

The attached file shows the example.

[Bborie Park]

What version of GDAL are you using? Testing your example on GDAL trunk (r24047) works fine. If you're using a version prior to 1.9, please try 1.9.

I've attached an image of what I'm getting.

[jomarlla]

Im using GDAL 1.9 release packaged from grass project repository ​http://download.opensuse.org/repositories/Application:/Geo/openSUSE_12.1/i586/

POSTGIS="2.0.0beta2SVN" GEOS="3.3.2-CAPI-1.7.2" PROJ="Rel. 4.7.1, 23 September 2009" GDAL="GDAL 1.9.0, released 2011/12/29" LIBXML="2.7.8"

Didnt try GDAL trunk. If the trunk version is already working maybe this ticket should be closed. Right now I can not build GDAL trunk to check it out by myself.

An easier way to check it:

select st_count(st_asraster ('POLYGON ((11 11, 21 11, 26 21, 16 21, 11 11))'::geometry, 1.5::double precision, 2::double precision, 11, 11, '8BUI', 100, -1, 0, 0, true));

st_count

---

40

You are getting 42 while Im getting 40.

Maybe some more people can try it with other gdal versions?

regards,

[Bborie Park]

Part of the problem here is there is nothing the PostGIS Raster devs (me included) can do to remedy the result you're getting as the PostGIS function is passing the geometry to GDAL to do the actual burning. If you can, you may want to see what you get using the geometry through the gdal_rasterize utility.

[pracine]

I get 40.

SELECT PostGIS_Full_Version ();

"POSTGIS="2.0.0alpha7SVN" GEOS="3.3.2-CAPI-1.7.2" PROJ="Rel. 4.6.1, 21 August 2008" GDAL="GDAL 1.9.0, released 2011/12/29" LIBXML="2.7.8" USE_STATS (core procs from "2.0.0alpha7SVN" need upgrade) (raster procs from "2.0.0alpha7SVN" need upgrade)"

[Bborie Park]

Using gdal trunk r24093, I get 42. I'm going to change the milestone for the future as though this ticket is worth watching, there isn't anything that the PostGIS devs can do about a GDAL behavior.

[Bborie Park]

Just tested GDAL 1.9.0 on Linux 64-bit and I get 42. On Linux 32-bit w/ GDAL 1.9.0, I get 40. On Linux 32-bit w/ GDAL trunk r24093, I get 40 again.

Strange that the behavior differs depending on the architecture.

[Bborie Park]

I'll test a different method using the gdal_rasterize utility on 32 vs 64 bit.

[Bborie Park]

After doing some additional digging, the difference in burned pixels boiled down to the use of the "touched" parameter.

Having "touched" be true causes the difference of burned pixels (42 vs 40 on 64 vs 32-bit)...

SELECT
	ST_Count(
		ST_AsRaster(
			'POLYGON ((11 11, 21 11, 26 21, 16 21, 11 11))'::geometry,
			1.5::double precision, 2::double precision,
			11, 11,
			'8BUI',
			100, 0,
			0, 0,
			true
		)
	);

With "touched" being false, 32 and 64-bit Linux return the same number of burned pixels: 34.

SELECT
	ST_Count(
		ST_AsRaster(
			'POLYGON ((11 11, 21 11, 26 21, 16 21, 11 11))'::geometry,
			1.5::double precision, 2::double precision,
			11, 11,
			'8BUI',
			100, 0,
			0, 0,
			false
		)
	);

Since everything is the same except the "touched" parameter, which only sets the ALL_TOUCHED option flag when calling GDALRasterizeGeometries(), there is a behavior difference in GDAL's algorithm.

I'm closing this ticket as there is nothing that can be done on the PostGIS side. Might be worth submitting a new ticket to GDAL though highlighting the difference in behavior for ALL_TOUCHED in 32 vs 64-bit environments.

[pracine]

Why not keeping it open as a link to a GDAL ticket and until a solution is found to this ticket. Otherwise it will fall into the limbo.

[Bborie Park]

I don't like keeping tickets open that we can't do anything about. The ticket would just be found in the closed tickets report so should exist forever.

If we want to keep these "GDAL" tickets open, I'd like a milestone similar to the "PostGIS GEOS" item for "PostGIS GDAL" so that it can be more appropriately categorized. But I thought there was discussion about keeping the milestone options limited to prevent clutter.

[pracine]

Who said we can't do anything about it? We can first fill a ticket in GDAL. We can even fix it ourself or put some pressure somewhere. If we close it without doing anything, it will just pop another time in the future. I don't like to close unfixed tickets. There are also plenty of tickets that stay here for years. The important is to have a way to "trac" them. Closed tickets are generally forgotten forever.

[strk]

There, "PostGIS GDAL" milestone. Now it takes a ticket to ​http://trac.osgeo.org/gdal dustymugs: will you do that and link back here ?

[Bborie Park]

GDAL ticket is ​4704