Opened 12 years ago

Last modified 12 years ago

#1648 reopened defect

[raster] ST_AsRaster unexpected result

Reported by: jomarlla Owned by: Bborie Park
Priority: medium Milestone: PostGIS GDAL
Component: raster Version: master
Keywords: Cc:

Description

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.

Attachments (2)

Imagen11.png (3.0 KB ) - added by jomarlla 12 years ago.
A pixel is not burned
gdal-r24047.png (38.3 KB ) - added by Bborie Park 12 years ago.

Download all attachments as: .zip

Change History (18)

by jomarlla, 12 years ago

Attachment: Imagen11.png added

A pixel is not burned

comment:1 by jomarlla, 12 years ago

Component: postgisraster
Owner: changed from pramsey to pracine

The attached file shows the example.

comment:2 by pracine, 12 years ago

Summary: ST_AsRaster unexpected result[raster] ST_AsRaster unexpected result

comment:3 by Bborie Park, 12 years ago

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.

by Bborie Park, 12 years ago

Attachment: gdal-r24047.png added

comment:4 by jomarlla, 12 years ago

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,

comment:5 by Bborie Park, 12 years ago

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.

comment:6 by pracine, 12 years ago

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)"

comment:7 by Bborie Park, 12 years ago

Milestone: PostGIS 2.0.0PostGIS 2.0.1

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.

comment:8 by Bborie Park, 12 years ago

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.

comment:9 by Bborie Park, 12 years ago

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

comment:10 by Bborie Park, 12 years ago

Owner: changed from pracine to Bborie Park
Status: newassigned

comment:11 by Bborie Park, 12 years ago

Resolution: wontfix
Status: assignedclosed

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.

comment:12 by pracine, 12 years ago

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.

comment:13 by Bborie Park, 12 years ago

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.

comment:14 by pracine, 12 years ago

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.

comment:15 by strk, 12 years ago

Milestone: PostGIS 2.0.1PostGIS GDAL
Resolution: wontfix
Status: closedreopened

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

comment:16 by Bborie Park, 12 years ago

GDAL ticket is 4704

Note: See TracTickets for help on using tickets.