> How do you know that the line (179 0, -179 0) is meant to cross the date 
> line? It could as well be a line that spans almost all of the globe. I don't 
> think the coordinates should be ambiguous, so the line that is meant to cross 
> the date line should have the coordinates that exceed the world bounds. This 
> is not cite compliant, but works with GeoServer and, as I hear from Chris, 
> also with FeatureServer.
>    
Further to this, consider a ship track starting in LA and proceeding to 
say Sydney. The track coordinates would start with negative longitude 
for LA and for now, would change to positive coordinates when it crossed 
the dateline. To resolve the ambiguity you cite, it would have to change 
one or other set of coordinates to so that abs(lon) >180 for the 
renderer approach to work. This is not how the data is traditionally 
stored and while we still resort to using 0-360 longitude references to 
overcome flat earth software, I look forward to the day when we dont. I 
am still in favour of  converting to shortest path.

There are two aspect to the problem. One is how vector geometry is 
rendered given that OL cant really dictate the conventions of how 
geometry will be presented when coming from a server. The second is how 
geometry created in OL (by handlers in particular) will be presented 
back to servers, eg as geometry for a spatial query or to create new 
geometry on the server.

I havent had much time on this today, but I have briefly reconsidered 
the option of doing the renderer type conversion but at the SVG level. 
This avoids the problem that renderer actually changes the geometry, but 
means it has to be implemented in every renderer. A utility function for 
converting x,y to local coordinates (but checking for IDL issues) would 
smooth this - canvas.js already has such function. It also means that if 
you have 179 0, -179,0 line with IDL in the screen area, then it will 
draw a line crossing the IDL. This doesnt bother me.

There is a need for a similar function to convert geometry created in OL 
to compensate for IDL (converting say the bounds in zoombox).

-- 
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

Reply via email to