Re: [gdal-dev] Nomination of Sean Gillies for the GDAL PSC
+1 On Tue, Sep 17, 2019 at 4:22 PM 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 contributed many bug reports > and design ideas to GDAL while developing those libraries, and he brings > nearly twenty years of active open source geospatial software contribution > experience with him. His API sensibilities will continue provide invaluable > direction and perspective going forward as GDAL continues to (slowly) > evolve. > > I'll start with a +1. > > Howard > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Andrey V. Kiselev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Nomination of Mateusz Łoskot for the GDAL PSC
+1 On Tue, Sep 17, 2019 at 4:21 PM Howard Butler wrote: > All, > > I would like to nominate Mateusz Łoskot to the GDAL PSC. > > Mateusz has been an active contributor to the GDAL project for nearly > fifteen years. He was the very first paid maintainer for the project, > closing bugs and running down issues, and his C/C++ expertise has helped > the project evolve as it has moved to C++11. He is also very helpful with > mailing list questions, and his experience and history with the project > make him an excellent candidate for participating in the GDAL PSC. > > I'll start with a +1. > > Howard > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Andrey V. Kiselev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit Access for Etienne Tourigny
On Fri, Sep 02, 2011 at 10:42:16PM +0200, Even Rouault wrote: Motion: Extend GDAL/OGR Commit Access to Etienne Tourigny +1 -- Andrey V. Kiselev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Motion: Commit Access for Paul Ramsey
On Wed, Jul 20, 2011 at 11:11:14PM +0200, Even Rouault wrote: Motion: Extend GDAL/OGR Commit Access to Paul Ramsey +1 -- Andrey V. Kiselev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Motion: Commit Access for Antonio Valentino
On Wed, Jun 29, 2011 at 10:37:52PM +0200, Even Rouault wrote: Motion: Extend GDAL/OGR Commit Access to Antonio Valentino +1 Best regards, Andrey -- Andrey V. Kiselev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Commit r19248
On Tue, Mar 30, 2010 at 08:25:07PM +0300, Ari Jolma wrote: I would like to read directly in the final string object. I think it could be done using the buffer API in recent Python branches. But is the string object useful from Python programmer's point of view then? (maybe NumPy?) Yep, NumPy is good for that, but it is a separate API. Here I would like to do just small optimization for ReadRaster call. Certainly we can save one buffer allocation/copy/deallocation cycle. I can let Perl allocate memory for a Perl string and then *possibly* give that buffer to the RasterIO, but the Perl string still needs to be unpacked by the Perl hacker. There are cases when the binary buffer is ok - for example in libral (C), and then in Geo::Raster (Perl) I do just that - but for the average Joe Perl Hacker it would be good to put it into a Perl 2D array - i.e., each number into its own scalar. That I could do in standard typemaps, but as I wrote, the interface is different from Band.ReadRaster, which returns the string. I have defined a ReadTile/WriteTile interface(*), which do just that, but currently the implementation is the read-copy-copy, and the 2nd one in Perl, which makes it even a bit slower. (*) see http://geoinformatics.tkk.fi/doc/Geo-GDAL/html/class_geo_1_1_g_d_a_l_1_1_band.html I will take a look at Perl part in more details and come with some suggestion later. I think we can arrange something useful for both bindings. -- Andrey V. Kiselev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Commit r19248
On Mon, Mar 29, 2010 at 11:23:08PM +0300, Ari Jolma wrote:
I was wrong in saying that there are no unnecessary memory copies in
Perl. It seems that the raster data is copied to a buffer, from which it
is copied to another buffer maintained by Perl. I then have an extra
layer of Perl code to copy from that buffer to Perl scalar arrays for
ease of use. An optimization to do away one of the copies would be
useful. That would mean copying from the initial buffer directly into
Perl arrays within a typemap - I haven't done that because of the
complication of several datatypes. To change that would mean - not to
break existing code - defining a new set of read/write methods.
Would that be compatible with what is wished for in the Python bindings?
Yes, that is what I tried to solve. In Python it looks like that:
%typemap(argout) (int *nLen, char **pBuf )
{
/* %typemap(argout) (int *nLen, char **pBuf ) */
Py_XDECREF($result);
%#if PY_VERSION_HEX = 0x0300
$result = PyBytes_FromStringAndSize( *$2, *$1 );
%#else
$result = PyString_FromStringAndSize( *$2, *$1 );
%#endif
}
PyString_FromStringAndSize() takes the array allocated in ReadRaster_internal()
function (see Band.i) and copies it into the string. The former array is being
deallocated after that. I would like to read directly in the final string
object. I think it could be done using the buffer API in recent Python
branches.
For now I have reverted back the problem commit.
Best regards,
Andrey
--
Andrey V. Kiselev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Motion: Commit Access for Adam Nowacki
On Mon, Feb 22, 2010 at 10:32:35PM +0100, Even Rouault wrote: Motion: Extend GDAL/OGR Commit Access to Adam Nowacki. +1 -- Andrey V. Kiselev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote RC4 as official 1.6.0 Release
On Sat, Dec 06, 2008 at 08:12:15AM -0500, Frank Warmerdam wrote: Motion: That the GDAL 1.6.0 RC4 release candidate be promoted to being our official 1.6.0 release. +1 Best regards, Andrey -- Andrey V. Kiselev ICQ# 26871517 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDALGridCreate() in python?
On Tue, Dec 09, 2008 at 08:41:32PM +0200, Ari Jolma wrote: I like to use the gdal_grid/GDALGridCreate() command from python. Are the function wrapped for use in python now? See: http://trac.osgeo.org/gdal/ticket/2023. If not,are there a posible workaround? It's not been added to the swig interface and there's no workaround. I guess you need to use the command line program. Adding it to the swig interface needs some thought as the function does not create a GDAL object- in fact it interpolates onto an in-memory raster. I am thinking on idea to create the native NumPy bindings for GDAL (using the NumPy typemaps). That should greatly help to create practical bindings for Grid functions and some other. Also it is possible to create the higher level wrapper for gridding hiding the arrays inside. Best regards, Andrey -- Andrey V. Kiselev ICQ# 26871517 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] build error in trunk
On Wed, Dec 03, 2008 at 08:15:17AM -0500, Kralidis,Tom [Ontario] wrote: make[1]: *** No rule to make target `gdalprofile.lo', needed by `default'. Stop. make[1]: Leaving directory `/home/tkralidi/foss4g/gdal/trunk/gdal/alg' make: *** [core-target] Error 2 Tom, That was my mistake when applying a fix for http://trac.osgeo.org/gdal/ticket/1878 Should be corrected now. Best regards, Andrey -- Andrey V. Kiselev ICQ# 26871517 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MSYS buildslave
On Wed, Oct 29, 2008 at 02:04:44PM +0200, Ari Jolma wrote: I've set up a buildslave, which builds GDAL from a fresh checkout of the trunk in Windows using the MSYS environment. Currently the build is quite lean and only Perl bindings are built in addition to the core dll and apps. Only Perl tests are run. Ari, If you are planning to extend a build to include NG Python bindings note that there is one problem. For some reason module built from swig/python/extensions/gdalconst_wrap.c cannot be loaded by the stock Python binaries (built with MSVS 2003). I have ended up renaming that file in gdalconst_wrap.cpp with the appropriate change in swig/python/setup.py and everything works fine after that. The problem is weird and I failed to pin it down, so the above workaround. Otherwise of that bug Python stuff should be perfectly compilable and usable with the official binary Python distribution. Best regards, Andrey -- Andrey V. Kiselev ICQ# 26871517 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL/OGR 1.6.0 Planning Meeting
On Tue, Oct 21, 2008 at 01:05:47PM -0400, Frank Warmerdam wrote: I'd like to hold a meeting for planning the GDAL/OGR 1.6 release this Friday at 10:00am EST (1400 GMT). http://trac.osgeo.org/gdal/wiki/ThirdMeeting +1 -- Andrey V. Kiselev ICQ# 26871517 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR: GetField methods problem
Anton, On Sat, Oct 18, 2008 at 11:45:49AM +0900, Anton Patrushev wrote: It is strange, but I have this problem again with the fresh installation of Ubuntu 8.04. I took GDAL 1.5.1 .deb packages from here http://les-ejk.cz/ubuntu/dists/hardy/multiverse/binary-i386/ and they look OK. But when I'm trying to compile my stuff, I get /usr/include/gdal/ogr_feature.h undefined reference to 'OGRFeature::GetFieldAsDouble(int)' /usr/include/gdal/ogr_feature.h undefined reference to 'OGRFeature::GetFieldAsInteger(int)' /usr/include/gdal/ogr_feature.h undefined reference to 'OGRFeatureDefn::GetFieldIndex(char const*)' just like with RHEL before. It looks pretty strange, 'cause I have all header files from gdal-dev. That means you forgot to link with the GDAL library. Try to add '-lgdal' option to you compilation command line. Best regards, Andrey -- Andrey V. Kiselev ICQ# 26871517 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Why warp.py tests disabled?
On Sat, Aug 02, 2008 at 03:20:59PM +0200, Mateusz Loskot wrote: Could you tell me why some test cases of warp.py have been disabled [1] ? The log message does not say much about. http://trac.osgeo.org/gdal/changeset/14617 Mateusz, These tests failed on some slaves (AFAIR on x86 hosts). I think it is due to the floating point issues, either computation errors or float-to-integer conversion. Actually I don't know what to do about that. Threshold is 1.0 for byte data type, so it means that we are having seriously different warping results on different hosts. At least these tests can be used locally when working with warping code. Best regards, Andrey -- Andrey V. Kiselev ICQ# 26871517 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
