weixj2003ld,
I couldn't open the link.
Try "gdalinfo -mm des.png" on both the output images. I think they will both
give the same output. UInt16 should give a dark image unless you perform
histogram equalization on it.
2010/5/11 weixj2003ld
> I download a elevation data (SRTM,GTOPO30) from
> ht
I download a elevation data (SRTM,GTOPO30) from
http://glcfapp.glcf.umd.edu:8080/esdi/index.jsp
use
gdal_translate -b 1 -of PNG -ot Byte source.tif des.png
and
gdal_translate -b 1 -of PNG -ot UInt16 source.tif des.png
differently,
with parameter 'UInt16',I get a black picture,with Byte,get a
On 10/05/2010 11:40 AM, Chaitanya kumar CH wrote:
Check if gdalinfo creates the xml files when used with the -stats option
on your images.
But be careful with 32bit float rasters. I just filed a bug on "gdalinfo
-stats" not computing min/max properly on these,
http://trac.osgeo.org/gdal/ticke
Hi Even,
Il giorno Mon, 10 May 2010 19:38:57 +0200
Even Rouault ha scritto:
> Please open a ticket in GDAL trac.
OK.
I just filed ticket #3572 (http://trac.osgeo.org/gdal/ticket/3572).
thanks
> Le Monday 10 May 2010 17:51:25 Antonio Valentino, vous avez écrit :
> > Hi,
> > I have a request fo
The reason is that .aux.xml files are generated only when it is necessary,
that is to say when the underlying base format cannot store the metadata.
You could just iterate through all your files and store the output of gdalinfo
in a file to fetch it layer. Or you could use 'gdal_translate -of VR
Check if gdalinfo creates the xml files when used with the -stats option on
your images. If it does, run it on all the images. I don't think there is a
much quicker way. The computation of the statistics is the bottleneck here.
On Mon, May 10, 2010 at 11:43 PM, Rubin, Jared wrote:
> That sucks.
Zermeno, Robert J CIV NAVAIR, 472100D wrote:
Frank,
Is there a specific order needed to read in the image pixels? Meaning, you
typically need to use the combination functions of:
1.
Redband = GDALRasterBand(dataset,1)
Blueband = GDALRasterBand(dataset,2)
Greenband= GDALRasterBand(dataset,3)
That sucks. I have hundreds of images on disk and would like to just have the
xml file for each file so that I can just do fast "greps" for specfic tags.
What is the reason behind this design choice? Also are any of the gdalinfo
calls quick?
Jared
-Original Message-
From: Chaitanya kuma
Please open a ticket in GDAL trac.
Le Monday 10 May 2010 17:51:25 Antonio Valentino, vous avez écrit :
> Hi,
> I have a request for GDAL developers.
> I would appreciate a lot if changes implemented in
>
> http://trac.osgeo.org/gdal/changeset/19651
>
>
> could be backported to 1.6 and 1.7 branches
Frank,
Is there a specific order needed to read in the image pixels? Meaning, you
typically need to use the combination functions of:
1.
Redband = GDALRasterBand(dataset,1)
Blueband = GDALRasterBand(dataset,2)
Greenband= GDALRasterBand(dataset,3)
2.
GDALRasterIO(redBand)
GDALRasterIO(Blueand)
Hi,
I have a request for GDAL developers.
I would appreciate a lot if changes implemented in
http://trac.osgeo.org/gdal/changeset/19651
could be backported to 1.6 and 1.7 branches.
I don't know if it is actually feasible but by sure my app would get a
great advantage.
Best regards
--
Anton
Hi,
But -al (without -so, "summary only") is listing all the features of all the
layers. It just happens to be that shapefile always has only one layer. Have
a try with Mapinfo tab file or some database with lots of tables and you will
notice that -al option does go through all the layers.
The manual page says:
*-al*:
List all features of all layers (used instead of having to give
layer names as arguments).
This is not a really clear answer for Antonio's question: when I read
this the first time, I thought this flag was meant to display
information about more layers, not
António Rocha deimos.com.pt> writes:
>
> Greetings
>
> I need to obtain a little bit more information regarding a Shapefile. I
> have done ogrinfo but I only obtained:
Hi,
What most users propably want to know about shapefiles first comes with
ogrinfo -al -so file.shp
Perhaps the manual
b-dataset and the data-format. I need
> information regarding projection/coordinates. How can I obtain it?
> Thanks
> Antonio
>
>
>
> __ Information from ESET NOD32 Antivirus, version of virus
> signature database 5100 (20100510) __
>
> The m
version of virus
signature database 5100 (20100510) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinf
d the data-format. I need
information regarding projection/coordinates. How can I obtain it?
Thanks
Antonio
__ Information from ESET NOD32 Antivirus, version of virus signature
database 5100 (20100510) __
The message was checked by ESET NOD32 Antivirus.
http://ww
Frank,
compilation went smooth using the --without-expat option.
On CentOS 5.4, expat cames as expat-1.95.8.
Thank you for your halp
Peter
Frank Warmerdam wrote
Subject: Re: [gdal-dev] Compilation problems on CentOS 5
Date: 07.05.2010 17:36
>Peter Hopfgartner wrote:
>> Hel
18 matches
Mail list logo
