John Callahan wrote:
Thanks for responding Hermann. Yes, I tried using -s_srs EPSG:3412 as
well as the full PROJ4 string with the same result. When specifying
-s_srs, does gdalwarp ignore (override) the project information in the
hdr file?
Hmm. AFAIK: gdal_translate -a_srs does override
Hermann Peifer wrote:
John Callahan wrote:
Thanks for responding Hermann. Yes, I tried using -s_srs EPSG:3412 as
well as the full PROJ4 string with the same result. When specifying
-s_srs, does gdalwarp ignore (override) the project information in the
hdr file?
Hmm. AFAIK: gdal_translate
I've also tried using the proj4 strings offered
for that EPSG, but the results are the same.
Hmm. It it looks to me that this should work:
gdal_translate -a_srs +proj=stere +lat_0=90 +lat_ts=70 +lon_0=-45 +k=1
+x_0=0 +y_0=0 +a=6378273 +b=6356889.449 +units=m +no_defs -a_ullr ...
See [1]
John Callahan wrote:
Thanks Frank/Hermann for your responses. However, something odd seems
to be going on here. I feel like I'm missing something on how GDAL
handles coordinate system information.
Using the same input data set, and converting to different formats, the
description of the
Dear gdal-dev list members,
I'm using a python tool called the regionator
(http://code.google.com/p/regionator/wiki/ Welcome) on a large
(14352x7440) png image. The regionator uses the GDAL library to resample
subsets of the original image into much smaller chunk images. These
images are
Mary Jo Brodzik wrote:
Dear gdal-dev list members,
I'm using a python tool called the regionator
(http://code.google.com/p/regionator/wiki/ Welcome) on a large
(14352x7440) png image. The regionator uses the GDAL library to
resample subsets of the original image into much smaller chunk
Thank you Frank. I hadn't thought about file formats supporting
projections or not. Typically, you think about the software or
algorithm not supporting a projection or coordinate system, not the
format itself.
- John
Frank Warmerdam wrote:
John Callahan wrote:
Thanks Frank/Hermann for
I just received word back from NSIDC. They mentioned this is a known
issue when projecting from polar to cylindrical coordinate systems.
http://trac.osgeo.org/gdal/ticket/2729
The work around is to specify the output extents in the command. For my
data, the proper command is:
gdalwarp -of
I will be out of the office starting 11/12/2009 and will not return until
11/16/2009.
I just became a father! I'm the proud parent of a little girl. I will
respond to your message when I return.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Hi Tamas,
2 issues directly related to the big raster dimensions :
* Currently GDAL allocates an array of pointer to raster blocks of size
nBlocksPerRow x nBlocksPerColumn where nBlocksPerRow =
(nRasterXSize+nBlockXSize-1) / nBlockXSize and nBlocksPerColumn =
(nRasterYSize+nBlockYSize-1) /
Yes. Or... you could cheat a bit. In the case of a shapefile, the spatial
reference is written in a .prj file. So technically you can create a fake
empty
shapefile with the right spatial reference, close it, rename the .prj to
have
the same basename as your shapefile of interes and re-open it.
Jason Roberts wrote:
Yes. Or... you could cheat a bit. In the case of a shapefile, the spatial
reference is written in a .prj file. So technically you can create a fake
empty
shapefile with the right spatial reference, close it, rename the .prj to
have
the same basename as your shapefile of
12 matches
Mail list logo
