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

[Tim Schaub]

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.