Opened 13 years ago
Last modified 12 years ago
#1648 reopened defect
[raster] ST_AsRaster unexpected result
Reported by: | jomarlla | Owned by: | dustymugs |
---|---|---|---|
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)
Change History (18)
by , 13 years ago
Attachment: | Imagen11.png added |
---|
comment:1 by , 13 years ago
Component: | postgis → raster |
---|---|
Owner: | changed from | to
The attached file shows the example.
comment:2 by , 13 years ago
Summary: | ST_AsRaster unexpected result → [raster] ST_AsRaster unexpected result |
---|
comment:3 by , 13 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 , 13 years ago
Attachment: | gdal-r24047.png added |
---|
comment:4 by , 13 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 , 13 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 , 13 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 , 13 years ago
Milestone: | PostGIS 2.0.0 → PostGIS 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 , 13 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 , 12 years ago
I'll test a different method using the gdal_rasterize utility on 32 vs 64 bit.
comment:10 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:11 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
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 , 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 , 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 , 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 , 12 years ago
Milestone: | PostGIS 2.0.1 → PostGIS GDAL |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
There, "PostGIS GDAL" milestone. Now it takes a ticket to http://trac.osgeo.org/gdal dustymugs: will you do that and link back here ?
A pixel is not burned