Re: [OpenLayers-Dev] SVG viewbox problem with minScale
Hi. Still i'm not convinced the problem is related to the pixel limit. When the layer is back to in range i tend to think that this.left and this.top should be reset to zero, which isn't the case today because from the renderer perspective it's like resolution has never changed. One way to solve this would be to have the layer pass the renderer the zoomChanged boolean value when calling setExtent, and have the renderer rely on that value to know whether resolution's changed. Although this will probably work in the going back in range situation, i'm not sure it'll work in the going back to visible situation, which must also be dealt with. Unless setVisibility(true) does pass zoomChanged=true to the layer moveTo call. This to be check, which i cant do at the moment. Regards. Eric 2008/7/28, Alexandre Dube [EMAIL PROTECTED]: Hi Eric, The location is correct. It is ok to have a 15000px limit and that works perfectly. To fix the bug, I think when the code checks the resolution, if it's the same than before, it should also check the location of one of our feature position... If it's near our 15000px limit ( let's say more than 14000px for example ) it should change the left-top value of the renderer. That way, even if we zoom out or pan, if we get out of our 15000px limit, features will continue to be displayed. What do you think ? Alexandre Eric Lemoine wrote: On Mon, Jul 28, 2008 at 3:35 PM, Alexandre Dube [EMAIL PROTECTED] wrote: So it seems to me that the problem doesn't really related to the 15000 px limit. In this scenario: - go out of range - pan and zoom without going beyond the 15000 px limit - go in range (the features should be visible as the limit was crossed) is the location of features correct? -- Eric -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] SVG viewbox problem with minScale
I have a patch that i'd like you to test. I cant post it right now but will do as soon as i can. Cheers. Eric 2008/7/29, Eric Lemoine [EMAIL PROTECTED]: Just checked: zoomChanged is set to true in moveTo when coming from setVisibility(true), so the fix describes in my previous email might just work. Eric 2008/7/29, Eric Lemoine [EMAIL PROTECTED]: Hi. Still i'm not convinced the problem is related to the pixel limit. When the layer is back to in range i tend to think that this.left and this.top should be reset to zero, which isn't the case today because from the renderer perspective it's like resolution has never changed. One way to solve this would be to have the layer pass the renderer the zoomChanged boolean value when calling setExtent, and have the renderer rely on that value to know whether resolution's changed. Although this will probably work in the going back in range situation, i'm not sure it'll work in the going back to visible situation, which must also be dealt with. Unless setVisibility(true) does pass zoomChanged=true to the layer moveTo call. This to be check, which i cant do at the moment. Regards. Eric 2008/7/28, Alexandre Dube [EMAIL PROTECTED]: Hi Eric, The location is correct. It is ok to have a 15000px limit and that works perfectly. To fix the bug, I think when the code checks the resolution, if it's the same than before, it should also check the location of one of our feature position... If it's near our 15000px limit ( let's say more than 14000px for example ) it should change the left-top value of the renderer. That way, even if we zoom out or pan, if we get out of our 15000px limit, features will continue to be displayed. What do you think ? Alexandre Eric Lemoine wrote: On Mon, Jul 28, 2008 at 3:35 PM, Alexandre Dube [EMAIL PROTECTED] wrote: So it seems to me that the problem doesn't really related to the 15000 px limit. In this scenario: - go out of range - pan and zoom without going beyond the 15000 px limit - go in range (the features should be visible as the limit was crossed) is the location of features correct? -- Eric -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] SVG viewbox problem with minScale
Thanks Eric, I'll test your patch as soon as it's ready. Alexandre Eric Lemoine wrote: I have a patch that i'd like you to test. I cant post it right now but will do as soon as i can. Cheers. Eric 2008/7/29, Eric Lemoine [EMAIL PROTECTED]: Just checked: zoomChanged is set to true in moveTo when coming from setVisibility(true), so the fix describes in my previous email might just work. Eric 2008/7/29, Eric Lemoine [EMAIL PROTECTED]: Hi. Still i'm not convinced the problem is related to the pixel limit. When the layer is back to in range i tend to think that this.left and this.top should be reset to zero, which isn't the case today because from the renderer perspective it's like resolution has never changed. One way to solve this would be to have the layer pass the renderer the zoomChanged boolean value when calling setExtent, and have the renderer rely on that value to know whether resolution's changed. Although this will probably work in the going back in range situation, i'm not sure it'll work in the going back to visible situation, which must also be dealt with. Unless setVisibility(true) does pass zoomChanged=true to the layer moveTo call. This to be check, which i cant do at the moment. Regards. Eric 2008/7/28, Alexandre Dube [EMAIL PROTECTED]: Hi Eric, The location is correct. It is ok to have a 15000px limit and that works perfectly. To fix the bug, I think when the code checks the resolution, if it's the same than before, it should also check the location of one of our feature position... If it's near our 15000px limit ( let's say more than 14000px for example ) it should change the left-top value of the renderer. That way, even if we zoom out or pan, if we get out of our 15000px limit, features will continue to be displayed. What do you think ? Alexandre Eric Lemoine wrote: On Mon, Jul 28, 2008 at 3:35 PM, Alexandre Dube [EMAIL PROTECTED] wrote: So it seems to me that the problem doesn't really related to the 15000 px limit. In this scenario: - go out of range - pan and zoom without going beyond the 15000 px limit - go in range (the features should be visible as the limit was crossed) is the location of features correct? -- Eric -- Alexandre Dubé Mapgears www.mapgears.com -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] Fwd: [OSGeo-Discuss] Annual Meeting at FOSS4G
See below tyler's call out for project presentations at FOSS4G. I will be there as well as chris schmidt and tim schaub... Is anyone else interested in getting up on stage and saying something? In the past, I think chris has done a good job of this but certainly welcome to offers e -- Forwarded message -- From: OSGeo Tyler Mitchell [EMAIL PROTECTED] Date: Mon, Jul 28, 2008 at 7:25 PM Subject: [OSGeo-Discuss] Annual Meeting at FOSS4G To: OSGeo Discussions [EMAIL PROTECTED] Just a quick note to invite projects and committees to present a brief update at the meeting. Just sign up here: http://wiki.osgeo.org/wiki/Annual_General_Meeting_2008 Tyler ___ Discuss mailing list [EMAIL PROTECTED] http://lists.osgeo.org/mailman/listinfo/discuss ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] SVG viewbox problem with minScale
On Tue, Jul 29, 2008 at 4:48 PM, Alexandre Dube [EMAIL PROTECTED] wrote: Thanks Eric, I'll test your patch as soon as it's ready. I attached it to http://trac.openlayers.org/ticket/1631. It is untested. -- Eric ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] svn 1.5
On Mon, Jul 28, 2008 at 10:45:00PM -0400, Tim Schaub wrote: Hey- Wondering if others think a move to subversion 1.5 would be good. A few features would be nice for OL development. Particularly merge tracking. From the release notes: At the moment, moving to subversion 1.5 on the server is a no-go. I'm assuming the stuff that you are talking about requires server upgrades. It doesn't look like Subversion 1.5 has been backported to Debian Etch (which is what the OL server uses), and I'd prefer not to install from sources other than debian repositories. Regards, -- Christopher Schmidt MetaCarta ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] svn 1.5
On Tue, Jul 29, 2008 at 8:39 PM, Christopher Schmidt [EMAIL PROTECTED] wrote: On Mon, Jul 28, 2008 at 10:45:00PM -0400, Tim Schaub wrote: Hey- Wondering if others think a move to subversion 1.5 would be good. A few features would be nice for OL development. Particularly merge tracking. From the release notes: At the moment, moving to subversion 1.5 on the server is a no-go. I'm assuming the stuff that you are talking about requires server upgrades. It doesn't look like Subversion 1.5 has been backported to Debian Etch (which is what the OL server uses), and I'd prefer not to install from sources other than debian repositories. Makes sense. -- Eric ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] svn 1.5
On Tue, 2008-07-29 at 14:39 -0400, Christopher Schmidt wrote: On Mon, Jul 28, 2008 at 10:45:00PM -0400, Tim Schaub wrote: Wondering if others think a move to subversion 1.5 would be good. It doesn't look like Subversion 1.5 has been backported to Debian Etch (which is what the OL server uses), and I'd prefer not to install from sources other than debian repositories. Is this maybe time to reopen the discussion of moving to OSGeo infrastructure? SDE ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] IE8 beta
I have tested with IE8 beta 1 and it is horribly messed up. Google Maps won't even render properly so its not limited to OpenLayers rendering improperly. I wouldn'y plan on trying to make it work until its nearing Release Candidate stages as it appears Microsoft will be doing some significant work for the next revision (beta 2). -- Nathan Gerber On Tue, Jul 29, 2008 at 3:08 PM, Bart van den Eijnden (OSGIS) [EMAIL PROTECTED] wrote: Hi list, has anybody done some testing with IE8 beta already? Is the upcoming 2.7 release expected to be compatible with IE8 beta? Best regards, Bart -- Bart van den Eijnden OSGIS, Open Source GIS [EMAIL PROTECTED] http://www.osgis.nl ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] IE8 beta
On Tue, Jul 29, 2008 at 09:08:29PM +0200, Bart van den Eijnden (OSGIS) wrote: Hi list, has anybody done some testing with IE8 beta already? Is the upcoming 2.7 release expected to be compatible with IE8 beta? Bart, There are no plans to test OL 2.7 with IE8. At this point, the only release hasn't even resulted in *VirtualEarth* working: They use IE7 compatibility mode on their own pages. If Microsoft isn't up to the task of making their maps work with their browser, I'm certainly not going to spend a lot of time on doing the same for OpenLayers. My feeling is that the current betas simply aren't ready. If this changes before our release, we may take some steps to change this, but I haven't seen evidence that this is likely before our 2.7 release. Regards, -- Christopher Schmidt MetaCarta ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] Scale control uses moveend
Hi Everybody, Is it ok if the Scale control registers a moveend event instead of a zoomend ? To recalculate the scale after panning doesn't look very useful to me. What do you think ? -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Scale control uses moveend
On Tue, Jul 29, 2008 at 03:37:05PM -0400, Alexandre Dube wrote: Hi Everybody, Is it ok if the Scale control registers a moveend event instead of a zoomend ? To recalculate the scale after panning doesn't look very useful to me. What do you think ? At some point in the future, the scale control may actually use geodesic measurements for determining measurements: in a case where you have a global map, scale is obviously not the same everywhere (think a Mercator map), and there has been some rumbling from people that they are unable to use the scale control because it doesn't match the Google Maps-created expectation that the scalebar will change as you drag north and south on a Mercator projected map. Regards, -- Christopher Schmidt MetaCarta ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Scale control uses moveend
On Tue, Jul 29, 2008 at 9:40 PM, Christopher Schmidt [EMAIL PROTECTED] wrote: On Tue, Jul 29, 2008 at 03:37:05PM -0400, Alexandre Dube wrote: Hi Everybody, Is it ok if the Scale control registers a moveend event instead of a zoomend ? To recalculate the scale after panning doesn't look very useful to me. What do you think ? At some point in the future, the scale control may actually use geodesic measurements for determining measurements: in a case where you have a global map, scale is obviously not the same everywhere (think a Mercator map), and there has been some rumbling from people that they are unable to use the scale control because it doesn't match the Google Maps-created expectation that the scalebar will change as you drag north and south on a Mercator projected map. I wouldn't have thought of that. Thanks for the explanation Chris. -- Eric ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] OpenLayers.Tile, abstract enough?
Hello For the grid strategy I needed a specialized tile class. What logically came to mind was create a child class of OpenLayers.Tile, namely OpenLayers.Tile.Vector. Looking at OpenLayers.Tile I discovered that OpenLayers.Tile includes back-buffer code that my class wouldn't need. For that reason, I implemented my vector tile class without inheriting from OpenLayers.Tile, which isn't good as my tile class does respect the tile interface. Shouldn't OpenLayers.Tile be as abstract as possible? Shoulnd't the backbuffer code be moved to some other place? What do you think? Thanks, -- Eric ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev