ahmet,
The gdaldem color-relief utility uses the color entries from a text file
which is given as the argument color_text_file. If you did create a map
using gdaldem color-relief, you should already have the file. Use the
entries from it.
On Wed, Sep 22, 2010 at 1:12 AM, ahmet temiz wrote:
> So
Chris,
Shapely is my backup plan. I have, essentially, wrapped shapely in gdal
using the load and dump wkt options before, but would love to be able to
access geos without any work arounds.
Thanks!
Jay
On Wed, Sep 22, 2010 at 2:02 PM, Christopher Barker
wrote:
> Jay L. wrote:
>
>> If not, wha
Jay L. wrote:
If not, what is the best place to look for information on enabling GEOS
in GDAL?
I don't know about that, but another way to use geos in Python is to use
Shapely:
http://pypi.python.org/pypi/Shapely
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Divisi
>As we are running out of 1.x numbers (1.8.0 hopfully coming out soon),
I'm
>thinking about a 2.0 release for something like the fall of 2012 - just
in
>time for the world to end.
That should simplify keeping track of the EPSG codes...
Doug
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 1
Afternoon all,
I have both FWTools and GDAL 1.6 (with the python bindings) installed
(windows7). I have a pair of scripts that I would like to use the GEOS
functionality with (intersection and buffer). I believe that FWTools
installed GEOS. Is there a way to use the GEOS installed FWTools from
Folks,
In IRC I was just mentioning to Howard that we might want to drop use of
CPL_STDCALL in the GDAL API if a 2.0 release ever occurs. It seemed to me
that such ideas ought to be kept track of so off the "Developer" section of
the Trac wiki I have created a page for this and pre-populated it
+1
I'll take care of adding the UTF-8 support in the C# bindings.
Best regards,
Tamas
2010/9/22 Frank Warmerdam
> Motion: I move to adopt RFC 30: Unicode Filenames.
>
> http://trac.osgeo.org/gdal/wiki/rfc30_utf8_filenames
>
> --
>
> I have made a variety of adjustments and improvements ba
Christiaan,
you can try creating your TIFF with the SPARSE_OK=YES creation option. This
will avoid writing unfilled blocks at dataset closing. However, in the normal
situation where you don't interrupt your dataset creation processus, if you
don't write all blocks, the resulting file will be sp
Le mercredi 22 septembre 2010 01:19:02, Frank Warmerdam a écrit :
> Motion: I move to adopt RFC 30: Unicode Filenames.
>
>http://trac.osgeo.org/gdal/wiki/rfc30_utf8_filenames
+1
Even
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.o
ahmet,
I can't understand why the error occurs. Can you provide a sample data that
gives this error?
On Wed, Sep 22, 2010 at 4:53 PM, ahmet temiz wrote:
> thank you for your interest
>
> here it is:
>
> or...@orkun-desktop:~/data/pro1001/yuk$ gdalinfo work1.tif
> Driver: GTiff/GeoTIFF
> Files:
Chaitanya,
Thanks for the help, but it didn't change anything. If it helps, I'm using gdal
1.7.2 with python 3.1 and numpy 1.5.
Cheers,
Andy
From: Chaitanya kumar CH [mailto:chaitanya...@gmail.com]
Sent: 22 September 2010 16:11
To: Hartley, Andrew
Cc: gdal-dev@l
Andy,
Try this instead.
out = outDrv.Create("outfile.tif", gscl.RasterXSize, gscl.RasterYSize, 1,
gdalconst.GDT_UInt16, *options = *[ 'COMPRESS=LZW' ] )
However, I am not sure this makes any difference because gdalinfo did tell
that there is LZW compression.
On Wed, Sep 22, 2010 at 4:41 PM, Har
Christiaan Janssen wrote:
Is there a way to quickly close a large dataset using the API? For
instance, I'm writing to very large TIFF file at which point the user
cancels, the code in turn stops what it's doing, closes the dataset, and
deletes the file. The problem is, since the file is around
Is there a way to quickly close a large dataset using the API? For instance,
I'm writing to very large TIFF file at which point the user cancels, the
code in turn stops what it's doing, closes the dataset, and deletes the
file. The problem is, since the file is around 5GB the close dataset
function
On Sep 22, 2010, at 5:58 AM, Chris Yesson wrote:
> Thanks to everyone for the comments.
> I have tried to fit the options in with the gdal-calc summer of code
> outline.
> Vince's code seems to be doing pretty much the same thing as mine but
> with slightly different options.
> At least if we p
Eccellente!
But strange. I have a system just like yours and I don't need to do that. :!
Regards,
Ivan
> ---Original Message---
> From: Massimo Di Stefano
> To: Massimo Di Stefano
> Cc: gdal-dev
> Subject: Re: [gdal-dev] svn build on mac osx 10.6.4 (errors in GDALmake.opt)
> Se
Thanks to everyone for the comments.
I have tried to fit the options in with the gdal-calc summer of code
outline.
Vince's code seems to be doing pretty much the same thing as mine but
with slightly different options.
At least if we post one version it will save someone else doing this
again.
I w
thank you for your interest
here it is:
or...@orkun-desktop:~/data/pro1001/yuk$ gdalinfo work1.tif
Driver: GTiff/GeoTIFF
Files: work1.tif
Size is 4716, 5481
Coordinate System is `'
Origin = (436921.7120955,4648461.9372529)
Pixel Size = (20.000,-20.000)
Imag
Ivan,
$: python --version
Python 2.6.1
$: printenv | grep python
$: whereis python
/usr/bin/python
Thanks!
Massimo.
Il giorno 22/set/2010, alle ore 13.05, Ivan Lucena ha scritto:
> Massimo,
>
> if you just run "/.configure" it should show:
>
> --
> ...
> checking for python bindings... d
> Hi all,
>
> I'm trying to create a Gtiff with LZW compression using python, with
> the code below, which I wrote with help from the tutorial at
> http://www.gdal.org/gdal_tutorial.html. Gdalinfo tells me that the
> resulting tif ("outfile.tif") has compression (Image Structure
> Metadata: COMPRE
Massimo,
if you just run "/.configure" it should show:
--
...
checking for python bindings... disabled
...
SWIG Bindings: no
...
--
Then you can just run make and it should be fine. Even if you want to use
GDAL+Python.
Did you install any additional Python distribution on top of wh
ahmet,
This error is reported by the grass library.
Is "work1.tif" in TIFF format? Can you post the output of gdalinfo on
work1.tif for more info?
On Wed, Sep 22, 2010 at 1:50 PM, ahmet temiz wrote:
> hello
>
> can you tell me what this problem is ?
>
> or...@orkun-desktop:~/data/pro1001/yuk$ p
Fixed using the path to python-config during the ./configure :
--with-python=/usr/bin/python2.6-config
Il giorno 22/set/2010, alle ore 09.07, Massimo Di Stefano ha scritto:
> Hi ,
>
> any clue about this message :
>
> "GDALmake.opt:50: *** missing separator. Stop. "
>
> i have it tring to
hello
can you tell me what this problem is ?
or...@orkun-desktop:~/data/pro1001/yuk$ python gdal_fillnodata.py -md
100 work1.tif dem1.tif
ERROR 1: libgrass: MAPSET is not set
Aborted
regards
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lis
Hi ,
any clue about this message :
"GDALmake.opt:50: *** missing separator. Stop. "
i have it tring to run "make "
on mac osx 10.6.4
1
2
3
4
5
6
7
8
9
10
11
12
PYTHON_INCLUDES = @PYTHON_INCLUDES@
PYTHON_LIBS = @PYTHON_LIBS@
PYTHON_CFLAGS = @PYTHON_CFLAGS@ @NUMPY_FLAG@
PYTHON = py
25 matches
Mail list logo
