Even,
gdal 1.5.0 gives the correct result.
I added the 900913 definition to /usr/share/proj/epsg files as:
# Spherical Mercator - Google
<900913> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
+x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs
-Steve
Even Rouault wrote:
Step
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 ma
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
p
Hy everybody,
I have a little probleme,
I have a GTiff picture and I make a traitement on this picture, my problem
appears to create the outpute picture for the moment I used the methods
below and it works but by changing data to 0/255
hDatasetOut = GDALCreateCopy( hDriver, OutputFile, hDataset,
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 d
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, 20
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 creat
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
- cre
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.
N
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.
Frank, gdal-dev,
Please find the attached copy of my work report.
Best regards,
--
Chaitanya kumar CH.
+91-9848167848
Work done from Wednesday, Apr 01, 2009 to Friday, Apr 17, 2009
Ticket #2930 (pending) (2 hr)
Categerized the warnings. Looked into the code. Researched for possibilities
of i
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.
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,
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 lo
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
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 $
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 certain
On Fri, Apr 17, 2009 at 9:43 AM, Marco Puppin 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 "ESRI Shapefi
Jukka Rahkonen mmmtike.fi> writes:
>
> It took 10 minutes to run and so far everything seemed to be OK.
> But when I changed resolution to -tr 2 2 gdalwarp really jammed.
> Process started and used all the processor time as usual,
> output tiff file was created, but after that everyhing just s
darrepac 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 2
> da
20 matches
Mail list logo
