[OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.

[Phil Scadden]

> My comment here was meant to say that I would not be in favor of any
> change that made it so the distance between (-170, 0) and (170, 0) was
> 20 (by default).
Am I not correct though in assuming that current geometric model assumes 
by default that the angular distance is 340? I am contending that this 
is a very poor default because I cannot think of a real world line 
structure where this is likely to be the correct way to construct the line.

> I understand the frustration.  If you can get involved in (or have
> suggestions for) OpenLayers 3.0 with regard to a different geometry
> model (or changes at some other level), that would be great.
>
Well the question of the how a line represented by  only two points 170 
0, -170 0 is surely key. It is inherently ambiguous so some convention 
must be applied. Inhouse we use shortest angular difference.  In 
principle, rendering on the sphere means operating in angles but 
pragmatically projected coordinates can often be used. I dont like 
coordinates where abs(lon) > 180 but can the projection system be 
confident that servers will not supply this?  I think OL can be 
re-engineered to do this in several way without a rewrite into angular 
geometry which I agree would be slow. There is generally only  a problem 
when
a/ ESPG indicates that OL is dealing with an earth projection (a not say 
a building map or drawing schematic).
b/ the 180 line is within the viewport. (which is automatically the case 
when either pole in within the viewport.

Detection of this need only happen when extent or projection changes and 
a variable "IDL in viewport" true/false can be set in the map object.

When IDL in viewport, then special handing is required in a number of 
places and it would be good to have utility routines to make the 
programming reasonably uniform. The issues as I see it ( and I dont know 
enough to answer them).

1/ should extent be allowed to exceed to baselayer.maxextent? At moment, 
this is a good way to detect the presence of 180 line. It would make an 
extent of (170, -10, -170 10) (or strictly projected equivalent) legal. 
I actually think this is bad idea. Extents should forced so right 
exceeds left or maths gets way too messy. A property for extent of 
includesIDL to indicate that coordinates being tested need to be 
corrected for IDL prior to test.

2/ interaction with server. this applied to coordinates passed to WFS 
spatial queries and any calls that would create geometry in the server. 
Only geoserver, (and only in experimental config) as far as I know 
handles IDL. ArcGIS server does okay provided projection has horizons 
(ie not a whole earth projection).

3/ Location of IDL handling code for vector rendering. Is it high level 
(eg in the handler at moment, but this doesnt deal with GML/KML/etc)? or 
is it low level (eg elements or right down in the renderers). I 
personally dont think you can deal with IDL on a per point basis, 
ignoring the line relationship or you will get the issue of  170 0, -170 
0 making life difficult. If map extent exceeded 180 degrees, then you 
are surely left with having to check for shortest path?  I'm inclined to 
try a suck-and-see approach with lowest part of elements but 
verification looks tricky. The problem with doing it in the renderer.js 
is that you change geometry. This could be a problem if passed back to a 
server.


-- 
Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St, 
Private Bag 1930, Dunedin, New Zealand Ph +64 3 4799663, fax +64 3 477 5232

Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.