[GRASS-dev] latlon support

[Markus Metz]

Glynn Clements wrote:
> 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.
>   
OK, I won't start hacking around here :-) I thought about it a bit more 
and it really is a big mess.
> 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).
>   
As long as the input is ok, I don't see a problem with GRASS modules, in 
theory the output should conform as well to Euclidean geometry as the 
input. But here the problem starts. I get all sorts of dirty data, in 
particular shapefiles, that I am supposed to work with, and cleaning 
them up is sometimes really a pain... After cleaning I have 
topologically correct vectors, but that doesn't guarantee that they are 
"Euclidified". If I understand you right I would have to check for every 
single line and every single boundary if every single vertex is correct. 
In practice I can only do an educated guess if, to stick to my previous 
example, it is correct that one point has lon 179 and the next point has 
lon 181, i.e. crossing the datum border is right, or if it is correct to 
go instead from lon 179 to lon -179, i.e. go over Greenwich meridian and 
not over the datum border. I guess that for most geographic features it 
will be correct to cross the datum border, as for the Siberian 
shorelines, and GRASS seems to do so (I haven't tested everything, just 
v.info, the display, and "Measure distance" in the display manager).
I have changed v.in.gshhs accordingly and both v.info and the display 
(wxgui) work as expected (correct).
> Higher-level code would then treat all coordinates as conforming to
> the rules of Euclidean geometry.
>   
I think this is the only way, higher-level code must assume that the 
coordinates given by the input are correct. The alternative is IMHO out 
of discussion (trying to guess if coordinates should be converted or not).
> 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.
>   
That can be intended but I am afraid not all people generating spatial 
data think about this effect. It may be safer to convert coordinates to 
the 180 deg lon and 90 deg lat limits and take the shortest way between 
two points.
> 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).
>
>   

Not afraid of worms but of horror,

Markus M