Joaquim,
On Wed, May 12, 2010 at 5:07 AM, Joaquim Luis wrote:
> Hi,
>
> Before filling a ticket I would like to ask here if this gdalwarp behavior
> is the intended one.
> When I convert a grid from geogs to UTM the nodatavalues are filled with
> zeros.
> I get the expected behaviour if I use th
Hi,
Before filling a ticket I would like to ask here if this gdalwarp
behavior is the intended one.
When I convert a grid from geogs to UTM the nodatavalues are filled with
zeros.
I get the expected behaviour if I use the -dstnodata with a numeric
value, but I found no way tom tell it use NaN.
There is really no reason to remove the 1.7.2 you've built. If you're
going to install in the same location then all will be overwritten, if
you install in a new location then it might be best to cleanup the
unused stuff. I think you can do 'make uninstall' as well.
Cheers,
Brice
Allen Rongone
Brice,
Thank you for all your help. However, I did want to know if I need to
back out all the gdal-1.7.2 I just installed before I start over, or
can I just run the make clean/ configure /make /make install, again
after I remove the old gdal from the system? And if so, how would that
be
It really looks like a linking error, make sure that
/opt/GOESR/local/lib is in your LD_LIBRARY_PATH before /usr/lib or
/usr/local/lib. If you won't use it, it would probably be best to
remove all gdal stuff from yum just to avoid any confusion.
Also when you ran python setup.py install in the sw
Aleksey,
You cannot rename a field in an existing dataset, but while using ogr2ogr you
can indeed use -sql to do the renaming during the conversion.
For example : ogr2ogr outdataset indataset -sql "SELECT src_field1 AS
dst_field1, src_field2 AS dst_field2 FROM sourcelayer"
See http://gdal.org/
On May 11, 2010, at 1:19 PM, Brice Lambi wrote:
What is your python path?
# python
import sys
sys.path
What does that say? It might have linked against the wrong version of
gdal or it might be finding another gdal library in your path. If you
are using the default python (/usr/bin/python)
What is your python path?
# python
>>> import sys
>>> sys.path
What does that say? It might have linked against the wrong version of
gdal or it might be finding another gdal library in your path. If you
are using the default python (/usr/bin/python) it is probably finding
something in /usr/lib
Hi,
Another question on ogr2ogr: is there a way to rename a field while
converting a layer? E.g. using ogr2ogr to convert a personal geodatabase
layer with long field names to a shapefile, I'd like to avoid automatic
truncation of field names, e.g. from "long_field_name123" to "long_field". I
know
Brice,
I think I was using the tarball specific to the python module. I
think I downloaded the correct one now - gdal-1.7.2.tar.gz
I ran the configure script as such:
# ./configure --prefix=/opt/GOESR/local --with-python
Then a make
# make
T
I just stumbled on this while looking for something completely
different, shp2pgsql:
http://postgis.refractions.net/docs/ch04.html
The shp2pgsql data loader converts ESRI Shape files into SQL suitable
for insertion into a PostGIS/PostgreSQL database either in geometry or
geography format. The lo
Hi Allen,
Are you sure you are downloading the source tarball?
http://download.osgeo.org/gdal/gdal-1.7.2.tar.gz
Try that link then the steps listed below. If configure complains about
missing dependencies use yum to install those.
Good luck,
Brice
Allen Rongone wrote:
> Hi Brice,
>
> Wh
You can use shp2text:
http://www.obviously.com/gis/shp2text/
It won't output the insert statements directly but it will create a tab
delimited file that you could then parse into your database.
Aleksey Naumov wrote:
> Dear GDAL users,
>
> Is there a way to use ogr2ogr or other means to conver
Dear GDAL users,
Is there a way to use ogr2ogr or other means to convert a layer (e.g. a
shapefile) into an SQL text file suitable for insertion into PostGIS? In
other words, a file with SQL text like:
INSERT INTO "my_table" ("the_geom" ) VALUES (GeomFromEWKT('SRID=-1;POLYGON
(( ...))'::TEXT) );
Hi Brice,
When I download and untar gdal-1.7.1.tar.gz, there is no configure
script to run.
Here is a directory listing of what I get after untarring:
[r...@psd14 GDAL-1.7.1]# ls
build fallback_build.bat GDAL.egg-info gdal.py GNUmakefile
osgeo PKG-INFOsamples setup.cfg
Please keep me informed, perhaps we can do an improvement by adding a
command line argument for the cache size.
Quoting acangi :
Thanks for the quick reply. I think it makes sense.
First I'll try to move all data to a computing machine with a big hard disk,
then if it's still slow, I'll try
Thanks for the quick reply. I think it makes sense.
First I'll try to move all data to a computing machine with a big hard disk,
then if it's still slow, I'll try to increase self.cacheSize as you write.
As gdal_retile.py isn't computing the empty tiles, I guess I can use :
( pixel width of the
Hi, I am the developer of the gdal_retile.py
I think the problem here is based on the following issue.
To make a pyramid with tiles in the Dimension width * hight based and
already tiled image with the same tile width and height, I have to
load the base tile and all 8 neighbors touching the
Hello,
It looks like gdal_retile.py slows down when processing a new level of the
pyramid.
Source files : 8065 geotiffs orthophotos of 4000 x 4000 pixels, in total 400
GB.
Command : gdal_retile.py -targetDir pyramid/ -levels 12 -v -s_srs
/mnt/webgisdata/geoserver/config/3812.prj -ps 512 512 -r
I would also be interested in such information.
Suscribing to this post in case it gets replies.
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Parallel-Processing-tp3837605p5034690.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
__
20 matches
Mail list logo
