Rasterio's tests are broken by changes coming in GDAL 3.11.0, but for known
and understood reasons. I'm fine with the release.
On Wed, May 7, 2025 at 10:05 AM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> +1 Even
&
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.osgeo.org> wrote:
>
>> Hi Even, Dan, and everyone,
>>
>> https://github.c
ps://download.osgeo.org/gdal/3.11.0/gdal3110beta1.zip
>
> Autotest snapshots:
>
> - https://download.osgeo.org/gdal/3.11.0/gdalautotest-3.11.0beta1.tar.gz
> - https://download.osgeo.org/gdal/3.11.0/gdalautotest-3.11.0beta1.zip
>
> Even
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
RTD is indispensable! +1 ftom me.
Sean Gillies
On Thu, Apr 17, 2025, 10:39 AM Howard Butler via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Dear PSC,
>
> GDAL and PROJ depend upon ReadTheDocs for documentation generation and
> hosting. RTD does not charge for open sourc
of GDAL as a dependency. I was considering creating an Anaconda
> package in a Linux environment (maybe using a virtual machine) and then a
> Mac environment so that I can have this package available on all operating
> systems. I was curious to see if anyone knows more about th
ip program and the
> NumFocus relationship and take some of this operational work off
> Howard's shoulders.
>
> I start with my +1
>
> Daniel
>
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
essing /vsis3/your-bucket/test/input.vrt [1/1] : 0ERROR 4:
>>> `/vsis3/your-bucket/test/input2.tif' does not exist in the file system, and
>>> is not recognized as a supported dataset name.
>>>
>>> But with -multi, notice the progress goes to 100%:
>>
he gdalautotest suite is also available:
>
> https://download.osgeo.org/gdal/3.10.1/gdalautotest-3.10.1rc1.tar.gz
> https://download.osgeo.org/gdal/3.10.1/gdalautotest-3.10.1rc1.zip
>
> The NEWS file is here:
>
>https://github.com/OSGeo/gdal/blob/v3.10
ally not.
> Butcher of all kinds of standards, open or closed formats. At the end,
> this is just about bytes.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
osgeo.org>
> *Aihe:* Re: [gdal-dev] Issue with the STACIT usage examples
>
>
>
>
>
>
>
> However, the subdataset names on the list are not accepted as-is without
> small edits.
> Does not work:
> gdalinfo STACIT:
> "https://paituli.csc.fi/geoserver/ogc/st
__
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
: fix compatibility issue with SWIG 4.3.0 and
> PYTHONWARNINGS=error
>
> Best regards,
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
> Butcher of all kinds of standards, open or closed formats. At the end,
> this is
OGR drivers will use some
> defaults, that might not always be appropriate.
>
> Even
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
precision. Neither
do, for example, Parquet and Arrow.
Anybody using these for anything crucial?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
is that people create it
> using software with none of the familiar GIS constraints.
>
> I've been looking at a collection of features that have the same set of
> properties (good), but one of the properties has a mix of strings (strings
> of digits, specifically) and
ntended behavior? Will
all such fields be found to be "String(JSON)", or does it depend on their
content?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi all,
In theory, we can read anything from a zip archive without extracting it to
the filesystem, but sometimes drivers have special requirements and
limitations. Is JP2 from a zipfile supported by OpenJPEG?
--
Sean Gillies
___
gdal-dev mailing list
Absolutely yes +1
On Wed, Sep 11, 2024, 8:24 PM Howard Butler via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> PSC,
>
> I am motioning to renew Even's maintainer contract through the GDAL
> Sponsorship Program that is hosted by NumFOCUS for another year.
>
> /me starts with a +1
>
> Howard
> ___
> 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
Hi Sibylle,
It looks to me that you need to specify an environment location within your
own user directory. The page at
https://conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html#specifying-a-location-for-an-environment
has instructions on this.
Yours,
On Tue, Aug 6, 20
say that I see a change in GDAL.
>
> ok, this is related to https://github.com/OSGeo/gdal/pull/9336 , which
> indeed wasn't honoring the SRC_METHOD=NO_GEOTRANSFORM and was using
> directly the geotransform from the source dataset.
>
> Fix queued in https://github.com/OSGeo/gdal/p
Thanks, Jukka!
On Mon, Apr 22, 2024 at 10:48 AM Rahkonen Jukka <
jukka.rahko...@maanmittauslaitos.fi> wrote:
> Hi,
>
>
>
> The mask thing may happen due to https://github.com/OSGeo/gdal/pull/9604.
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gda
l380beta1.zip
>
> Autotest snapshots:
>
> - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz
> - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip
>
> Even
>
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
wrote:
>
> Le 19/04/2024 à 17:28, Sean Gillies a écrit :
>
> Even,
>
> Does the shared attribute of a VRT sourceFilename element not affect
> caching at all?
>
> If shared is set to 0, then one GDALDataset per VRTSource will be opened.
> This has little benefit.
>
n filenames, not VSIFILE* instances, so you will save network reads
>
> Even
> Le 19/04/2024 à 16:48, Sean Gillies via gdal-dev a écrit :
>
> Happy Friday, folks!
>
> Are the source rasters of a VRT added to the block cache such that
> different VRTs using the same source can
Happy Friday, folks!
Are the source rasters of a VRT added to the block cache such that
different VRTs using the same source can avoid reads from disk or the
network? Or is it intended that the VSI cache covers this need instead?
Thanks,
--
Sean Gillies
ted sources
>
> - if you do so, prefer doing that on dedicated workstations that don't
> have access to sensitive information
>
> - you may reduce your potential exposure by disabling at build time
> optional dependencies you don't need.
>
> Even
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
havior of the system. It
would be hard to figure it out just by reading the code.
On Fri, Feb 16, 2024 at 8:29 AM Sean Gillies wrote:
> Thanks for the tip, Thomas!
>
> On Thu, Feb 15, 2024 at 9:45 AM thomas bonfort
> wrote:
>
>> Hi Sean,
>> I believe/recall this i
t Readdir() (which might break drivers
> that require sidecar files to work, but speeds up those where sidecar files
> are optional and not used in a cloud-storage environment (namely cogs) )
>
> On Tue, Feb 13, 2024 at 6:12 PM Sean Gillies via gdal-dev <
> gdal-dev@lists.osgeo.org
More specifically: if I have a "/vsipyopener/foo.tif" object, do drivers
always look for other files at paths precisely relative to that one? Does
this vary among drivers?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi all,
I haven't found a specification for the empty pixel value of datasets
created by, say, gdal_create. Is it format specific?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Happy New Year to you too, Abel.
Other drivers, such as PCI and NITF, include some files in the data
directory. See https://github.com/OSGeo/gdal/tree/master/data.
Distributions generally copy these to $prefix/share/gdal on unix-like
systems. I'm not aware of a practice of copying data out of a
Hi Even,
I'm wondering how this relates to STAC. Do you imagine that GDAL users
should and will use this to publish large collections of data? When should
they use this and when should they use STAC collections instead?
Back in the day our tile indexes were shapefiles. I don't think this would
be
is quite cumbersome to deal with our setup.py's
>>> setuptools . All details (a bit tricky) in
>>> https://github.com/OSGeo/gdal/issues/8069 . It seems it would be
>>> simpler
>>> if the bindings just required numpy, which is the confugration most
>>> people using the bindings likely actually end up using anyway.
>>>
>>> Any opposition to that?
>>>
>>> Even
>>>
>>>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
ys.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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
27;m not familiar at all with the wheel Python packaging tools, but if
> you'd want to have GDAL plugins in separate package(s) then you'd need
> to have a way of having the gdal_XXX.so / ogr_XXX.so be put in some
> known location that can be advertized to libgdal core with
>
ts.osgeo.org> wrote:
> Hi,
>
> Motion: adopt RFC 96: Deferred C++ plugin loading
>
> https://github.com/OSGeo/gdal/pull/8648
>
> Pre-rendered view:
>
>
> https://github.com/rouault/gdal/blob/rfc96_text/doc/source/development/rfc/rfc96_deferred_plu
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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
.8.0beta1.zip
>
> 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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
ithub.com/OSGeo/gdal/pull/8561
>>
>> The issue is particularly visible on Windows, or more generally any
>> operating system (or file system where the output file is located) which
>> has no VSIVirtualHandle::PRead() implementation, but it can also be
>> occasionally rep
>
> * OSGeo 2023 Community Sprint will be held in Vienna, Austria November
> 6-9th, 2023. https://wiki.osgeo.org/wiki/OSGeo_Community_Sprint_2023 GDAL
> PSC members seeking travel support should contact Howard Butler privately
> to coordinate.
>
> Next Meeting
> -
ions in
> regards to GDAL maintainers:
>
> * Authorize Alessandro Pasotti for up to 30 hrs/month with a rate increase
> of 10 euros/hr until 30 NOV 2024.
> * Authorize Even Rouault for up to 90 hrs/month with a rate increase of 10
> $/hr until
re if we'd want
>> > to make gdaltransform follow cs2cs (possibly with a
>> > --axis-order=gis_friendly/authority_compliant explicit flag)
>> >
>> > Maybe some 'Ex' (which stands for API) functions in the C API could be
>> > removed and thei
system, with deep knowledge
>> > of CRS topics and PROJ (I've also nominated him for PROJ membership),
>> > contributing to PDAL as well. As part of his job, he's involved in
>> > orthomosaic/raster generation ou
removed and their extra/modified arguments reincorporated with the
> > original non-Ex function. Would totally make sense for the few ones
> > impacted by RFC95 like GDALGetDefaultHistogramEx,
> > GDALSetDefaultHistogramEx, GDALGetRasterHistogramEx
> >
> > There might
Hi Alessandro,
On Fri, Sep 15, 2023 at 8:31 AM ElPaso wrote:
> Il 14/09/23 17:14, Sean Gillies ha scritto:
> > Hi all,
> >
> > In https://github.com/OSGeo/gdal/pull/8155#issuecomment-1704923263 I
> > think I see (for the first time?) the beginning of a specification
:{filename}
> GPKG:{filename}:{tablename}
> netCDF:{filename}:{variable_name}
> HDF5:{filename}:{dataset_path}
> ZARR:{filename} (mostly when filename is /vsicurl/ and we don't have a
> ReadDirectory() API)
> ZARR:{filename}:{path_to_array}
>
> ZARR:{filename}:{path_to_
format drivers don't have to
create their own new idiosyncratic file names.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Enthusiastic +1 from me
On Tue, Sep 12, 2023, 1:22 PM Howard Butler wrote:
> Dear PSC,
>
> Dan Baston is an active GDAL maintainer who does not currently have merge
> rights. Let's fix that so he can get more work done without waiting on
> someone to merge things up :)
>
> /me starts with +1
>
>
; improve the current error message with a hint for the reason for the error
>> and the (likely) reason for it to happen.
>>
>> I've also added pointers in the doc page to the CMakeLists.txt files
>> where the dependencies are expressed. Hopefully people who are in the
siness of
> making custom GDAL builds can make sense of that.
>
> Even
> Le 20/05/2023 à 01:26, Sean Gillies a écrit :
>
> Hi all,
>
> I really appreciate the documentation at
> https://gdal.org/development/building_from_source.html. But there are
> gaps. For exampl
a driver's dependencies to be enabled when I enable a
driver?
If not, can we consider using GDAL maintenance funding and resources on
documenting the heck out of this system?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.
Hi Jon,
The number one gotcha with patching is documented here
https://docs.python.org/3/library/unittest.mock.html#where-to-patch. In a
nutshell, you have to patch your own module. I see you're patching gdal in
your tests. Patching gdal from your test doesn't do anything, it's too
late.
Hope thi
t offers much performance benefit.
>
> Dan
>
> [1] https://lists.osgeo.org/pipermail/gdal-dev/2022-February/055433.html
> _______
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
refactor it.
>
> I've tried to enhance the existing documentation page related to tests
> with recommendations from this email thread and other things from related
> RFCs: https://github.com/OSGeo/gdal/pull/7277
>
> Even
> Le 20/02/2023 à 16:42, Sean Gillies a écrit :
of old tests, but I think it is worth adopting a
better practice for tests now and in the future.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
;>
>> This is something I wanted to at least experiment. I've mixed feelings
>> if it's something we actually want to adopt.
>>
>> Even
>>
>> --
>> http://www.spatialys.com
>> My software is free, but my time generall
but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
DALDataset::Close() method" is
>> available for review in https://github.com/OSGeo/gdal/pull/7108
>>
>> Admittedly, nothing particularly exciting, but this should provide GDAL
>> users with better error detection.
>>
>> Even
>>
>> --
>&
ess to compressed raster data:
>
> https://github.com/OSGeo/gdal/pull/7020
>
> Starting with my +1
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mail
No objection from me!
On Tue, Dec 13, 2022, 8:19 AM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Hi,
>
> https://github.com/qgis/QGIS/issues/51188 has been brought to my
> attention. The issue is that the new background building of the RTree of
> GeoPackage files introduced in
dal/pull/6633#issuecomment-1307736762>, or
>> unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AAAIHIKG7X65SX4OULJMUFTWHKT5TANCNFSM6AAR2E6MJY>
>> .
>> You are receiving this because you commented.Message ID:
>>
>>
>
>
> --
> Sean
gt; <https://github.com/OSGeo/gdal/pull/6633#issuecomment-1307736762>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAAIHIKG7X65SX4OULJMUFTWHKT5TANCNFSM6AAR2E6MJY>
> .
> You are receiving this beca
Hi,
Another approach, also involving a copy, is to read the raster data as
numpy arrays and compute the statistics of those arrays. The GDAL method
also has to read the raster data to compute statistics, of course, but
doesn't store the entirety of it in memory.
On Mon, Oct 10, 2022, 6:51 AM Lau
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
lpful when it is about
> corrupted data. e.g if you parse WKB geometries there are tons of potential
> error situations, and emitting a specific error for each one would require
> a lot of coding effort, would bloat the code base & the size of the GDAL
> binary.
>
That makes sense.
Given all this, I think I'll modify my error recording approach to also use
the return values of functions. The combination of errors and return values
will be enough information to determine whether rasterio should raise a
Python exception.
Thanks!
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
;s C API:
https://docs.python.org/3/c-api/exceptions.html#exception-handling (I feel
like GDAL could use some documentation like this).
* Python exception chaining:
https://docs.python.org/3/tutorial/errors.html#exception-chaining
* On the difference between an exception raised while handling and "raise
from":
https://blog.ram.rachum.com/post/621791438475296768/improving-python-exception-chaining-with
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
+1
-- Forwarded message -
From: Sean Gillies
Date: Thu, May 12, 2022 at 10:52 AM
Subject: Re: [gdal-dev] Motion: adopt GDAL 3.5.0RC4 as final 3.5.0 release
To: Even Rouault
+1
Great work, everybody! And thank you for the build support.
On Wed, May 11, 2022 at 3:36 AM Even
Explicitly setting rpath in LDFLAGS solved my PROJ 9 problem. This feels
like a regression. It isn't necessary for Linux and wasn't necessary for
autotools builds of PROJ 8.2.1.
Back on topic: GDAL 3.5.0rc4 seems fine.
On Tue, May 10, 2022, 4:18 PM Sean Gillies wrote:
> Thanks
ting with a PROJ 8.2.1 autoconf build) ? I don't
>> know... Mac + rpath is hostile territory for me.
>>
>> Does running a GDAL binary, like gdalinfo, works before using that
>> delocate module ?
>>
>> Yes 5413 is CMake specific.
>>
>> Even
>>
ing a GDAL binary, like gdalinfo, works before using that
> delocate module ?
>
> Yes 5413 is CMake specific.
>
> Even
> Le 10/05/2022 à 23:02, Sean Gillies a écrit :.
>
> Hi Even,
>
> I'm running into a problem with GDAL 3.5.0rc4 and PROJ 9.0.0 on macos. It
>
; are reported before.
> >
> > The "release/3.5" branch has been created for all bug fixes related to
> > 3.5.x. master is now targetting 3.6.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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
o.org/gdal/3.5.0/gdal-3.5.0rc3.tar.xz
>https://download.osgeo.org/gdal/3.5.0/gdal-3.5.0rc3.tar.gz
>https://download.osgeo.org/gdal/3.5.0/gdal350rc3.zip
>
> Even
> Le 09/05/2022 à 20:47, Sean Gillies a écrit :
>
> Hi Even,
>
> I'm still using the legacy configure scr
> https://download.osgeo.org/gdal/3.5.0/gdal350doc.zip
> >
> > The GDAL-GRASS plugin sources and release process has been moved to
> > https://github.com/OSGeo/gdal-grass
> >
> > I'll call for a vote promoting it to next week if no serious problems
>
ithub.com/OSGeo/gdal/blob/master/apps/gdalwarp_bin.cpp
>
> The COG driver is also a user of it, perhaps more illustrative than the
> above :
> https://github.com/OSGeo/gdal/blob/master/frmts/gtiff/cogdriver.cpp#L552
>
> Even
> Le 13/04/2022 à 21:53, Sean Gillies a écrit :
>
WarpAppOptionsNew expect more values at the head of the command
line? Is that why it is missing "-r"? Or is my string list made up of the
wrong kind of strings? Documentation examples of building the arguments for
GDALWarp are scarce. I'd be super grateful for help
> fundamental ways. I'm not sure what I would put in a RFC that is not in
> their commit message. Maybe I don't understand what your concern is.
>
> Even
> Le 24/03/2022 à 15:28, Sean Gillies a écrit :
>
> Hi all,
>
> The intent and scope of the features develop
Hi all,
The intent and scope of the features developed in
https://github.com/OSGeo/gdal/pull/5463 and
https://github.com/OSGeo/gdal/pull/5390 seem rather big and unclear to me.
This seems to me to warrant an RFC. Yes? No?
--
Sean Gillies
___
gdal-dev
gt; NumFocus liaison team will coordinate dispersement as directed by the GEOS
> PSC and NumFocus rules.
>
> Thank you again to the GDAL Sponsors https://gdal.org/sponsors/index.html
> who have made this kind of grant possible. A better GEOS makes for a better
> GDAL.
>
> Howard
18 AM Even Rouault
wrote:
> Hi,
>
> As the discussion seems to have calmed down, I move to adopt RFC 85:
> Policy regarding substantial code additions:
> https://github.com/OSGeo/gdal/pull/5128
>
> Starting with my +1
>
> Even
>
>
--
Sean Gillies
__
ute or copy this e-mail.
> Please notify the sender immediately by email if you have received this
> email by mistake and delete this email from your system.
> JBA Risk Management Limited is registered in England, company number
> 07732946, 1 Broughton Park, Old Lane North, Broughton, Skipton, North
> Yorkshire, BD23 3FD, England.
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
GDAL, especially if you test like
> we do which exact requests are done and in which order, if we change at
> some later point how requests are done
>
> Even
> Le 05/10/2021 à 17:44, Sean Gillies via gdal-dev a écrit :
>
> Hi all,
>
> In writing some rasterio tests I
aster/autotest/gcore/vsicurl.py#L473.
Do we intend to support this or is it a missing feature?
--
Sean Gillies
___
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
>
Excellent!
+1
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
> two calls.
>
> We could synchronize in our API, but it still has the same issue if the
> user parallely used the C APIs directly or via a different interface.
>
> Relevant PR in rust gdal bindings:
> https://github.com/georust/gdal/pull/215
>
> -
> Regards
>
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
" axis order
> caused other issues.
>
> Even
>
>
> Le 02/09/2021 à 17:19, Sean Gillies a écrit :
>
> Oops, forgot to reply to the list. Also, to be more specific, could we
> hold 3.3.2 until Monday, September 6?
>
> On Thu, Sep 2, 2021 at 9:10 AM Sean Gillies w
Oops, forgot to reply to the list. Also, to be more specific, could we hold
3.3.2 until Monday, September 6?
On Thu, Sep 2, 2021 at 9:10 AM Sean Gillies wrote:
> I wish I'd noticed the change around EPSG:4326 sooner. I didn't see a
> particular announcement, but the breakag
r,
say using https://pypi.org/project/pytest-random-order/, and fix the
setup/teardown so that tests are properly isolated.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
x27;ll call for a vote promoting it to final later this week if no
> > serious problems are reported before.
> >
> > 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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
ship.html
>
> The terms of the contract are for 833 hours at $120/hr USD.
>
> Howard
>
> PS I will coordinating the contracting activity in my role as the GDAL
> NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary.
> Please contact us direc
+1
On Tue, Jun 8, 2021 at 4:50 AM Even Rouault
wrote:
> Hi,
>
> Motion:
>
> adopt RFC 83: guidelines for the use of GDAL project sponsorship (
> https://github.com/OSGeo/gdal/pull/3855 )
>
> Starting with my +1
>
> Even
>
--
Sean Gillies
___
sibling files, etc...)
> Although the raster handling side of godal is mostly feature complete
> with gdal, the vector and spatial-referencing part is not.
>
> Outside contributions to both these projects are welcome through github.
>
>
it is widely used as an exchange format. But I'll defer for
> GeoJSON until we see if the *OGC Features* and *Geometries JSON* SWG comes
> with something regarding this.
>
> Even
> Le 27/05/2021 à 19:24, Sean Gillies via gdal-dev a écrit :
>
> Hi all,
>
> I've got a
t; NumFOCUS fully operational, here's a new RFC for your consideration to
> > give guidelines on how we can use the sponsorship funds, who can
> > apply, etc. Input welcome.
> >
> > https://github.com/OSGeo/gdal/pull/3855
> >
> > Even
> >
>
--
Sean Gil
/trickier question of patching in support
> >> to the data formats.
> > :thumbsup:
> >
> > As for the patching of data formats with GDAL application-specific
> metadata, as I said, I don't have a better option, but I'm satisfied if the
> proce
that takes into account
> earthquakes however, you could perhaps need to add a 3rd digit to
> identify precisely the day.
>
> Even
>
To me, it seems that the parameterization or description of coordinate
epochs in OGC 19-005r4 is a bit sketchy.
Even, are you saying that coordinate shifts in PROJ are entirely functions
of the datetime delta since the coordinate epoch?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
; integrated,
> but it isn't there at the moment.
> Cheers,
> Aaron
>
> On Mon, May 3, 2021 at 12:05 PM Jean-Roc Morreale (ml) <
> jrmorreale...@enoreth.net> wrote:
>
>> Hi Aaron,
>>
>> Is the HTJ2K's output still readable by a reg
ease. 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
alys.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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
;gcs://s11-dev-vincent-tiledb-test-public/S2B_MSIL1C_20210227T032659_N0209_R018_T47MQV_20210227T072433.tiledb'.
>
> Is there any way to correctly specify this tiledb url on gcs for gdal?
>
> Vincent.
>
> --
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
1 - 100 of 285 matches
Mail list logo
