Hello,
I think this is a bug report, or maybe a feature request.
I'm writing a script that shells out to gdalwarp. The GTiff files that
I might see as input to this script include palette and non-palette
images, and I'd like to be able to reliably compress the output
without human interven
All,
Continuing my release manager role from the 1.6.2 release, I would like to
produce a 1.6.3RC1 on November 14th (this Sunday). Consider this your notice
to complete any bugs or backports for the 1.6 branch lest they be pushed
forward to 1.6.4 (which is likely to be released after or along
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 i
> 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
Selon Jason Roberts :
> Greetings OGR experts,
>
>
>
> I have a shapefile for which no spatial reference was defined when the
> shapefile was created, but I know the spatial reference and would like to
> set it on this existing shapefile. Is this possible with the OGR Python API?
>
You're correct
Greetings OGR experts,
I have a shapefile for which no spatial reference was defined when the
shapefile was created, but I know the spatial reference and would like to
set it on this existing shapefile. Is this possible with the OGR Python API?
It looks like the only place that takes an OGR
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) / nBlock
Folks,
I've been testing with the WMS/TMS driver at large zoom levels
according to the following WMS XML file:
http://web0.nearmap.com/maps/hl=en&x=${x}&y=${y}&z=${z}&nml=Vert
-20037508.34
20037508.34
20037508.34
-20037508.34
20
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
htt
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
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 y
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 imag
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 s
John,
I guess you are right: "+lat_0=-90" shouldn't result into
"PARAMETER["latitude_of_origin",-70]". There seems to be some parameter
confusion.
It also looks like
http://spatialreference.org/ref/epsg/3412/prettywkt/ would be wrong in
this case.
EPSG guidance notes 7.2 describe polar st
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 out
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 output coordinate systems
> 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]
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 -
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 the
19 matches
Mail list logo
