darrepac pascal.darre at laposte.net writes:
HEllo,
I have a 45GB BIGTIFF file at 1m/pixel
With gdal_warp I am trying to resample it to 2m/pixel.
The process start but block at 0%.
I have changed the lanczos resampling algo to cubic in order to go faster but
the status, after more than
On Fri, Apr 17, 2009 at 9:43 AM, Marco Puppin puppin...@gmail.com wrote:
Hey Paolo,
oh yeah, your trik works!!!
Perfectly, also the incriminated shape has been exported in all his
geometries and data.
Thanks so much, that was so easy, now i learned something..
and if you write
ogr2ogr -f
Thanks for this suggestion, Peter. Not really seeing how 1.5.0 could build in
such circumstances yet 1.6.0 fail, I checked XercescVersion.hpp - which contains
#define XERCES_VERSION_MAJOR 2
#define XERCES_VERSION_MINOR 7
#define XERCES_VERSION_REVISION 0
Next, in order to be absolutely
Peter et al,
I have now tracked down one of the undefined's to a change in the sources
between 1.5.0 and 1.6.0 - gmlreader.cpp:
(working in 1.6.0 ...)
diff gmlreader.cpp /usr/postel/gdal-1.5.0/ogr/ogrsf_frmts/gml/gmlreader.cpp
2c2
* $Id: gmlreader.cpp 15773 2008-11-20 20:17:16Z rouault $
Got it: the problem proved to be libtool! I've successfully built a working
version of GDAL 1.6.0 by adding the '--without-libtool' to configure and tested
this version using ogr2ogr to translate a gml file to ESRI Shapefile format.
Fascinating, as libtool itself is unchanged between 1.5.x and
Hi there,
The problem that reported is gone. I just need to update from trunk and rebuild
the python binder with swig. Scott
is right, you can get around that problem by running your script image by
image. In my case I was running the script
on a cgi-bin environment, querying the same pixel
darrepac wrote:
Hello,
I was willing to transform a 24bits RGB Geotiff into a 8bits palette and so
found that RGB2PCT was the tool to use. Unfortunately, it creates me a grey
image with 2 colors in the palette...I have tried with the options -n 256
but I got the same result. Any clue?
Pascal,
Peter,
That rings a bell too. Very good work, though enough to drive
you to distraction if your job is geo not IT!
Good for you for posting your work.
I suggested to sunfreeware.com that they might consider keeping
a build of gdal available from their site, so as to mitigate
issues like this.
Thank you Frank,
I think I should have said, how do I get both the real and imaginary
numbers out as Float32, since ultimately I do want to calculate
magnitude (as you might have guessed). Then I could read the 'real' and
'imaginary' numbers into IDL as 2 separate tiffs do do the calculation.
Hi,
I have put the JPIPKAK prototype code in
http://svn.osgeo.org/gdal/sandbox/normanb/
and the original RFC is at
http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support
I have pruned the formats in this sandbox since I had a lot of problems
uploading to SVN.
Comments appreciated.
Norman,
I don't think the way you have created your sandbox is going to be efficient
to track and review the changes. It appears you have done an *import* of a
*modified* GDAL tree.
I think it would have been better to do that in several steps :
- delete the content of your sandbox in SVN
-
Even,
thanks, I will do this now.
Norman
-Original Message-
From: Even Rouault [mailto:even.roua...@mines-paris.org]
Sent: Fri 4/17/2009 11:34 AM
To: gdal-dev@lists.osgeo.org
Cc: Norman Barker
Subject: Re: [gdal-dev] JPIPKAK in the sandbox
Norman,
I don't think the way you have
I think I figured out why this wasn't working, I guess LinearRings
aren't considered full-fledged geometry objects, so it only works if you
add it to a polygon, then test for intersections.
Thanks anyway...
Amanda
-Original Message-
From: Henneke, Amanda M
Sent: Thursday, April 16,
Derek Mueller wrote:
Thank you Frank,
I think I should have said, how do I get both the real and imaginary
numbers out as Float32, since ultimately I do want to calculate
magnitude (as you might have guessed). Then I could read the 'real' and
'imaginary' numbers into IDL as 2 separate tiffs
Hi all,
I have a serious problem that you might be able to shed some light on.
I have a landsat geotif (actually lots of them) and when I projection
them on a systems with v1.5.2 and v1.4.4.0 I get very different results!
The image sizes are different, the projection info is different, the
Stephen,
Which version gives the right result ?
I've checked that GDAL SVN trunk (1.7.0dev) gives the same result as the one
you get with GDAL 1.5.2.
It looks like EPSG:900913 definition was added in data/cubewerx_extra.wkt for
GDAL 1.5.0. I've tested again with GDAL 1.4.4 and it doesn't even
16 matches
Mail list logo
