<div dir="ltr">Hi Even,<div><br></div><div>   Thanks a lot for the explanation - will modify as needed! Yes, the behviour was a little surprising, as it is not present with e.g. 'ATTRIBUTE=<something>' .</div><div><br></div><div>Cheers,</div><div>Simon</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 12, 2015 at 11:25 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Le mardi 11 août 2015 11:36:32, Simon Lyngby Kokkendorff a écrit :<br>
> Hello list,<br>
><br>
>   I'm trying to rasterize some 3d-lines programtically from python. Using<br>
> gdal 1.11.2 from the osgeo4w64 environment. Seems to work fine, except that<br>
> I get a z-offset of 255 (one byte) in my output raster. Works fine if I use<br>
> gdal_rasterize with the -3d option.<br>
><br>
>  The following python code should reproduce the problem:<br>
><br>
> from osgeo import ogr,gdal<br>
> print gdal.__version__<br>
> georef=[0,1.0,0,10.5,0,-1.0]<br>
> m_drv_ogr=ogr.GetDriverByName("Memory")<br>
> line_ds = m_drv_ogr.CreateDataSource( "dummy")<br>
> layer = line_ds.CreateLayer( "lines", None, ogr.wkbLineString25D)<br>
> layerdefn=layer.GetLayerDefn()<br>
> line=ogr.Geometry(ogr.wkbLineString25D)<br>
> line.AddPoint(0,5.5,0)<br>
> line.AddPoint(10,5.5,10)<br>
> feature=ogr.Feature(layerdefn)<br>
> feature.SetGeometry(line)<br>
> res=layer.CreateFeature(feature)<br>
> layer.ResetReading()<br>
> m_drv_gdal=gdal.GetDriverByName("MEM")<br>
> raster_ds=m_drv_gdal.Create("dummy",10,10,1,gdal.GDT_Float64)<br>
> raster_ds.SetGeoTransform(georef)<br>
> ok=gdal.RasterizeLayer(raster_ds,[1], layer, options=["BURN_VALUE_FROM=Z"])<br>
> A=raster_ds.ReadAsArray()<br>
> print A<br>
><br>
> Will output:<br>
><br>
> [[   0.    0.    0.    0.    0.    0.    0.    0.    0.    0.]<br>
>  [   0.    0.    0.    0.    0.    0.    0.    0.    0.    0.]<br>
>  [   0.    0.    0.    0.    0.    0.    0.    0.    0.    0.]<br>
>  [   0.    0.    0.    0.    0.    0.    0.    0.    0.    0.]<br>
>  [   0.    0.    0.    0.    0.    0.    0.    0.    0.    0.]<br>
>  [ 255.  256.  257.  258.  259.  260.  261.  262.  263.  264.]<br>
>  [   0.    0.    0.    0.    0.    0.    0.    0.    0.    0.]<br>
>  [   0.    0.    0.    0.    0.    0.    0.    0.    0.    0.]<br>
>  [   0.    0.    0.    0.    0.    0.    0.    0.    0.    0.]<br>
>  [   0.    0.    0.    0.    0.    0.    0.    0.    0.    0.]]<br>
<br>
</div></div>Simon,<br>
<br>
looking closer, the issue is that the Python bindings of gdal.RasterizeLayer()<br>
have a default constant burn value of 255 if not explicitly specified. This<br>
constant burn value comes in addition to the other source of burning, such as<br>
Z.<br>
So the fix is to add burn_values = [0] as a keyword of gdal.RasterizeLayer()<br>
<br>
I guess the rationale of that was that without any option, the rasterizing<br>
would burn 255, which is a reasonable default. But it is true that it is<br>
rather unexpected if you specify BURN_VALUE_FROM=Z<br>
<br>
Even<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> Cheers,<br>
> Simon Kokkendorff, Dansish Geodata Agency<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</font></span></blockquote></div><br></div>