[GRASS-dev] latlon support

[Glynn Clements]

Markus Metz wrote:

> When I was updating v.in.gshhs (see user list) I came across a strange 
> phenomenon in GRASS latlon support when crossing the datum border. The 
> map extends reported by v.info are wrong because East is larger than 180 
> (about 191) and converted to (East - 360) which is only 10 degrees east 
> of West. The shorelines are spanning 370 degrees of longitude and not 10 
> degrees. I know GRASS doesn't support crossing the datum border, i.e. 
> going beyond 180E or 180W, but I don't understand why not. The GSHHS 
> shoreline vector for example crosses the datum border and clipping or 
> converting coordinates of vertices would create artifacts. Geographic 
> features can cross the datum border, so why not supporting a range -360 
> to 360 for longitude? I am aware that 181 is equal to -179 (in latlon), 
> but going from 179 to 181 is different from going from 179 to -179. 
> Mathematically the difference in the first case is 2 degrees longitude, 
> in the latter case 358 degrees longitude. The distance between two 
> points depends on whether you go east or west (or north or south). So 
> if  the first point is on 179 lon and the second is on 181 lon, this 
> would indicate to go east, while when the second point is on -179 lon 
> this would indicate to go west from the first point. Does that make sense?
> How much havoc would it cause to support longitudes from -360 to 360 in 
> latlon?

The biggest problem is likely to be that, once you open this can of
worms, you'll just run away in horror. I know I did.

IMHO, the optimal solution for lat/lon is to remove the region
constraints, and require the data to be "Euclidified" either on input
or by the low-level retrieval functions (e.g. G_get_raster_row etc).

Higher-level code would then treat all coordinates as conforming to
the rules of Euclidean geometry.

E.g. you could freely set the region to west=-360, east=+360, and get
two copies of the globe. The points 0,-360 and 0,+360 would be treated
as being separated by twice the equatorial circumference. And so on.

Expecting every piece of code which deals with coordinates to
explicitly handle both Euclidean and non-Euclidean cases is asking too
much, IMHO. Actually, not IMHO; you just have to look at the code to
see how often it doesn't happen.

E.g. although the new display library is based around the same path
construction primitives as PostScript, PDF, and cairo, it can't just
feed the coordinates directly to the driver.

Instead, it has to store the entire path locally, so that it can draw
multiple copies (once with the RHS of the shape appearing on the LHS
of the display, and once with the LHS of the shape appearing on the
RHS of the display).

-- 
Glynn Clements <glynn at gclements.plus.com>