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

Michael Barton michael.barton at asu.edu
Mon Nov 30 14:22:54 EST 2009

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.


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

More information about the grass-dev mailing list