On Tue, 23 Feb 2010 23:00:31 +0100 Even Rouault
wrote:
> you can try the following tricks to remap your nodata value from
> -32768 (this is type typical value for most DEM) to 0 :
>
> 1) gdalwarp -srcnodata -32768 -dstnodata 0 src_dem.tif out_dem.tif
Thanks, that helped. I had to run gdalwarp a
Benjamin Welton wrote:
Hey,
Iv got a question on whether or not its possible to read a single
pixel value from multiple bands using one GDAL call in python? The file
working with is an ENVI BIP file that has a large number of bands
(around 1000) and im looking for a way to reduce the pytho
I have written a C++ application that uses GDAL libraries for raster analysis.
The compiling crashes when trying to link to gdal libraries. I am getting an
error for every GDAL object such as:
[Linker error] undefined reference to `GDALAllRegister'
[Linker error] undefined reference to `GDALO
Hey,
Iv got a question on whether or not its possible to read a single
pixel value from multiple bands using one GDAL call in python? The file
working with is an ENVI BIP file that has a large number of bands
(around 1000) and im looking for a way to reduce the python overhead by
only maki
On Wed, 03 Feb 2010 09:54:10 -0500, Travis Kirstine wrote:
> I have a general question regarding how to handle the null values with 1
> band byte grey scale images. Typically I will receive a image with
> pixels at the edges of a image with a value of 0 however some of the
> interior pixel value
Thanks for your patience,
The metadata about my file is wrong because it is the metadata from the
deriving 32 bit file. If I calculate the statistics of my new 8 bit file
(which i do in ArcGIS, i dont know if GDAL does this?), then the statistics
are correct, but ArcGIS also applies a standard de
Ytrapaet,
There is no such thing as an 'associated color table' in strict
TIFF meaning. In the specific case of DEM TIFF you have either one of
two cases: 1) a grayscale TIFF that is generated using some sort of
mapping between raw elevation values and grayscale colors. If the
mapping is 1
Hi!
Any progress on this? I am having exactly the same problem. I am using GDAL
1.6, Python binding 1.6 for python 2.6 on a Windows 7 64bit machine.
When I try to use gdal_merge.py, python crashes with the same error message
in ntdll.dll.
Any ideas on how to fix this?
bye
Nop
--
View
Hum, then I have no clue. Yes I tested with a dataset with zeros.
You can file a ticket on Trac with the dataset and the .clr file attached,
provided that the dataset is not too big (no more than 1 MB). Otherwise,
you'll have to provide a link to the dataset.
Le Tuesday 23 February 2010 22:26:4
Maxime,
you can try the following tricks to remap your nodata value from -32768 (this
is type typical value for most DEM) to 0 :
1) gdalwarp -srcnodata -32768 -dstnodata 0 src_dem.tif out_dem.tif
2) or gdalbuildvrt -srcnodata -32768 -vrtnodata 0 out_dem.vrt src_dem.tif
(you need GDAL 1.7.1 for
Hmm! Thanks, that is definitely not something I would have checked--However, I
don't think it's my problem. I checked my .clr file I'm running, and I don't
see anything out of the ordinary:
$ xxd T_SFC.clr
000: 2d34 302e 3020 2031 3237 2032 3535 2032 -40.0 127 255 2
010: 3535 0a2d 333
Hi all,
I am trying to have gdal_contour operate on SRTM data from CGIAR
(http://srtm.csi.cgiar.org/). The problem is that this dataset has
oceans set to "nodata". This creates ugly artifacts along the shores
(you can see an example here on the red lines:
http://www.mguillaud.net/tmp/Screenshot.pn
I think the problem lies in you .clr file. I pasted the content from the email
into a file, and when looking with an hexadecimal editor, I see that there
are several instances of a strange hexadecimal sequence "0xc2 0xa0" that is
used as a separator between the figures. If your original .clr fil
Hello List,
I may have encountered a bug in gdaldem color-relief. When I use it to apply a
color map to a GeoTIFF band that has positive and negative and zero values, the
zero pixels are always translated as having alpha 0, even if the color map file
explicitly states zero values should be opaq
Frank Warmerdam wrote:
> Mateusz Loskot wrote:
>>> It *seems* like a bad idea to embed such behavior in a particular
>>> driver.
>>
>> Yes, I understand your point. Perhaps I should narrow the test with
>> check if URL consists of "geojson" token, like
>> http://server/path/geojson/1234 or ftp://s
Mateusz Loskot wrote:
It *seems* like a bad idea to embed such behavior in a
particular driver.
Yes, I understand your point.
Perhaps I should narrow the test with check if URL consists of "geojson"
token, like http://server/path/geojson/1234 or
ftp://server/path/file.geojson and if not present
Frank Warmerdam wrote:
> Stephan Holl wrote:
>> Hello,
>>
>> I am trying to use ogrinfo with a URL to a KML-file. I have compiled
>> gdal 1.7.1 with libcurl, so it _should_ do that.
>>
>> The Errormessage is the following:
>> ogrinfo
>> "http://mw1.google.com/mw-earth-vectordb/haiti/Haiti-Earthqua
Frank Warmerdam wrote:
> Mateusz Loskot wrote:
Is this a known issue that ogrinfo does not work with remote URLs?
>>> Stephan,
>>>
>>> I am not aware of any support in OGR for working on remote urls.
>>> There is
>>> an http driver in GDAL that sort of supports this for rasters, but I
>>> don
Mateusz Loskot wrote:
Is this a known issue that ogrinfo does not work with remote URLs?
Stephan,
I am not aware of any support in OGR for working on remote urls. There is
an http driver in GDAL that sort of supports this for rasters, but I don't
think the same thing exists in OGR.
Frank,
G
anotherObject wrote:
Sorry for not being clearer: I started off with a a 32bit tif - however, im
not sure how I can tell if it has an associated color table.
Ytrapaet,
Try running gdalinfo against the file and seeing what it reports. Including
a gdalinfo report with your email would make it
6dev in FWTOOLS and I'm using 1.5.4 in Ubuntu OS (to work
with GRASS)
Thank you
Best regards
Antonio Rocha
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4890 (20100223) __
The message was checked by ESET NOD32 Antivirus.
http:/
Hi Frank
>Ytrapaet,
>
>If you had a 16bit DEM with no color information (such as a normal DTED
>for instance) the following command would convert to 8bit by linear scaling
>of the min/max to 0-255 without applying any color table. The implicit
>color interpretation of the result is greyscale.
>
Hi,
these days I'm trying to resurrect the GeoTools OGR datastore (a bridge
between the GeoTools data reading API and the OGR one).
Things are working fine, thanks for the nice job on the Java bindings.
The one problem I'm seeing at the moment is an issue trying to repack
shapefiles, when I run
Stephan Holl wrote:
Hello,
I am trying to use ogrinfo with a URL to a KML-file. I have compiled gdal
1.7.1 with libcurl, so it _should_ do that.
The Errormessage is the following:
ogrinfo "http://mw1.google.com/mw-earth-vectordb/haiti/Haiti-Earthquake-nl.kml";
ERROR 1: GeoJSON parsing error
anotherObject wrote:
I have successfully been using gdal_translate to convert some tifs. Viewing
my resulting 8 byte tifs through a GIS viewer, the color ramp is perfect.
However I converted these to 8 byte so i could further work with them in
photoshop.
When I open one of my 8 byte .tifs in p
I have successfully been using gdal_translate to convert some tifs. Viewing
my resulting 8 byte tifs through a GIS viewer, the color ramp is perfect.
However I converted these to 8 byte so i could further work with them in
photoshop.
When I open one of my 8 byte .tifs in photoshop, the DEM looks
26 matches
Mail list logo
