[GRASSLIST:4843] Re: Problems importing Data into lat/lon with negtiv south value

[Paul Kelly]

On Mon, 15 Nov 2004, Glynn Clements wrote:

> Paul Kelly wrote:
>
>> This doesn't really explain what looks like a bug, but I think it is a
>> side-effect of GDAL trying to set the current region to match the imported
>> data, which IMHO I don't think it should do. E.g. what if you were running
>> an analysis in the background for which the region set was very important,
>> and then imported a new file and r.in.gdal suddenly changed the current
>> region?
>
> r.in.gdal doesn't modify the WIND file. If you use the -e flag, it
> modifies the DEFAULT_WIND file in the PERMANENT mapset[1], otherwise
> it only modifies the process' internal region.

I don't disagree that this is the actual behaviour, but on reading though 
the source code it seems to me this wasn't the intended behaviour and it 
is trying to write out the bounds of the imported map as the current 
region (i.e WIND). But G_set_window() doesn't change anything because of 
some caching it does or something (I looked into it a long time ago and 
don't remember all the details now).

Unless I'm misunderstanding what G_set_window() is supposed to do but I 
think it's for setting the current region.

>> I think it should only do this if the -e flag to extend the region is
>> given, or perhaps there should be a new flag specifically to set the
>> region to match the imported file.
>
> I'm not sure that there would be much point, as you can just use
> "g.region rast=..." if you want that behaviour.

Yes I agree, except from what I've noticed it seems r.in.gdal was designed 
to actually do this. But maybe these lines should really be deleted then:

>> If you comment out the lines in raster/r.in.gdal/main.c:
>>      if(G_set_window (&cellhd) < 0)
>>          exit(3);
>> and re-compile does it work?
>> Although seeing that doesn't fix the underlying bug, it might run into
>> problems later I suppose.
>>
>> Anybody else have an opinion on the region setting and extending behaviour
>> of r.in.gdal and v.in.ogr?
>
> If r.in.gdal is importing a georeferenced raster, it should attempt to
> set the correct bounds and resolution (i.e. cellhd) for that raster,
> rather than using (0,0,W,H). It shouldn't attempt to set the current
> region or the default region; that should be left to g.region (which
> should have an option to set the default region).
>
> I don't think that this is an issue for v.in.ogr; AFAIK, vector maps
> don't have a region (cellhd).

If you are using v.in.ogr to create a new location based on the projection
of the vector map being imported, it has to create a DEFAULT_WIND, and it is
good to populate it with meaningful region extents, which can be got through
some OGR function (get extents or something like that).

Paul