On Wed, 9 Sep 2015 10:29:04 AM user gdal wrote:
> Can you try posting an actual, compilable example?
>
> Ans. There is a GUI from which I extract parameters which can give us a lot
> of inconvenience. The program compiles without 'abusing' me. What I am
> getting is a run time (or debug time)
Hi Homme,
> From my point of view anything that makes the new API feel less like a
> wrapper
> around a system call is great: passing expensive objects like datasets and
> enabling progress functions is important. Hopefully this would also mean
> passing objects as cutline layers for gdalwarp
Le mercredi 09 septembre 2015 04:48:13, Cheng Tang a écrit :
> Hi Gdal Developers:
>
> I have a question: Can I change icon of placemark of a kml file through
> code using ogr python? I did not find this function in ogr document.
Tang,
you need to use the LIBML driver of GDAL (not necessarily
On 08/09/15 16:28, Even Rouault wrote:
For example, let's say the user calls gdal.Translate("format" => "GTiff", >>> "src_win" => [100,400,50,50] ) (this is probably not valid Perl
syntax, >>> but hope you got it !), and you would call
GDALTranslateOptionsNew(list) >>> where you would build
> In terms of
> unsetting options, will passing NULL to the relevant setter do the trick,
> or do we need to
> re-create the structure in that case?
The setters should behave nicely hopefully (ie deallocate any previously
allocated/duplicated objected, and assign NULL ). If for some reason that
On 09/09/15 10:38, Even Rouault wrote:
In terms of
unsetting options, will passing NULL to the relevant setter do the trick,
or do we need to
re-create the structure in that case?
The setters should behave nicely hopefully (ie deallocate any previously
allocated/duplicated objected, and
On 2015-09-09 13:33, Ari Jolma wrote:
On 09.09.2015 14:21, sebastic wrote:
On 2015-09-09 12:51, Ari Jolma wrote:
1.10.1 was released two years ago and there seems to be >60 commits
to
that branch since.
For example the latest Debian (Jessie) seems to still use GDAL 1.10.
Is it time for
Le mercredi 09 septembre 2015 12:51:15, Ari Jolma a écrit :
> Folks,
>
> 1.10.1 was released two years ago and there seems to be >60 commits to
> that branch since.
>
> For example the latest Debian (Jessie) seems to still use GDAL 1.10.
>
> Is it time for 1.10.2?
Hi Ari,
Do you think they
On 09.09.2015 14:11, Even Rouault wrote:
Le mercredi 09 septembre 2015 12:51:15, Ari Jolma a écrit :
Folks,
1.10.1 was released two years ago and there seems to be >60 commits to
that branch since.
For example the latest Debian (Jessie) seems to still use GDAL 1.10.
Is it time for 1.10.2?
On 09.09.2015 14:21, sebastic wrote:
On 2015-09-09 12:51, Ari Jolma wrote:
1.10.1 was released two years ago and there seems to be >60 commits to
that branch since.
For example the latest Debian (Jessie) seems to still use GDAL 1.10.
Is it time for 1.10.2?
For Debian there is no need for
Folks,
1.10.1 was released two years ago and there seems to be >60 commits to
that branch since.
For example the latest Debian (Jessie) seems to still use GDAL 1.10.
Is it time for 1.10.2?
Ari
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Le mercredi 09 septembre 2015 13:25:43, Ari Jolma a écrit :
> On 09.09.2015 14:11, Even Rouault wrote:
> > Le mercredi 09 septembre 2015 12:51:15, Ari Jolma a écrit :
> >> Folks,
> >>
> >> 1.10.1 was released two years ago and there seems to be >60 commits to
> >> that branch since.
> >>
> >>
On 2015-09-09 12:51, Ari Jolma wrote:
1.10.1 was released two years ago and there seems to be >60 commits to
that branch since.
For example the latest Debian (Jessie) seems to still use GDAL 1.10.
Is it time for 1.10.2?
For Debian there is no need for a 1.10.2 release, such an update is not
Hi Even,
On 09/09/15 10:04, Even Rouault wrote:
Hi Homme, > >> From my point of view anything that makes the new API feel less
like a >> wrapper >> around a system call is great: passing expensive
objects like datasets and >> enabling progress functions is important.
Hopefully this would
Hi Even,
thanks for your response. Okay, I see now.
If I would extend asTIFFTags variable of type GTIFFTags in geotiff.cpp, I
should be able to use more of the tifftags, or am I wrong? Maybe I have to have
a look at the type handling and some other places where the table is used too.
I had
15 matches
Mail list logo