Hello!
I've been trying to figure this out for a while and this would be my first
time asking a question here.
How do I load a 3-band tiff into a virtual dataset, add a band (alpha
layer), warp the virtual dataset, then write it out to a TIFF again
(different, path, different name)?
I'm loadin
Hello!
I've been trying to figure this out for a while and this would be my first
time asking a question here.
How do I load a 3-band tiff into a virtual dataset, add a band (alpha
layer), warp the virtual dataset, then write it out to a TIFF again
(different, path, different name)?
I'm loading a
> Note: it is best
> to also create a ticket in GDAL Trac with the proposed patch, otherwise there
> is a risk of them getting forgotten in the email traffic.
Even,
Thank you for repoly.
Yes, next time, I 'll create a ticket in GDAL Trac.
I'll check
http://trac.osgeo.org/gdal/changeset/24514
Le mardi 29 mai 2012 09:45:36, Florent JITIAUX a écrit :
> Hi all,
>
> first I would like to know if the DDS (Direct Draw Surface) format is
> planed to be integrated in Gdal.
Not to my knowledge. You would be interested in writing DDS tiles more than
reading them, right ? To my understanding, t
Le mardi 29 mai 2012 12:26:04, OKI Miyuki a écrit :
> Hi all,
>
>I made patch for OGR cpl_recode_stub.cpp,
>to enable codepage conversion on windows platform.
>
Miyuki,
Thanks for your patch. I've incorporated it with some adjustements (a few
error checks and warnings reporting in case
Le mardi 29 mai 2012 23:12:45, Frank Warmerdam a écrit :
> Craig,
>
> My opinion is that applications should assume alpha is not pre-multiplied.
> I have been hesitant to "un-premultiply" premultiplied TIFF images - partly
> because it is hard to hit all the appropriate code paths safely and partl
Craig,
My opinion is that applications should assume alpha is not pre-multiplied.
I have been hesitant to "un-premultiply" premultiplied TIFF images - partly
because it is hard to hit all the appropriate code paths safely and partly
because the result will be lossy.
Going forward GDAL should do o
Tamas Szekeres wrote:
> I have added a ticked for such an issue long ago, but I don't remember
> what would be the expected solution.
> http://trac.osgeo.org/gdal/ticket/2279
>
> There should be an external config option to instruct the driver which
> representation should be used.
I think it wo
How to configure gdalwarpOptions to use openclkernel.
Like I did
warpOptions->papszWarpOptions=CSLSetNameValue(papszList,"USE_OPENCL","YES");
It compiled but I don't think so its using openclkernel.
In gdalwarpkernel they are checking WarpOptions for selecting between
GENERAL_CASE and OPENCL
On Tue, May 29, 2012 at 7:38 AM, Etienne Tourigny
wrote:
> Hi list,
>
> It seems that the +b parameter of Proj.4 strings generated by gdal can
> have different precisions, dependent on the architecture (i386 vs.
> ams64) for various linux flavors and gdal versions (1.6 - 1.9).
>
> The CRS from EPS
>
> "Make a virtual mosaic with blue background colour (RGB: 0 0 255)"
> gdalbuildvrt -hidenodata -vrtnodata "0 0 255" doq_index.vrt doq/*.tif
Added as suggested. Generally, we'd surely welcome doc improvements from power
users like you.
>
> -Jukka Rahkonen-
>
> __
I am going to take a look and report back on the ticket. OK?
> ---Original Message---
> From: Nicolas Simon
> To: gdal-dev@lists.osgeo.org
> Subject: [gdal-dev] Multipolygon with holes from OCI becomes invalid
> Sent: May 29 '12 04:10
>
> Hi,
> I had a similar problem as the one
Hi list,
It seems that the +b parameter of Proj.4 strings generated by gdal can
have different precisions, dependent on the architecture (i386 vs.
ams64) for various linux flavors and gdal versions (1.6 - 1.9).
The CRS from EPSG:4131 can have slightly different values: (
+b=6356075.413140239 vs.
Even Rouault mines-paris.org> writes:
> >
> > Knowing tricks is fun but I could tolerate having some parameter driven way
> > for
> > setting the VRT background colour.
>
> Actually, I'm just thinking that there's another less convoluted way of doing
> it. Try using "-vrtnodata 255 -hidenodata"
If anyone knows how to hack nmake.opt and alg/makefile.vc to build gdal with
opencl support on windows, please do reply.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi all,
I made patch for OGR cpl_recode_stub.cpp,
to enable codepage conversion on windows platform.
CODEPAGE Somthing like this "CP932" to "UTF-8"
"CP1252" to "UTF-8"
...
and
Hi,
I had a similar problem as the one described in
http://trac.osgeo.org/gdal/ticket/3753
I found the problem, and provided a patch.
The patch resolves my problem and the one described in the ticket.
Can someone with commit access update the trunk with the patch ?
VSIF* functions are not properly mapped to the C# bindings, VSIFReadL
has python specific implementation only, as far as I see.
I'm not sure whether this API should officially be published or not,
since I don't remember about an RFC or a ticket about the expected
requirements and type mapping sugge
I have added a ticked for such an issue long ago, but I don't remember
what would be the expected solution.
http://trac.osgeo.org/gdal/ticket/2279
There should be an external config option to instruct the driver which
representation should be used.
Best regards,
Tamas
2012/5/29 Craig Bruce :
Hi all,
first I would like to know if the DDS (Direct Draw Surface) format is
planed to be integrated in Gdal. This format is used in World Wind and DDS
tiles are loaded faster than JPEG or PNG tiles.
I would like also to know if it's planed to have the possibility of making
World Wind layers. Th
Just reading through this thread about GDAL, C# and memory streams as
I have a similar problem.
The thread seemed to end on a positive note with Maksim Sestic and
Even Rouault seeming to reach a conclusion.
However when I started using the API's Maksim & Even where discussing
I found that Gdal.VS
21 matches
Mail list logo
