Hamish wrote: > > 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 ?) I suppose the same issue could apply here. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grassuser mailing list grassuser@grass.itc.it http://grass.itc.it/mailman/listinfo/grassuser