Re: [OpenLayers-Dev] clearing handlers
Right that was my concern, and my use case used to be (the bug is now fixed fortunately) clearing the sketch layer of the measure control. Since the measure control can have different types of Handlers I would now need to do different things according to which is the underlying Handler. Btw the bug was that when using the mouse wheel for zooming, the measure geometry would not scale so it needed to be cleared. Best regards, Bart Eric Lemoine wrote: I guess Bart is saying that the RegularPolygon handler has an API method named clear (which clear the sketch layer's renderer and destroy the features in that layer), which the other drawing handlers don't have. I'm personally wondering why clear is in an API method in the reg polygon handler in the first place. Eric 2008/11/7, Christopher Schmidt [EMAIL PROTECTED]: On Thu, Nov 06, 2008 at 09:10:20AM +0100, [EMAIL PROTECTED] wrote: Hi list, why is the interface for clearing handlers not standardized? Maybe there is a good reason for it that I am missing. Why do you need to clear handlers? I'm not seeing the use case, I don't think. For Handler/RegularPolygon.js the function is called clear. It will clear the renderer of the layer and call destroyFeatures() on the layer. For Handler/Path.js, Handler/Point.js and Handler/Polygon.js you have to call destroyFeature directly. Would it not be better to have a API method called clear on all these Handlers? Thoughts? Best regards, Bart ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev -- Christopher Schmidt MetaCarta ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev -- 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
Re: [OpenLayers-Dev] popup closebox issue
Hi Eric, There is no problem with the popup closebox on Safari with a mac... I'll try this week end on my pc with safari... Eric Lemoine-3 wrote: Hello I noticed that the popup closebox is not rendered on Safari (Safari 3.0.3 on Windows). Has anyone else experienced that? Is the problem existing on Safari on Mac as well? Thanks, -- Eric ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev -- View this message in context: http://www.nabble.com/popup-closebox-issue-tp20378034p20381276.html Sent from the OpenLayers Dev mailing list archive at Nabble.com. ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] popup closebox issue
Yeah, I'll fill one. Thanks to you both for your feedback. Eric 2008/11/7, Erik Uzureau [EMAIL PROTECTED]: Confirmed on Windows XP, 3.0.4 ...do you want to file a ticket for that, eric? erik On Fri, Nov 7, 2008 at 4:27 AM, Eric Lemoine [EMAIL PROTECTED] wrote: Hello I noticed that the popup closebox is not rendered on Safari (Safari 3.0.3 on Windows). Has anyone else experienced that? Is the problem existing on Safari on Mac as well? Thanks, -- Eric ___ 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] Bug in rendering features with cluster strategy
I tried this small patch but unfortunately the problem persist. Is there
a new patch for this issue ( feature stays on screen when zooming with
mouse over it with cluster strategy ) ?
If not, I would like to disable the wheel zoom. How can I do that ?
Alexandre
Tim Schaub wrote:
Hey-
Eric Lemoine wrote:
Yes. Especially since drawFeature is often called from addFeatures,
where we're assured that the feature is in the layer. So, instead, we
may want to change the select feature control so that it calls
drawFeature only if, in the case of selection, the feature is in the
features array, and in the case of unselection, the feature is in
the selectedFeatures array. What do you think? Eric
The problem is in the Feature handler. We destroy features, but
references to them are still truthy. Since the destroy code sets the
layer property to null, one check of an undestroyed feature is to check
feature.layer.
See http://trac.openlayers.org/attachment/ticket/1806/destroyed.patch
2008/11/4, Tim Schaub [EMAIL PROTECTED]:
Hey-
Ivan Grcic wrote:
OK... i found it..inside Layer.Vector...now the question is: should i
put something like this:
if (OpenLayers.Util.indexOf(this.features, feature) != -1){
inside drawFeature: function(feature, style) {
Nope. Making drawFeature that safe at the expense of iterating through
every feature with every draw is a mistake.
or inside every other function inside Layer.Vector that uses
drawFeature function?
When I put it here:
drawFeature: function(feature, style) {
--if (OpenLayers.Util.indexOf(this.features, feature) != -1){
..
..
}
}
it works pretty fine for me :) Eric?
On Mon, Nov 3, 2008 at 9:53 AM, Ivan Grcic [EMAIL PROTECTED] wrote:
Yup, its not Cluster Strategy...
http://trac.openlayers.org/ticket/1806#comment:2
On Mon, Nov 3, 2008 at 9:11 AM, Eric Lemoine [EMAIL PROTECTED] wrote:
Hi.
Yes, this looks like a bug in OpenLayers.
I'm under the impression that this isn't a bug in the cluster strategy
but either in Layer.Vector or in Control.SelectFeature. Indeed, I
think SelectFeature calls layer.drawFeature on feature
selection/unselection without checking whether the feature is in the
layer. And i'm saying this may be a bug in Layer.Vector because it may
be that drawFeature should be responsible for checking whether the
feature is in the layer before actually drawing it.
This is just coming from the top of my head so i may be wrong, but i'm
feeling this is a good track to follow :)
Eric
2008/11/2, Ivan Grcic [EMAIL PROTECTED]:
Hi list,
i discovered a bug while developing my OL application, in cluster
strategy class.
Bug occurs when you hover over one feature that represent a cluster
(or externalGraphic or like in cluster example - vector circle
http://openlayers.org/dev/examples/strategy-cluster.html)
When you zoom in/out while that feature-cluster is selected (by
quickly double-clicking or easier using scroll on ur mouse), on next
zoom that cluster is rendered (stays on screen) together with newly
created clusters! And clearly it shouldnt be there. The old
(phantom) cluster is not selectable, as he doesnt exist on the new
zoom level..he just stays there on screen...annoying me :)
As you zoom in again and again, phantom clusters always render, always
at the same position in the map div...
Please confirm that this is a bug, im going crazy here with this one :|
--
Ivan Grcic
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
--
Ivan Grcic
--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
--
Alexandre Dubé
Mapgears
www.mapgears.com
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] Cluster strategy getResolution bug ?
Hi devs, I got a problem using the cluster strategy. At first, it didn't seemed to work at all. I always got the same number of feature with or without the cluster strategy applied. After a few search, I found out the problem was at line 143 : *var* resolution = *this*.layer.getResolution(); I just replaced the line for : *var* resolution = *this*.layer.map.getResolution(); and it worked. The reason is : My base layer has 10 fixed scales ( which gives 10 resolutions), from 0 to 9. My vector layer has only 7, which represents resolutions 3 to 9 of the base layer's scales, but the vector layer itself has his own scales array from 0 to 6. So, the line 143 which called resolution 3 from the base layer calls resolution 3 from the vector layer, which is wrong ! Anyone else noticed this ? -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Bug in rendering features with cluster strategy
Hey Alex...well actually i didnt catch time to try the patch...but
before patch was made i created dirty hack that was working for me.
Its not the best solution, but hey it works :)
inside drawFeature just add one if statement
function(feature, style) {
if (OpenLayers.Util.indexOf(this.features, feature) != -1){
...
...
}
}
(but for sure I will try the patch supplied in 1806 as soon as i can)
On Fri, Nov 7, 2008 at 8:15 PM, Alexandre Dube [EMAIL PROTECTED] wrote:
Answer to my second question... still looking for the first...
If not, I would like to disable the wheel zoom. How can I do that ?
oNavCtrl = new OpenLayers.Control.Navigation(
{ 'zoomWheelEnabled': false});
Alexandre Dube wrote:
I tried this small patch but unfortunately the problem persist. Is there
a new patch for this issue ( feature stays on screen when zooming with
mouse over it with cluster strategy ) ?
If not, I would like to disable the wheel zoom. How can I do that ?
Alexandre
Tim Schaub wrote:
Hey-
Eric Lemoine wrote:
Yes. Especially since drawFeature is often called from addFeatures,
where we're assured that the feature is in the layer. So, instead, we
may want to change the select feature control so that it calls
drawFeature only if, in the case of selection, the feature is in the
features array, and in the case of unselection, the feature is in
the selectedFeatures array. What do you think? Eric
The problem is in the Feature handler. We destroy features, but
references to them are still truthy. Since the destroy code sets the
layer property to null, one check of an undestroyed feature is to check
feature.layer.
See http://trac.openlayers.org/attachment/ticket/1806/destroyed.patch
2008/11/4, Tim Schaub [EMAIL PROTECTED]:
Hey-
Ivan Grcic wrote:
OK... i found it..inside Layer.Vector...now the question is: should i
put something like this:
if (OpenLayers.Util.indexOf(this.features, feature) != -1){
inside drawFeature: function(feature, style) {
Nope. Making drawFeature that safe at the expense of iterating through
every feature with every draw is a mistake.
or inside every other function inside Layer.Vector that uses
drawFeature function?
When I put it here:
drawFeature: function(feature, style) {
-- if (OpenLayers.Util.indexOf(this.features, feature) != -1){
..
..
}
}
it works pretty fine for me :) Eric?
On Mon, Nov 3, 2008 at 9:53 AM, Ivan Grcic [EMAIL PROTECTED] wrote:
Yup, its not Cluster Strategy...
http://trac.openlayers.org/ticket/1806#comment:2
On Mon, Nov 3, 2008 at 9:11 AM, Eric Lemoine [EMAIL PROTECTED] wrote:
Hi.
Yes, this looks like a bug in OpenLayers.
I'm under the impression that this isn't a bug in the cluster strategy
but either in Layer.Vector or in Control.SelectFeature. Indeed, I
think SelectFeature calls layer.drawFeature on feature
selection/unselection without checking whether the feature is in the
layer. And i'm saying this may be a bug in Layer.Vector because it may
be that drawFeature should be responsible for checking whether the
feature is in the layer before actually drawing it.
This is just coming from the top of my head so i may be wrong, but i'm
feeling this is a good track to follow :)
Eric
2008/11/2, Ivan Grcic [EMAIL PROTECTED]:
Hi list,
i discovered a bug while developing my OL application, in cluster
strategy class.
Bug occurs when you hover over one feature that represent a cluster
(or externalGraphic or like in cluster example - vector circle
http://openlayers.org/dev/examples/strategy-cluster.html)
When you zoom in/out while that feature-cluster is selected (by
quickly double-clicking or easier using scroll on ur mouse), on next
zoom that cluster is rendered (stays on screen) together with newly
created clusters! And clearly it shouldnt be there. The old
(phantom) cluster is not selectable, as he doesnt exist on the new
zoom level..he just stays there on screen...annoying me :)
As you zoom in again and again, phantom clusters always render, always
at the same position in the map div...
Please confirm that this is a bug, im going crazy here with this one
:|
--
Ivan Grcic
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
--
Ivan Grcic
--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
--
Alexandre Dubé
Mapgears
www.mapgears.com
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
--
Ivan Grcic
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Cluster strategy getResolution bug ?
Yup, and i was about to fill this one too :) Did u fill the ticket allready? On Fri, Nov 7, 2008 at 10:30 PM, Alexandre Dube [EMAIL PROTECTED] wrote: Hi devs, I got a problem using the cluster strategy. At first, it didn't seemed to work at all. I always got the same number of feature with or without the cluster strategy applied. After a few search, I found out the problem was at line 143 : *var* resolution = *this*.layer.getResolution(); I just replaced the line for : *var* resolution = *this*.layer.map.getResolution(); and it worked. The reason is : My base layer has 10 fixed scales ( which gives 10 resolutions), from 0 to 9. My vector layer has only 7, which represents resolutions 3 to 9 of the base layer's scales, but the vector layer itself has his own scales array from 0 to 6. So, the line 143 which called resolution 3 from the base layer calls resolution 3 from the vector layer, which is wrong ! Anyone else noticed this ? -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev -- Ivan Grcic ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Cluster strategy getResolution bug ?
And i think it might be connected to with http://www.nabble.com/Cluster-and-Scales-map-options-td20224740.html#a20224740 On Sat, Nov 8, 2008 at 12:00 AM, Ivan Grcic [EMAIL PROTECTED] wrote: Yup, and i was about to fill this one too :) Did u fill the ticket allready? On Fri, Nov 7, 2008 at 10:30 PM, Alexandre Dube [EMAIL PROTECTED] wrote: Hi devs, I got a problem using the cluster strategy. At first, it didn't seemed to work at all. I always got the same number of feature with or without the cluster strategy applied. After a few search, I found out the problem was at line 143 : *var* resolution = *this*.layer.getResolution(); I just replaced the line for : *var* resolution = *this*.layer.map.getResolution(); and it worked. The reason is : My base layer has 10 fixed scales ( which gives 10 resolutions), from 0 to 9. My vector layer has only 7, which represents resolutions 3 to 9 of the base layer's scales, but the vector layer itself has his own scales array from 0 to 6. So, the line 143 which called resolution 3 from the base layer calls resolution 3 from the vector layer, which is wrong ! Anyone else noticed this ? -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev -- Ivan Grcic -- Ivan Grcic ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
