Re: [OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.
On Monday, August 16, 2010, christopher.schm...@nokia.com wrote: On Aug 16, 2010, at 4:00 AM, ext Andreas Hocevar wrote: Hi, I stand corrected, at least in part: On Aug 16, 2010, at 09:37 , Andreas Hocevar wrote: I am still not sure that doing this in the renderer rather than in path.js, polyon.js is the right thing. I am. Fixing this in the handlers won't help for features that cross the date line that come e.g. from a WFS, because there you will likely have coordinates that don't exceed the world extent. I just asked Andrea Aime from GeoServer how GeoServer handles features that cross the date line. So if you store a feature with coordinates like -181 0, -179 0, GeoServer will accept that by default (but not in cite testing mode). And it will also return coordinates like this as stored, i.e. not as 179 0, -179 0. I do not know how other WFS implementations, or MapFish, or FeatureSever handle this. FeatureServer returns exactly what you give it; it doesn't know what a world is. Catching up on this thread... Same for MapFish. -- Eric Lemoine Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel : 00 33 4 79 44 44 96 Mail : eric.lemo...@camptocamp.com http://www.camptocamp.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.
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 (-17, 0) and (17, 0) is 34. 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
Re: [OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.
On Aug 18, 2010, at 23:25 , Phil Scadden wrote: Please don't try to bake in any assumptions about heading in a line segment. Our geometry model is based on coordinates on a plane. My opinion is that crossing the dateline is application logic. So when I try to draw say a zoom rectangle across the date line, You mean using the ZoomBox control? This works fine. Try it out in our spherical-mercator.html example. or measure a distance between two points which happen to be on opposite sides of the dateline, Using the geodesic measuring algorithm, this also works already. how do I put that logic in my application to cope with this without altering OL? Or draw a selection polygon to choose some data in a WFS layer? Here you could use the sketch handlers after applying my patch, and then split the polygon at the maxExtent bounds (patches for polygon splitting welcome :-) ). This is where problems occurs. The reason for looking at the renderer approach is that there remain problems with just doing it in the handlers. You may want to try the SVG2 renderer I am currently working on. There is a chance that it works with geometries that exceed the world bounds (like the ones you get from my patched sketch handlers when drawing over the date line with sciteCompliant set to false). The new renderer development is an ongoing process and can be found in this sandbox: http://svn.openlayers.org/sandbox/ahocevar/renderer-ng Regards, Andreas. Obviously its pointless for me to continue work on renderer model if it wont be accepted into OL, so I'll the study the remaining issues with the handlers in Andreas's patch today. But I dont believe there is a solution to the problem without altering OL. Geometries should be split when the user tries to draw beyond the domain of the coordinate system. Well to be honest I am sick to death of geometry models based on a plane when we live on a spherical earth, and its especially a pain when you live close to the 180 lines and nightmare if you are working near the pole. I would really like to see OL get onto a sphere. There is dearth of tools for working on a sphere. Our inhouse software always manages it because its taken into account from day 1 but reengineering flat earth software to work with real world geometry is a mega pain. Would you be so keen on applications having to split geometry if you lived on the 180 line? -- 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 -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers. ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.
On 8/18/10 3:25 PM, Phil Scadden wrote: Please don't try to bake in any assumptions about heading in a line segment. Our geometry model is based on coordinates on a plane. My opinion is that crossing the dateline is application logic. 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). So when I try to draw say a zoom rectangle across the date line, or measure a distance between two points which happen to be on opposite sides of the dateline, how do I put that logic in my application to cope with this without altering OL? Or draw a selection polygon to choose some data in a WFS layer? This is where problems occurs. The reason for looking at the renderer approach is that there remain problems with just doing it in the handlers. Obviously its pointless for me to continue work on renderer model if it wont be accepted into OL, so I'll the study the remaining issues with the handlers in Andreas's patch today. But I dont believe there is a solution to the problem without altering OL. Geometries should be split when the user tries to draw beyond the domain of the coordinate system. Well to be honest I am sick to death of geometry models based on a plane when we live on a spherical earth, and its especially a pain when you live close to the 180 lines and nightmare if you are working near the pole. I would really like to see OL get onto a sphere. There is dearth of tools for working on a sphere. Our inhouse software always manages it because its taken into account from day 1 but reengineering flat earth software to work with real world geometry is a mega pain. Would you be so keen on applications having to split geometry if you lived on the 180 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. Tim -- Tim Schaub OpenGeo - http://opengeo.org Expert service straight from the developers. ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.
Using the geodesic measuring algorithm, this also works already. Not for area. Here you could use the sketch handlers after applying my patch, and then split the polygon at the maxExtent bounds (patches for polygon splitting welcome :-) ). Andreas, the code does work but only after applying your patches. There was no way for application to solve the problem by splitting geometry without them. Also the patch is making an assumption about 179 0, -179 0. If extent is across dateline, then the joining line you would make with say the path handler crosses the dateline, rather than going around the world (which is what it used to do). You may want to try the SVG2 renderer I am currently working on. There is a chance that it works with geometries that exceed the world bounds (like the ones you get from my patched sketch handlers when drawing over the date line with sciteCompliant set to false). The new renderer development is an ongoing process and can be found in this sandbox: http://svn.openlayers.org/sandbox/ahocevar/renderer-ng I would also need to put same logic into canvas.js. However, this must make assumptions on line directions for 179 0, -179 0 if you are doing this at this level. For the moment, I am working with your patches and seeing what are the unresolved issues. I had next to no time on this over last few days but should be able to get back to it this afternoon. -- 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
Re: [OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.
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). 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. -- 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
Re: [OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.
On 8/17/10 7:14 PM, Phil Scadden wrote: How do you know that the line (179 0, -179 0) is meant to cross the date line? You cant as far as I know. And how would you unambiguously specify it? Please don't try to bake in any assumptions about heading in a line segment. Our geometry model is based on coordinates on a plane. My opinion is that crossing the dateline is application logic. Geometries should be split when the user tries to draw beyond the domain of the coordinate system. We generally store everything in arcSDE in WGS84 lat/long and depend on client mapping to sort it out. When you have no unambiguous way of specify which way the line goes, the obvious convention is take the shortest distance. ship track/air track are overwhelming source of data in this catagory while I cant really think of a mapping application where you would want 179,0, -179,0 to be circle the globe. -- Tim Schaub OpenGeo - http://opengeo.org Expert service straight from the developers. ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.
Tim, apologies for the tone of earlier email. I am finding this a frustrating exercise and believe me, openlayers is best javascript client I can find. I really appreciate your efforts with this one. The alternative for us is arc web mapping and I've gone grey making it work. For the problem of combining vector data across the 180 line with google imagery, ESRI's response could be summarised as bite your bum. Please don't try to bake in any assumptions about heading in a line segment. But surely you are already making an assumption on 179 0, -179 0 - to draw it right around the globe? I cant think a of single application where this would be correct. An assumption surely has be made some time as a two point segment like this is inherently ambiguous on a globe. The shortest path assumption might not be the most economical from a programming points of view but is surely the one most likely to be correct? -- 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
Re: [OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.
How do you know that the line (179 0, -179 0) is meant to cross the date line? You cant as far as I know. And how would you unambiguously specify it? We generally store everything in arcSDE in WGS84 lat/long and depend on client mapping to sort it out. When you have no unambiguous way of specify which way the line goes, the obvious convention is take the shortest distance. ship track/air track are overwhelming source of data in this catagory while I cant really think of a mapping application where you would want 179,0, -179,0 to be circle the globe. -- 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
Re: [OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.
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
Re: [OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.
Hey Phil, thanks for your efforts on this! The reason why I recommended to just use the maxExtent is because for OpenLayers 3.0, we are planning a Location object that will replace LonLat and Geometry.Point, which will be aware of projections. So any efforts in that direction done now won't live long. For now, if you use wrapDateLine: true, you just should use the maxExtent of the whole world. If you want to restrict where the user can pan to, configure restrictedExtent on the map. Regards, Andreas. On Aug 16, 2010, at 04:22 , Phil Scadden wrote: Got another question here. I dont think you can use maxextent to get the required correction to apply since a user may change it. I also notice that the logic used seems to apply to rectilinear projections - it wouldnt be accurate for say conic projections. It seems that accurate way to transform geometry crossing the 180 is unproject to pixel then reproject again but without 180 corrections. -- 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 -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers. ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.
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@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Patrch for getting vector drawing working over the 180 line going.
Okay, I have worked away at doing this in the renderer (drawfeature). I have hit another problem with this approach. Suppose you have 180 line down the middle. Draw an object on the right hand side. geometry.getBounds returns bounds in terms of negative no. (the underlying longs are negative going into the projection). However the extent of the viewport, (used in if (!bounds.intersectsBounds(this.extent)) ) has the right hand side in positive coordinates. The net result is that nothing is visible until you add a point on the left hand side of the date line and suddenly all is visible. Now - should I fix intersectBounds to handle a much more complicated case and then get bounds in same coord. Or should I convert the bounds to consistant coordinates first (my choice)? I am still not sure that doing this in the renderer rather than in path.js, polyon.js is the right thing. I also have to modify the measure controls which dont handle coordinates jumping from positive to negative and back very well. -- 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
