> but why then does it work fine for me?
> I downloaded a 180W tile, that looks fine too:
> ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM3/Australia/S20W180.hgt.zip
>
> Origin = (-180.0004166,-18.9995834)
> Pixel Size = (0.0008333,-0.0008333)
>
I grabbed the s
> > gdalinfo W180N10.tif
>
> > Origin = (-180.0004196,10.0004170)
> > Pixel Size = (0.0008333,-0.0008333)
Hamish:
> note in this case the amount it exceeds 180 by is 1/2 the
> cell resolution.
> So in this case, the SRTM tile is not broken, it is what it
>
> > Jamie Adams wrote:
> > > In my case, the source GeoTiff had a geotransform of:
> > > (-180.012497, 0.0083297, 0.0, 90.0,
> > > 0.0, -0.0083297)
...
> My global 0.5 min grid is working, but I've discovered problems with
> other data sets
Hamish:
> > what is the p
On Mon, Oct 13, 2008 at 6:08 PM, Hamish <[EMAIL PROTECTED]> wrote:
> Jamie Adams wrote:
> > In my case, the source GeoTiff had a geotransform of:
> > (-180.012497, 0.0083297, 0.0, 90.0,
> > 0.0, -0.0083297)
> >
> > One strange thing was, the original grass import (w
Jamie Adams wrote:
> In my case, the source GeoTiff had a geotransform of:
> (-180.012497, 0.0083297, 0.0, 90.0,
> 0.0, -0.0083297)
>
> One strange thing was, the original grass import (west coordinate of
> 180E) had the same geotransform as the corrected raster I r
On Mon, 2008-10-13 at 16:59 -0700, Jamie Adams wrote:
> Sure, python w/ gdal is great for doing these sanity checks. Assuming
> you are using a FWTools install or have the python-gdal plugin:
>
> python
>
> >>> import gdal
>
> or newer version:
> >>> from osgeo import gdal
>
> >>> image = gdal
Sure, python w/ gdal is great for doing these sanity checks. Assuming you
are using a FWTools install or have the python-gdal plugin:
python
>>> import gdal
or newer version:
>>> from osgeo import gdal
>>> image = gdal.Open('/the/path/to/my/raster.tif',gdal.GA_ReadOnly)
or if your version
On Mon, 2008-10-13 at 16:13 -0700, Jamie Adams wrote:
> Thanks for the suggestions. I opened the image up in python using
> gdal, looked at the geotransform and found that the image is
> ever-so-slightly shifted west (-180.012497). Hence the
> negative W-E center. Maybe this is why GRASS
Thanks for the suggestions. I opened the image up in python using gdal,
looked at the geotransform and found that the image is ever-so-slightly
shifted west (-180.012497). Hence the negative W-E center. Maybe
this is why GRASS thinks it has a 180E origin also, though I don't know.
I che
On Mon, 2008-10-13 at 12:41 -0700, Jamie Adams wrote:
> Hello all,
>
> When I import a global elevation dataset with extents 180w 90n 180e
> 90s using r.in.gdal, the GRASS raster shows up with w-e extents both
> showing 180E. While this doesn't seem to be affecting raster
> calculations, afaik, i
Hello all,
When I import a global elevation dataset with extents 180w 90n 180e 90s
using r.in.gdal, the GRASS raster shows up with w-e extents both showing
180E. While this doesn't seem to be affecting raster calculations, afaik,
it's causing issues with QGIS. It displays it with it's origin at
11 matches
Mail list logo
