I'm running GRASS 6.2 on Ubuntu Linux, supported by GDAL 1.4 utilities.
And I'm importing raster images in tif format (exported from ArcMap as TIF
files) using r.in.gdal, into a location created by manually entering the bounding
coordinates and projection parameters. The bounding lat/long coordinates
contain the boundaries of the image that I am importing. The 'override projection'
option is set.
When I press the Run button on the r.in.gdal dialog, the error occurs:
GRASS_INFO_WARNING(19479,1): G_set_window(): Illegal latitude for North.
From searching the lists for a solution, I dont see much that is of help, but there
are some hints that this might be a software version conflict of some type.
Does anyone have any insight or a fix for this error? I have also seen the
error when trying to create a new location using the a geo-referenced tif file.
Thanks for any assistance,
Rick Reeves
NCEAS
UC Santa Barbara
I'm running GRASS 6.2 on Ubuntu Linux, supported by GDAL 1.4 utilities.
And I'm importing raster images in tif format (exported from ArcMap as TIF
files) using r.in.gdal, into a location created by manually entering the
bounding
coordinates and projection parameters. The bounding lat/long coordinates
contain the boundaries of the image that I am importing. The 'override
projection'
option is set.
When I press the Run button on the r.in.gdal dialog, the error occurs:
GRASS_INFO_WARNING(19479,1): G_set_window(): Illegal latitude for North.
From searching the lists for a solution, I dont see much that is of
help, but there
are some hints that this might be a software version conflict of some type.
Does anyone have any insight or a fix for this error? I have also seen the
error when trying to create a new location using the a geo-referenced
tif file.
The error mostly occurs when importing non-georeferenced images into a
lat/lon location.
Non-georeferenced images are normally imported with the lower-left
corner at (0,0) and with a resolution of one unit per cell. For a
lat/lon location, this typically results in the top edge of the image
being above 90 degrees, hence the error.
You may be able to get around this problem by changing the location to
x/y while importing the image, and changing it back after the image's
bounds have been set correctly.
It can sometimes occur when importing geo-referenced images where the
top row is centred on 90N, resulting in the top edge being half a cell
above that. I am not aware of any workaround for this case.
> GRASS_INFO_WARNING(19479,1): G_set_window(): Illegal latitude for North.
Glynn:
The error mostly occurs when importing non-georeferenced images into a
lat/lon location.
Non-georeferenced images are normally imported with the lower-left
corner at (0,0) and with a resolution of one unit per cell. For a
lat/lon location, this typically results in the top edge of the image
being above 90 degrees, hence the error.
..
It can sometimes occur when importing geo-referenced images where the
top row is centred on 90N, resulting in the top edge being half a cell
above that. I am not aware of any workaround for this case.
The last case is a bit of an anomaly as every cell in the row must contain the
same value, as they overlap at the pole. If they are not all the same, you
could claim that the dataset was broken.... the next pragmatic question is how
to accomodate broken datasets without annoying users too much? Throw away the
row at the pole? (ie instead of G_fatal_error() import as much as possible with
a warning that some data has been thrown away- please check & here's probably
why it happened. I guess that is still problematic for longitude when column
360 wants to wrap around and overwrite earlier <360 data ?)
Hamish
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
> The error mostly occurs when importing non-georeferenced images into a
> lat/lon location.
>
> Non-georeferenced images are normally imported with the lower-left
> corner at (0,0) and with a resolution of one unit per cell. For a
> lat/lon location, this typically results in the top edge of the image
> being above 90 degrees, hence the error.
..
> It can sometimes occur when importing geo-referenced images where the
> top row is centred on 90N, resulting in the top edge being half a cell
> above that. I am not aware of any workaround for this case.
The last case is a bit of an anomaly as every cell in the row must contain the
same value, as they overlap at the pole. If they are not all the same, you
could claim that the dataset was broken.... the next pragmatic question is how
to accomodate broken datasets without annoying users too much? Throw away the
row at the pole? (ie instead of G_fatal_error() import as much as possible with
a warning that some data has been thrown away- please check & here's probably
why it happened.
That's the most straightforward solution, but it needs to be done in
the importer (r.in.*) rather than libgis.
The only viable libgis fix is to simply remove the latitude check.
I guess that is still problematic for longitude when column
>360 wants to wrap around and overwrite earlier <360 data ?)