a few lines above the new work-around XY locations are specifically
tested for & dealt with. the `break` should ensure that XY loc'ns
never reach the patched code.
is the real problem that the "XY location (unprojected)" text has
been translated so the match no longer works?
if so, and it is ok to have that be translated (I'm not sure it
is), should we change it to run g.region -p and check that the
projection code == 0 as a steadier target?
Hello,
in short - Your analysis of code is wrong. Break interupts while cycle
(@478) and thus $prj is unset but used @490.
Maris.
2009/11/30, Hamish <hamish_b@yahoo.com>:
Hi,
wrt r39856,
a few lines above the new work-around XY locations are specifically
tested for & dealt with. the `break` should ensure that XY loc'ns
never reach the patched code.
is the real problem that the "XY location (unprojected)" text has
been translated so the match no longer works?
if so, and it is ok to have that be translated (I'm not sure it
is), should we change it to run g.region -p and check that the
projection code == 0 as a steadier target?
2009/11/30, Hamish wrote:
> wrt r39856,
>
> a few lines above the new work-around XY locations are specifically
> tested for & dealt with. the `break` should ensure that XY loc'ns
> never reach the patched code.
>
> is the real problem that the "XY location (unprojected)" text has
> been translated so the match no longer works?
>
> if so, and it is ok to have that be translated (I'm not sure it
> is), should we change it to run g.region -p and check that the
> projection code == 0 as a steadier target?
>
> or is the XY compare otherwise busted?
Maris wrote:
in short - Your analysis of code is wrong. Break interupts
while cycle (@478) and thus $prj is unset but used @490.
ah, you are exactly right. my apologies. I had remembered testing that
XY locations worked with it a while back, and thought they still would
be & was hypothesizing as to why that might be. but it got broken again
since that time for other reasons fixed by your patch.