Graeme,
Can you try again with a much larger interval?
On Thu, Oct 13, 2011 at 6:32 AM, Graeme Merrall wrote:
> I'm trying out gdal_contour just to see what falls out of it as an
> experiment. I've noticed it seems to get to "0.." e.g. 7% or so, and
> then seems to hang. I'm trying it on a re
Jay,
Can you provide a small sample image that shows this problem?
On Thu, Oct 13, 2011 at 7:35 AM, Jay L. wrote:
> I have a series of raster images (GTiff) that are causing ArcMap10 to hang.
> After trying a number of different things (32bit to 8bit, translate to
> another format, compression
I have a series of raster images (GTiff) that are causing ArcMap10 to hang.
After trying a number of different things (32bit to 8bit, translate to
another format, compression, tiling, etc.) I suspect that the issue could be
with the interleave. Gdalinfo shows that INTERLEAVE=BAND. The GTiff driv
I'm trying out gdal_contour just to see what falls out of it as an
experiment. I've noticed it seems to get to "0.." e.g. 7% or so, and
then seems to hang. I'm trying it on a relatively small DTM
The cmdline is pretty simple "gdal_contour -a ELEL -i 1.0
dtm_11072101.tif dtm-1m.shp"
and gdalinf
Thanks Brian,
I'll give it a try.
Regards
On 12 October 2011 13:00, Brian Case wrote:
> Travis,
>
> you have to run gdal_fillnodata on each band, then splice the outputs
> back together.
>
> if the nodata areas on the inside do not connect to the outside area you
> could create an alpha band
>
>
Travis,
you have to run gdal_fillnodata on each band, then splice the outputs
back together.
if the nodata areas on the inside do not connect to the outside area you
could create an alpha band
### -color 0,0,0 assumes odata value of 0
nearblack -dstalpha -near 0 -nb 0 -setalpha -color 0,0,0 \
Hi,all
Today,Alex Mantaut provided a code which can get some Cosmosky-med
HDF5 file metadata and georeference(including Gcps).
The patch:
http://trac.osgeo.org/gdal/attachment/ticket/4160/hdf5_csk_111011.patch
http://trac.osgeo.org/gdal/attachment/ticket/4160/hdf5_csk_111011.patch
Le 23/07/2011 16:17, Михаил a écrit :
Hello, everybody.
I have some images in TIFF format created in Photoshop. Also, I have
georeferncing for each file in txt.
If I'm working with BMP files, then i have no problems - I can use this
command line for example
gdal_translate -co COMPRESS=LZW -co JPE
Hello, everybody.
I have some images in TIFF format created in Photoshop. Also, I have
georeferncing for each file in txt.
If I'm working with BMP files, then i have no problems - I can use this
command line for example
gdal_translate -co COMPRESS=LZW -co JPEG_QUALITY=100 -a_srs "+proj=utm
+zon
I have some RGB orthophotos that have interior holes, typically 1
pixel. Most of the images have "valid" nodata around the edges. I
would like to fill the interior holes while maintaining the valid
nodata around the edges. I have tried gdal_fillnodata.py but cannot
get the utility to return a mu
Dear all,
Re: http://trac.osgeo.org/gdal/ticket/3638
The current version of the SOSI driver depends on a library called FYBA.
This library is about to be made open source under a MIT/X licence. That
means, we could legally include it fully in the SOSI driver, and I would
like to start a discussio
Well, at least you can guess that the prime meridian is Greenwich and
not Rome.
Good luck!
Sig
Il giorno mer, 12/10/2011 alle 12.19 +0200, emmexx ha scritto:
> Il 10/12/2011 12:10 PM, Luca Sigfrido Percich scrisse:
> > Yes, in that case you need to store in a file the WKT implementation of
> > t
Il 10/12/2011 12:10 PM, Luca Sigfrido Percich scrisse:
> Yes, in that case you need to store in a file the WKT implementation of
> the CS and add the -s_srs "file.prj" option.
>
> Before doing this, have you tried -s_srs EPSG:4806 ?
I tried that to no avail.
The transformed coordinates are wrong.
Hi,
if I use gdalwarp to convert a geotiff with nodata set into another one I get a
bad result. The nodata value is not taken over and gdalwarp replaces these
pixel with whatever colorindex it is. Example files can be found here:
www.qlandkarte.org/files.tar.gz
f1.tif is the source and f2.tif
Yes, in that case you need to store in a file the WKT implementation of
the CS and add the -s_srs "file.prj" option.
Before doing this, have you tried -s_srs EPSG:4806 ?
http://spatialreference.org/ref/epsg/4806/
It uses international 1924 and not Rome 1940 spheroid, though.
Sig
Il giorno mer
Il 10/11/2011 09:50 AM, Luca Sigfrido Percich scrisse:
> Hi Max,
>
> have you tried
>
> ogr2ogr -t_srs EPSG:4326 -f "one of many formats" outputfile myshape.shp
>
> As ogrinfo recognizes the source shape CS (I guess it has a .prj file
> associated with it), you should only transform (-t_srs) int
16 matches
Mail list logo
