Re: [gdal-dev] GDAL 3.3.0 RC1 available

2021-04-28 Thread Sean Gillies via gdal-dev
Thanks for explaining, Even. Makes sense to me. On Wed, Apr 28, 2021 at 2:59 AM Even Rouault wrote: > Sean, > > This was the trend of the previous cycles. I see I also produced a 3.1.4 > at about the same time of 3.2.0. This offers 6 month of support for a given > feature release. Otherwise

Re: [gdal-dev] PROJ context and threads

2021-04-28 Thread Andrew Bell
On Wed, Apr 28, 2021 at 9:38 AM Even Rouault wrote: > We could have a OSRSetAutoclosePROJDatabase() global function that would > call proj_context_set_autoclose_database() when it creates the per-thread > PROJ context > > ==> ogr/ogr_proj_p.cpp > > An alternative would be to enhance PROJ to have

Re: [gdal-dev] PROJ context and threads

2021-04-28 Thread Even Rouault
We could have a OSRSetAutoclosePROJDatabase() global function that would call proj_context_set_autoclose_database() when it creates the per-thread PROJ context ==> ogr/ogr_proj_p.cpp An alternative would be to enhance PROJ to have a mode where the SQLite3 db handle would be shared amongst

Re: [gdal-dev] PROJ context and threads

2021-04-28 Thread Andrew Bell
On Tue, Apr 27, 2021 at 11:44 PM Alan Snow wrote: > By default pyproj uses the autoclose option and provides this option for > users who want better performance and know they have a single threaded > application: > https://pyproj4.github.io/pyproj/stable/api/global_context.html > Thanks for

Re: [gdal-dev] Test Failures

2021-04-28 Thread Even Rouault
Do you have any idea why the differences exist? Is it worth investigating? Quite likely subtle differences in behavior of the JPEG compression library. Mine on ubuntu 20.04 is libjpeg-turbo 2.0.3 with IJG libjpeg 8 ABI. I presume if you built if from source and linked it against GDAL,

Re: [gdal-dev] Test Failures

2021-04-28 Thread Andrew Bell
Even, Do you have any idea why the differences exist? Is it worth investigating? On Wed, Apr 28, 2021 at 8:35 AM Even Rouault wrote: > Andew, > > visually the difference between your image and the one generated on my PC > are almost indistinguishable (no spatial shift at least). Please submit

Re: [gdal-dev] Test Failures

2021-04-28 Thread Even Rouault
Andew, visually the difference between your image and the one generated on my PC are almost indistinguishable (no spatial shift at least). Please submit a PR adding your checksums as alternate accepted ones. You may just remove the "if sys.platform == 'darwin'" case. Hopefully adding your

Re: [gdal-dev] Test Failures

2021-04-28 Thread Andrew Bell
Here is the output tif file along with the command and its terminal output. On Tue, Apr 27, 2021 at 3:02 PM Even Rouault wrote: > > Le 27/04/2021 à 20:49, Andrew Bell a écrit : > > > > On Tue, Apr 27, 2021 at 2:27 PM Even Rouault > wrote: > >> Andrew, >> >> This could be due to the PROJ

Re: [gdal-dev] GDAL 3.3.0 RC1 available

2021-04-28 Thread Even Rouault
Sean, This was the trend of the previous cycles. I see I also produced a 3.1.4 at about the same time of 3.2.0. This offers 6 month of support for a given feature release. Otherwise that cuts it to 4 months. Even Le 28/04/2021 à 03:59, Sean Gillies a écrit : Hi Even, I see that there's

Re: [gdal-dev] very slow sql ogr2ogr conversion

2021-04-28 Thread Neil Walker
The problem is bcp. The docs says bcp is only enabled for suitable drivers like native 11.0. I have this because ssms uses it and its in my odbc list. However when I try to use it as a driver, ogr2ogr fails. Only the default driver works, which I presume does not support bcp. So how can I get

Re: [gdal-dev] very slow sql ogr2ogr conversion

2021-04-28 Thread Neil Walker
Thanks, this is Windows 10. I turned debug on and noticed it said BCP 0. BCP is available and I use it so not sure why it says 0? However, I will test using that flag to see if it works or enables it. Like I said, the other odd thing is it told me to try one of three drivers (odbc, sql server,

Re: [gdal-dev] Nitf Metadata parsing

2021-04-28 Thread bradh
I did not set any additional environment variables or macros. I just used my usual gdal build. You are of course free to do whatever you like. BradOn 28 Apr 2021 11:01 am, jovajova24 wrote:Brad, sorry for pushing but I'm going in circles here. It looks like you and Even had this discussion i.e.,

Re: [gdal-dev] very slow sql ogr2ogr conversion

2021-04-28 Thread Hector muro
Hi Neil, I found a similar situation once. Are you using Linux? If so, I think the ogr2ogr MSSQLSpatial driver for Linux does not use BCP (for multiple inserts, which is why the CSV goes so fast). If not, have you tried using the MSSQLSpatial Configuration Options for the command? I don't