[GRASS-dev] latlong problem

[Hamish]

Glynn Clements wrote:
> Personally, I'd be tempted to just treat the 180th meridian as a
> discontinuity (New Zealanders and Japanese would have to stick to
> using projected locations).

aw, come on Glynn. I could just as easily argue that folks in the UK
should stick to using projected locations and GRASS enforce 0-360.
It's no solution.


> I wouldn't be surprised if there are a *lot* of places in the code
> which ought to contain specific code to handle longitude wrapping but
> don't.

AFAICT, all the raster and region code is happy to use both +-180 and
0-360 lons; all the vector modules currently don't know or attempt to do
anything about it; and as we see here the libgis vector code is a mixed
lot.

> [E.g. "d.vect ... render=c" doesn't handle it correctly. 

the one I noticed was:

g.region n=90N s=90S w=-180 e=180
v.in.region world_box
d.vect world_box


> D_polygon_clip() does the clipping in geographic coordinates, before
> transforming the vertices to display coordinates. Most of the time,
> this is preferable, as you eliminate the conversion overhead for any
> points which are discarded by clipping.]
> 
> Actually, this isn't a problem which can be "solved". What do you do
> if you *want* a polygon which spans 340° of longitude? How do you
> interpret a polygon which spans exactly 180°; which hemisphere does it
> cover?

So centroid placement is crucial (you should at least be able to trust
v.in.ascii form=standard). There are a number of tests for point-in-
polygon which could be employed then. As for if the smaller or bigger
polygon is "inside" (e.g. world ozone coverage vs hole) for GIS-
generated polygons, I guess just keeping with the current mode of "pick
the smaller area" is a good choice. Martin's v.in.region bug is that
that rule is not consistent throughout the code?

Polar lat/lon can also be a display issue (see prev email), but e.g.
d.geodesic seems happy enough & reports seemingly correct distances
from a lat/lon loc'n.


> IOW, I don't think that we'll ever get this "right".

Well, hopefully we can get the vector handling code "good enough" that
we don't hear any complaints about it (like the region and raster code
now). But of course it is much harder to get right than a simple if(a>b)
cartesian math.

Markus:
> Well, to me
>  http://mpa.itc.it/markus/tmp/admin98_oceans_fixed.png
> looks much more reasonable than
>  http://mpa.itc.it/markus/tmp/admin98_oceans_buggy.png
> 
> Sorry for this stupid comment, but I still think that there is a
> problem. And in this case it is a perfect -180 .. 180deg map. The
> rendering is ok for 3/4th of the map but not the northern part
> (although there is a north boundary in the map, see "fixed" map
> example).

There is a bug there, but probably we should be careful about "fixing"
the problem in the wrong place (discl: I haven't actually looked).


Hamish