) must be used to read images with Type=Float,
which is the type the USA government uses to distribute all digital elevation
modes.
Greg
On Jun 26, 2011, at 12:35 PM, Even Rouault wrote:
> Le dimanche 26 juin 2011 17:02:46, Greg Coats a écrit :
>> GDAL 1.7.3, released 2010/11/10, for
GDAL 1.7.3, released 2010/11/10, for Mac OS X 10.6, acquired from
http://www.kyngchaos.com/software:frameworks, properly reads geo referenced
raster images of Type=Float32. For the example 468 MB image, gdalinfo properly
reports Type=Float32, and Computed Min/Max=35.024,748.615.
GDAL 1.8.0, rel
ls shows that every file and directory has the same (false) modification date
and time. This makes it impossible to see when a particular source code file
was actually last updated. Can the final GDAL source code be released with
accurate modification dates and times? Greg
On Jan 12, 2011, at 1
>From a JPEG2000 image, you can use kdu_expand -reduce to quickly extract an
>image of the top (or any other) level pyramid. In the example below, I extract
>from a JPEG2000 image, pyramid level 10 from a 142 GB image in 0.10 seconds.
>Perhaps you could consider using JPEG2000.
Greg
$ ls -hl dc
Using GDAL and QGIS, I am able to pan and zoom through 1699 highly compressed
GeoJP2 images, that are seamlessly joined together by a .vrt file. After
zooming in to narrowing the area of interest, I then want to know the filename
of the highly compressed GeoJP2 image I am currently viewing, so t
In a well documented test, I found that gdal_translate processing of a 675 MB
image with --config GDAL_CACHEMAX 40 took 10,473 seconds, while processing with
--config GDAL_CACHEMAX 45 was 63 times faster!, taking only 166 seconds.
However, further increases in the GDAL_CACHEMAX did not effect pr
According to http://www.gdal.org/formats_list.html the maximum GDAL NITF file
size is 10 GB. Greg
On Aug 25, 2010, at 10:24 AM, turtlewax wrote:
> 1. Is there a known limitation of NITF output?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://
I agree that unsigned byte does not support -128. Signed byte does support
-127. Signed byte does not could support -128. I note that
http://www.gdal.org/gdal_translate.html shows that gdal_translate supports 11
data types
Byte/Int16/UInt16/UInt32/Int32/Float32/Float64/CInt16/CInt32/CFloat32/CF
First, instead of using GDAL 1.6.0 from December 2008, why not use GDAL 1.7.2
from April 2010?
Second, since your objective is to create a tiled GeoTIFF, you can do that with
one gdal_translate command.
$ gdal_translate --version
GDAL 1.7.2, released 2010/04/23
$ gdal_translate -of GTiff -ot Byte
On Jul 18, 2010, at 6:09 PM, Leith Bade wrote:
> they only have a 32-bit build
Not true.
The complaint that Kakadu has never offered 64 bit versions of their command
line executables for free is false. The Kakadu web site now offers, for free,
version 6.4 for Mac OS X compiled for 32 bit and 64
On Jul 18, 2010, at 12:44 AM, Leith Bade wrote:
> kdu_compress also has a memory limit at 2 GB
Not true. Based on your comment, I suspect that you are using a version of
Kakadu that is more than 3 years old, or that was deliberately compiled for a
32 bit environment.
Since version 6.0, releas
Since you have 4 GB RAM, I suggest overriding the 40 MB GDAL_CACHEMAX default,
and increasing it
gdal_merge.py --config GDAL_CACHEMAX 1000
The maximum possible GDAL_CACHEMAX is
gdal_merge.py --config GDAL_CACHEMAX 2147
Greg
On Jul 16, 2010, at 9:19 PM, Leith Bade wrote:
> Hi,
>
> I am trying t
I do not see that you specified that the output TIFF image be tiled
-co TILED=YES -co BLOCKXSIZE=512 -co BLOCKYSIZE=512
gdal_merge.py supports the -v input option that reports progress as a % for
every source image merged into the destination image.
It is better to do the initial gdal_merge.py un
Tiff files are composed of either one or more tiles, or one or more stripes. No
single tile or stripe can be larger than 2 GB. The original Tiff standard
further required that a .tif file not be larger than 4 GB. The BigTiff standard
does away with this 4 GB .tif file limit.
GDAL supports BigTif
Frank, Yes! Thank you. Greg
On Jul 5, 2010, at 7:25 PM, Frank Warmerdam wrote:
> Greg Coats wrote:
>> Following Frank's suggestion, and in accordance with the web page GDAL
>> Utilities http://www.gdal.org/gdal_utilities.html Creating New Files
>> I
Following Frank's suggestion, and in accordance with the web page GDAL
Utilities http://www.gdal.org/gdal_utilities.html Creating New Files
I issued these GDAL commands
$ gdal_translate --version
GDAL 1.7.2, released 2010/04/23
$ gdal_translate -of GTiff -ot Uint16 -a_srs NAD83_UTM18N.wkt in.tif
What is the EPSG code for NAD 1983, UTM Zone 18N?
Where does one go to lookup the EPSG code for a projection?
Greg
On Jul 5, 2010, at 8:53 AM, Monica Buescu wrote:
> Hi
> I don't want to interrupt or disturb the conversation but, wouldn't it be
> much better to just use EPSG code for NAD 1983, U
eoTiff
Origin = (271500.000,4335000.000)
Pixel Size = (38.385826771653548,-38.385826771653548)
gdalinfo report for gdal_translate output GeoTiff
Origin = (-78.0009998,40.0005515)
Pixel Size = (0.92592592593,-0.92592592593)
Is there another necessary
gdal_translate -a_srs provides for the output file to be in a different
projection than the input file.
What is the syntax for telling gdal_translate -a_srs to use the projection
shown by gdalinfo to be used in the GeoTiff below, which is NAD 1983, UTM Zone
18N?
Greg
$ gdalinfo dcua_reduce7.tif
With GDAL 1.7.2, released 2010/04/23, I used gdalbuildvrt to build a .vrt file
that points to 726 GeoJPEG2000 images. Then, I use QGIS 1.5.0, release 13519M
to pan and zoom through these images. When zoomed in, how do I get Qgis to
identify which ONE of the raster images in the .vrt file is curr
GDAL version 1.7.2 source code is not yet available from
http://trac.osgeo.org/gdal/wiki/DownloadSource
Greg
On Thu Apr 29, 2010, at 9:15 AM, Frank Warmerdam wrote:
> Konstantin Baumann wrote:
Motion: GDAL/OGR 1.7.3 RC2 is declared the official 1.7.2 release.
>>> I presume you meant "G
Open source ImageMagick, according to
http://www.imagemagick.org/script/formats.php , supports the "Sun Rasterfile"
format, that, according to http://www.fileformat.info/format/sunraster/egff.htm
, begins with a 32 byte header. The Sun Rasterfile format does not store
georeferencing metadata.
G
A .tif file in organized such that it begins with a very small header, is
followed by all of the pixels, and then the file ends with the TIFF tags.
So, if one wanted to change or set for example the TIFF resolution tags, there
are three resolution tags: XResolution=282, YResolution=283, and
Reso
Indeed I do!
The fixed & enhanced code for frmts/jp2kak/jp2kakdataset.cpp was actually
available before GDAL 1.7.0 was released, but Frank elected not to include it,
and I was given assurances at that time by Frank that the fixed
jp2kakdataset.cpp would be include in the next release of GDAL. GD
rsion.
I think I am supposed to vote numerically: -1 Greg Coats
Greg
On Feb 8, 2010, at 2:58 PM, Frank Warmerdam wrote:
> Folks,
>
> I have prepared a GDAL/OGR 1.7.1 release candidate at:
>
> http://download.osgeo.org/gdal/gdal171RC1.zip
> http://download.osgeo.org/gd
Frank,
Thanks for preparing this GDAL 1.7.1 Release Candidate 1.
I observe that line 2578 of frmts/jp2kak/jp2kakdataset.cpp has the old
needlessly restrictive
if( dfQuality < 1.0 || dfQuality > 100.0 )
even though you had replaced that restriction on or before 25 Jan 2010 with the
less restrictiv
You are using the source code for what version of GDAL? Greg
On Feb 7, 2010, at 5:27 PM, jl...@ualg.pt wrote:
> Hi,
>
> I'm getting these (and more) errors while trying to build libecw on Mac OSx
> 10.6.
> I could build on the previous cat, but not now on SL.
> Any one did that?
>
> Thanks
>
Even though GDAL 1.7.0 RC1 was released on 19 Jan 2010, and GDAL 1.7.0 RC1 is
GDAL 1.7.0, GDAL 1.7.0 is also not available to the Apple Mac OS X community
from http://www.kyngchaos.com , and since GDAL 1.7.0 is being retracted, I
doubt that GDAL 1.7.0 will ever be available to the Mac OS X commu
What not try using the Jan 2010 GDAL 1.7.0, rather than the Jan 2009 GDAL
1.5.4? Greg
On Feb 3, 2010, at 7:10 PM, Gregor at HostGIS wrote:
> I then rebuilt GDAL/OGR 1.5.4
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailm
For example, all TIFF files begin with a header that starts with an endianness
indicator, that is 0x49 for little endian and 0x4D for big endian. Greg
On Feb 3, 2010, at 12:38 PM, Chaitanya kumar CH wrote:
> Alejandro,
>
> The endianness may be in the image file header. What format is it?
>
>
Even Rouault offers GDAL 1.7.0 compiled for Ubuntu at
http://even.rouault.free.fr/
On Feb 3, 2010, at 3:14 AM, Mattias Carlsson wrote:
> Thanks, that says version is 1.5.4. I guess an upgrade might do the trick.
> However, as I am very green in Linux, I have yet to compile my first source
> an
Use gdal_translate --version
Since you told me that you are using GDAL version 1.5.0 from December 2007, I
suggest that you upgrade to GDAL 1.7.0 from January 2010. Greg
On Feb 2, 2010, at 4:01 PM, Mattias Carlsson wrote:
> Hi,
>
> I am trying to learn how to use ogr2ogr to convert a shapefile
, Antonio Valentino wrote:
> Hi Greg,
>
> Il giorno Sun, 31 Jan 2010 14:58:19 -0500
> Greg Coats ha scritto:
>
>> Regarding the diff function
>> "diff": computes the difference between 2 raster bands (b1 - b2)
>> Since the result of diff could be a negative n
Yes, GDAL can successfully process images with 15,000 columns by 15,000 rows. I
have used GDAL on a computer with only 3 GB RAM to process an image with Image
Width: 260,000 Image Length: 195,000. What version of GAL are you using? Are
you using GDAL 1.7.0? What operating system are you using? H
Regarding the diff function
"diff": computes the difference between 2 raster bands (b1 - b2)
Since the result of diff could be a negative number, for example 99-150=-51, I
suggest that there be an additional function that provides the absolute value
of diff, which would be 51 in this example.
Gre
On Jan 28, 2010, at 3:13 AM, Peder Axensten wrote:
> What is the raster size restrictions in gdal/numpy?
I have successfully used gdal_merge.py to create a 142 GB .tif file, on a
computer with only 3 GB RAM, under Apple Mac OS X 10.6. Greg
tiffinfo dcua0002.tif
Image Width: 26 Image Lengt
As a practical matter, I do not see this restriction in GDAL. On Thu 21
Sep 2006, I created with gdal_merge.py a 3 GB .tif having 18,400 columns by
52,800 rows by RGB. On Thu 11 Dec 2009, gdal_translate processed a 150 GB
untiled .tif to a tiled .tif with 260,000 columns by 195,000 rows. Gr
I find that GDAL version 1.6.3, released 2009/11/19, gdal_translate fully
supports reading and writing a 150 GB GeoTiff image 260,000 columns by 195,000
rows by RGB. Greg
$ tiffinfo dcua0002_BigTiffYES.tif
Image Width: 26 Image Length: 195000
Tile Width: 512 Tile Length: 512
Resolutio
Since GDAL supports BigTiff, there is no practical limit on GDAL .tif file
size. Also, with Kakadu JPEG2000 there is no practical limit on .jp2 file size.
Greg
On Jan 8, 2010, at 12:41 AM, srweal wrote:
> Unfortunately, due to file sizes, other file formats like TIF are not
> feasible.
I have a simple .tif, created in Photoshop, that consists of a horizontal line,
a vertical line, and some text, and that (thanks to Frank) is now a
georeferenced GeoTIFF. Is there a command line tool that will read in the
georeferenced GeoTIFF and write out a georeferenced vector file, likely a
image_in1.tif is a .tif without georeferencing info. image_in2.tif is a .tif
with georeferencing info. What do I add to the gdal_translate command below so
that the output image_out3.tif, whose pixels will be identical to the pixels in
image_in1.tif, will include the georeferencing info in image
000],PARAMETER["false_northin
> g",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]
> ],AUTHORITY["EPSG","26711"]]
> 4.4072e+005, 6.e+001, 0.000
> 0e+000, 3.75132000e+006,
> 0.
I am running the 31 Dec 2009, Qgis version 1.4.0 Enceladus, code revision
12644, compiled for Mac OS X 10.6, downloaded from http://www.kyngchaos.com
The problem I am having is that while files created by GDAL 1.6.3, released
2009/11/19 gdalbuildvrt that include in the .vrt file absolute paths w
, Even Rouault wrote:
> I was a bit confused by what your 2 screenshots showed. I know suppose that
> they show 2 VRTs layers.
On Jan 4, 2010, at 5:59 PM, Even Rouault wrote:
> Greg Coats a écrit :
>> I do not think I want the black, opaque areas that gdalbuildvrt is making u
I do not think I want the black, opaque areas that gdalbuildvrt is making up
for areas where there is no imagery to become transparent and remain black, I
want them to be white and opaque. Surely, there are many places in the RGB
images where one or more bands is already set to the value 255, an
By default, gdal_merge.py starts by creating an output image with all black
pixels, and then replaces these black pixels with pixels from the images being
read in. Passing to gdal_merge.py -init 255 pre-initializes the output image to
all white, instead of all black, pixels.
Similar to gdal_merg
I think the year for GDAL 1.7.0 should be 2009, instead of 2008. Greg
On Dec 4, 2009, at 12:16 PM, Roger Bivand wrote:
$ gdalinfo --version
GDAL 1.7.0dev, released 2008/11/26
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/
On Oct 14, 2009, at 12:40 PM, Greg Coats wrote:
How does one specify that gdalbuildvrt save relative paths, rather
than absolute paths?
On Oct 14, 2009, at 12:59 PM, Jürgen E. Fischer wrote:
Looks like that isn't supported directly yet.
Since Qgis supports saving relative paths, it
dcua_00.30m_BostonBlvd_8x8_BigTiff=YES.tif | grep Image
Image Width: 4 Image Length: 36000
Greg Coats
Reston, Virginia, USA
On Nov 10, 2009, at 11:34 AM, Jennings Jay wrote:
PS I’d like to query the output file to learn the pixel sizes, but
gdalinfo doesn’t give that for some reason. Can anyone suggest a
means to
According to http://www.gdal.org/frmt_gtiff.html , for a .tif
composed of stripes, rather than tiles, GeoTIFF defaults to setting
the size of a strip to be 8K bytes. This default can be over ridden
by using BLOCKYSIZE=n. When working with images > 200MB, 8K seems to
be particularly small. O
Compiling GDAL version 1.6.2's Kakadu based JPEG2000 support in frmts/
jp2kak/jp2kakdataset.cpp with gcc version 4.2.1 yields from the "Set
some user-overridable parameters." section the following warning 15
times jp2kakdataset.cpp:2472: warning: deprecated conversion from
string constant to
Your reference to lanscoz is likely referring to Lanczos resampling
http://en.wikipedia.org/wiki/Lanczos_resampling
The gdalwarp man page shows that it supports 5 resampling methods:
near, bilinear, cubic, cubicspline, lanczos.
http://www.gdal.org/gdalwarp.html
Greg
On Oct 15, 2009, at 4:00 AM
I develop on one computer, and then deploy on other computers. For
example, I develop on a desktop computer with many external hard
drives, and then deploy on a notebook computer with only an internal
hard drive. Additionally, I develop using a desktop computer's
external hard drives, and t
Because JPEG2000 images inherently contain a pyramid of reduced
resolution images, the Kakadu Software demo application kdu_expand,
that is available for free for Win32, Mac OS X, Linux, Solaris,
provides a very fast way to create reduced resolution overview images.
For me, the kdu_expand -
Greg Coats :
I have one .tif that has tag 700 XMP metadata, and has a tag 33723
IPTC metadata, but does not have tags 33550, 33922, 34264, 34735,
34736, 34737 georeferencing metadata. I have a second .tif that has
does not have tag 700 XMP metadata, nor does it have tag 33723 IPTC
metadata, but it
I support Frank's suggestion, and note that it is my understanding
that when the user does not specify a value for --config
GDAL_CACHEMAX, then the default of (only) 40 MB is used.
In January 2009, working with GDAL version 1.6.0, I did some testing
and documenting of the effect of GDAL_CAC
The GDAL default value for GDAL_CACHEMAX is 40 MB. I routinely set up
my gdal_translate scripts to run with a larger value for GDAL_CACHEMAX.
export GDAL_CACHEMAX_value=50
gdal_translate --config GDAL_CACHEMAX ${GDAL_CACHEMAX_value}
In my benchmark tests, I have observed that thi
I have one .tif that has tag 700 XMP metadata, and has a tag 33723
IPTC metadata, but does not have tags 33550, 33922, 34264, 34735,
34736, 34737 georeferencing metadata. I have a second .tif that has
does not have tag 700 XMP metadata, nor does it have tag 33723 IPTC
metadata, but it does
On Aug 22, 2009, at 4:51 AM, Hermann Peifer wrote:
Just to repeat my earlier observations: over the last days, I tried
with all kinds of -wm and GDAL_CACHEMAX settings, and also added
the options TILED=YES and SKIP_NOSOURCE=YES. I haven't documented
the performance changes systematically, b
G2000 library I have to
specifically load or something?
From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org
] On Behalf Of Greg Coats
Sent: 18 August 2009 15:44
To: Smart, Gary
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Converting to J2K
$ gdal_tran
$ gdal_translate --version
GDAL 1.6.2, released 2009/07/31
$ gdal_translate -of JPEG2000 18stj940125.tif 18stj940125.jp2
Input file size is 5000, 5000
0...10...20...30...40...50...60...70...80...90...100 - done.
FYI The convention for JPEG2000 image files is to use the
extension .jp2.
Greg
On
s if it gets the job done.
But even with this statement:
gdal_retile --config GDAL_CACHEMAX 4000-v -s_srs EPSG:28992 -of ECW
-ps 17335 16000 -targetDir tiles large.ecw
I get the Memory error.
Do you also have any suggestion on that. Would be very much
appreciated.
Thanks,
Paul
2009/8/14
It is my understanding that the default is
gdal_translate --config GDAL_CACHEMAX 40 ...
which equates to 40 MB of memory.
If you want to allow gdal_translate to use say 2 GB of memory for
GDAL_CACHEMAX, enter
gdal_translate --config GDAL_CACHEMAX 2000 ...
In my experience, increasing GDAL_CACHE
develop
the QGIS project file. If you are interested, then please contact me.
Greg Coats
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
The code in 1.6/gdal/frmts/jp2kak/jp2kakdataset.cpp calls upon the
http://www.kakadusoftware.com/ JPEG2000 software to display, read,
and write .jp2 files. This code has not been updated since 2002, and
does not take advantage of any of the major advances in the Kakadu
JPEG2000 software, i
geojasper includes a utility that conveniently compares a GeoTif
image to a GeoJp2 image. Greg Coats
$ geoimgcmp
Image Comparison Utility (Version 1.900.1).
usage:
geoimgcmp -f reference_image_file -F other_image_file [-m metric]
The metric argument may assume one of the following values
I have 3 single band GeoTIF images of the same geographic area: one
for the Red band, one for the Green band, and one for the Blue band,
gtif_R.tif, gtif_G.tif, gtif_B.tif. Please, what is the
gdal_translate syntax http://www.gdal.org/gdal_translate.html to
combine these 3 single band GeoT
I have 3 single band GeoTIF images of the same geographic area: one
for the Red band, one for the Green band, and one for the Blue band,
gtif_R.tif, gtif_G.tif, gtif_B.tif. Please, what is the
gdal_translate syntax http://www.gdal.org/gdal_translate.html to
combine these 3 single band GeoT
68 matches
Mail list logo
