Even Rouault wrote:
>
> Yo say 'gdalmerge quits with an error', but you didn't mention the exact
> error
> message nor the command line you've used, so it is hard to tell what's
> wrong
>
Oh, that cause was obvious. Since the TIF had lost the georefence, there was
no overlap between the reque
Chaitanya kumar CH wrote:
>
> Since you said that gdalwarp did not work, try gdal_merge.py with the
> options "-n -332768 -init 0".
>
Thank you, this did the job!
Nop
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Handling-nodata-values-tp5222453p5224997.html
Sent
Chaitanya kumar CH wrote:
>
>
> In line 93 in val_repl.py, the default value is taken as of type Byte. For
> a
> quick fix, mention the data type of the raster reported by gdalinfo with
> the
> option -ot to the script. Refer to (
> http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/samp
Thank you for your reply. I played around a little bit but without success.
When I apply val_repl.py to the data, it appears to cut off all the higher
elevations while the lower areas remain untouched. So the resulting TIF is
unusable. What could cause this problem?
gdal_contour seems to recogn
Hi!
I am trying to create contour lines (and later hillshading) from CGIAR data.
They use –32768 as a nodata value for sea areas which results in tremendous
cliffs if the data is processed by gdal_contour as it is.
I am looking for a way to replace this nodata value in the geotiffs by a
simple
Tamas Szekeres wrote:
>
> If you could do a test with the binaries provided at
> http://vbkto.dyndns.org/sdk/ that would be helpful. It seems the python
> auto-tests are working well with these packages on a Win2003 Server x64
> platform.
>
I have downloaded a release from there. It looks a b
I am running the 32bit Versions of python and gdal.
bye
Nop
--
View this message in context:
http://n2.nabble.com/Gdal-Python-Win7-crash-with-ReadAsArray-tp4398401p4788484.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
_
Hi!
Eventually I had some time to look into this again.
First thing I tried is updating python to 2.6.5 - no change, still crashes.
Then I tried running exactly the same files in a 32bit XP virtual machine.
It works there. This is a workaround, but not a solution as I cannot run the
whole work
Hi!
I am still struggling with this problem. No ideas anybody? Or maybe a
recommendation for a better forum to adress this matter?
bye
Nop
--
View this message in context:
http://n2.nabble.com/Gdal-Python-Win7-crash-with-ReadAsArray-tp4398401p4712621.html
Sent from the GDAL - Dev
Hi!
A small update. I tried this again, with the 1.6.0 bindings and the 1.6.1
bindings and in the XP compatibility mode. Always the same crash.
Does any of you have an idea what might be the reason?
- Python 2.5 vs. 2.6 Problems?
- Windows 7 problem?
- 64 bit machine problem?
- missing dependen
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
Hi!
Frank Warmerdam wrote:
>
> NopMap wrote:
>> Is this also true for -projwin? From the documentation I got the
>> impression
>> that -srcwin requires meters while -projwin accepted the coordinates in
>> lat/lon??
>
> -srcwin takes the locations in pix
Hi!
Frank Warmerdam wrote:
>
> You need to specify the corners in the coordinate system of the
> image. So the values should be the meter based projected coordinates
> like 1102062,6818226.
>
Is this also true for -projwin? From the documentation I got the impression
that -srcwin requires m
Hi!
I am trying to make a GeoTiff a little bit smaller with gdal_translate.
Gdalinfo shows that the TIF has the following size:
Upper Left ( 1102062.959, 6818226.972) ( 9d54'0.00"E, 52d 6'0.00"N)
Lower Right ( 1692080.162, 6257943.762) ( 15d12'0.77"E, 48d54'0.71"N)
I call
gdal_translate -pro
Hi!
I am building a map with several layers containing OSM geometry and
hillshading+contours. The rendering chain for the hillshading is
SRTM GeoTiff -> gdal_merge -> gdal_warp -> hillshading.exe -> mapnik
Now I have the problem that the hillshading and the geometry do not
quite match. It seem
Hi!
Frank Warmerdam wrote:
>
> Also, high contour density
> can occur if there are crazy no-data values in the raster (ie. -1e7 in a
> floating point raster) which can trigger a huge "pile" of contours around
> the bad data value.
>
I think you are right. After another subdivision, both halv
Hi!
I have sudden problem with gdal_contour after using ist successfully many
times. There seems to be a problem with a certain area. When I tried it
first, gdal_contour quit with an out-of-memory message, exceeding 2GB of
virtual memory. When I reduced the area and called
gdal_merge.py -o M:\s
17 matches
Mail list logo
