Re: [gdal-dev] CSharp bindings queued for removal (was Re: GDAL CSharp bindings maintainers/contributors listening... ?)

[Paul Harwood via gdal-dev]

I think it more reflects this thread
https://lists.osgeo.org/pipermail/gdal-dev/2021-April/053868.html

On Wed, 29 Jan 2025 at 09:11, Rahkonen Jukka <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> The named maintainer thing may reflect this thread Re: [gdal-dev] C#
> bindings compilation
> 
> from 2021.
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gdal-dev  *Puolesta *Paul
> Harwood via gdal-dev
> *Lähetetty:* keskiviikko 29. tammikuuta 2025 10.14
> *Vastaanottaja:* Even Rouault 
> *Kopio:* gdal-dev 
> *Aihe:* Re: [gdal-dev] CSharp bindings queued for removal (was Re: GDAL
> CSharp bindings maintainers/contributors listening... ?)
>
>
>
> It seems to be a hyper aggressive move to go from a highly technical
> question about UTF-8 to "remove C# totally".
>
>
>
> If the question is "We need a named maintainer for C# or we remove it"
> then I will step forward since I have an app that depends on it. However, I
> don't feel competent enough in SWIG to address detailed changes such as
> UTF-8 without help.
>
>
>
> I seem to remember saying the same thing a few years ago and did not even
> get an acknowledgement that I had responded.
>
>
>
> Paul
>
>
>
> On Wed, 29 Jan 2025, 04:32 Even Rouault via gdal-dev, <
> gdal-dev@lists.osgeo.org> wrote:
>
> 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

Re: [gdal-dev] CSharp bindings queued for removal (was Re: GDAL CSharp bindings maintainers/contributors listening... ?)

[Paul Harwood via gdal-dev]

It seems to be a hyper aggressive move to go from a highly technical
question about UTF-8 to "remove C# totally".

If the question is "We need a named maintainer for C# or we remove it" then
I will step forward since I have an app that depends on it. However, I
don't feel competent enough in SWIG to address detailed changes such as
UTF-8 without help.

I seem to remember saying the same thing a few years ago and did not even
get an acknowledgement that I had responded.

Paul

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

> 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... ?)

[Rahkonen Jukka via gdal-dev]

Hi,

The named maintainer thing may reflect this thread Re: [gdal-dev] C# bindings 
compilation
 from 2021.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Paul Harwood 
via gdal-dev
Lähetetty: keskiviikko 29. tammikuuta 2025 10.14
Vastaanottaja: Even Rouault 
Kopio: gdal-dev 
Aihe: Re: [gdal-dev] CSharp bindings queued for removal (was Re: GDAL CSharp 
bindings maintainers/contributors listening... ?)

It seems to be a hyper aggressive move to go from a highly technical question 
about UTF-8 to "remove C# totally".

If the question is "We need a named maintainer for C# or we remove it" then I 
will step forward since I have an app that depends on it. However, I don't feel 
competent enough in SWIG to address detailed changes such as UTF-8 without help.

I seem to remember saying the same thing a few years ago and did not even get 
an acknowledgement that I had responded.

Paul

On Wed, 29 Jan 2025, 04:32 Even Rouault via gdal-dev, 
mailto:gdal-dev@lists.osgeo.org>> wrote:

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] Approval of github requests now enabled

[Even Rouault via gdal-dev]

Hi,

I've disabled the rights for contributors with github merge requests to 
auto-approve their own.


Straight translation: "someone" from the "community" will have to 
approve or disapprove my pull requests, or they will sit in the limbo, 
as they should.


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 RFC106: Metadata items to reflect driver update capabilities

[Even Rouault via gdal-dev]

Motion passed with +1 from PSC members JavierJS, JukkaR, SeanG and me 
(and community member Andrew Aitchison)


Even

Le 27/01/2025 à 10:24, Even Rouault via gdal-dev a écrit :

Hi,

The RFC text has been adjusted to reflect the candidate implementation 
which is now ready


Motion: Adopt RFC106: Metadata items to reflect driver update 
capabilities (https://github.com/OSGeo/gdal/pull/11708)


Starting with my +1,

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

[Even Rouault via gdal-dev]

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

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

[Kurt Schwehr via gdal-dev]

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] gdal2tiles error with exclude and vsigs

[Martin Ewart via gdal-dev]

Hi,

I'm just reporting an error with gdal2tiles when running with the --exclude
argument and with the output directory being set to a google bucket using
/vsigs/.
It appears that the absence of a blank tile causes the upload to fail. The
command works fine without --exclude. Full error below the mail.

Thanks,

Martin


Version
GDAL 3.10.1, released 2025/01/08

Error:
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
  File "/usr/lib/python3.12/multiprocessing/pool.py", line 125, in worker
result = (True, func(*args, **kwds))
^^^
  File "/usr/lib/python3.12/site-packages/osgeo_utils/gdal2tiles.py", line
1574, in create_overview_tile
if not isfile(base_tile_path):
   ^^
  File "/usr/lib/python3.12/site-packages/osgeo_utils/gdal2tiles.py", line
95, in isfile
return stat.S_ISREG(stat_res.mode)
^
AttributeError: 'NoneType' object has no attribute 'mode'
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/bin/gdal2tiles", line 33, in 
sys.exit(load_entry_point('GDAL==3.10.1', 'console_scripts',
'gdal2tiles')())

 ^^^
  File "/usr/lib/python3.12/site-packages/osgeo_utils/gdal2tiles.py", line
4676, in main
return submain(argv, called_from_main=called_from_main)
   
  File "/usr/lib/python3.12/site-packages/osgeo_utils/auxiliary/util.py",
line 46, in enable_exceptions_wrapper
return fun(*args, **kwargs)
   
  File "/usr/lib/python3.12/site-packages/osgeo_utils/gdal2tiles.py", line
4706, in submain
multi_threaded_tiling(input_file, output_folder, options, pool)
  File "/usr/lib/python3.12/site-packages/osgeo_utils/auxiliary/util.py",
line 46, in enable_exceptions_wrapper
return fun(*args, **kwargs)
   
  File "/usr/lib/python3.12/site-packages/osgeo_utils/gdal2tiles.py", line
4618, in multi_threaded_tiling
for _ in pool.imap_unordered(
 
  File "/usr/lib/python3.12/multiprocessing/pool.py", line 873, in next
raise value
AttributeError: 'NoneType' object has no attribute 'mode'
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev