> 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
