from
disk every time. My question is whether or not this will change when we
move over to the new PROJ. Will data be cached or will we need the path to
proj.db to be configured all the time?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev
d lose
that insurance and may experience some trouble that is hard to diagnose.
Could a GDAL API function that allowed modification of the search path in
GDAL's own context help?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
> that will internally call proj_context_set_search_paths() on PROJ context
> managed by GDAL (affecting the already created TLS ones, and future ones)
>
>
Sounds good! I just added a ticket about this:
https://github.com/OSGeo/gdal/issues/1191.
--
Sean Gillies
_
is encountering HDF5 metadata items that can't be decoded using
Python's UTF-8 codec and I've love to be able to sort this out.
Thanks,
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
oid*, int, int, int, double) ()
> from ../rasterio/.libs/libgdal-c9384152.so.20.5.0
>
> Any ideas?
>
> Thanks,
>
> Ari
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osg
ooking at the details of this particular case, this is an
> inappropriate
> handling by the HDF5 driver of some types of attributes.
> Fixed by
>
> https://github.com/OSGeo/gdal/commit/9640098fc79b6ba6bb135f8715fa3e7dd2705691
> which I've backported to 2.4 as well
>
> Even
>
Thanks
Remove PROJ.4 dependency and functionality,
> causing removal of SHPProject(), SHPSetProjection() and
> SHPFreeProjection()
> * contrib/shpproj.c: removed
If you remove methods and a utility, would it be better to call this
shapelib 2.0?
--
Sean Gillies
_
have thoughts on this.
>
>
> Even
>
I'd prefer to see the existing infrastructure reused because then some
logging of network activity would automatically appear for users of
Rasterio (which already subscribes to CPLDebug messages).
I think the right amount of default logging would be to call
nt GDAL drivers?
>
> I'm looking to get some useful information regarding these for
> end-user debugging purposes...
>
> Nyall
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mai
SION["PROJ4_GRIDS","@null"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Mercator_2SP"],PARAMETER["standard_parallel_1",0],PARAMETER["central_meridian",0],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["Meter",1],AUTHORITY["EPSG","3857"]]'
Am I wrong to understand the semantics of "+init=epsg:3857" as "open the
epsg database, get entry 3857, and use that"? Is this different from
specifying the entry directly?
Thanks in advance,
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
lt in GDAL 3.0
> So either cope with it with the x,y you get.
> Or add sr->SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER);
>
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______
> gdal-dev mailing lis
--
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
_
Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
__
.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
rsbarn
>
> We could have perhaps actually called the version 3.0.
>
> >
> > I'd be happy to do the work, once I find the commit where the function
> was
> > removed.
>
> in mega-commit 8e5eeb35bf76390e3134a4ea7076dab7d478ea0e
>
> Even
>
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
download.grib download.tif 261.99s user 18.57s system 98%
> cpu 4:45.62 total
>
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
l-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
Hi,
On Thu, Sep 19, 2019 at 8:31 AM Klaus Braun <
klaus.br...@geographie.uni-freiburg.de> wrote:
> Hi,
>
> on my SUSE box I compiled gdal 2.4.2 and 3.0.1 in the same way, enabling
> python
> bindings.
>
> When I use osr.CoordinateTransformation() in my python script to do a
> coordinate
>
t; On Sep 17, 2019, at 8:21 AM, Howard Butler wrote:
> >
> > All,
> >
> > I would like to nominate Sean Gillies to the GDAL PSC.
> >
> > Sean leads the development of two important Python geospatial projects
> based on GDAL/OGR – rasterio and Fiona. He has contribut
uptools 41.2.0
six 1.12.0
urllib3 1.25.6
wheel 0.33.6
xdg 1.0.7
I think there is something else going on with your system. Do you have a
much older version of pip? Or is there a script that is executing
> the nodes. Impact correct reconstruction of holes in shapefile driver
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mai
> 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
xample, it looks like much of the
"magic" of these plugins is going to be undone by requirements to prefix
the connection strings with the name of the plugin driver. Is `ogrinfo
PASSTHROUGH:myfile` any improvement over `python passthrough.py myfile`?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
: cannot open shared
> object file: No such file or directory
>
>
> I install the following packages in the docker container using conda:
>
> RUN conda install -c conda-forge numpy pandas poppler rasterio gdal
> rasterstats
>
>
> _______
Thanks, Even. I've flushed out rasterio's usage of FlushCache.
On Thu, Oct 3, 2019 at 11:04 AM Even Rouault
wrote:
> On jeudi 3 octobre 2019 10:14:45 CEST Sean Gillies wrote:
> > In the comments above FlushCache() in gcore/gdaldataset.cpp it is said:
> >
> > * U
that is not addressed? Does it vary by
format and driver?
Thanks!
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
a fan of
the green (our planet is blue, no?) and I think the kerning in "G D A L"
could be improved upon, it's too loose for my taste. I appreciate the work
that's gone into the designs, for sure.
--
Sean Gillies
___
gdal-dev mailing list
gdal-de
he two processes in your program. Even will have
a more definitive answer, I'm sure. but I think these are your options:
1. use a physical temp file, easily shared between processes
2. use a more sophisticated shared memory (mmap?)
3. implement the merge in Python within the original process
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
s://github.com/mapbox/rasterio/issues/524#issuecomment-156655258.
Briefly: depending on the format driver, setting the geotransform can be a
no-op if the given transform is ~= the identity transform. For GeoTIFF,
both (0, 1, 0, 0, 0, 1) and (0, 1, 0, 0, 0, -1) are considered to be ~=
identity and are invalid inputs that are ignored.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
PROJ4. But no longer an issue with
> GDAL 3,
> or can be avoided with GDAL 2.x as well when building with --with-
> [static-]proj[4])
> * the OGDI library loading its plugin. But OGDI is sufficiently a odd
> beast
> that we don't need/want this in a general pu
ot;EPSG",8802]],PARAMETER["False
> easting",0,LENGTHUNIT["metre",1],ID["EPSG",8806]],PARAMETER["False
>
> northing",0,LENGTHUNIT["metre",1],ID["EPSG",8807]]],CS[Cartesian,2],AXIS["(E)",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["(N)",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001'
> ct NULL
>
> What am I doing wrong?
If you pass "EPSG:4326" to importFromProj4 instead of "+init=epsg:4326"
(and likewise for EPSG:3857) the deprecated syntax warning won't be
printed. I expect that the error would be cleared up too, at least that is
my experience with the latest in these libraries.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
uxiliary layers for nested
> objects.
> Thinking that a fun exercise would be to write a script that would convert
> the
> GeoJSON content into XML (there are already utilities to do that) and
> generate
> a XML schema. And then feed that into GMLAS. Sounds fun, doesn't it ;-) ?
w.bell...@gmail.com
> ___
> 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
iate your help!
>
The background is transparent, I think it may appear white due to details
of your image viewer. If you convert the warped GeoTIFF to a PNG like
gdal_translate -of PNG warped.tif warped.png
you'll have a file that looks properly transparent in a browse
itional
information. A world file is one such auxiliary file.
You can convert and warp like like this:
gdalwarp -r near -s_srs EPSG:4326 -t_srs EPSG:3857 -of GTiff
latest_radaronly.gif warped.tif
The gdalinfo program will show you the bounds of the result and you can
confirm they are what you expect.
?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
inux-gnu/libc.so.6 (0x7f1a4d476000)
/lib64/ld-linux-x86-64.so.2 (0x7f1a4e67d000)
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
ed scipy-1.4.1
$ pip install scipy==1.3.2
...
Successfully installed scipy-1.3.2
$ python
Python 3.6.6 (default, Sep 12 2018, 18:26:19)
[GCC 8.0.1 20180414 (experimental) [trunk revision 259383]] on linux
Type "help", "copyright", "credits" or &q
r, so there would be a risk to rush that into the release)
>
>
>
> Even
>
That's fair. Carry on!
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
t GDAL 3.1.3 RC1 as final 3.1.3 release
>
>
>
> +1 Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lis
from osgeo.gdal import deprecation_warn
> deprecation_warn('gdal_calc')
> from osgeo.gdal_calc import *
> if __name__ == '__main__':
> sys.exit(main(sys.argv))
>
> What do you think?
>
> Idan
>
> _______
> gdal-dev mail
working on a patch
for this.
This VRT background fill is different from nodata. The scale offset could
be different from the nodata value. BTW, It takes advantage of GDAL
shortcuts predicated on scale ratio. The "dummy.tif" file is never opened
and doesn't even exist.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
IFF driver
not actually delete the VSIMEM file?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
On Wed, Oct 21, 2020 at 4:06 AM Even Rouault
wrote:
> Hi,
>
> Motion:
>
> Adopt GDAL 3.1.4 RC2 as final 3.1.4 release
>
> Starting with my +1
>
> Even
>
Even, thanks for clearing up the question I had yesterday. I've tested RC2
and don't see any new issues
hen available? GDAL 3.1.3 works with PROJ 6.x and it would be
least surprising if GDAL 3.1.4 did as well.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
defaults.
The warning comes from
https://github.com/OSGeo/gdal/blob/2818ff0a49f65741a55b9cea79df496cc05f85e3/gdal/frmts/grib/gribdataset.cpp#L2149
.
Is this sensitivity expected?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
with CHECK_WITH_INVERT_PROJ=YES)
>
>
>
> CHECK_WITH_INVERT_PROJ is mostly a gdalwarp implementation detail to make
> things work in some cases. I wouldn't advise to use it universally unless
> you know you need to use it (one good reason is that not all PR
&
> 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
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
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
ebrew-osgeo4mac/issues/456#issuecomment-414220068
.
If some other homebrew package updated your armadillo library after you
installed gdal, you'll need to reinstall gdal.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
;> lrwxr-xr-x 1 username staff 25 Oct 28 09:06 libarmadillo.10.dylib
>> -> libarmadillo.10.1.1.dylib
>> lrwxr-xr-x 1 username staff 21 Oct 28 09:06 libarmadillo.dylib ->
>> libarmadillo.10.dylib
>> drwxr-
rinfo "PG:dbname=testdb user=foo"
> ogrinfo "mySQL:testdb,user=foo"
>
These seem like they could be driver specific, but generalized key-value
parameters.
> ogrinfo OCI:warmerda/passw...@gdal800.dreadfest.com
Wat?
> GDALOpen() is not even aware that HDF5:bla means that the dataset will be
> recognized by the HDF5 driver
>
>
Wait what?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
e to me. I'm not aware of GDAL needing any features of Python
3.7, so 3.6 sounds good.
Since the project hasn't dropped support for a Python version in a long
time, maybe there should be a plan to warn in code and make announcements
on OSGeo lists? It's only a suggestion. I don't insist.
--
an HDF5 itself.
>
>
Thank you for explaining.
> >> ogrinfo OCI:warmerda/password@.dreadfest
>
> >Wat?
>
> Text has just been formatted into email link because of the @ sign that
> belongs to the Oracle connection string "username" / "password" @ &q
happened
>
> Thoughts ?
>
> Even
>
We already have a way of passing "open" options for vsicurl:
https://gdal.org/user/virtual_file_systems.html#vsicurl-http-https-ftp-files-random-access.
What about reusing that conceptual framework and syntax?
For example:
"foo.cs
ith something excellent and expressive and
broadly supported in GDAL, QGIS, rasterio, GeoPandas, GeoTrellis etc.
[1] https://en.wikipedia.org/wiki/Uniform_Resource_Name
[2] https://filesystem-spec.readthedocs.io/en/latest/index.html
[3] https://tools.ietf.org/html/rfc8141#section-2.3
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
he order of coordinates in
the interior rings of polygons extracted by GDAL's polygonizer and a change
in the number of polygons extracted, but no other issues. I don't think
these need to hold up the release.
+1
--
Sean Gillies
___
gdal-dev mailing list
ntent (the GeoJSON driver accepts the content
> to
> be directly provided as the dataset name), or XML (VRT, WMS drivers).
> We have also the subdataset syntax "HDF5:foo.hdf:my_variable"
>
Could VRT XML and JSON be exempted? We already have a way to embed open
options in the
ygon
that changed, the number of polygons is unchanged. Sorry for the false
alarm.
--
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
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
+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
___
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
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
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
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:
>
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
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
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
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
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
>
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
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
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
;> > --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
+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
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
; 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
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
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
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
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
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
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.
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
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
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
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
>
> 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
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
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
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
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 :
>
>
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
>
--
101 - 200 of 257 matches
Mail list logo
