Saâd,
I too got errors.
The only way to avoid them for now it to run the individual rasters through
their own filter vrt files.
I am going to dig deeper in the ticket #4616.
http://trac.osgeo.org/gdal/ticket/4616
On Fri, Apr 13, 2012 at 5:39 PM, Saâd HESSANE wrote:
> Hy list,
>
> Has anyone rep
I am a new GDAL user and have been trying to use gdalwarp to reproject a 2D
array of swath-based (satellite) floating-point data values (no projection)
that reside in a flat binary file. I also have the corresponding
floating-point geolocation binary files that are the same dimensions as the
data
On 4/13/2012 1:50 PM, Carl Godkin wrote:
I think a lot of formats support the concept of NODATA. The GDAL API
has functions for checking for this in the GDALRasterBand class, for
instance, as
double GDALRasterBand::GetNoDataValue() in the C++ or in the C API
as GDALGetRasterNoDataValue().
I'
Ethan,
It only happens if there appears to be a valid mask on the source
image that gets copied by gdal_translate in a CreateCopy() call to the
jpeg driver. There are various reasons a source might or might not
have a mask.
Best regards,
Frank
On Fri, Apr 13, 2012 at 2:31 PM, Ethan Alpert wrot
Ok why does this not happen with multi band jpgs?
From: Even Rouault [mailto:even.roua...@mines-paris.org]
Sent: Friday, April 13, 2012 1:13 PM
To: gdal-dev@lists.osgeo.org
Cc: Ethan Alpert
Subject: Re: [gdal-dev] Problem with garbage bytes of data after EOI marker in
single band JPEG
Le
On Fri, Apr 13, 2012 at 12:07 PM, David Strip wrote:
> What data formats besides geotiff support a NODATA value? Is there a
> uniform GDAL approach to determining the NODATA value or otherwise
> determining if a pixel is a NODATA pixel? I know that this value is stored
> in a geotiff tag, but th
David,
Some formats support identifying a particular pixel value as nodata
and some do not.
When they don't and you write nodata, we usually try to store the
information in an
.aux.xml file (auxilary metadata) which at least GDAL based applications would
recognise.
Best regards,
Frank
On Fri, Ap
Hi Etienne,
Etienne Tourigny wrote:
> You should use gdalwarp only, no ned for gdal_merge.py.
Thanks for that. So noted.
> The order of input datasets is important, so in your case you should use
> gdalwarp south.tif north.tif merge.tif
>
> Plus you don't need a mask, the last input file wil
You should use gdalwarp only, no ned for gdal_merge.py.
The order of input datasets is important, so in your case you should use
gdalwarp south.tif north.tif merge.tif
Plus you don't need a mask, the last input file will override the first one.
Etienne
On Fri, Apr 13, 2012 at 4:09 PM, Gregory,
Hi all,
I don't think I'm understanding correctly how to use masking bands. My goal is
to create a mosaic between two adjacent rasters using mask bands on each raster
to define the valid data. As a test, I have two single band GeoTiffs
(north.tif and south.tif) that overlap by about 400 rows.
Le vendredi 13 avril 2012 19:53:41, Ethan Alpert a écrit :
>
> This has been running for years. Recently a customer who receives these
> started scanning the JPG's for security threats. Turns out that the
> JPG's I've been writing have garbage data after the JPEG EOI marker.
>
This is not garbage
What data formats besides geotiff support a NODATA value? Is there a
uniform GDAL approach to determining the NODATA value or otherwise
determining if a pixel is a NODATA pixel? I know that this value is
stored in a geotiff tag, but that won't work for other formats.
___
Le vendredi 13 avril 2012 15:30:44, Jukka Rahkonen a écrit :
> Even Rouault mines-paris.org> writes:
> > Jukka,
> >
> > Your question made me look more closely at the capabilities of the JP2Box
> > support in GDAL, and I discovered that I had to write just a few lines of
> > code to add support f
I have a very old GDAL based tool I wrote that creates JPEG thumbnails
for GeoTiff's. Since the GeoTiff's can be any size and I used a perl
script to compute the aspect ratio so I can center a reduced size image
in a square thumbnail.
I'm looking for any suggestions as to how I can look into th
On Fri, Apr 13, 2012 at 10:00 AM, David Strip wrote:
> are there conditions under which these two values are not the same? It seems
> to me they should match, but maybe I'm missing something.
David,
The XSize of a dataset should always match the xsize of the bands
fetched with GetRasterBand() on
are there conditions under which these two values are not the same? It
seems to me they should match, but maybe I'm missing something.
Thanks
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Even Rouault mines-paris.org> writes:
>
> Jukka,
>
> Your question made me look more closely at the capabilities of the JP2Box
> support in GDAL, and I discovered that I had to write just a few lines of
> code
> to add support for writing georeferencing in the existing openjpeg driver.
> S
Hy list,
Has anyone reproduce the bug?
Thank you.
2012/4/12 Saâd HESSANE
> Yes of course :
>
>>
>> ...
>> ...
>>
>> 0
>> Gray
>>
>> 1.tif
>> 1
>> > DataType="UInt16" BlockXSize="8449" BlockYSize="1" />
>>
>>
>> 0
>>
>>
>>
In my case, I got a VRT consisting of about 20 GeoTIFFs, where each tile
has overviews in them.
I did write some sandbox code, and tried the gdalwarp tool. Both are
equally slow.
There are earlier posts related to this aswell.
Den 13. apr. 2012 13:36 skrev "Even Rouault"
følgende:
> Selon Oyvin
Selon Oyvind Idland :
> I am currently using GDAL 1.8.0, and have found that reprojecting VRT
> datasets can be incredibly
> slow (several minutes in my case). I believe there are bugs/tickets related
> to this issue.
>
> I am only interested in reprojecting arbitrary datasets (or portions of it)
I am currently using GDAL 1.8.0, and have found that reprojecting VRT
datasets can be incredibly
slow (several minutes in my case). I believe there are bugs/tickets related
to this issue.
I am only interested in reprojecting arbitrary datasets (or portions of it)
into a screen size window, on the
> Hi,
>
> Alex Sevaliev from j2k-codec.com already wrote such a tool for us. It can be
> used
> in a fast mode when new GML boxes are written at the end of the JPEG2000 file
> and then it is super fast even with however big files.
Yes, in fact, if the GML file to insert is already generated, the t
22 matches
Mail list logo
