BURN_VALUE_FROM option for GDALRasterizeGeometries

[xenononarcticus]

This patch defines a BURN_VALUE_FROM option for GDALRasterizeGeometries. This option instructs GDALRasterizeGeometries(0 to derive the burn value from an alternate source. Currently the only recognized source is "Z", which is the interpolated Z coordinate of the source geometry, added to the explicit padfGeomBurnValue value. This is sensible for wkb[Multi]Point and wkb[Multi]LineString? geometries but unimplemented for wkb[Multi]Polygon because interpolating Z within the filled polygon interior is extremely non-trivial.

These files are modified against a GDAL 1.6 release which does not appear to differ to greatly from the SVN trunk version.

[warmerdam]

Chaitanya,

Please review and incorporate in trunk as time permits.

[xenononarcticus]

I'd like to check and see if this change is acceptable, as I'd like to get it approved so the client who requested it can integrate it into their builds via SVN.

[chaitanya]

Replying to xenononarcticus:

I'd like to check and see if this change is acceptable, as I'd like to get it approved so the client who requested it can integrate it into their builds via SVN.

I am actively working on it. I had to make some modifications due to changes between 1.6 branch and the trunk.

In the mean time I can use some sample datasets you have used to test this.

[xenononarcticus]

Unit Test for rasterize burn Z

[xenononarcticus]

I have added gdalrasterizeburnztests.h

Include it, instantiate an GDALRasterizeBurnZTestCase object (with an arbitrary string argument to the constructor) and call the testGDALRasterizeBurnZ() method to exercise the feature.

[xenononarcticus]

Is there anything else I can do to help ensure this makes the 1.7 RC1?

[chaitanya]

Replying to xenononarcticus:

Is there anything else I can do to help ensure this makes the 1.7 RC1?

I just need to do a bit more testing. Just an hour or two. It should be done shortly.

[chaitanya]

Patch applied to trunk in r18164.

Future work could include introducing the M value from XYM or XYZM. The filled polygons could use some help too.

[rouault]

Chaintanyach,

* I don't see the point of having GDALBurnValueSrc enum and GDALRasterizeInfo struct definition in gdal_alg.h, which is a public header (and thus subject to backward compatibility issues), whereas they look to be only used byte implementation code. I think they might be better placed in a private header like gdal_alg_priv.h.

* the comment '<dt>"BURN_VALUE_FROM":</dt> <dd>May be set to GDALBurnValueSrc.GBV_Z to use the Z values of the geometries...' is found twice in the changeset and doesn't seem appropriate. papszOptions is an array of strings. The user of the API cannot assign a numeric enum value for the BURN_VALUE_FROM option. So from the user point of view, the appropriate value is "Z" instead, no ?

* the new capability should be tested in the autotest suite.

[chaitanya]

Moved the GDALBurnValueSrc enum and GDALRasterizeInfo struct definitions from gdal_alg.h to gdal_alg_priv.h in trunk. (r18227)

[chaitanya]

Applied patch r18340 to trunk.

It adds the functionality to polygons. However, it just uses the Z value from the first point and uses it throughout the polygon.

Added test rasterize_3 in autotest/alg/rasterize.py.