I experience the same with GDAL and other OSGeo mailing lists. The
delay in receiving a message can be as much as two days, and messages
often arrive out-of-sequence. Other times things happen more or less
instantaneously.
Folks spent some time investigating the issue with the geos-devel list
but
+1 Dan
On Wed, May 7, 2025 at 3:25 PM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> +1 Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
>
Hi Andrew,
Some ideas are discussed in this thread:
https://lists.osgeo.org/pipermail/gdal-dev/2024-August/059331.html
I wish it were easier.
Dan
On Fri, May 2, 2025 at 11:11 AM Andrew Bell via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Hi,
>
> Is there an easy way to search the archives of
Hi Rich,
This is a bug -- the "read" step does not exclusively pass GDAL_OF_VECTOR
to GDALOpen, so it attempts to read raster layers from the input. I've made
one possible fix at https://github.com/OSGeo/gdal/pull/12203.
Dan
On Sat, Apr 26, 2025 at 2:14 PM Richard Greenwood via gdal-dev <
gdal-d
Hi Rich,
Thanks for testing this. I think a pipeline works well here:
gdal vector pipeline read tl_2024_us_state.shp ! select
"STUSPS,NAME,_ogr_geometry_" ! geom set-type --multi ! write "PG:$PGCONN"
--lco GEOMETRY_NAME=geom
Dan
On Fri, Apr 25, 2025 at 7:35 PM Richard Greenwood via gdal-dev <
Sean,
Can you post to the PR or create an issue that explains the problem? I'm
generally not in favor of GDAL ignoring invalid user inputs, because in my
experience they lead to difficult-to-track errors in user code.
Dan
On Sun, Apr 20, 2025 at 9:42 PM Sean Gillies via gdal-dev <
gdal-dev@lists
Thanks for the explanation. I'm +1 on pro subscriptions for GDAL and PROJ.
The extra number of runners (6 in pro vs 2 in the current plan) will also
be helpful for GDAL.
Dan
On Thu, Apr 17, 2025 at 4:30 PM Howard Butler wrote:
>
>
> > On Apr 17, 2025, at 2:10 PM, Daniel Baston wrote:
> >
> > H
Hi Howard,
I agree that RTD is useful for our project. Given the recent funding for
two documentation contributors, the pull request previews that RTD provides
will be especially helpful.
Still, I'd argue the project most essential for our docs is Sphinx itself.
Do you know if/how dollars sent to
+1
Dan
On Wed, Mar 12, 2025 at 9:15 AM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Hi,
>
> Seth Girvin (https://github.com/geographika) and Harrissou Sant-anna
> (DelazJ) are interested in contributing improvements to the GDAL
> documentation, one of the most recurring item whe
+1 Dan
On Mon, Mar 3, 2025 at 11:30 AM Daniel Morissette via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Hi PSC members,
>
> I would like to nominate Michael Smith to become a member of the GDAL
> Project Steering Committee.
>
>https://www.osgeo.org/member/michael-smith/
>
> Mike is a long
Simon,
Setting the NoData value of your mask band to 255 instead of 0 should cause
pixels not covered by a mask tile to be considered valid.
Dan
On Mon, Feb 24, 2025 at 2:37 PM Simon Wright via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Dear subscribers
>
> I'm exploring the use of a VRT to
-0 Dan
On Wed, Feb 19, 2025 at 5:24 AM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Motion: adopt RFC 108
>
> +1 Even
>
> Le 18/02/2025 à 18:28, Even Rouault via gdal-dev a écrit :
> > "Formalizing" recent discussions:
> > https://github.com/OSGeo/gdal/pull/11862
> >
> --
> http
>
> Any preliminary documentation on this?
>
Preliminary, yes:
https://gdal--11850.org.readthedocs.build/en/11850/programs/gdal_raster_calc.html
(from https://github.com/OSGeo/gdal/pull/11850)
Dan
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https
Hi Abdul,
For the specific case of multiple rasters that share the same extent, the
next release of GDAL should have a replacement "gdal_calc" that would take
multiple inputs and write a VRT that applies an expression to those inputs
("max", in your case). In the meantime, I think your best option
+1 Dan
On Mon, Feb 10, 2025 at 3:27 PM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Hi,
>
> I move to adopt RFC 107
>
> Starting with my +1
>
> Even
>
> Le 06/02/2025 à 22:19, Even Rouault via gdal-dev a écrit :
> > Hi,
> >
> > Please review https://github.com/OSGeo/gdal/pull/11
Hi Parveen,
test_ecw_7 is run (successfully) in the Ubuntu 20.04 configuration:
https://github.com/OSGeo/gdal/actions/runs/13092743556/job/36531334565#step:18:4258
I'm pretty sure this is the only workflow that has ECW available. Some ECW
tests are still skipped because they require a newer versi
+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:
>
>>
+1 Dan
On Wed, Jan 15, 2025 at 10:13 AM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Hi,
>
> The candidate implementation is now ready (I'm afraid nobody will find the
> energy to review the ~ 4000 different edits throughout the code base... )
> and all CI targets are green. *Al
+1 Dan
On Thu, Jan 9, 2025 at 7:14 AM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Hi,
>
> Motion: approve GDAL 3.10.1 RC2 as 3.10.1 release
>
> Starting with my +1
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
> Butcher of all kind
Yes, this works (with a directory name of "autotest").
On Thu, Jan 9, 2025 at 2:24 PM Even Rouault
wrote:
>
> Le 09/01/2025 à 20:08, Daniel Baston a écrit :
> > It looks like the packaged gdalautotest snapshot does not include a
> > pytest.ini, which causes many warnings to be generated
> > (Pyt
It looks like the packaged gdalautotest snapshot does not include a
pytest.ini, which causes many warnings to be generated
(PytestUnknownMarkWarning) and also some collection errors such as this
one.
― ERROR collecting
gdrivers/data/s104/generate_tes
+1
Dan
On Thu, Jan 2, 2025 at 9:54 AM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Hi,
>
> Happy New Year to everyone!
>
> PSC,
>
> GDAL depends on conda-forge builds for a number of its continuous
> integration configurations, as well as offering builds of the master
> branch
Thank you!
Dan
On Wed, Dec 11, 2024 at 10:54 AM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Motion passed with +1 from PSC members JavierJS, JukkaR, HowardB,
> FrankW, DanielM and me
>
> Dan, welcome on board!
>
> Le 09/12/2024 à 15:10, Even Rouault via gdal-dev a écrit :
> >
+1
Dan
On Thu, Sep 19, 2024 at 3:34 PM Javier Jimenez Shaw via gdal-dev
wrote:
>
> I agree
>
> On Thu, 19 Sept 2024, 20:35 Even Rouault via gdal-dev,
> wrote:
>>
>> Hi,
>>
>> I suggest we complete remove the content from
>> https://trac.osgeo.org/gdal/wiki. At this point, it is totally outdate
Hi Even,
Thanks for the suggestions. I've played around with it a bit more
without much success.
> No you didn't do anything obviously wrong. I'm not sure that in the
> ArrowDataset mode libarrow actually uses group statistics to filter out
> row groups, which might cause it to actually ingest th
Hello,
I'm trying to use ogr2ogr with an attribute filter to pull 14 polygons
from Overture maps. Running the following command with CPL_DEBUG=ON
tells me that "PARQUET: Attribute filter fully translated to Arrow"
yet it takes about 7 minutes to complete, and appears to download
quite a bit of dat
> From what I see, robots.txt is automatically configured for the default
> version:
> https://docs.readthedocs.io/en/stable/reference/robots.html
I read this as saying that the robots.txt published by the default
branch will be served from the top level of the domain
(https://proj.org/robots.txt
Thanks, Rob. I've added a robots.txt to the PR (using /en/latest/,
since /en/stable/ is not yet published)
Dan
On Wed, Jul 24, 2024 at 7:44 AM Robert Coup via gdal-dev
wrote:
>
> On Wed, 24 Jul 2024 at 12:27, Even Rouault wrote:
> >
> >
> > Le 24/07/2024 à 12:33, Javier Jimenez Shaw via gdal-de
> Could a random user easily check
> out the docs repo and (with 100% open source tooling) generate the
> docs?
Yes, we are currently and would continue to use Sphinx for the
documentation build.
Dan
On Tue, Jul 23, 2024 at 1:18 PM Greg Troxel via gdal-dev
wrote:
>
> Daniel
Hello,
I've put together a configuration to build GDAL's documentation using
ReadTheDocs. As far as I know, this is the simplest way of publishing
version-specific documentation and rending documentation for pull
requests. A current build of the documentation can be viewed at
https://gdal.readthed
If a single MULTIPOINT record is OK, then you can do
ogrinfo test.shp -q -dialect SQLITE -sql 'SELECT
ST_DissolvePoints(GEOMETRY) FROM test'
Dan
On Thu, May 30, 2024 at 8:49 PM Dan Jacobson via gdal-dev
wrote:
>
> $ ogrinfo 0.lines.kml -q -dialect SQLITE -sql \
> 'SELECT ST_PointN(GEOMETRY, ge
It looks like Doxygen is using argument names from the function prototype
instead of the implementation:
https://github.com/OSGeo/gdal/blob/master/gcore/gdal_priv.h#L753
I did some searching but didn't come across a way to change this behavior.
It looks like many other functions include the argume
Perhaps a Sphinx substitution could be made with the relevant text and
added to
https://github.com/OSGeo/gdal/blob/master/doc/source/substitutions.rst
Dan
On Wed, Mar 27, 2024 at 5:01 PM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Salut Thomas,
>
> There's a tension between be
33 matches
Mail list logo
