[postgis-devel] [PostGIS] #1648: [raster] ST_AsRaster unexpected result
PostGIS
trac at osgeo.org
Tue Jun 12 08:37:54 PDT 2012
#1648: [raster] ST_AsRaster unexpected result
-----------------------+----------------------------------------------------
Reporter: jomarlla | Owner: dustymugs
Type: defect | Status: closed
Priority: medium | Milestone: PostGIS 2.0.1
Component: raster | Version: trunk
Resolution: wontfix | Keywords:
-----------------------+----------------------------------------------------
Changes (by dustymugs):
* status: assigned => closed
* resolution: => wontfix
Comment:
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.
--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/1648#comment:11>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
More information about the postgis-devel
mailing list