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

Andreas Hocevar ahocevar at opengeo.org
Tue Aug 17 04:50:03 EDT 2010


After doing more investigation, there is one thing I am concerned about with the renderer approach:

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.

So a possible plan of attack would be two-fold:
* Use my patch for http://trac.openlayers.org/ticket/2787. Now the above line geometry will either be (179 0, 181 0) or (-179 0, -181 0).
* Continue your renderer work, but do not convert (179 0, -179 0) to a geometry that crosses the date line.

Regards,
Andreas.


On Aug 17, 2010, at 06:52 , Phil Scadden wrote:

> Worked part of today on the renderer. It seems to me that:
> 
>             var IDL = (this.extent.right > this.map.maxExtent.right);
> is a very simple indicator of whether there is an IDL problem to deal with.
> this.extent extends the projection coordinates over the 180 line rather 
> than going to negative numbers.
> 
> Changing feature.geometry in renderer works pretty well. Only zoombox 
> continues to do the wrong thing because the pixel to latlon creates 
> negative numbers. Easily fixed. However, this still modifies the values 
> of the feature.geometry rather than a clone because various other parts 
> of the system (the handlers) independently modify the geometry so 
> modifying a clone doesnt work.(rubberbanding stops working). I have 
> little idea what effect that would have on other parts of openlayers. 
> The critical thing will be for a polygon created for the purposes of 
> selecting features through WFS but havent tested this yet. Geoserver 
> handling of the 180 line is in a version that is giving us a problem 
> with arcsde.
> 
> Will do more work on this tomorrow hopefully.
> 
> geodesic true fixes the distance calculation for measure control but 
> area isnt working. I have yet to investigate why.
> 
> 
> 
> 
> 
> 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 at openlayers.org
> http://openlayers.org/mailman/listinfo/dev

-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.




More information about the Dev mailing list