Re: [gdal-dev] GDAL 3.3.0 RC1 available

[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 that cuts it to 4 months.
>
> Even
> Le 28/04/2021 à 03:59, Sean Gillies a écrit :
>
> Hi Even,
>
> I see that there's also a 3.2.3 candidate. Usually we discontinue the
> previous minor version, right? Why in this case are we have a 3.3.0rc1 and
> a 3.2.3rc1?
>
> On Mon, Apr 26, 2021 at 6:57 AM Even Rouault 
> wrote:
>
>> Hi,
>>
>> I have prepared a GDAL/OGR 3.3.0 release candidate. The feedback on beta1
>> was useful to spot and fix a few bugs.
>
>
-- 
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] PROJ context and threads

[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 a mode where the SQLite3
> db handle would be shared amongst several contexts. In theory that could be
> possible as you can invoke sqlite3_open_v2() with SQLITE_OPEN_FULLMUTEX.
> But would require non completely trivial changes.
>
Thanks. I can work around this issue for now.

Changes in GDAL might be nice, but I need to work with what's available
today. I could certainly PR the first suggestion if there is interest.
Perhaps I'm at the point where I should be using PROJ directly rather than
as wrapped by GDAL.

-- 
Andrew Bell
andrew.bell...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] PROJ context and threads

[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 several contexts. In theory that could 
be possible as you can invoke sqlite3_open_v2() with 
SQLITE_OPEN_FULLMUTEX. But would require non completely trivial changes


Le 28/04/2021 à 15:30, Andrew Bell a écrit :
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 this!  But it appears that the PROJ context held by a 
thread using GDAL is private, so I don't think I can call 
proj_context_set_autoclose_database(). I think I'm going to have to 
make sure that the thread actually terminates in order to release the 
context.


If someone has other suggestions, I'd be happy to hear them.

--
Andrew Bell
andrew.bell...@gmail.com 

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] PROJ context and threads

[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 this!  But it appears that the PROJ context held by a thread
using GDAL is private, so I don't think I can call
proj_context_set_autoclose_database(). I think I'm going to have to make
sure that the thread actually terminates in order to release the context.

If someone has other suggestions, I'd be happy to hear them.

-- 
Andrew Bell
andrew.bell...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Test Failures

[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, 
you'd get the same checksums.


We should try to minimize tests using JPEG for that reason, but in that 
instance, this test is really meant to check JPEG specific code paths in 
the COG driver. Or use some kind of perceptualdiff test for such test, 
but the "perceptualdiff" utility does consider "your" and "mine" image 
to be different, so that wouldn't help. We'd probably need something 
clever that tolerates pixel values differences that can be quite 
important (the max here is a difference of 19 units) but detects there's 
no spatial shift.




On Wed, Apr 28, 2021 at 8:35 AM Even Rouault 
mailto:even.roua...@spatialys.com>> 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 a PR adding your checksums as alternate accepted
ones. You may just remove the "if sys.platform == 'darwin'" case.
Hopefully adding your checksums should fix the OSX CI too


--
Andrew Bell
andrew.bell...@gmail.com 


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Test Failures

[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 a
> PR adding your checksums as alternate accepted ones. You may just remove
> the "if sys.platform == 'darwin'" case. Hopefully adding your checksums
> should fix the OSX CI too
>

-- 
Andrew Bell
andrew.bell...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Test Failures

[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 checksums should fix the OSX CI too


Even

Le 28/04/2021 à 14:20, Andrew Bell a écrit :
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 
mailto:even.roua...@spatialys.com>> wrote:



Le 27/04/2021 à 20:49, Andrew Bell a écrit :



On Tue, Apr 27, 2021 at 2:27 PM Even Rouault
mailto:even.roua...@spatialys.com>>
wrote:

Andrew,

This could be due to the PROJ version, but as I'm running
with 8.0 too (and one of the CI config runs PROJ master), I
suspect you just need to install the "conus" grid for NAD27
to WGS84 transformations into {proj_prefix}/share/proj .
Unpack
http://download.osgeo.org/proj/proj-datumgrid-1.8.tar.gz


I have PROJ_NETWORK set to ON. I was under the impression that
this would cause PROJ to find whatever grids shift files it
needed at runtime. Is there more configuration that's necessary
to get this to happen or do I misunderstand the PROJ_NETWORK setting?


That should be fine. Actually I was wrong. This test case doesn't
involve any datum shift / grids as it is EPSG:4326 to EPSG:3857
reprojection.

That might then just be a subtle different rounding issue in
computations in GDAL and/or PROJ, or more likely, due to using a
different JPEG library as this test case involves JPEG
compression. If that was the case, you might add your checksums as
an alternative expected output. We do that in a number of places.

Looking a few lines before the failure, I actually see that the CI
got that issue and we worked around it with:

    if sys.platform == 'darwin' and gdal.GetConfigOption('TRAVIS',
None) is not None:
    assert got_cs != [0, 0, 0]
    else:

Could you run

gdal_translate ../autotest/gdrivers/data/small_world.tif out.tif
-of COG co TILING_SCHEME=GoogleMapsCompatible -co COMPRESS=JPEG

and attach the resulting file ?



Thanks,
-- 
Andrew Bell

andrew.bell...@gmail.com 


-- 
http://www.spatialys.com  

My software is free, but my time generally not.



--
Andrew Bell
andrew.bell...@gmail.com 


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Test Failures

[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 version, but as I'm running with 8.0 too
>> (and one of the CI config runs PROJ master), I suspect you just need to
>> install the "conus" grid for NAD27 to WGS84 transformations into
>> {proj_prefix}/share/proj . Unpack
>> http://download.osgeo.org/proj/proj-datumgrid-1.8.tar.gz
>>
> I have PROJ_NETWORK set to ON. I was under the impression that this would
> cause PROJ to find whatever grids shift files it needed at runtime. Is
> there more configuration that's necessary to get this to happen or do I
> misunderstand the PROJ_NETWORK setting?
>
> That should be fine. Actually I was wrong. This test case doesn't involve
> any datum shift / grids as it is EPSG:4326 to EPSG:3857 reprojection.
>
> That might then just be a subtle different rounding issue in computations
> in GDAL and/or PROJ, or more likely, due to using a different JPEG library
> as this test case involves JPEG compression. If that was the case, you
> might add your checksums as an alternative expected output. We do that in a
> number of places.
>
> Looking a few lines before the failure, I actually see that the CI got
> that issue and we worked around it with:
>
> if sys.platform == 'darwin' and gdal.GetConfigOption('TRAVIS', None)
> is not None:
> assert got_cs != [0, 0, 0]
> else:
>
> Could you run
>
> gdal_translate ../autotest/gdrivers/data/small_world.tif out.tif -of COG
> co TILING_SCHEME=GoogleMapsCompatible -co COMPRESS=JPEG
>
> and attach the resulting file ?
>
>
> Thanks,
>
> --
> Andrew Bell
> andrew.bell...@gmail.com
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>

-- 
Andrew Bell
andrew.bell...@gmail.com


gdal_translate.tar.gz
Description: GNU Zip compressed data
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.3.0 RC1 available

[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 also a 3.2.3 candidate. Usually we discontinue the 
previous minor version, right? Why in this case are we have a 3.3.0rc1 
and a 3.2.3rc1?


On Mon, Apr 26, 2021 at 6:57 AM Even Rouault 
mailto:even.roua...@spatialys.com>> wrote:


Hi,

I have prepared a GDAL/OGR 3.3.0 release candidate. The feedback
on beta1 was useful to spot and fix a few bugs.

The changes between beta1 and RC1 are identified in:

https://github.com/OSGeo/gdal/commit/a882173d688e6042c9dc7b1b57d8d169b04abe2b


Note a potential impact on packaging recipees regarding a few
esoteric untested/undocumented python scripts,
now moved as "samples" scripts of the gdal-utils package

Pick up an archive among the following ones (by ascending size):

https://download.osgeo.org/gdal/3.3.0/gdal-3.3.0rc1.tar.xz

https://download.osgeo.org/gdal/3.3.0/gdal-3.3.0rc1.tar.gz

https://download.osgeo.org/gdal/3.3.0/gdal330rc1.zip


A snapshot of the gdalautotest suite is also available :

https://download.osgeo.org/gdal/3.3.0/gdalautotest-3.3.0rc1.tar.gz

https://download.osgeo.org/gdal/3.3.0/gdalautotest-3.3.0rc1.zip


A snapshot of the documentation is at:

https://download.osgeo.org/gdal/3.3.0/gdal330doc.zip


GDAL-GRASS plugin:

https://download.osgeo.org/gdal/3.3.0/gdal-grass-3.3.0.tar.gz


NEWS at:

https://github.com/OSGeo/gdal/blob/v3.3.0RC1/gdal/NEWS


I'll call for a vote promoting it to final later this week if no
serious problems are reported before.

release/3.3 branch has been created for bug fixes and master is
now 3.4.0dev

Best regards,

Even

-- 
http://www.spatialys.com 

My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org 
https://lists.osgeo.org/mailman/listinfo/gdal-dev




--
Sean Gillies


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[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 it to work when I know the driver is there but ogr refused
to use it?

Thanks.



On Wed, 28 Apr 2021, 08:17 Hector muro,  wrote:

> 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 remember exactly what they are but it's well
> documented. It was something on the lines of "MSSQLSPATIAL_USE_BCP" and
> "MSSQLSPATIAL_BCP_SIZE"
>
> Another thing I found useful was to check the SSMS Profiler to see what's
> going on as you run.
>
> Finally, I was forced by circumstances to use SQL Server, but if that's
> not your case, I strongly recommend you to get away from it :)
>
> Hope this helps,
>
> Hector
>
>
> On Tue, 27 Apr 2021, 19:47 Neil Walker, 
> wrote:
>
>> Hello,
>>
>> First time user, I hope this is the right mailing list :)
>>
>>
>>
>> I have a fairly small (37mb - 160,000 linestrings) shp file and it loads
>> into QGIS in a couple of seconds. I want to import this into sql server, so
>> used the following ogr2ogr command:
>>
>>
>>
>> ogr2ogr -f "MSSQLSpatial"
>> "MSSQL:server=myserver;database=mydatabase;Trusted_Connection=True;"
>> "NZ_RoadLink.shp" -a_srs "EPSG:27700" -nln "neilshape" -progress -lco
>> UPLOAD_GEOM_FORMAT=wkt
>>
>>
>>
>> It's UK Ordnance Survey open roads data if anyone is interested. After 40
>> minutes it got to 3% complete then I gave up.
>>
>>
>> So I instead saved it as a CSV and it took about 1 minute, I then
>> imported this CSV into sql server and that took 1 minute too.
>>
>>
>>
>> I then ran the following command and it worked ok too after a few
>> seconds, I don't know if it's right or not but looks ok...
>>
>>
>>
>> alter table add geom GEOMETRY
>>
>> update table set geom=replace(wkt,'Z','')
>>
>>
>>
>> So, can anyone let me know what could be causing this massive slowdown
>> because my database connection is fast and there are no network issues. I
>> have tried using all the available sql server drivers (SQL Server, default
>> ODBC) but it's still this slow. I actually also have 'sql server native
>> 11.0' but ogr2ogr refused to use this.
>>
>>
>> If nobody has a clue can you confirm if my removal of 'Z' in this command
>> is ok or what a better way is?
>>
>>
>> Also, I don't know if it's just the way it is but I kept getting 'invalid
>> database object mydatabase' until I entered the UPLOAD_GEOM_FORMAT=wkt
>> parameter. Clearly 'mydatabase' has nothing to do with the error...
>>
>>
>> Thanks.
>>
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[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, sql server native client). I have and use all 3 but when
I tried to use native client ogr2ogr failed to run with an error.

On Wed, 28 Apr 2021 at 08:17, Hector muro  wrote:

> 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 remember exactly what they are but it's well
> documented. It was something on the lines of "MSSQLSPATIAL_USE_BCP" and
> "MSSQLSPATIAL_BCP_SIZE"
>
> Another thing I found useful was to check the SSMS Profiler to see what's
> going on as you run.
>
> Finally, I was forced by circumstances to use SQL Server, but if that's
> not your case, I strongly recommend you to get away from it :)
>
> Hope this helps,
>
> Hector
>
>
> On Tue, 27 Apr 2021, 19:47 Neil Walker, 
> wrote:
>
>> Hello,
>>
>> First time user, I hope this is the right mailing list :)
>>
>>
>>
>> I have a fairly small (37mb - 160,000 linestrings) shp file and it loads
>> into QGIS in a couple of seconds. I want to import this into sql server, so
>> used the following ogr2ogr command:
>>
>>
>>
>> ogr2ogr -f "MSSQLSpatial"
>> "MSSQL:server=myserver;database=mydatabase;Trusted_Connection=True;"
>> "NZ_RoadLink.shp" -a_srs "EPSG:27700" -nln "neilshape" -progress -lco
>> UPLOAD_GEOM_FORMAT=wkt
>>
>>
>>
>> It's UK Ordnance Survey open roads data if anyone is interested. After 40
>> minutes it got to 3% complete then I gave up.
>>
>>
>> So I instead saved it as a CSV and it took about 1 minute, I then
>> imported this CSV into sql server and that took 1 minute too.
>>
>>
>>
>> I then ran the following command and it worked ok too after a few
>> seconds, I don't know if it's right or not but looks ok...
>>
>>
>>
>> alter table add geom GEOMETRY
>>
>> update table set geom=replace(wkt,'Z','')
>>
>>
>>
>> So, can anyone let me know what could be causing this massive slowdown
>> because my database connection is fast and there are no network issues. I
>> have tried using all the available sql server drivers (SQL Server, default
>> ODBC) but it's still this slow. I actually also have 'sql server native
>> 11.0' but ogr2ogr refused to use this.
>>
>>
>> If nobody has a clue can you confirm if my removal of 'Z' in this command
>> is ok or what a better way is?
>>
>>
>> Also, I don't know if it's just the way it is but I kept getting 'invalid
>> database object mydatabase' until I entered the UPLOAD_GEOM_FORMAT=wkt
>> parameter. Clearly 'mydatabase' has nothing to do with the error...
>>
>>
>> Thanks.
>>
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Nitf Metadata parsing

[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., 

http://osgeo-org.1560.x6.nabble.com/gdal-dev-Accessing-DES-in-NITF-through-GDAL-td5434141.html



You gave me the example of how to output the DES's  from the command line,

but the builds I'm pulling can't actually get access to the DES data on

Windows. 



Was your build that you showed the output from above complied with the

ESRI_NITF flagged as Even suggested? 



If yes, I can't figure out how to set the ESRI_NITF build flagged, any

thoughts?



Thanks again.











--

Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html

___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

https://lists.osgeo.org/mailman/listinfo/gdal-dev


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[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 remember exactly what they are but it's well documented.
It was something on the lines of "MSSQLSPATIAL_USE_BCP" and
"MSSQLSPATIAL_BCP_SIZE"

Another thing I found useful was to check the SSMS Profiler to see what's
going on as you run.

Finally, I was forced by circumstances to use SQL Server, but if that's not
your case, I strongly recommend you to get away from it :)

Hope this helps,

Hector


On Tue, 27 Apr 2021, 19:47 Neil Walker,  wrote:

> Hello,
>
> First time user, I hope this is the right mailing list :)
>
>
>
> I have a fairly small (37mb - 160,000 linestrings) shp file and it loads
> into QGIS in a couple of seconds. I want to import this into sql server, so
> used the following ogr2ogr command:
>
>
>
> ogr2ogr -f "MSSQLSpatial"
> "MSSQL:server=myserver;database=mydatabase;Trusted_Connection=True;"
> "NZ_RoadLink.shp" -a_srs "EPSG:27700" -nln "neilshape" -progress -lco
> UPLOAD_GEOM_FORMAT=wkt
>
>
>
> It's UK Ordnance Survey open roads data if anyone is interested. After 40
> minutes it got to 3% complete then I gave up.
>
>
> So I instead saved it as a CSV and it took about 1 minute, I then imported
> this CSV into sql server and that took 1 minute too.
>
>
>
> I then ran the following command and it worked ok too after a few seconds,
> I don't know if it's right or not but looks ok...
>
>
>
> alter table add geom GEOMETRY
>
> update table set geom=replace(wkt,'Z','')
>
>
>
> So, can anyone let me know what could be causing this massive slowdown
> because my database connection is fast and there are no network issues. I
> have tried using all the available sql server drivers (SQL Server, default
> ODBC) but it's still this slow. I actually also have 'sql server native
> 11.0' but ogr2ogr refused to use this.
>
>
> If nobody has a clue can you confirm if my removal of 'Z' in this command
> is ok or what a better way is?
>
>
> Also, I don't know if it's just the way it is but I kept getting 'invalid
> database object mydatabase' until I entered the UPLOAD_GEOM_FORMAT=wkt
> parameter. Clearly 'mydatabase' has nothing to do with the error...
>
>
> Thanks.
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev