k, 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/pull/9724
>
> (that said, tests reprojecting
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
st 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
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.
>
> The scope of
s, 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
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
. 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 is very driver depend
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
cifically: 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
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
t;>> 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
e, 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
n 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
> GDAL_DRIVER_PATH.
>
> Even
>
>
--
Sean Gi
gt;
> 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_plugin_loading.rst
>
>
> Star
t; 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
gt;
> --
> 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
om/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 reproduced on
23 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
> -
t; 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 30 JUL 20
;> > --axis-order=gis_friendly/authority_compliant explicit flag)
>> >
>> > Maybe some 'Ex' (which stands for API) functions in the C API could be
>> > removed and their extra/modified arguments reincorporated with the
>> > original non-Ex function. Would tot
m, 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 out of images and
ith the
> > original non-Ex function. Would totally make sense for the few ones
> > impacted by RFC95 like GDALGetDefaultHistogramEx,
> > GDALSetDefaultHistogramEx, GDALGetRasterHistogramEx
> >
> > There might be also some defaults (open, creation options) that could
&g
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
th_to_array}:{third_dim_index}[:{fourth_dim_index}[:{fifth_dim_index}...]]
>
> - Other syntax
>
> vrt:// connection string (
> https://gdal.org/drivers/raster/vrt.html#vrt-connection-string) . e.g.
> vrt://my.tif?bands=3,2,1
>
> Do you have also /vsi syntax in mind ?
>
> E
vers 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
>
h 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
>> business of making custom GDAL builds ca
DAL 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 example, today I ran into
>
>
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.osgeo.org
https
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
ers 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
>
--
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 :
>
>
ut 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
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 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
taset::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
>>
>> --
>> h
>
> 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 mailing list
> gdal-dev@lists.o
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
633#issuecomment-1307736762>, or
>> unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AAAIHIKG7X65SX4OULJMUFTWHKT5TANCNFSM6AAR2E6MJY>
>> .
>> You are receiving this because you commented.Message ID:
>>
>>
>
>
> --
> Sean Gill
lt;https://github.com/OSGeo/gdal/pull/6633#issuecomment-1307736762>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAAIHIKG7X65SX4OULJMUFTWHKT5TANCNFSM6AAR2E6MJY>
> .
> You are receiving this because y
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
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
; 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
ing:
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, Alan!
&g
J 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
>> Le 10/05/2022 à 23
ike 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
> occurs when I use
efore.
> >
> > 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
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 script and have foun
oad.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
> > are reported before.
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 :
>
> Hi
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 from anyone who has got
code
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 developed in
>
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
aison 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
>
--
Sean
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
___
e 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
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 am able to get GDAL
/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
chronize 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
s 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 wrote:
>
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 breakage was o
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
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
sponsorship.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
___
iles, 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.
>
> Best regards,
ormat. 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 suggestion about limiting the
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 Gillies
___
t
> >> 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
> process of writing epochs into metadata is opt-in (some
ed 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 regular GDAL/OpenJPEG ?
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.3rc1
gt; 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
db-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
the organization that defines
> the format is. People could reimplement that from scratch
>
> Note that there is potentially the OGR VRT format (that could go as
> application/ogrvrt+xml), but that is a separate schema and likely less used
> than its raster counterpart.
>
> Le 20/0
I know, GDAL is the only
> software
> > that plays VRTs, and probably the only software that ever can,
> considering
> > the extensions and embedded Python stuff.
> >
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
oaded on the website
> (https://github.com/OSGeo/gdal/pull/3681 to be updated)
>
> and the proposed answers to the NumFOCUS application form are at:
>
> https://docs.google.com/document/d/1bc5jdpCe1axdyBHxbJnun7e0DTyDoZI_eFYgJYnOhB8/edit
>
> which will be sub
er to open VRTs that were downloaded from a
> server.
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
t; would need to be enriched with details from the RFC, to explain how the 2
>> pypi packages relate, and the potential issues in the workflows you
>> indicate.
>>
>> The HOWTO-RELEASE procedure will likely need to be adjusted.
>>
>> I'll app
be much
better for users if we didn't have 2 distributions contending for the same
namespace.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
he pixel center
> point). In this case, how does the value burned to the raster is chosen
> among the candidates?
>
> Best regards,
> Hug
>
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
e removed in GDAL 3.5.
> Implemented in https://github.com/OSGeo/gdal/pull/3505
>
> Starting with my +1
>
> Even
>
> --
> http://www.spatialys.com
>
> ___
> gdal-dev mailing li
community find that it effectively steers $$ to consultants that fix bugs
> > and maintain the project? With the difference in image/logo sizes, is the
> > intent to make this look a bit like a conference sponsor page?
> >
> > --
> > Sean Gillies
>
>
> Hi,
>
fix bugs
and maintain the project? With the difference in image/logo sizes, is the
intent to make this look a bit like a conference sponsor page?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
should we
expect only minor changes at this point?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
for what a driver
RFC might look like and I suggest we discuss that as well.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
ivers
>>> at compile time, could we expand on this mechanism to mark problematic
>>> drivers as "orphaned" in this case? The code would still live in the repo
>>> but would be effectively disabled until someone with sufficient interest
>>> invests
les (i.e.
> style.json) when reading? Does it even have that functionality?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
roject.
>
Agreed. I'd like to try to improve this situation in 2021.
>
> It's clear what's happened in the past is a combination of luck and
> graciousness by both Frank and Even.
>
> Howard
>
Howard, you're so right. Not every industry enjoys a resource like GDAL.
It's a s
of these drivers in 3.3 as well? I'd
be in favor of that.
Thanks for writing that third bullet point. I've thought twice about
changes for exactly that reason.
Formats come and go. We can't expect the GDAL project and its maintainers
(mostly you!) to be the curators forever of all data.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi Mateusz,
The OSGeo sysadmins found something to correct in mailman configuration,
I'm giving that a test here.
On Wed, Dec 9, 2020 at 1:32 AM Mateusz Loskot wrote:
> On Tue, 8 Dec 2020 at 23:16, Sean Gillies wrote:
> >
> > The state of the art for very thin Python b
ssible to a wider community.
>>
>> I would like my library to present functions that take rasters as input
>> and produce rasters as outputs. I can modify the C++ side to have the
>> functions work on GDALRasterBands, GDALDatasets
t I don't recall the
> answer and could not find it again. A simple example of "best practice"
> would be ideal.
>
>
> With many thanks, Alex
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
&
> Joaquim! However, it seems like we have to code that ourselfs, thus the
> above digging.
>
> Cheers
> Felix D.
> _______
> 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
1 - 100 of 257 matches
Mail list logo
