Jorge,
On Mon, Oct 31, 2011 at 2:17 PM, Even Rouault
wrote:
> Selon Jorge Martin :
>> I am using RasterIO function to write tiff files. The problem
>> appears when the image size is aprox. 25000x25000 (500Mb), the last lines
>> of the image are not correctly written. The last lines are wri
Selon Jorge Martin :
> Hello,
>
>I am using RasterIO function to write tiff files. The problem
> appears when the image size is aprox. 25000x25000 (500Mb), the last lines
> of the image are not correctly written. The last lines are written with 0
> or 255 value. I have checked that if I on
That's what I usually do. I just convert my file to AAIGrid and use sed
to replace the nodata to a value I like J
Bob
Bob Moskovitz
Seismic Hazards Mapping Program
California Geological Survey
CONFIDENTIALITY NOTICE: This communication is intended only for the use
of the individual o
Hi Giovanni,
I've seen -3.4028234663852886e+038 (which is a huge negative value.
Your minds eye probably saw a "-" instead of "+") as a nodata value.
Regards,
Bob
Bob Moskovitz
Seismic Hazards Mapping Program
California Geological Survey
CONFIDENTIALITY NOTICE: This communicatio
Ops, you're right Bob. So the problem is the huge negative value... So the
problem is how to substitute it, maybe with a more treatable value outside
my raster range...
giovanni
2011/10/31 Moskovitz, Bob
> Hi Giovanni,
>
> ** **
>
> I’ve seen -3.4028234663852886e+038 (which is a huge nega
Hi,
I'm having some troubles with raster algebra on a raster with very small
(near zero, but not).
I'm using numpy (through python gdal) to do a multiplication, eg
numpy.multiply(rasterarr,2), but I obtain the following raster stats:
http://pastebin.com/hHiUrWwD.
I suppose that -3.4028234663852886
Hello,
I am using RasterIO function to write tiff files. The problem
appears when the image size is aprox. 25000x25000 (500Mb), the last lines
of the image are not correctly written. The last lines are written with 0
or 255 value. I have checked that if I only write a tiff file with the las
Jan,
Is the problem only with gdalwarp? Were you able to use the twf file with
gdal_translate? If it works with gdal_translate create a VRT file using it
and then use the VRT file in place of the original tiff.
gdal_translate -of VRT DOP_3905470.tif DOP_3905470.vrt
gdalwarp -s_srs EPSG:25832 -t_s
Jan,
GDAL's GeoTIFF driver checks for the twf file automatically while reading.
You can create this file manually.
On Mon, Oct 31, 2011 at 9:11 PM, Jan Tappenbeck wrote:
> **
> hi !
>
> i know this format - so add the parameter manuell ??
>
> no set a flag and then the twf will integrate automa
Jan,
[1]: http://www.gdal.org/frmt_various.html#WLD
On Mon, Oct 31, 2011 at 8:39 PM, Jan Tappenbeck wrote:
>
>
> Hi !
>
> this is a very strange way - i have tfw-file for the images.
>
> is there a possibility to integrate this information to the
> gdalwarp-command.
>
GDAL should automatically
Kat,
The method suggested by the message is the quick and clean method.
After creating the temp.vrt file with gdal_translate, you can use it with
the gdal2tiles script in place of the original tif.
On Mon, Oct 31, 2011 at 7:29 PM, katrin eggert
wrote:
> Hi
> I just did what you have told me and
Hi
I just did what you have told me and I got this error:
usage: Usage: gdal2tiles.py [options] input_file(s) [output]
gdal2tiles.py: error: Please convert this file to RGB/RGBA and run
gdal2tiles on the result.
>From paletted file you can create RGBA file (temp.vrt) by:
gdal_translate -of vrt -
Selon ahmet temiz :
> hello
>
> Using the gdal.jar,
> I am confused about getting other field values after obtaining FID.
>
> I got ly2.GetFeature(fid)) but when I used
> ly2.GetNextFeature().GetFieldAsString("koy"),
> I got exception.
Which exception ? Please be precise when you report issues.
hello
Using the gdal.jar,
I am confused about getting other field values after obtaining FID.
I got ly2.GetFeature(fid)) but when I used
ly2.GetNextFeature().GetFieldAsString("koy"),
I got exception.
What is the way to get other field values after getting fid value of a
particular record ?
rega
Dear Even,
On Fri, Oct 28, 2011 at 6:21 PM, Even Rouault
wrote:
>
> This sounds as another symptom of the precision loss issue that has been
> fixed
> for the ticket http://trac.osgeo.org/gdal/ticket/4292
>
> Fixed in GDAL 1.9.0dev
>
>
Thank you for your reply. I tested using gdal-svn-trunk-2011.
That might be the answer - or at least part of it, I still get brain fade
trying to work through projections and projection conversion.
I'll try and think this bit through again!
Here's the gdalinfo from the input file :
Driver: GTiff/GeoTIFF
Files: brw.tif
Size is 48243, 78372
Coordinate Syste
http://osgeo-org.1803224.n2.nabble.com/file/n6947649/tilersrc.tar.gz
tilersrc.tar.gz
Here's the source. It's a bit of lashup, but the principle bits that must
underly the problem are the tile and boundingbox classes (both pretty small)
and the pixoffsets and readtile functions in the gdshelper cl
Kat,
Do you want your browser to load the whole image in your window as a single
image? If so, you need to be running a WMS server. If not, please explain.
On Mon, Oct 31, 2011 at 2:35 PM, katrin eggert
wrote:
> Hi
> THanks for the feedback I will try it right now.
> Just one question: Is it pos
On 30/10/2011 20:16, Iain wrote:
But the tiles
I generate appear to be out about 1/4 degree too far north (look OK east
west) over the whole area. (the mapnik generated tiles, using background
from hill shade + colour-relief and data from openstreetmap in a postgis
database are all fine and matc
19 matches
Mail list logo
