Even Rouault
Even Rouault
(unlocking) > In that case I will have to order my features prior to running gdal_rasterize, I guess. You could also use ``-sql "SELECT * FROM spray_area ORDER BY spray_rate"``
> I'm unable to determine the correct name for `bApproxOK` There's none. It is a positional optional argument, not a named one. Cf usages in https://github.com/OSGeo/gdal/blob/master/autotest/gcore/gcps2geotransform.py
> * test_fgdb.gdb.zip Maybe @jmckenna remembers the provenance of this file ? Otherwise you could potentially switch to one of the GDAL autotest suite samples: https://github.com/OSGeo/gdal/tree/master/autotest/ogr/data/filegdb
@michaeljones just to indicate that the link to your open collective account in your top message is broken. Should read https://opencollective.com/breathe
> Is that true @rouault ? Good question to which I don't know the answer. Maybe @drons who introduced support for encodings in the mapinfo driver knows. Perhaps the "laundering"...
Current state of things. The following GDAL Python script with PROJ master / 9.5.1 runs in 400 ms on my Linux system ```python from osgeo import osr src_srs = osr.SpatialReference()...
(take above test with a bit of grain of salt as using osr.CoordinateTransformation.TransformBounds() might not be totally representative of the work done by msProjectRect())
Using Python Mapscript gives similar, albeit slightly slower: 540 ms: ```python import mapscript src_proj = mapscript.projectionObj("EPSG:25833") minx=200000 miny=5.886e+06 maxx=465000 maxy=6.075e+06 epsg_list = [ 25832, 3034, 3035, 3044, 3045, 31468, 31469,...
Using directly PROJ C API, 210 ms: ```c+++ #include #include #include int main() { PJ_CONTEXT *context = proj_context_create(); PJ *src = proj_create(context, "EPSG:25833"); const int epsg_list[] = { 25832, 3034,...