Re: [gdal-dev] [EXTERNAL] Re: ds.DeleteLayer(idx) "failed: database table is locked"

[Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] via gdal-dev]

Thanks Evan,

Yes, the dataset is open with the update flag set.

It’s a bit awkward because I want to replace the layer with the layer returned 
by the query.  If I do the naïve “ds.CopyLayer(sql_lyr, layer_name, 
options=[“OVERWRITE=YES”]) this appears to enter into an infinite loop.  So 
looks like I need to do this manually.

Best,
Jesse

Lead Computer Scientist
Science Systems and Applications, Inc.
Dr Compton Tucker Team
NASA Goddard Space Flight Center

From: Even Rouault 
Date: Thursday, January 30, 2025 at 1:47 PM
To: Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] 
, gdal dev 
Subject: [EXTERNAL] Re: [gdal-dev] ds.DeleteLayer(idx) "failed: database table 
is locked"
CAUTION: This email originated from outside of NASA.  Please take care when 
clicking links or opening attachments.  Use the "Report Message" button to 
report suspicious messages to the NASA SOC.


Jessy,

Trying to remove superfluous intermediate layers in a GPKG dataset.  The 
general logic is

Ds = ogr.open(fp)

I assume you meant ogr.Open(fp, update=True) otherwise you'd got another type 
of error.


Lyr = ds.executesql(query)
Ds.DeleteLayer(idx) <- failed, database table is locked, may be caused by 
“sqlite3_exec(DROP TABLE “rtree_layername_geom”) failed: database table is 
locked

Is layer deletion not supported while a “result set” from a SQL query is on the 
dataset is active?  Perhaps importantly, the query sources the deleted layer.

Yes most likely. Calling ds.ReleaseResultSet(Lyr) before should make things 
work.

You could possibly also try to open the dataset after setting 
gdal.SetConfigOption("OGR_SQLITE_JOURNAL", "WAL") , but I'm not positive at all 
this would avoid this particular issue.
Even

--

http://www.spatialys.com

My software is free, but my time generally not.

Grumpy maintainer.

"De l'égo à l'égoût, il n'y a qu'une bouche mal refermée", André Isaac
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 100: Add support for the float16 data type

[Daniel Baston via gdal-dev]

+1 Dan

On Wed, Jan 29, 2025 at 2:37 PM Kurt Schwehr via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Thanks Even and Erik for the additional work on RFC 100!!
>
> Let's get the voting going again. I hereby change my vote:
>
> +1 KurtS
>
> On Thu, Nov 7, 2024 at 10:24 AM Kurt Schwehr  wrote:
>
>> I vote -1 currently as there hasn't been enough discussion. I just added
>> comments to the RFC PR.
>>
>> On Thu, Nov 7, 2024 at 6:40 AM Erik Schnetter via gdal-dev <
>> gdal-dev@lists.osgeo.org> wrote:
>>
>>> I move to adopt RFC 100 (adding support for the float16 data type).
>>>
>>> The pull request for RFC 100 is here:
>>> https://github.com/OSGeo/gdal/pull/10146 .
>>>
>>> A candidate implementation is here:
>>> https://github.com/OSGeo/gdal/pull/11180 .
>>>
>>> I vote +1.
>>>
>>> -erik
>>>
>>> ___
>>> 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
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 100: Add support for the float16 data type

[Rahkonen Jukka via gdal-dev]

+1

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Erik Schnetter 
via gdal-dev
Lähetetty: torstai 7. marraskuuta 2024 16.40
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Motion: adopt RFC 100: Add support for the float16 data type

I move to adopt RFC 100 (adding support for the float16 data type).
The pull request for RFC 100 is here: https://github.com/OSGeo/gdal/pull/10146 .

A candidate implementation is here: https://github.com/OSGeo/gdal/pull/11180 .

I vote +1.

-erik

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

Re: [gdal-dev] Motion: adopt RFC 100: Add support for the float16 data type

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Wed, 29 Jan 2025 at 20:27, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Thanks Erik for finalizing all that work.
>
> +1 Even
>
> Le 07/11/2024 à 15:39, Erik Schnetter via gdal-dev a écrit :
> > I move to adopt RFC 100 (adding support for the float16 data type).
> >
> > The pull request for RFC 100 is here:
> > https://github.com/OSGeo/gdal/pull/10146 .
> >
> > A candidate implementation is here:
> > https://github.com/OSGeo/gdal/pull/11180 .
> >
> > I vote +1.
> >
> > -erik
> >
> >
> > ___
> > 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.
> Grumpy maintainer.
> "De l'égo à l'égoût, il n'y a qu'une bouche mal refermée", André Isaac
>
> ___
> 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] CSharp bindings queued for removal (was Re: GDAL CSharp bindings maintainers/contributors listening... ?)

[Tamas Szekeres via gdal-dev]

Even,

The silence is not necessary because we neglect the C# bindings, just
because we are doing our daily work (using the bindings).
I'm personally maintaining the GDAL 
and it's related nuget packages based on these bindings for several years
and it has 658.1K downloads overall and 147 downloads per day in average.
The packages are used by projects such as ArduPilot/MissionPlanner,
DotSpatial, SharpMap which are also widely used projects, so we can
consider the importance sigificant, and such change (removing the bindings
entirely) would involve general dissatisfaction against GDAL I think.
In my opinion, we should also distinguish whether an issue reported against
the binding is a blocker or just a nice to have change. In my understanding
the implementation of the UTF-8 to unicode conversion at all relevant
methods would be beneficial, but not something which would block the
overall usage (it has already been done for the most important parts I
think). If the required functionality is really important to someone, I
think he/she will spend some time to contribute it or pay someone to make
it happen.

I also think that the gdal-dev list is not proactively monitored by the
GDAL users (or by the indirect users) well enough, so that we can make such
decisions to remove a binding or a driver nased on that. Whe should
probably find some alternative ways (like surveys or feedback forms at the
site or gather some other statistics like doc page loads and downloads) by
which the community can express their interest against a specific component
and would be sufficient to detect disinterests.

In any case, I'll review and will be trying to to sort out some open issues
against csharp in the next few weeks.

Best regards,

Tamas


Even Rouault via gdal-dev  ezt írta (időpont:
2025. jan. 29., Sze, 5:33):

> Hearing silence, the only logical conclusion is that there is no interest
> ==> https://github.com/OSGeo/gdal/pull/11746
>
> Le 27/09/2024 à 20:15, Even Rouault via gdal-dev a écrit :
>
> Hi,
>
> This is your regular remainder that nobody in the core GDAL maintainer
> team is a CSharp aficionado (we don't have a personal grief against it,
> just that we are blatantly ignorant, at least speaking for myself !), so
> related tickets about it will definitely result in no action.
>
> See
> https://github.com/OSGeo/gdal/issues?q=is%3Aissue+is%3Aopen+label%3A%22csharp+bindings%22
>
> The current trend is that people seem to be annoyed by UTF-8 related
> issues. The issue is likely that our methods that accept or take a const
> char* in the SWIG bindings should use a specific typemap to map to CSharp
> Unicode strings instead of the "C" one or whatever those concepts are
> called in CSharp. There is an existing "utf8_path" typemap that is used in
> method that accept filenames, that should probably be renamed to
> utf8_string and be used more extensively. And probably with a version of
> the methods to also return a raw C string / bytearray in the cases where
> drivers don't know the encoding and might return "random" stuff. Cf pull
> request #10652 where I did something for Java that suffered from that later
> issue.
> Happy pull requests!
>
> Even
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
> ___
> gdal-dev mailing 
> listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
> Grumpy maintainer.
> "De l'égo à l'égoût, il n'y a qu'une bouche mal refermée", André Isaac
>
> ___
> 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] CSharp bindings queued for removal (was Re: GDAL CSharp bindings maintainers/contributors listening... ?)

[Michael Smith via gdal-dev]

Maybe the bindings should be moved out if gdal to a separate repo so those 
interested in the bindings can monitor that specific repo and not gdal in 
general. 

 

Mike

 

 

-- 

Michael Smith

Remote Sensing/GIS Center

US Army Corps of Engineers

 

 

From: gdal-dev  on behalf of Tamas Szekeres 
via gdal-dev 
Reply-To: Tamas Szekeres 
Date: Thursday, January 30, 2025 at 12:41 PM
To: Even Rouault 
Cc: "gdal-dev@lists.osgeo.org" 
Subject: Re: [gdal-dev] CSharp bindings queued for removal (was Re: GDAL CSharp 
bindings maintainers/contributors listening... ?)

 

Even,

 

The silence is not necessary because we neglect the C# bindings, just because 
we are doing our daily work (using the bindings).

I'm personally maintaining the GDAL and it's related nuget packages based on 
these bindings for several years and it has 658.1K downloads overall and 147 
downloads per day in average. The packages are used by projects such as 
ArduPilot/MissionPlanner, DotSpatial, SharpMap which are also widely used 
projects, so we can consider the importance sigificant, and such change 
(removing the bindings entirely) would involve general dissatisfaction against 
GDAL I think. 

In my opinion, we should also distinguish whether an issue reported against the 
binding is a blocker or just a nice to have change. In my understanding the 
implementation of the UTF-8 to unicode conversion at all relevant methods would 
be beneficial, but not something which would block the overall usage (it has 
already been done for the most important parts I think). If the required 
functionality is really important to someone, I think he/she will spend some 
time to contribute it or pay someone to make it happen.

 

I also think that the gdal-dev list is not proactively monitored by the GDAL 
users (or by the indirect users) well enough, so that we can make such 
decisions to remove a binding or a driver nased on that. Whe should probably 
find some alternative ways (like surveys or feedback forms at the site or 
gather some other statistics like doc page loads and downloads) by which the 
community can express their interest against a specific component and would be 
sufficient to detect disinterests.

 

In any case, I'll review and will be trying to to sort out some open issues 
against csharp in the next few weeks.

 

Best regards,

 

Tamas

 

 

Even Rouault via gdal-dev  ezt írta (időpont: 2025. 
jan. 29., Sze, 5:33):

Hearing silence, the only logical conclusion is that there is no interest ==> 
https://github.com/OSGeo/gdal/pull/11746

 

Le 27/09/2024 à 20:15, Even Rouault via gdal-dev a écrit :

Hi,

This is your regular remainder that nobody in the core GDAL maintainer team is 
a CSharp aficionado (we don't have a personal grief against it, just that we 
are blatantly ignorant, at least speaking for myself !), so related tickets 
about it will definitely result in no action. 

See 
https://github.com/OSGeo/gdal/issues?q=is%3Aissue+is%3Aopen+label%3A%22csharp+bindings%22

The current trend is that people seem to be annoyed by UTF-8 related issues. 
The issue is likely that our methods that accept or take a const char* in the 
SWIG bindings should use a specific typemap to map to CSharp Unicode strings 
instead of the "C" one or whatever those concepts are called in CSharp. There 
is an existing "utf8_path" typemap that is used in method that accept 
filenames, that should probably be renamed to utf8_string and be used more 
extensively. And probably with a version of the methods to also return a raw C 
string / bytearray in the cases where drivers don't know the encoding and might 
return "random" stuff. Cf pull request #10652 where I did something for Java 
that suffered from that later issue.

Happy pull requests! 

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
-- 
http://www.spatialys.com
My software is free, but my time generally not.
Grumpy maintainer.
"De l'égo à l'égoût, il n'y a qu'une bouche mal refermée", André Isaac
___
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 

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

[gdal-dev] ds.DeleteLayer(idx) "failed: database table is locked"

[Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] via gdal-dev]

Hi,

Trying to remove superfluous intermediate layers in a GPKG dataset.  The 
general logic is

Ds = ogr.open(fp)
Lyr = ds.executesql(query)
Ds.DeleteLayer(idx) <- failed, database table is locked, may be caused by 
“sqlite3_exec(DROP TABLE “rtree_layername_geom”) failed: database table is 
locked

Is layer deletion not supported while a “result set” from a SQL query is on the 
dataset is active?  Perhaps importantly, the query sources the deleted layer.

GDAL v3.9.3

Best,
Jesse

Lead Computer Scientist
Science Systems and Applications, Inc.
Dr Compton Tucker Team
NASA Goddard Space Flight Center
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ds.DeleteLayer(idx) "failed: database table is locked"

[Even Rouault via gdal-dev]

Jessy,


Trying to remove superfluous intermediate layers in a GPKG dataset.  
The general logic is


Ds = ogr.open(fp)

I assume you meant ogr.Open(fp, update=True) otherwise you'd got another 
type of error.




Lyr = ds.executesql(query)

Ds.DeleteLayer(idx) <- failed, database table is locked, may be caused 
by “sqlite3_exec(DROP TABLE “rtree_layername_geom”) failed: database 
table is locked


Is layer deletion not supported while a “result set” from a SQL query 
is on the dataset is active? Perhaps importantly, the query sources 
the deleted layer.


Yes most likely. Calling ds.ReleaseResultSet(Lyr) before should make 
things work.


You could possibly also try to open the dataset after setting 
gdal.SetConfigOption("OGR_SQLITE_JOURNAL", "WAL") , but I'm not positive 
at all this would avoid this particular issue.


Even

--
http://www.spatialys.com
My software is free, but my time generally not.
Grumpy maintainer.
"De l'égo à l'égoût, il n'y a qu'une bouche mal refermée", André Isaac
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] adding points to geometries

[Javier Jimenez Shaw via gdal-dev]

Hey Scott

You gave me an idea: cut first with a region on the north hemisphere and
then the south.
The circle does not work as expected. In EPSG:4326 you need a rectangle.
First I created different entries, adding 1 to the fid to avoid
collisions.
But later I decided to just "st_collect" the polygons in a single
multipolygon (per entry). The final sql is like this:

select
fid, name, iso_a2, iso_a3
,coalesce(
st_collect(
st_intersection(
ST_GeomFromText('MULTIPOLYGON(((-180 90, -180 0, 180 0, 180
90, -180 90)))'),
geom),
st_intersection(
ST_GeomFromText('MULTIPOLYGON(((-180 -90, -180 0, 180 0,
180 -90, -180 -90)))'),
geom)
),
geom) as geom
from countries

Thank you.


On Sun, 26 Jan 2025 at 17:33, Scott via gdal-dev 
wrote:

> Hey Javier,
>
> Maybe create 2 geometries, southern and northern hemisphere, then do an
> intersection of both with your source geometries. You would have to
> create new fid as the new geom's would the same fid. Untested, something
> like this:
>
> ogr2ogr -dialect sqlite -sql @newGeom.sql target.gpkg source.gpkg
>
> newGeom.sql
>
> select
> r.fid
> ,r.geom
> from (
> select
>fid
>,st_intersection(MakeCircle(0, 90, 4326, .001), geom) as geom
> from mygeoms
>
> union all
>
> select
>fid
>,st_intersection(MakeCircle(0, -90, 4326, .001), geom) as geom
> from mygeoms
> ) r
>
> Hope that helps,
> Scott
>
> On 1/26/25 02:14, Javier Jimenez Shaw via gdal-dev wrote:
> > Hi
> >
> > I have a vector layer (like /usr/share/qgis/resources/data/
> > world_map.gpkg) and I need to add a point at latitude 0 for every
> > segment (in line or polygon) that crosses the equator.
> >
> > How can I do it?
> >
> > Thanks,
> > Javier.
> >
> > ___
> > 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
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev