I'm not sure of the history of this (guess I missed it). But finding xy locations by a code would be much easier and more reliable than searching for the string "XY location (unprojected)". Unfortunately, code == 0 can also be found in non-xy locations. I don't know what the rules are for setting this code or how it is set.
Michael
On Nov 30, 2009, at 10:00 AM, grass-dev-request@lists.osgeo.org wrote:
Message: 2
Date: Mon, 30 Nov 2009 03:37:01 -0800 (PST)
From: Hamish <hamish_b@yahoo.com>
Subject: [GRASS-dev] Re: r39856 - Do not fail to start gis.m in XY
location due to missing proj info
To: grass-dev@lists.osgeo.org
Message-ID: <788540.37747.qm@web110009.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=us-asciiHi,
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?
Hamish