[GRASS-user] bug in r.proj or just artifact of weird (unrealistic) reprojection ?

[Moritz Lennert]

On 25/09/12 12:16, Glynn Clements wrote:
>
> Moritz Lennert wrote:
>
>> - A location in EPSG 31370 (Belgian Lambert 1972) - Objectif:
>> project the elevation raster layer from the nc_spm_08 dataset into
>> that Belgian projection dataset - A first run of r.proj to get the
>> coordinates of the layer in the new projection system. Here's the
>> result:
>>
>> n=2370907.92051779 s=2378797.24912944 w=-6087464.12326059
>> e=-6068211.64408602 rows=1350 cols=1500
>>
>> As you can see s>  n. g.region bails out on that.
>>
>> But, when you just switch n and s, then everything works fine and
>> the elevation dataset gets projected to the correct spot.
>>
>> Now, I know that this is not the typical reprojection scenario, but
>> I'm wondering whether this indicates an underlying issue in
>> r.proj's boundary calculation algorithm.
>
> This has nothing to do with r.proj's boundary calculation algorithm,
> which isn't used for -p/-g. Instead, it simply projects the
> south-east and north-west corners of the input map, and assumes that
> the projected points are also the south-east and north-west corners.
>
> Clearly, this will be inaccurate for anything other than projecting
> between cylindrical projections and/or lat-lon.
>
> The region-cropping optimisation which is used for projecting (when
> the -n isn't given) projects the entire boundary, sampled at the
> source resolution, then uses the bounding box of the projected
> boundary. AFAICT, this works for all but pathological cases (e.g. a
> projection which is tangential to the region being projected).
>
> Can you try the attached patch?

Thanks for the patch ! Actually, I wasn't precise enough in my mail. I
was using 6.*. While testing with grass7 with and without the patch, I 
noticed that the problem does not appear in grass7. The patch here does 
not make a difference for the output of -g (or -p) which is:

n=2384892.88888888 s=2364922.88888888 w=-6087606.16666662 
e=-6068356.16666662 rows=1350 cols=1500

I don't know what is different in the code between grass6 and grass7 
that explains this issue.

Moritz