[GRASS-dev] Re: grass-dev Digest, Vol 43, Issue 46

[Michael Barton]

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 at lists.osgeo.org wrote:

> Message: 2
> Date: Mon, 30 Nov 2009 03:37:01 -0800 (PST)
> From: Hamish <hamish_b at 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 at lists.osgeo.org
> Message-ID: <788540.37747.qm at web110009.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
>
> 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?
>
> or is the XY compare otherwise busted?
>
>
> Hamish
>