On 8/19/10 8:34 PM, Phil Scadden wrote: > >> 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).
Currently, our geometries don't know anything about coordinate reference systems. So, yes, the distance between (-170, 0) and (170, 0) is 340. And this is not an angular measure. And there are no units. And, the distance between (-170000, 0) and (170000, 0) is 340000. And these are perfectly valid geometries. Again, in the future, geometry calculations may be smarter. I'm just describing the way things are now. > 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. > > -- Tim Schaub OpenGeo - http://opengeo.org Expert service straight from the developers. _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev