> The VRT driver is the usual solution to a lot of problem but we cannot
> automatize the solution on environment other than C/C++ or command
> scripts. But unfortunately, even if we add those two function much of the
> VRT magic is still not on the VRT code but in gdal_translate.cpp [0].
Yes, som
Even Rouault mines-paris.org> writes:
>
> Jukka,
>
> I tried to simulate your scenario but couldn't observe any performance
> difference (on Linux, but I doubt that the OS would make a difference) when
> generating a test DB with 3.7.9 or 3.7.14, and using it with the other
> version.
> Howe
Hi Even,
> Date: Tue, 10 Jun 2014 17:43:50 +0200
> From: even.roua...@mines-paris.org
> To: lucena_i...@hotmail.com
> CC: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] VRTDataset in Java
>
> Ivan,
>
> gdal_vrt.h is an already installed header file and the symbols are exported
> (CPL_DLL), s
Indeed, thanks a lot Even. The OVR in GDAL_TIFF_OVR_BLOCKSIZE made me
believe it was only for external .ovr overviews.
Etienne
2014-06-10 8:48 GMT-04:00 Even Rouault :
> Selon "Etienne B. Racine" :
>
> > Hi List,
> >
> > Is there a way to control the block size of overviews and inspect that
> >
Thanks Even!
Silas
- Original Message -
From: "Even Rouault"
To: "Silas Faltus"
Cc: gdal-dev@lists.osgeo.org
Sent: Tuesday, June 10, 2014 11:17:32 AM
Subject: Re: [gdal-dev] Question regarding OGRPolygon intersection
Silas,
More exactly, GEOS is a port in C++ of JTS. It does exactly w
Silas,
More exactly, GEOS is a port in C++ of JTS. It does exactly what JTS does for
this, so it considers the coordinates as being located on a 2D cartesian plane.
No spherical/ellipsoidal geometry is involved.
Even
> Hi,
>
> I was hoping to use GDAL for testing when two convex polygons interse
Hi,
I was hoping to use GDAL for testing when two convex polygons intersect. I was
able to do this with something similar to:
polyOne->Intersects(polyTwo);
Both polyOne and polyTwo are OGRPolygon and are defined in geographic
coordinates, i.e. latitude and longitude (decimal degrees). I've als
On Tue, Jun 10, 2014 at 6:28 AM, Even Rouault
wrote:
>
>> Thanks, that makes sense. However, the result is somehow surprising and I
>> guess that in most cases unusable for the user. I wonder if it would be good
>> to print something like "WARNING. Encountered 4 source bands, assuming CMYC
>> colo
Ivan,
gdal_vrt.h is an already installed header file and the symbols are exported
(CPL_DLL), so this is a public C API (although a bit confidential probably)
As far as SWIG bindings is concerned, some work would be needed. New shadow
types should be introduced to model VRTDataset and VRTSourcedRas
> Thanks, that makes sense. However, the result is somehow surprising and I
> guess that in most cases unusable for the user. I wonder if it would be good
> to print something like "WARNING. Encountered 4 source bands, assuming CMYC
> color space". Behaviour is not very easy to understand by readi
Do we have plans to add those entries to the GDAL API (C, Java, etc.)?
-- \...\GDAL\TRUNK\FRMTS\VRT\GDAL_VRT.H
VRTDatasetH CPL_DLL CPL_STDCALL VRTCreate( int, int );
CPLXMLNode CPL_DLL * CPL_STDCALL VRTSerializeToXML( VRTDatasetH, const char * );
CPLErr CPL_STDCALL VRTAddSource( VRTSourc
Even Rouault mines-paris.org> writes:
> > Hi Even,
> >
> > Sorry, I must have been unclear. The question was about writing out a real
> > JPEG file, not JPEG compressed TIFF
>
> Ah my fault. I read too fast.
>
> > The command gdal_translate -of jpeg rgba_in.tif jpeg_out.jpg creates a jpeg
> > f
Selon "Etienne B. Racine" :
> Hi List,
>
> Is there a way to control the block size of overviews and inspect that
> block size from gdalinfo ?
> I have a raster with 256x256 block size.
> Band 1 Block=256x256 Type=Byte, ColorInterp=Red
> Band 2 Block=256x256 Type=Byte, ColorInterp=Green
> Band 3 B
Hi List,
Is there a way to control the block size of overviews and inspect that
block size from gdalinfo ?
I have a raster with 256x256 block size.
Band 1 Block=256x256 Type=Byte, ColorInterp=Red
Band 2 Block=256x256 Type=Byte, ColorInterp=Green
Band 3 Block=256x256 Type=Byte, ColorInterp=Blue
I'
Selon Jukka Rahkonen :
> Even Rouault mines-paris.org> writes:
>
> >
> > Selon Jukka Rahkonen mmmtike.fi>:
> >
> > > Hi,
> > >
> > > I would like to know what happens if I convert an original RGBA tiff
> image
> > > into jpeg as
> > >
> > > gdal_translate -of jpeg rgba_in.tif jpeg_out.jpg
> > >
Even Rouault mines-paris.org> writes:
>
> Selon Jukka Rahkonen mmmtike.fi>:
>
> > Hi,
> >
> > I would like to know what happens if I convert an original RGBA tiff image
> > into jpeg as
> >
> > gdal_translate -of jpeg rgba_in.tif jpeg_out.jpg
> >
> > I know that for getting a good result I can
Selon Jukka Rahkonen :
> Hi,
>
> I would like to know what happens if I convert an original RGBA tiff image
> into jpeg as
>
> gdal_translate -of jpeg rgba_in.tif jpeg_out.jpg
>
> I know that for getting a good result I can add "-b 1 -b 2 -b 3" but I am
> curious to know what happens and how GDAL
Hi,
I would like to know what happens if I convert an original RGBA tiff image
into jpeg as
gdal_translate -of jpeg rgba_in.tif jpeg_out.jpg
I know that for getting a good result I can add "-b 1 -b 2 -b 3" but I am
curious to know what happens and how GDAL computes sort of a transparent
sepia c
18 matches
Mail list logo