> 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. _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
