feat: add GDALRasterizeGeometries wrapper

[msalib]

• I agree to follow the project's code of conduct.
• I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

---

This new function rasters::rasterize lets you "burn in" a sequence of vector::Geometry objects into a raster Dataset.

[lnicola]

I haven't looked too closely, but it feels like RasterizeOptions should have a manual Default implementation. There's no obvious reason why MergeAlgorithm should default to Replace, so that decision should be left for RasterizeOptions to take.

[msalib]

Ah, that makes more sense. Done!

[msalib]

I'm not 100% certain where the best place to put this is. I considered making it a Dataset method, but it only makes sense for raster Datasets, and it seems a bit niche. It might also go in the vector module since it takes a sequence of Geometry objects but that also seems odd.

I'm also not 100% convinced that passing in separate slices for geometries and burn_values is the best; it might make more sense to have a struct or pair with both and just pass a slice of that struct/tuple. But doing that might be annoying for cases where folks have an expensive to compute collection of Geometrys and want to pass different burn_values without updating. This might be better structured as a builder.

[lnicola]

Sorry for taking so long on this. I don't mind where the code sits, but I'm not too fond of that TextOptions API, mostly because it stores two Vecs. Other places call CSLSetNameValue directly, maybe you could do the same until we get a better API.

[msalib]

No worries on the delay; everyone is busy and I really appreciate your review!

This version uses a TextOptions that stores only a pointer and calls CSLSetNameValue directly as you suggested.

There are a few places that use asserts for input validation; would you prefer that I replace those with real errors added to GdalError instead?

[msalib]

Actually, the asserts were bothering me, so I just put in more proper error handling, but I'm happy to remove it if you prefer.

[lnicola]

This version uses a TextOptions that stores only a pointer and calls CSLSetNameValue directly as you suggested.

Yeah, that looks better. I'm not too keen on the name, but I don't have any great suggestion (CSLStringList?) and it's not public yet.

Actually, the asserts were bothering me, so I just put in more proper error handling, but I'm happy to remove it if you prefer.

The error on special characters is kinda' fine, though I'm not sure it's really required. GDAL doesn't do anything fancy there, I think their point is simply to not have the separator in the key.

The other checks are less idiomatic: the user gave us some bogus arguments that don't make sense. It's closer to "used the wrong index in an array" than "a file was missing from disk". To put it differently, if you made this mistake in your code, would you prefer a panic right off the bat, or an error that was propagated up the stack until handled somewhere?

But I'm around "-0" on these, and feel free to ignore my opinion anyway (or to wait/ask for another one).

[msalib]

Sorry for my confusion, but do you want any other changes?

[lnicola]

Ah, no, I don't have any other strong feelings about the panics, but maybe someone else wants to take a look?

[lnicola]

bors r+

I guess we can still iterate on this if anything comes up.

[bors]

Build succeeded:

• ci ubuntu-20.04
• ci ubuntu-20.04 (--all-features)
• clippy