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 , 6 years ago
comment:2 by , 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 , 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.
comment:4 by , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
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.
I guess the input vector dataset is not in UTM18 projection ?
If so, this is a known behaviour (although not really expected admitedly)