December 8, 2020 4:46:07 PM
To: Alex HighViz
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] How to wrap a C++ library using GDAL in a Python
library?
I may have misunderstood but I think you are asking the wrong community.
You can take your own C++ library and make it available to a Pytho
Hello,
Could somebody please put me on the right track with the following problem?
I have a C++ library that makes use of GDAL for processing raster maps and I
would like to wrap some of its features into a Python library to make it
accessible to a wider community.
I would like my library to p
From: Alex Highviz
Sent: 22 June 2018 18:27:14
To: even.roua...@spatialys.com
Subject: Re: [gdal-dev] Help with idiomatic GDAL solution for raster algebra
benchmark
On 14/06/2018 21:22, Even Rouault wrote:
>
> [ ]
> - 1000x1000 is somewhat small
On 19/06/2018 18:41, Mateusz Loskot wrote:
> On 19 June 2018 at 11:50, Alex HighViz wrote:
>> On 19/06/2018 10:28, Mateusz Loskot wrote:
>>> On 19 June 2018 at 11:22, Alex HighViz wrote:
>>>> Regrettably I overstated the performance in my previous post, due to
On 19/06/2018 10:28, Mateusz Loskot wrote:
> On 19 June 2018 at 11:22, Alex HighViz wrote:
>> Regrettably I overstated the performance in my previous post, due to a bug
>> that is now solved. With the solved bug, Pronto is about 50% slower than
>> GDAL directly. I belie
> Even Rouault wrote
> A few thoughts:
[ ]
> 1000x1000 is somewhat small. Perhaps benchmark on larger rasters
I am still working on your other suggestions, but thought it would be fair to
report on my progress.
Regrettably I overstated the performance in my previous post, due to a bug that
is
Great, will try and let you know.
From: Mateusz Loskot
Sent: 15 June 2018 00:27:34
To: Alex HighViz
Cc: Even Rouault; gdal-dev@lists.osgeo.org; Hagen-Zanker AH Dr (Civil & Env.
Eng.)
Subject: Re: [gdal-dev] Help with idiomatic GDAL solution for raster alg
pronto is geared
to express all operations at the pixel level.
From: Even Rouault
Sent: 14 June 2018 21:22:36
To: gdal-dev@lists.osgeo.org
Cc: Alex HighViz; Hagen-Zanker AH Dr (Civil & Env. Eng.)
Subject: Re: [gdal-dev] Help with idiomatic GDAL solution for ra
oost.GIL?
Thank you for your input.
Alex
p.s. I do remember a blog post or message on the boost mailing list by you
saying how great it would be to have Boost.GIL compatible with GDAL.
-Original Message-
From: Mateusz Loskot [mailto:mate...@loskot.net]
Sent: 14 June 2018 1
Dear all,
I few times I have posted to the list trying to promote the idea of providing
iterators over pixels in a raster band , and more generally to make raster data
accessible using (future) standard conforming ranges. It would make
implementing algorithms on raster data a lot more intuitive
From: Even Rouault [mailto:even.roua...@spatialys.com]
> I just planted the seed. Contributions (preferably as pull requests)
> welcome...
Ok just did that PR #411.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailma
> Even:
> In fact the nature of the object which is returned depends on the iterator,
> and as documented in the API, for the sake of implementation simplicity,
> those iterators do not necessarily respect the whole semantics of iterators.
I don't think that is necessary, at least in the case of
1) https://gist.github.com/marioroy
Alex HighViz kirjoitti 22.01.2018 klo 17:40:
Dear all,
I would like to re-open an older discussion. At several points in the last year
there has been a discussion of raster algebra / map algebra functionality on
this list. There still is an associated
Dear all,
I would like to re-open an older discussion. At several points in the last year
there has been a discussion of raster algebra / map algebra functionality on
this list. There still is an associated RFC by Ari Jolma
(https://trac.osgeo.org/gdal/wiki/rfc62_raster_algebra).
The reaso
>> Richard Barnes:
>>In building tile/block managers, I too have found it difficult to use
>>iterators or design algorithms without specifically considering both
>>tiles/blocks >>and cells. Without doing so, it is very easy to write code
>>which is (extremely) cache inefficient.
I think that
15 matches
Mail list logo
