Opened 6 years ago

Closed 5 years ago

#7197 closed defect (wontfix)

GDAL_Rasterize - creation with -a_srs and -te

Reported by: nbonniere Owned by: warmerdam
Priority: normal Milestone: closed_because_of_github_migration
Component: default Version: 2.2.2
Severity: normal Keywords:
Cc:

Description

When creating a new target raster image instead of modifying an existing one, the desired rasterize operation is not done.

set PATH=%PATH%;"C:\OSGeo4W64\bin"

set GDAL_DATA=C:\OSGeo4W64\bin\..\share\epsg_csv

set image_width=1024

set image_height=1024

set utm_zone=18

set utm_left=450495.0

set utm_bottom=5003505.0

set utm_right=473535.0

set utm_top=5026545.0

set sourcevec=../../GeoDatabase/fme.ogr/dataset/canvec.gdb

set destinationtiff=UTMmap.tif

gdal_rasterize -init 0 -ot Byte -ts %image_width% %image_height% -te %utm_left% %utm_bottom% %utm_right% %utm_top% -of GTiff -a_srs "+proj=utm +zone=%utm_zone% +datum=wgs84" -burn 192 -burn 192 -burn 0 -l road_segment_1 %sourcevec% %destinationtiff%

All I get is a blank tiff file, with correct format (-init, -ot, -of), srs data (-a_srs), size (-ts), but blank raster.

If I follow it with another call:

gdal_rasterize -b 1 -b 2 -b 3 -burn 192 -burn 192 -burn 0 -l road_segment_1 %sourcevec% %destinationtiff%

it then works perfectly as expected, now modifying the tiff file that was created by the first call.

It is probable that the srs (-a_srs) or extents (-te) are only inserted at the end and not used initially to extract the vector information and create the raster.

Change History (4)

comment:1 by Even Rouault, 6 years ago

I guess the input vector dataset is not in UTM18 projection ?

If so, this is a known behaviour (although not really expected admitedly)

<dt> <b>-a_srs</b> <i>srs_def</i>:</dt><dd> (GDAL >= 1.8.0)
Override the projection for the output file. If not specified, the projection of
the input vector file will be used if available. When using this option, no reprojection
of features from the SRS of the input vector to the specified SRS of the output raster,
so use only this option to correct an invalid source SRS.

comment:2 by nbonniere, 6 years ago

That's right, the <src_datasource> file is not UTM-18. According to http://www.gdal.org/gdal_rasterize.html, since version 2.1.0, gdal_rasterize re-projects to the projection specified in the <dst_filename>.

So when a <dst_filename> does not exist, and needs to be created, and since -a_srs specifies the desired projection, I expected a re-projection as if the file already existed.

I don't understand the concept of -a_srs to override the projection if the data itself doesn't match. Perhaps a -t_srs and -te_srs (as in gdal_warp) would be an alternative.

I guess I need to do a three step process. First create a blank raster, then add srs information with gdal_translate, then do gdal_rasterize.

comment:3 by Jukka Rahkonen, 6 years ago

About -a_srs, I can see use cases for it from real world, for example if shapefiles have been delivered without .prj file and source srs is therefore unknown. In gdalwarp using -t_srs really makes re-projection to happen if -s_srs is known. Because gdal_rasterize with -a_srs does not re-project vectors I consider it is behaving like the -a_srs parameter in gdal_translate.

If gdal_rasterize will support creating target image in a user given coordinate system some day, then it would be the time to introduce -t_srs parameter, as well as -s_srs.

Last edited 6 years ago by Jukka Rahkonen (previous) (diff)

comment:4 by Even Rouault, 5 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.

Note: See TracTickets for help on using tickets.