[gdal-dev] gdal_rasterize expected behaviour

Hugues François hugues.francois at inrae.fr
Mon Mar 8 09:48:04 PST 2021


Hi Sean, 

That's perfectly clear and that's what I feared! I'll try to deal with that before processing my data with gdal_rasterize. 

All the best, 
Hug

-- 

Hugues François [ mailto:prenom.nom at inrae.fr ] 

IR - Administrateur de la BD Stations / StationoScope 

http://www.observatoire-stations.fr 

UR LESSEM 

+33 4 76 76 27 44 

+33 6 77 66 21 31

----- Mail original -----
De: "gdal-dev" <gdal-dev at lists.osgeo.org>
À: "gdal-dev" <gdal-dev at lists.osgeo.org>
Envoyé: Lundi 8 Mars 2021 17:48:51
Objet: Re: [gdal-dev] gdal_rasterize expected behaviour

Hi Hug, 

GDALRasterizeGeometries takes an array of geometries and iterates over them from start to end, burning them into the raster one at a time. With a strictly ordered vector layer, you can expect the later shapes to be burned over the earlier ones. 

On Mon, Mar 8, 2021 at 7:00 AM Hugues François < [ mailto:hugues.francois at inrae.fr | hugues.francois at inrae.fr ] > wrote: 


Hello, 

I don't know exactly where I should ask this question and I wasn't able to find the answer when searching on the internet (maybe I didn't use the right keywords). 

I have to rasterize a vector layer, made of polygons, which resolution is finer than the destination raster I have to use so that I want to use the "all_touched" option. But since my the raster resolution is coarser than the vector one, it may happens sometimes that a single pixel is touched by several polygons (and sometime none of them encompass the pixel center point). In this case, how does the value burned to the raster is chosen among the candidates? 

Best regards, 
Hug 






-- 
Sean Gillies 


[Fichier texte:ATT00001] 



More information about the gdal-dev mailing list