Dan Baston
Dan Baston
> but at least the user will see some non-zero percentage at the beginning... OTOH getting stuck at 5% before jumping to 100% can be confusing. > Do you believe...
Some timings from simplifying TIGER state boundaries with a tolerance of 1e-3... 97% of runtime in GDALVectorSimplifyCoverageOutputDataset::Process(OGRLayer&, OGRLayer&) 93% of runtime in geos::coverage::CoverageSimplifier::simplify(double) which is split into 40% in geos::coverage::CoverageRingEdges::build...
@rouault This is along the lines of what I was thinking with this comment: https://github.com/OSGeo/gdal/pull/12406#discussion_r2094547998 But rather than an argument `--pixel-function` that is mutually exclusive with `--calc`, I would consider...
Isn't this behavior different from the muparser dialect in a fundamental way, in that with muparser N bands of input will produce N bands of output, but with `--dialect builtin`,...
Nice! I have been tied up on other things but hope to look at this soon.
I implemented the muparser behavior intentionally to match what numpy would do in this situation. That's why the inputs must have the same number or bands, or a single band.
We don't need source names for `--dialect builtin`, so https://github.com/rouault/gdal/pull/65 removes that requirement
Additional suggestions in https://github.com/rouault/gdal/pull/68, https://github.com/rouault/gdal/pull/67
> any opinions on if adding a glossary should be pursued? I like it!
This is now fixed by https://github.com/OSGeo/gdal/pull/13480 for the upper version selector: but not the lower version selector: