[GRASS5] LatLong E/W problem in southern hemisphere

[Markus Neteler]

On Fri, Oct 15, 2004 at 06:53:39PM +0200, Roger Bivand wrote:
> On Fri, 15 Oct 2004, Markus Neteler wrote:
> 
> > On Fri, Oct 15, 2004 at 06:30:40PM +0200, Roger Bivand wrote:
> > > On Fri, 15 Oct 2004, Markus Neteler wrote:
> > > 
> > > > Hi,
> > > > 
> > > > we have a map in LatLong, located somewhere in Argentina:
> > > > 
> > > > g.region rast=noaa -p
> > > > projection: 3 (Latitude-Longitude)
> > > > zone:       0
> > > > datum:      wgs84
> > > > ellipsoid:  a=6378137 es=0.00669438
> > > > north:      30:24S
> > > > south:      35:42:00.0036S
> > > > west:       58:17:59.9964W
> > > > east:       65:11:59.9892W        <- note this correct value
> > > 
> > > Just asking: does Southern hemisphere mean we look at things upside down? 
> > > Shouldn't east be (yes) east of west, this east is almost 7 degrees west 
> > > of west, and I think the algorithm is (logically) assuming that you want 
> > > what is asked for, 353 degrees? Or am I missing something (I wouldn't be 
> > > surprised!)? Maybe a warning could be useful when the nsres/ewres ratio is 
> > > so extreme?
> > 
> > Roger, the problem (to me) is that above we have the expected value
> > 65:11:59.9892W, which becomes later 294.800003 
> > (360 - 294.800003 = 65.2 !). So the wrap around doesn't work (or whatever).
> > 
> 
> Why is the declared east west of west? Isn't the program just doing what 
> it was asked to do? It seems to say that, well, if the stated east is west 
> of west *in lat-long* this can be resolved by going round the other way, 
> which it then does. Isn't this an input error? 
> 
> east=-65.199997 west=-58.299999
> 
> west=           east=
> 
> seems more likely? I don't think it's the code, I think it's doing what it 
> was told?
> 
Roger,

let's see it from a user's perspective (my colleague):
He fetched the NOAA image from the web, file in plain binary
format. The metadata told him how to select the parameters
for r.in.bin.
First he mixed east and west and it gave *no* error (while it
does in case of north/south confusion). This delivered a messy
map. Eventually I found out that he mixed east/west, changing
that the map was imported correctly. But of course I was
wondering why r.in.bin didn't complain.

You may be right that the behaviour is correct. But in fact
not helpful for this particular case. I darkly remember that
this was discussed once here, but don't recall details.
It was probably the same trap of 'how to go around the globe...'.
But shouldn't this then raise alarm due to a wrong number
of columns? Ah, in fact the resolution was wrong then. So
it's the way how r.in.bin determines rows/cols/resolution.

Now it seems clear to me: no bug, but unfortunate case.

Markus