Re: [OpenLayers-Dev] SVG viewbox problem with minScale
Hi Eric, I opened a ticket : #1631. Of what I understand, the bug comes from the resolution and inRange value of the layer. While it's not inRange, our renderer doesn't change its left and top values, even if we zoom. But, when inRange, it first checks the resolution. If it changed, then new left-top values are created but in our case it didn't so the left-top values remain the sames and when each features is added, they are out of the 15000 pixel range and are not displayed. Best regards, Alexandre Eric Lemoine wrote: You indeed found a bug. Can you open a ticket and attach some code to help developpers reproduce it. Do you observe the same problem if you dont go beyond the 15000 px? I.e. go in range, pan w/o going beyond the limit, go out of range, pan, and go back in range. I'm trying to understand whether the problem comes from the code relating to the 15000px limit. Thanks. Eric 2008/7/25, Alexandre Dube [EMAIL PROTECTED]: Hi everybody, I use Firefox ( big fan ). Of what I understand, each time I zoom in or out a map that has a vector layer, the left and top values of the rederer's viewbox are reseted to 0. I have a WFS layer with a minScale: 4 in my map. So, the first time I get inRange of my layer, left and top are reset to 0. If I pan, they change their value and if their value is 15000 pixels away from my original left-top, no feature will be drawn. The problem is if I zoom out of my minScale: 4, my layer becomes inactive. Zooming out don't reset the left-top values. So, if I pan to somewhere else and then zoom in until I get inRange of my minScale, my WFS layer shows no features because it's as we didn't zoom at all ( the resolution is the same that the time we zoom out of range ) . But, if I zoom in again once, then the features appear (because the resolution has changed, and left-top are reseted to 0). If I zoom out once, the features are still there. I think the line 504 in SVG.js should be changed. Instead of doing nothing if not inValidRange, it should check again by ignoring the resolution. That would resolve the issue, I think... Any comments ? -- Alexandre Dubé Mapgears www.mapgears.com ___ 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] Layer.Text popup getting bigger
Hi, I posted this message to the users list but got no reply. I don't know if anybody noticed this yet : when you use a Layer.Text and you keep clicking on the same marker, the popup gets bigger and bigger. Even the example it does that : http://openlayers.org/dev/examples/markersTextLayer.html Any comments ? Is that a reported bug ? -- 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
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] 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] Vector features don't display at level 0
Ok, I'll just have to wait for the next release then :) ( I wasn't sure if the trunk was actually as the next release would be. ) Thanks, Alexandre Christopher Schmidt wrote: On Fri, Sep 05, 2008 at 07:37:57AM -0400, Alexandre Dube wrote: Hi devs, I use OpenLayers 2.6 and I have an issue while using vector features. I have a WFS layer that displays features on different zoom levels. When I initialize the zoom level to anything but 0, features are displayed. If I then go back to level 0, features are displayed. But, when I start at level 0, features are not displayed. I then zoom to level 1 and here they are. Back to 0 they're here again. Also, if I start at level 0 ( features not here ), and unselect the layer in the layerswitcher and reselect it, features appear. When starting at level 0, the features array contain features. The layer is inRange and is Visible so it should show its features ? I tested my application with the trunk and the features are displayed at level 0 on start. I was wondering if this is a known bug and if it has already been fixed. Er, if it works in trunk, then isn't the answer to this an obvious yes? Regards, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] WFSDescribeFeatureType request in 2.7-rc1 extra ?
Hi devs,
I noticed a new strange behavior with OpenLayers 2.7-rc1 using
WFSDescribeFeatureType format.
Here's the request I'm using :
var sUrl = olWFSRoads.getFullRequestString({
REQUEST: DescribeFeatureType,
SERVICE: WFS,
TYPENAME: BDGA_ROUTE_L_ARC,
VERSION: 1.0.0
});
OpenLayers.loadURL(sUrl, '', this, setRoadAttributes);
Here's the end of the URL in :
2.6 : SRS=EPSG%3A32198TYPENAME=BDGA_ROUTE_L_ARC
2.7 : SRS=EPSG%3A32198TYPENAME=BDGA_ROUTE_L_ARC?
With 2.7, I get the following error : Invalid typename
(BDGA_ROUTE_L_ARC?). There should not be a ? at the end of the request.
Then, I realized that typename is already at the beginning of the
request so I just quoted //TYPENAME: BDGA_ROUTE_L_ARC, and it worked,
but the ? is still there ( at the end ) but it didn't affect
anything. I don't know if this extra ? could appear elsewhere ( on
other requests )
Should I open a ticket for this ?
--
Alexandre Dubé
Mapgears
www.mapgears.com
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] WFSDescribeFeatureType request in 2.7-rc1 extra ?
I tried an other request and got the same problem. In Requests.js at
line 90, that's where it gets its extra ?
OpenLayers.loadURL(
/bdga/getLayersByType.php?mapfile=+szMapfile, '', this, setLayers);
The request becomes :
.../bdga/getLayersByType.php?mapfile=/mypath/bdga.map?
Alexandre
Alexandre Dube wrote:
Hi devs,
I noticed a new strange behavior with OpenLayers 2.7-rc1 using
WFSDescribeFeatureType format.
Here's the request I'm using :
var sUrl = olWFSRoads.getFullRequestString({
REQUEST: DescribeFeatureType,
SERVICE: WFS,
TYPENAME: BDGA_ROUTE_L_ARC,
VERSION: 1.0.0
});
OpenLayers.loadURL(sUrl, '', this, setRoadAttributes);
Here's the end of the URL in :
2.6 : SRS=EPSG%3A32198TYPENAME=BDGA_ROUTE_L_ARC
2.7 : SRS=EPSG%3A32198TYPENAME=BDGA_ROUTE_L_ARC?
With 2.7, I get the following error : Invalid typename
(BDGA_ROUTE_L_ARC?). There should not be a ? at the end of the request.
Then, I realized that typename is already at the beginning of the
request so I just quoted //TYPENAME: BDGA_ROUTE_L_ARC, and it worked,
but the ? is still there ( at the end ) but it didn't affect
anything. I don't know if this extra ? could appear elsewhere ( on
other requests )
Should I open a ticket for this ?
--
Alexandre Dubé
Mapgears
www.mapgears.com
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] Vector labels
Hi dev, Anything new about vector labels ? -- 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
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] Cluster strategy getResolution bug ?
Ok thanks Tim, I had some trouble at first trying to use minResolution/maxResolution... But quickly found out that when you want a layer only visible at a certain reach, you must choose either scale OR resolution to work with, not both. I was setting maxResolution to 3.527775872778806 but at some point it was given a new value of 35.27775872778806 ( the maxResolution of the baseLayer... ) because I used scales:[xx,xx,xx]. Using resolutions[xx,xx,xx] solved this problem. But, in the end it didn't help with my cluster strategy problem. I still have to hack Cluster.js to make it work properly. Well, in the end I don't understand what I'm doing wrong. Sorry. Alexandre Tim Schaub wrote: Hey- Alexandre Dube wrote: Hi Eric, Ok, I understand what you mean. But I already set specific scales to the vector layer that are supposed to give the same resolutions I need. I mean : Base layer (map) has scales in its options: [ 10, 5, 25000, 1, 5000, 2500, 1000, 500, 250, 100] Vector layer has scales in its options: [1, 5000, 2500, 1000, 500, 250, 100] So I expect the vector layer to have the good corresponding resolutions, but it hasn't. Maybe that is the issue. Any thoughts ? Only the resolutions in your base layer are respected. Individual resolution values on all overlay layers are ignored. When your map changes resolution, layer.calculateInRange is called for each overlay layer. If this returns false, the layer is not displayed. The layer.calculateInRange method checks layer.minResolution and layer.maxResolution. If map.getResolution returns a value that is between the min/max for the layer (inclusive), calculateInRange returns true. (The exception to this is when layer.alwaysInRange is true.) If you are encountering a situation where calculateInRange does not return the appropriate value, or if you think the precision in the scale to resolution conversion is not consistent, please start a new thread (this has nothing to do with vector layers or the cluster strategy). Tim Alexandre Eric Lemoine wrote: Hi Alexandre If you want your vector layer to be visible only for a subset of the base layer's resolutions you should set maxResolution and/or minResolution in your vector layer options. If you pass an array of resolutions to the vector layer, you can end up with vectorlayer.resolutions[i] != baselayer.resolutions[i], where i is any index of the vector layer's resolutions array. And I think you are hitting the above case, which is making the cluster strategy doesn't behave as you expect it to. So I don't see anything wrong with the cluster strategy relying on this.layer.getResolution. I'd really like to hear what others think about that. Cheers, Eric 2008/11/7, Alexandre Dube [EMAIL PROTECTED]: 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 -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Cluster strategy should not process data when layer is currently disabled (visibility=false)
I get the same behavior as Ivan's on my application which has very similar resolution settings on map an vector layer. Because a layer's features are not destroyed when it goes out of range (inRange) or becomes invisible (visibility), the cluster strategy still clusters those existing features. I don't have that many features to display when the layer becomes inRange, so I never noticed any slowing down. Alexandre Ivan Grcic wrote: This post evolved from previous discussion named bbox strategy and zooming Clustering features with cluster strategy takes some time. If there are many features to cluster, it will take even more time :) So there are some scenarios where clustering shouldnt be recalculated. Example: I want to see my cluster layer only after 5th zoom level. No clustering should be made when i play on zoom level 0-4 with other layers, because it slows things down, and the cluster layer is still not visible at all (its only clustering features in background) It should only cluster when layer is visible (and the current map resolution is inside array resolution of clustered layer, if we define seperate set of resolution) So if map has: resolutions: [0,1,2,3,4,5,6,7,8,9] and vector layer: resolutions: [5, 6, 7, 8, 9] clustering should occur only on vector layers resolution :5, 6, 7, 8 and 9. I hope you see where im pointing now, Best regards, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Cluster strategy should not process data when layer is currently disabled (visibility=false)
Eric Lemoine wrote: Alexandre, Could you apply the patches attached to #1831 et #1834 and report back? Thanks, http://trac.openlayers.org/ticket/1831 http://trac.openlayers.org/ticket/1834 -- Eric Problem solved for me. No events ( like clustering) are triggered by the layer on moveend while it's not inRange or visible. Thanks Eric, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] Strategy.Save new events
Hi devs, http://trac.openlayers.org/ticket/1902 is an unassigned ticket with a patch implementing new features to the Strategy.Save. Comments are welcomed, Regards, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] Proxy with dev.openlayers.org
Hi devs, Some examples on sandboxes don't work because http://dev.openlayers.org/proxy/ doesn't exist. Could that be fixed ? -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] new Strategy.OptionsByZoom
Hi devs, http://trac.openlayers.org/ticket/1905 is an unassigned ticket implementing a new feature : Strategy.OptionsByZoom See live examples of use : (working) http://dev4.mapgears.com/bdga/options-by-zoom-bdga.html (missing different data sources) http://dev.openlayers.org/sandbox/adube/openlayers/examples/options-by-zoom.html Comments are welcomed, Regards, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] multipleSelectFeature on one layer
Hi devs, I would like to propose some changes about the SelectFeature control. First, I'll introduce what I want to do : I want to change the color of a feature while the mouse is over it without selecting it. I managed to do this by building a customized control similar to the SelectFeature control named HighlightFeature. I shared the code and some people showed interest in this feature. In fact, it was a good enough to be added to trunk but there was a problem : it's too similar to the SelectFeature control. My first new option was to modify the SelectFeature control to be able to select and highlight. That's what I did, but I hit a wall : I needed to add more new events beforefeaturehighlighted, featurehighlighted, etc. a new array of highlightedFeatures, etc... That also became a pain because it was yet an other duplication of something already existant ( similair select feature events, an array of selected features, etc) SO, that brings me to this solution, the first one Eric Lemoine proposed : an array of selectedFeatures and select events for the control ( without removing the ones of the layer ). Doing that, one vector layer could have multiple select feature controls that would know which feature it has selected, they could all have a different renderIntent value ( this is already possible ) or their own style. Then, the user could interact directly with the desired control's selectedFeatures. My example : One SelectFeature that select on click, has the default render intent select, on which I register a featureselected to display a form to fill. And one other SelectFeature that select on hover, has a custom render intent temporary to have a different color and an event registered to featureselected to display a quick popup of the infos of the hovered feature. Even my DeleteFeature control I created a couple of weeks ago could work by using an other SelectFeature control and using its own featureSelected array. I'll make thoses small changes, an example and propose this as an enhancement. What do you think ? Regards, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] multipleSelectFeature on one layer
Hi devs, Eric was right : A first note. The current select feature implementation should accomodate this use case: two controls on the same layer, one working on click and the other on hover, only one of them actually changing the feature style. This is achievable by registering a beforefeatureselected listener, and have this listener return false. Adding beforefeatureunselected might help fully accomodate that use case. Now if we want the two controls to do feature styling, we need the stuff I mentioned previously - per-control selectedFeatures arrays and events. But this is unfortunately not sufficient. Use case: two controls, one working on click and the other on hover, both doing feature styling but with different render intents. If we have this sequence mouse goes over feature, mouse clicks feature, mouse goes out of feature, then the feature ends up being rendered with the default render intent, while it's still selected from the click control's perspective. In most cases, this isn't desirable I think. At this point I don't have a solution to the above issue. An idea that could resolve this issue : features could have a stack of renderIntent instead of a normal string value. Instead of assigning new renderIntent value, it would stack in renderIntents array. Instead of reseting to default, it would remove the last renderIntent in the stack. When the stack is empty, the default renderIntent is applied. That could work. I'll try this and come back with more details. Alexandre Alexandre Dube wrote: Hi devs, I would like to propose some changes about the SelectFeature control. First, I'll introduce what I want to do : I want to change the color of a feature while the mouse is over it without selecting it. I managed to do this by building a customized control similar to the SelectFeature control named HighlightFeature. I shared the code and some people showed interest in this feature. In fact, it was a good enough to be added to trunk but there was a problem : it's too similar to the SelectFeature control. My first new option was to modify the SelectFeature control to be able to select and highlight. That's what I did, but I hit a wall : I needed to add more new events beforefeaturehighlighted, featurehighlighted, etc. a new array of highlightedFeatures, etc... That also became a pain because it was yet an other duplication of something already existant ( similair select feature events, an array of selected features, etc) SO, that brings me to this solution, the first one Eric Lemoine proposed : an array of selectedFeatures and select events for the control ( without removing the ones of the layer ). Doing that, one vector layer could have multiple select feature controls that would know which feature it has selected, they could all have a different renderIntent value ( this is already possible ) or their own style. Then, the user could interact directly with the desired control's selectedFeatures. My example : One SelectFeature that select on click, has the default render intent select, on which I register a featureselected to display a form to fill. And one other SelectFeature that select on hover, has a custom render intent temporary to have a different color and an event registered to featureselected to display a quick popup of the infos of the hovered feature. Even my DeleteFeature control I created a couple of weeks ago could work by using an other SelectFeature control and using its own featureSelected array. I'll make thoses small changes, an example and propose this as an enhancement. What do you think ? Regards, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] WFS protocol
Unfortunately, the meeting didn't happen yet. We'll let the community know when it happens. Alexandre Christopher Schmidt wrote: On Thu, Jan 15, 2009 at 09:37:02AM -0700, Tim Schaub wrote: Hey- We've done quite a bit of work toward a working WFS protocol in the topp/wfs sandbox. The work includes (fairly significant) changes to filters and formats and will need to be divided into a few tickets at least. The protocol will likely not satisfy *all* cases for WFS, but I think it is important that we get something working in the trunk. Additional enhancements can come later. Alexandre Dube and I will be meeting on #openlayers at 16:30 GMT, Tues Jan 20 (next week) to talk about dividing up responsibilities for making patches and getting this in the trunk. Somehow I missed this meeting taking place on IRC. Can you sum up the results of it? Perhaps post a log? Regards, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] multipleSelectFeature on one layer
Hi Eric, You're right. So instead of removing the last renderIntent from the stack, we need to remove the last renderIntent of the current SelectFeature. SFC = SelectFeature Control RIA = renderIntents array Let's say the mouse goes hover a feature and get selected by a 1st SFC : RIA : [temporary] Then the user click it to select it with an other SFC : RIA : [temporary, select] Then the mouse goes out of the feature, unselecting it from the 1st SFC : RIA : [select] The feature is still drawn with the select renderIntent. What do you think ? With this, you don't need to have 4 different possibilities. The user can define an infinite number of different renderIntents, have a styleMap defining each one of them. Alexandre Eric Lemoine wrote: Hi Alex Consider this sequence: mouse goes over feature, feature is clicked (for selection), and clicked again (for unselection). With your stack of intents logic, the feature isn't redrawn as a result of the second click; instead it should be redrawn with the hover control's render intent, shouldn't it? Eric 2009/1/23, Alexandre Dube ad...@mapgears.com: Hi devs, Eric was right : A first note. The current select feature implementation should accomodate this use case: two controls on the same layer, one working on click and the other on hover, only one of them actually changing the feature style. This is achievable by registering a beforefeatureselected listener, and have this listener return false. Adding beforefeatureunselected might help fully accomodate that use case. Now if we want the two controls to do feature styling, we need the stuff I mentioned previously - per-control selectedFeatures arrays and events. But this is unfortunately not sufficient. Use case: two controls, one working on click and the other on hover, both doing feature styling but with different render intents. If we have this sequence mouse goes over feature, mouse clicks feature, mouse goes out of feature, then the feature ends up being rendered with the default render intent, while it's still selected from the click control's perspective. In most cases, this isn't desirable I think. At this point I don't have a solution to the above issue. An idea that could resolve this issue : features could have a stack of renderIntent instead of a normal string value. Instead of assigning new renderIntent value, it would stack in renderIntents array. Instead of reseting to default, it would remove the last renderIntent in the stack. When the stack is empty, the default renderIntent is applied. That could work. I'll try this and come back with more details. Alexandre Alexandre Dube wrote: Hi devs, I would like to propose some changes about the SelectFeature control. First, I'll introduce what I want to do : I want to change the color of a feature while the mouse is over it without selecting it. I managed to do this by building a customized control similar to the SelectFeature control named HighlightFeature. I shared the code and some people showed interest in this feature. In fact, it was a good enough to be added to trunk but there was a problem : it's too similar to the SelectFeature control. My first new option was to modify the SelectFeature control to be able to select and highlight. That's what I did, but I hit a wall : I needed to add more new events beforefeaturehighlighted, featurehighlighted, etc. a new array of highlightedFeatures, etc... That also became a pain because it was yet an other duplication of something already existant ( similair select feature events, an array of selected features, etc) SO, that brings me to this solution, the first one Eric Lemoine proposed : an array of selectedFeatures and select events for the control ( without removing the ones of the layer ). Doing that, one vector layer could have multiple select feature controls that would know which feature it has selected, they could all have a different renderIntent value ( this is already possible ) or their own style. Then, the user could interact directly with the desired control's selectedFeatures. My example : One SelectFeature that select on click, has the default render intent select, on which I register a featureselected to display a form to fill. And one other SelectFeature that select on hover, has a custom render intent temporary to have a different color and an event registered to featureselected to display a quick popup of the infos of the hovered feature. Even my DeleteFeature control I created a couple of weeks ago could work by using an other SelectFeature control and using its own featureSelected array. I'll make thoses small changes, an example and propose this as an enhancement. What do you think ? Regards, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing
Re: [OpenLayers-Dev] multipleSelectFeature on one layer
Hi devs, My only problem remaining : should the layer keep its selectedFeature array ? If so, on selection, it's easy to know if a feature is already selected. As soon as one control adds it to its own array, it checks in the layer's one and add it if it's not there. But for unselection, before removing it from the layer's array, we would need to check all select features control and all controls containing select features control. Since we can easily say that one control does a specific task at a time, I don't really see the use of the selectedFeatures array in the layer. I would just remove it and avoid the above problem. What do you think ? Alexandre Alexandre Dube wrote: Hi Eric, You're right. So instead of removing the last renderIntent from the stack, we need to remove the last renderIntent of the current SelectFeature. SFC = SelectFeature Control RIA = renderIntents array Let's say the mouse goes hover a feature and get selected by a 1st SFC : RIA : [temporary] Then the user click it to select it with an other SFC : RIA : [temporary, select] Then the mouse goes out of the feature, unselecting it from the 1st SFC : RIA : [select] The feature is still drawn with the select renderIntent. What do you think ? With this, you don't need to have 4 different possibilities. The user can define an infinite number of different renderIntents, have a styleMap defining each one of them. Alexandre Eric Lemoine wrote: Hi Alex Consider this sequence: mouse goes over feature, feature is clicked (for selection), and clicked again (for unselection). With your stack of intents logic, the feature isn't redrawn as a result of the second click; instead it should be redrawn with the hover control's render intent, shouldn't it? Eric 2009/1/23, Alexandre Dube ad...@mapgears.com: Hi devs, Eric was right : A first note. The current select feature implementation should accomodate this use case: two controls on the same layer, one working on click and the other on hover, only one of them actually changing the feature style. This is achievable by registering a beforefeatureselected listener, and have this listener return false. Adding beforefeatureunselected might help fully accomodate that use case. Now if we want the two controls to do feature styling, we need the stuff I mentioned previously - per-control selectedFeatures arrays and events. But this is unfortunately not sufficient. Use case: two controls, one working on click and the other on hover, both doing feature styling but with different render intents. If we have this sequence mouse goes over feature, mouse clicks feature, mouse goes out of feature, then the feature ends up being rendered with the default render intent, while it's still selected from the click control's perspective. In most cases, this isn't desirable I think. At this point I don't have a solution to the above issue. An idea that could resolve this issue : features could have a stack of renderIntent instead of a normal string value. Instead of assigning new renderIntent value, it would stack in renderIntents array. Instead of reseting to default, it would remove the last renderIntent in the stack. When the stack is empty, the default renderIntent is applied. That could work. I'll try this and come back with more details. Alexandre Alexandre Dube wrote: Hi devs, I would like to propose some changes about the SelectFeature control. First, I'll introduce what I want to do : I want to change the color of a feature while the mouse is over it without selecting it. I managed to do this by building a customized control similar to the SelectFeature control named HighlightFeature. I shared the code and some people showed interest in this feature. In fact, it was a good enough to be added to trunk but there was a problem : it's too similar to the SelectFeature control. My first new option was to modify the SelectFeature control to be able to select and highlight. That's what I did, but I hit a wall : I needed to add more new events beforefeaturehighlighted, featurehighlighted, etc. a new array of highlightedFeatures, etc... That also became a pain because it was yet an other duplication of something already existant ( similair select feature events, an array of selected features, etc) SO, that brings me to this solution, the first one Eric Lemoine proposed : an array of selectedFeatures and select events for the control ( without removing the ones of the layer ). Doing that, one vector layer could have multiple select feature controls that would know which feature it has selected, they could all have a different renderIntent value ( this is already possible ) or their own style. Then, the user could interact directly with the desired control's selectedFeatures. My example : One SelectFeature
Re: [OpenLayers-Dev] multipleSelectFeature on one layer
Amos Hayes wrote: I think the big questions for me are: Where are you planning to store the states? Do you mean feature.state ? I don't understand what you mean. How will an app developer obtain a list of currently selected features and distinguish between the 'selections' that have been applied if more than one control has been set up? Since each SelectControl would have its own selectedFeatures array, you can easilly access them with yourControl.selectedFeatures. By defining each control a different renderIntent and having a renderIntents stack array, you can easilly keep track of by what control the feature was selected. I understand the fact that trying to have more than one SelectFeature at a time is not very logic since one control == one type of action the user wants to do, and normally the user wants to do 1 at a time, like : - select features to delete them - select a feature to modify its geometry then save - select a feature to display its attributes values in a popup Normally, only one of theses should be active at a time, except the last one because it's only to display some info. The feature doesn't get modified. So, it could be active at the same time as the other two, with a hover:true option to display the popup when over a feature and changing its color. Nothing more. What do you think ? Alexandre -- Amos Hayes Geomatics and Cartographic Research Centre Carleton University aha...@gcrc.carleton.ca +1.613.520.2600x8179 On 26-Jan-09, at 10:13 AM, Alexandre Dube wrote: Hi devs, My only problem remaining : should the layer keep its selectedFeature array ? If so, on selection, it's easy to know if a feature is already selected. As soon as one control adds it to its own array, it checks in the layer's one and add it if it's not there. But for unselection, before removing it from the layer's array, we would need to check all select features control and all controls containing select features control. Since we can easily say that one control does a specific task at a time, I don't really see the use of the selectedFeatures array in the layer. I would just remove it and avoid the above problem. What do you think ? Alexandre Alexandre Dube wrote: Hi Eric, You're right. So instead of removing the last renderIntent from the stack, we need to remove the last renderIntent of the current SelectFeature. SFC = SelectFeature Control RIA = renderIntents array Let's say the mouse goes hover a feature and get selected by a 1st SFC : RIA : [temporary] Then the user click it to select it with an other SFC : RIA : [temporary, select] Then the mouse goes out of the feature, unselecting it from the 1st SFC : RIA : [select] The feature is still drawn with the select renderIntent. What do you think ? With this, you don't need to have 4 different possibilities. The user can define an infinite number of different renderIntents, have a styleMap defining each one of them. Alexandre Eric Lemoine wrote: Hi Alex Consider this sequence: mouse goes over feature, feature is clicked (for selection), and clicked again (for unselection). With your stack of intents logic, the feature isn't redrawn as a result of the second click; instead it should be redrawn with the hover control's render intent, shouldn't it? Eric 2009/1/23, Alexandre Dube ad...@mapgears.com: Hi devs, Eric was right : A first note. The current select feature implementation should accomodate this use case: two controls on the same layer, one working on click and the other on hover, only one of them actually changing the feature style. This is achievable by registering a beforefeatureselected listener, and have this listener return false. Adding beforefeatureunselected might help fully accomodate that use case. Now if we want the two controls to do feature styling, we need the stuff I mentioned previously - per-control selectedFeatures arrays and events. But this is unfortunately not sufficient. Use case: two controls, one working on click and the other on hover, both doing feature styling but with different render intents. If we have this sequence mouse goes over feature, mouse clicks feature, mouse goes out of feature, then the feature ends up being rendered with the default render intent, while it's still selected from the click control's perspective. In most cases, this isn't desirable I think. At this point I don't have a solution to the above issue. An idea that could resolve this issue : features could have a stack of renderIntent instead of a normal string value. Instead of assigning new renderIntent value, it would stack in renderIntents array. Instead of reseting to default, it would remove the last renderIntent in the stack. When the stack is empty, the default renderIntent is applied. That could work. I'll try this and come back with more details. Alexandre
Re: [OpenLayers-Dev] multipleSelectFeature on one layer
Hey, Eric Lemoine wrote: Hi If I understand you correctly, on unselect you always redraw the feature after removing the intent from the intents array, right? Yes Does your logic work with two controls, two of which having the same render intent. If the intents array is [a, b, a], I fear that an not the proper intent will be removed. Am I wrong? It does, because having the same renderIntent == having the same style applied. The only issue remaining is : does the layer need to keep its selectedFeatures array ? Alexandre Cheers, Eric 2009/1/26, Alexandre Dube ad...@mapgears.com: Hi Eric, You're right. So instead of removing the last renderIntent from the stack, we need to remove the last renderIntent of the current SelectFeature. SFC = SelectFeature Control RIA = renderIntents array Let's say the mouse goes hover a feature and get selected by a 1st SFC : RIA : [temporary] Then the user click it to select it with an other SFC : RIA : [temporary, select] Then the mouse goes out of the feature, unselecting it from the 1st SFC : RIA : [select] The feature is still drawn with the select renderIntent. What do you think ? With this, you don't need to have 4 different possibilities. The user can define an infinite number of different renderIntents, have a styleMap defining each one of them. Alexandre Eric Lemoine wrote: Hi Alex Consider this sequence: mouse goes over feature, feature is clicked (for selection), and clicked again (for unselection). With your stack of intents logic, the feature isn't redrawn as a result of the second click; instead it should be redrawn with the hover control's render intent, shouldn't it? Eric 2009/1/23, Alexandre Dube ad...@mapgears.com: Hi devs, Eric was right : A first note. The current select feature implementation should accomodate this use case: two controls on the same layer, one working on click and the other on hover, only one of them actually changing the feature style. This is achievable by registering a beforefeatureselected listener, and have this listener return false. Adding beforefeatureunselected might help fully accomodate that use case. Now if we want the two controls to do feature styling, we need the stuff I mentioned previously - per-control selectedFeatures arrays and events. But this is unfortunately not sufficient. Use case: two controls, one working on click and the other on hover, both doing feature styling but with different render intents. If we have this sequence mouse goes over feature, mouse clicks feature, mouse goes out of feature, then the feature ends up being rendered with the default render intent, while it's still selected from the click control's perspective. In most cases, this isn't desirable I think. At this point I don't have a solution to the above issue. An idea that could resolve this issue : features could have a stack of renderIntent instead of a normal string value. Instead of assigning new renderIntent value, it would stack in renderIntents array. Instead of reseting to default, it would remove the last renderIntent in the stack. When the stack is empty, the default renderIntent is applied. That could work. I'll try this and come back with more details. Alexandre Alexandre Dube wrote: Hi devs, I would like to propose some changes about the SelectFeature control. First, I'll introduce what I want to do : I want to change the color of a feature while the mouse is over it without selecting it. I managed to do this by building a customized control similar to the SelectFeature control named HighlightFeature. I shared the code and some people showed interest in this feature. In fact, it was a good enough to be added to trunk but there was a problem : it's too similar to the SelectFeature control. My first new option was to modify the SelectFeature control to be able to select and highlight. That's what I did, but I hit a wall : I needed to add more new events beforefeaturehighlighted, featurehighlighted, etc. a new array of highlightedFeatures, etc... That also became a pain because it was yet an other duplication of something already existant ( similair select feature events, an array of selected features, etc) SO, that brings me to this solution, the first one Eric Lemoine proposed : an array of selectedFeatures and select events for the control ( without removing the ones of the layer ). Doing that, one vector layer could have multiple select feature controls that would know which feature it has selected, they could all have a different renderIntent value ( this is already possible ) or their own style. Then, the user could interact directly with the desired control's selectedFeatures. My example : One SelectFeature that select on click, has the default render intent select, on which I register a featureselected
Re: [OpenLayers-Dev] multipleSelectFeature on one layer
Alexandre Dube wrote: Hi, Here's an other possibility : SFA : selectedFeature Array RI : renderIntent RIA : renderIntent Array Let's say we forget about the controls to have their own SFA. Only the layer has its own SFA. on featureselect if feature is not in SFA add feature to SFA trigger featureselected add RI of the control to the feature's RIA drawFeature(feature, RI) on featureunselect find RI of the control unselecting and remove it from RIA drawFeature(feature, LastRI) if LastRI == default, meaning no more controls have this feature selected remove feature from SFS trigger featureunselected Issues : - The wierd concept here is that the events select are only triggered once. solution ? : They could be triggered every time the feature gets drawn instead of added to the array. - If the user define a selectStyle in the SelectFeature control, then the renderIntent is not added to the stack. solution ? : When the user define a selectStyle, it could add the control's renderIntent to the feature stack without using it to draw the feature. The only problem is that on unselection, the feature could sometime be drawn with the wrong color, but at least the problem of is the feature still selected would be resolved. Using renderIntent would be preferable that way. What do you think ? forget about the below part ... ( too much copy/paste ) On featureselect, add the feature to the SFA, add the RI of the control selecting it to the feature's RIA and drawFeature. On featureselect by an other control, do not add the feature in the SFA since it's already there but add the RI to the The SelectFeature controls does 2 things : select features ( adding them to the layer.sf array ) and changing the color. forget about the above part... Amos Hayes wrote: I think the big questions for me are: Where are you planning to store the states? How will an app developer obtain a list of currently selected features and distinguish between the 'selections' that have been applied if more than one control has been set up? -- Amos Hayes Geomatics and Cartographic Research Centre Carleton University aha...@gcrc.carleton.ca +1.613.520.2600x8179 On 26-Jan-09, at 10:13 AM, Alexandre Dube wrote: Hi devs, My only problem remaining : should the layer keep its selectedFeature array ? If so, on selection, it's easy to know if a feature is already selected. As soon as one control adds it to its own array, it checks in the layer's one and add it if it's not there. But for unselection, before removing it from the layer's array, we would need to check all select features control and all controls containing select features control. Since we can easily say that one control does a specific task at a time, I don't really see the use of the selectedFeatures array in the layer. I would just remove it and avoid the above problem. What do you think ? Alexandre Alexandre Dube wrote: Hi Eric, You're right. So instead of removing the last renderIntent from the stack, we need to remove the last renderIntent of the current SelectFeature. SFC = SelectFeature Control RIA = renderIntents array Let's say the mouse goes hover a feature and get selected by a 1st SFC : RIA : [temporary] Then the user click it to select it with an other SFC : RIA : [temporary, select] Then the mouse goes out of the feature, unselecting it from the 1st SFC : RIA : [select] The feature is still drawn with the select renderIntent. What do you think ? With this, you don't need to have 4 different possibilities. The user can define an infinite number of different renderIntents, have a styleMap defining each one of them. Alexandre Eric Lemoine wrote: Hi Alex Consider this sequence: mouse goes over feature, feature is clicked (for selection), and clicked again (for unselection). With your stack of intents logic, the feature isn't redrawn as a result of the second click; instead it should be redrawn with the hover control's render intent, shouldn't it? Eric 2009/1/23, Alexandre Dube ad...@mapgears.com: Hi devs, Eric was right : A first note. The current select feature implementation should accomodate this use case: two controls on the same layer, one working on click and the other on hover, only one of them actually changing the feature style. This is achievable by registering a beforefeatureselected listener, and have this listener return false. Adding beforefeatureunselected might help fully accomodate that use case. Now if we want the two controls to do feature styling, we need the stuff I mentioned previously - per-control selectedFeatures arrays and events. But this is unfortunately not sufficient. Use case: two controls
Re: [OpenLayers-Dev] selectedfeature + mousemove
Hi, Could you explain a little more what you're trying to accomplish ? There might be other ways to do what you want. Regards, Alexandre toni hernández wrote: Hi, I've been a couple of days looking at the code and trying to add a mousemove function inside the SelectFeature control. I have tried with handlers but so far I haven't succeeded. Still trying. Anyone can give a hand? thanks. ___ 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
Re: [OpenLayers-Dev] DeleteFeature Control
Hi Devs, http://trac.openlayers.org/ticket/1882 The way I see this control now the more I think it should have been done an other way. Currently : - It uses feature+keyboard+box handlers for selection/unselection - It has its own array of selected features - It directly changes the renderIntent of the selected/unselected features (which is wrong) Should instead : - Have an integrated SelectFeature control, like the ModifyFeature control, but with more handlers (keyboard). I think this needs discussion : - A SelectFeature control, on deactivation, should always unselect all features. - This control has the following behaviors : keyboards combinations of shift + ctrl for selections and the select on click, more select on click+ctrl and no unselection on click on a selected feature. They are different than the SelectFeature control. IMHO, the DeleteFeature behaviors are more standard-like. Comments are welcomed. -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] SelectFeature control
Hi devs, I brought several weeks ago some possible modification ideas that the SelectFeature control could have, including : - having its own selectedFeatures array with the corresponding events that are currently in the layer - the feature renderIntent could be a stack of strings ( an array ) instead of a string only, selecting a feature would add select to the array, unselecting would remove it. That would enable the possibility to have multiple SelectFeature controls at the same time. For example, one onHover the other onClick, both having their own customized style. So far, I had no positive comments about theses ideas but I'd like to talk about it more to know exactly why they're not good ideas, please. Kind regards, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] SelectFeature control
Hi Eric,
This looks flawless but the easiest way to know would be to test it.
I would be glad to test this.
One thing to though is that a SelectFeature control can draw features
depending on its renderIntent value OR selectStyle value. So, instead
of storing the previous renderIntent, it could be the previous drawer (
i.e. control ) and call feature._previousdrawer.drawFeature(feature) and
the previous control itself would draw the feature depending if it has a
selectStyle or renderIntent.
Your solution looks simple and great. It has this concept :
this == current drawer
feature._previousdrawer ( or previousrenderintent ) == the previous drawer
With our 2 controls example that is enough. Plus, as long as we keep
the selectedFeature array in the layer objet, there's no need to know
more than current and previous. If we have let's say ( silly ) 6
select features at the same time, having all their own colors, a feature
is selected/highlighted and unselected/unhighlighted one at a time so
curent and previous drawer is enough. With that in mind, no need
for a stack of renderIntent or a stack of _previousDrawer.
What do you think ?
Alexandre
Eric Lemoine wrote:
On Thu, Mar 5, 2009 at 5:09 PM, Alexandre Dube ad...@mapgears.com wrote:
Sorry, I should have written :
Control #1, select on click, color: blue
Control #2, highlight on hover, color: yellow, highlightOnly
The problem is that control #2 :
highlight a feature even if it's selected
doesn't unhighlight a feature that is selected
so, a blue-selected-feature becomes yellow, and then moving out it remains
yellow. Do you see what I mean ?
You are so right!
How about that: unhighlight only if I'm the last drawer of the
feature, and unhighlight to the previous render intent. The
implementation would look like this:
(1) the select feature control places a reference to itself in the
feature it is about to highlight (whether highlightOnly is set or not)
feature._drawer = this;
this.layer.drawFeature(feature, selectStyle);
(2) before highlighting a feature store in the feature it current renderIntent
feature._previousRenderIntent = feature.renderIntent;
(3) unhighlight only if I'm the last drawer of the feature
if(feature._drawer == this) {
this.layer.drawFeature(feature, feature._previousRenderIntent);
}
It looks better to me, tell me if this is flawed again.
Thanks for the collaboration on this Alexandre.
--
Eric
--
Alexandre Dubé
Mapgears
www.mapgears.com
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] SelectFeature control
Thanks Eric, I'll have to try that in the following days. I'll let you know if I have comments. Regards, Alexandre Eric Lemoine wrote: On Fri, Mar 13, 2009 at 4:28 PM, Eric Lemoine eric@gmail.com wrote: I like it. See the attached eric-to-alexandre patch ;-) Alexandre, I attached a more complete patch to http://trac.openlayers.org/ticket/1596. Cheers, -- Eric -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] SelectFeature control
Hi Eric, This is sweet. It accomplish everything we need to have two or more SelectFeatures controls at the same time, on the same layer. And the new highlight events make it possible to have temporary things happening at the same time, like displaying a popup on hover. Great work Eric. You're going to make a lot of people happy with this fix. Alexandre Eric Lemoine wrote: Alexandre, I attached a more complete patch to http://trac.openlayers.org/ticket/1596. Cheers, -- Eric -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] DeleteFeature control
Hi, I just sent (finally) a new patch for ticket 1882 (1) (DeleteFeature control) and set the status to review. (1) http://trac.openlayers.org/ticket/1882 Regards, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] DeleteFeature control
Hey, I'd like to ask a couple of questions about this control. Currently, the only thing it really does is change the state of the selected features to DELETE and on 'del' keypress, it triggers a 'deletefeatures' event, but it doesn't actually delete (commit, destroy, remove, etc.) anything. The user needs to listen to the event and do what he wants himself. That bugs me a little. What good is a DeleteFeature control if it doesn't do anything by itself ? So I'm thinking of adding a couple of functions that would take care of theses actions, but at the same time I'm aware of the Strategy.Save strategy that already has the role of committing changes. It's not supporting HTTP/MapFish protocol at the moment though... Here's what I would do : - add a boolean 'commit' property - false : only destroy the features on screen - true : commit the changes (using the Save strategy or protocol.commit...) Since I'm using featureserver and Protocol.MapFish (which is not part of the OpenLayers project) I can't figure how I could avoid to delete 'manually' the features, i.e. not in the control itself. Any hint would be appreciated, Alexandre Alexandre Dube wrote: Hi, I just sent (finally) a new patch for ticket 1882 (1) (DeleteFeature control) and set the status to review. (1) http://trac.openlayers.org/ticket/1882 Regards, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] DeleteFeature control
Hi Eric,
Eric Lemoine wrote:
(I never used Protocol.MapFish and Strategy.Save together, I'm curious
to know why they don't play together)
I haven't tried either, but in the past I tried the HTTP protocol +
featureserver and the Save strategy wasn't able to read the insertedId
of the response received. I should simply try it and see what's the
status now...
So long that the control user can be notified when a feature is
deleted I don't see the value of having the control committing the
changes.
Ok
I don't understand. Can't you listen to featuredeleted from your
control and trigger saveStrategy.save()? (assuming Strategy.Save work
with Protocol.MapFish).
Yes. I just wondered if it was better to do it internally...
Some general comments on your control: from my understanding the
control has two activities, (1) when a feature is selected change its
state and redraw it, (2) when some delete key is pressed trigger
events. Since they are *independent* activities they could be done by
independent controls, and I think I'd disagree with wiring independent
activities within a single control.
If we had support for composite controls in the base Control class one
could do something like what follows to implement your delete
control's behavior:
var delCtrl = new OpenLayers.Control({
handler: new OpenLayers.Handler.Keyboard({
keydown: function(evt) {
var delKey = ...
if(delKey) {
saveStrategy.save();
}
}
}),
controls: [
new OpenLayers.Control.SelectFeature(
layer, {
onSelect: function(f) {
f.state = DELETE;
this.layer.drawFeature(f);
}
})
]
});
If I understand correctly, you would disagree to have this control added
as a new OpenLayers official control because of its 2 independent
actions, so you suggest instead I should define a customized control
like above but it requires to have controls within the control to be
automatically activated/deactivated on 'this' control
activation/deactivation. Is that it ?
(the support for composing controls I mentioned above involves having
the base Control class activates and deactivates every control that's
passed in the controls option.)
What do you think?
Cheers,
About the 'controls' property and the act./dea. automatism : that's a
good idea, but wouldn't it be good to have a 'handlers' property also
and activate/deactivate all handlers as well ? Currently, control has a
'handler' property only. Would it make sense to have 'handlers' added a
do the same kind of automatism as the new 'controls' property ?
Regards,
Alexandre
Any hint would be appreciated,
Alexandre
Alexandre Dube wrote:
Hi,
I just sent (finally) a new patch for ticket 1882 (1) (DeleteFeature
control) and set the status to review.
(1) http://trac.openlayers.org/ticket/1882
Regards,
--
Alexandre Dubé
Mapgears
www.mapgears.com
___
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
Re: [OpenLayers-Dev] [openlayers/mapserver]display shapefile content having TYPE as LINE
Hi,
First, that question is more suitable for the 'users' mailing list.
See below for more.
abir rezgui wrote:
Hi there!
I want to display the content of a shapefile using mapserver with
openlayers. I did it successfully in cases where the layer's type is
POLYGON but I still don't know where is the problem to do it when the
layer's type is LINE.
Here are informations about my shapefile displayed with ogr info:
INFO: Open of
`C:\ms4w\Apache\htdocs\my_shape_files\shape_ams\EXP_SEGMENT_FONCTIONNEL.shp'
using driver `ESRI Shapefile' successful.
Layer name: EXP_SEGMENT_FONCTIONNEL
Geometry: Line String
Feature Count: 6
Extent: (633527.743437, 2517184.387950) - (669562.958005, 2556945.272294)
Layer SRS WKT:
(unknown)
ID_SEGMENT: Real (24.5)
ID_RESEAU: Real (24.5)
TYPE_ETB_O: String (5.0)
ID_ETB_ORI: Real (24.5)
TYPE_ETB_E: String (5.0)
ID_ETB_EXT: Real (24.5)
CODE_OUVRA: String (30.0)
ID_RAMONAB: Real (24.5)
CLASSIFICA: String (80.0)
LONGUEUR_S: Real (24.5)
PME: Real (24.5)
EXPL_DEGS_: String (80.0)
COMMENTAIR: String (255.0)
PK_INIT: Real (24.5)
ID_ENTITE_: String (30.0)
STATUT_CON: String (1.0)
AUTEUR: String (80.0)
DATE_DERNI: Date (10.0)
Here is the content of my mapfile:
MAP
IMAGETYPE PNG
EXTENT 633527.743437 2517184.387950 669562.958005
2556945.272294
SIZE 400 300
SHAPEPATH /ms4w/Apache/htdocs/my_shape_files/shape_ams
IMAGECOLOR 255 255 255
LAYER
NAME EXP_SEGMENT_FONCTIONNEL
DATA EXP_SEGMENT_FONCTIONNEL
STATUS OFF
TYPE LINE
STATUS DEFAULT
CLASS
NAME AMS Example
STYLE
COLOR0 0 0
OUTLINECOLOR 32 32 32
END
END
END
END
finally here is the content of the html file with the javascript code:
html xmlns=http://www.w3.org/1999/xhtml;
head
titleMapServer Layer: AMS Example/title
script src=../../lib/OpenLayers.js/script
script type=text/javascript
var map, layer, mybounds;
function init(){
map = new OpenLayers.Map(map);
layer = new OpenLayers.Layer.MapServer( Exemple AMS,
http://localhost:8081/cgi-bin/mapserv.exe?map=/ms4w/Apache/htdocs/my_examples_MS/ams_exp.map;,
{layers: EXP_SEGMENT_FONCTIONNEL, format: 'image/png', isBaseLayer:
false, opacity: 1});
map.addLayer(layer);
mybounds = new
OpenLayers.Bounds(633527.743437,2517184.387950,669562.958005,2556945.272294);
map.zoomToExtent(mybounds);
map.addControl( new OpenLayers.Control.LayerSwitcher() );
}
/script
/head
body onload=init()
div id=titleMapServer Layer: AMS Example/div
div id=map/div
/body
/html
Your map object is missing an 'options' object (2nd argument) with the
required 'projection', 'units', 'maxResolution', etc. properties. Plus,
your data seems to be in meters. OpenLayers is in degrees by default.
Here's an example of what I mean :
=
var oMapOptions = {
controls: [], units: 'm', maxResolution: 156543.0339,
maxExtent: new OpenLayers.Bounds( -1192709.604, -204908.6926,
1172293.7082, 2338511.3665),
projection: new OpenLayers.Projection(EPSG:32198),
numZoomLevels: 11,
scales: [1300, 800, 400, 200, 100,
50, 25, 10, 5, 25000, 1]
};
oMap = new OpenLayers.Map( 'map', oMapOptions );
=
Also, the 3rd argument of your OpenLayers.Layer.MapServer object is an
object of 'params'. isBaseLayer is a 'options' parameter of the 4th
argument. See the code source of Layer/MapServer.js. This should look
more like :
layer = new OpenLayers.Layer.MapServer(
Exemple AMS, // layer name
http://localhost:8081/cgi-bin/mapserv.exe?map=/ms4w/Apache/htdocs/my_examples_MS/ams_exp.map;,
// url
{layers: EXP_SEGMENT_FONCTIONNEL, format: 'image/png'}, // params
(server-side options)
{isBaseLayer: false, opacity: 1} // options (openlayers options)
);
By the way, 'format' is a Layer.WMS parameter only. You should switch
to WMS since it's better than MapServer.
Regards,
I tried to display this shapefile without using openlayers and it
worked so I guess the problem is in the javascript code probabily when
calling the method /*OpenLayers.Layer.MapServer()*/ but when I tried
to debug the code I found no errors! Note that I did the same way to
display other shapefiles content having TYPE POLYGON with openlayers
using mapserver and that worked well so I don't know what else to do now!
Please HELP!
--
Abir Rezgui
---
Elève Ingénieur à l'Ecole Nationale des Sciences Informatiques ( ENSI )
Re: [OpenLayers-Dev] DeleteFeature control
Eric Lemoine wrote: so, to get to the delete control you've been working on, I see more value, in terms of flexibility, in adding control composition to the control base class. I also agree. Originally, the control had a Feature handler instead of a SelectFeature control. Looking at it now, it's too simple to be justified as a new control. About the 'controls' property and the act./dea. automatism : that's a good idea, but wouldn't it be good to have a 'handlers' property also and activate/deactivate all handlers as well ? Currently, control has a 'handler' property only. Would it make sense to have 'handlers' added a do the same kind of automatism as the new 'controls' property ? Agreed. Great. -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] DeleteFeature control
Hi,
I'm trying to reproduce what we discuss. I'm not really familiar with
this method and I'm having difficulties with 'this'. Here's what I have
so far :
/*** START ***/
var delCtrl = new OpenLayers.Control({
layer: olWFSRoads,
handlers: {keyboard: new OpenLayers.Handler.Keyboard(this,{ //
--- 'this' is not the control
keydown: function(evt) {
var code = evt.keyCode;
//var features = this.layer.selectedFeatures; // ---
this is not the control, and so on...
var features = olWFSRoads.selectedFeatures; // - can we
avoid the use of olWFSRoads ?
if(code == OpenLayers.Event.KEY_DELETE features.length 0
this.confirmDelete() ) {
this.deleteFeatures(features);
return;
}
}
})},
controls: [
new OpenLayers.Control.SelectFeature(
olWFSRoads, {
onSelect: function(f) {
f.state = OpenLayers.State.DELETE;
this.layer.drawFeature(f);
}
})
],
confirmDelete: function() {
return (confirm(Delete selected features ?))
},
deleteFeatures: function(features) {
this.layer.destroyFeatures(features);
}
});
/*** END ***/
I made the discussed changes to the OL.Control to be able to automatize
activation/deactivation/setMap.
If you look at the -- arrow, you'll see a 'this', which is
supposed to be the control, owner of the handler. Well, that 'this' is
not the control, it's the html page (figures). I tried to put 'delCtrl'
instead but it didn't work. I really wonder how I am supposed to create
controls that way (without creating a class) and use the 'this' (or
something else).
Any hint would be greatly appreciated,
Alexandre
P.S. Also, I believe it's ok to have my 'user' functions, like
confirmDelete directly inside the control since the control is
completely custom-made (i.e. not using events).
Alexandre Dube wrote:
Eric Lemoine wrote:
so, to get to the delete control you've been working on, I see more
value, in terms of flexibility, in adding control composition to the
control base class.
I also agree. Originally, the control had a Feature handler instead of
a SelectFeature control. Looking at it now, it's too simple to be
justified as a new control.
About the 'controls' property and the act./dea. automatism : that's a good
idea, but wouldn't it be good to have a 'handlers' property also and
activate/deactivate all handlers as well ? Currently, control has a
'handler' property only. Would it make sense to have 'handlers' added a
do the same kind of automatism as the new 'controls' property ?
Agreed.
Great.
--
Alexandre Dubé
Mapgears
www.mapgears.com
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] DeleteFeature control
Oh and by the way, here's what I did for the Control (attached). Is it
ok (too much, i.e. about the use of hasOwnProperty functions) ?
Thanks,
Alexandre
Alexandre Dube wrote:
Eric Lemoine wrote:
so, to get to the delete control you've been working on, I see more
value, in terms of flexibility, in adding control composition to the
control base class.
I also agree. Originally, the control had a Feature handler instead of
a SelectFeature control. Looking at it now, it's too simple to be
justified as a new control.
About the 'controls' property and the act./dea. automatism : that's a good
idea, but wouldn't it be good to have a 'handlers' property also and
activate/deactivate all handlers as well ? Currently, control has a 'handler'
property only. Would it make sense to have 'handlers' added a do the same kind
of automatism as the new 'controls' property ?
Agreed.
Great.
--
Alexandre Dubé
Mapgears
www.mapgears.com
Index: Control.js
===
--- Control.js (revision 9573)
+++ Control.js (working copy)
@@ -117,6 +117,20 @@
*/
handler: null,
+/**
+ * Property: handlers
+ * {Array of(OpenLayers.Handler)} null
+ */
+handlers: null,
+
+/**
+ * Property: controls
+ * Controls can contain other controls. When this control is activated, all
+ * its child controls, i.e. this.controls should be activated as well.
+ * {Array of(OpenLayers.Controls)} null
+ */
+controls: null,
+
/**
* APIProperty: eventListeners
* {Object} If set as an option at construction, the eventListeners
@@ -235,6 +249,22 @@
if (this.handler) {
this.handler.setMap(map);
}
+if(this.handlers) {
+for(var key in this.handlers) {
+if(this.handlers.hasOwnProperty(key)
+ typeof this.handlers[key].setMap == function) {
+this.handlers[key].setMap(map);
+}
+}
+}
+if(this.controls) {
+for(var key in this.controls) {
+if(this.controls.hasOwnProperty(key)
+ typeof this.controls[key].setMap == function) {
+this.controls[key].setMap(map);
+}
+}
+}
},
/**
@@ -303,6 +333,22 @@
if (this.handler) {
this.handler.activate();
}
+if(this.handlers) {
+for(var key in this.handlers) {
+if(this.handlers.hasOwnProperty(key)
+ typeof this.handlers[key].activate == function) {
+this.handlers[key].activate();
+}
+}
+}
+if(this.controls) {
+for(var key in this.controls) {
+if(this.controls.hasOwnProperty(key)
+ typeof this.controls[key].activate == function) {
+this.controls[key].activate();
+}
+}
+}
this.active = true;
if(this.map) {
OpenLayers.Element.addClass(
@@ -328,6 +374,22 @@
if (this.handler) {
this.handler.deactivate();
}
+if(this.handlers) {
+for(var key in this.handlers) {
+if(this.handlers.hasOwnProperty(key)
+ typeof this.handlers[key].deactivate == function) {
+this.handlers[key].deactivate();
+}
+}
+}
+if(this.controls) {
+for(var key in this.controls) {
+if(this.controls.hasOwnProperty(key)
+ typeof this.controls[key].deactivate == function) {
+this.controls[key].deactivate();
+}
+}
+}
this.active = false;
if(this.map) {
OpenLayers.Element.removeClass(
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] DeleteFeature control
Hi,
I'm going to work on my example today. See below.
Eric Lemoine wrote:
why not using the regular
var i, len, control;
for(i = 0, len = controls.length; i len; i++) {
control = controls[i];
}
?
Right. I just wondered if it could have been possible to have a {}
instead of a [] for controls, like {selectControl: new OL.C.SF(),
myCustomControl: new OL.C.Custom() } (like the handlers) instead of
[new OL.C.SF, OL.C.Custom]...
I'll just go with [] then. Thanks,
--
Alexandre Dubé
Mapgears
www.mapgears.com
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Trigger save event
Hi, jessisena wrote: Finally I 've solved the problem triggering an event (from save.js) of the layer which was the listener... Anyway, exists some way to do what I was asking for? Which is the way to receive in a specific layer the success or fail event declared in Save.js ? I'd like to help, but I'm not sure I understand what you mean. Do you have more than one vector layer you commit changes with a single SaveStrategy ? You said you were able to trigger the events you were looking for : what more do you need to do ? Kind regards, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] DeleteFeature control
Eric Lemoine wrote:
Alexandre
I now understand one of your problems, you need to give the handler a
reference to the control, but the control does not exist yet since
you're actually creating it. Giving the handler a fake control, of the
form {map: map} (where map is the map instance) should do the trick.
I think handlers do not actually require a reference to the control,
they just need a reference to the map (to register listeners). So I
don't understand why we have this constraint. Anyone involved in the
design of handlers knows?
Mmm... I understand, but since I need to use callbacks on handler
events, I think it's simpler to create my control the way I already did
it. I won't go any further in this example.
I still agree with automatic controls and handlers
activation/deactivation. Attached an new patch with the simple changes
needed. Is it ok ? If it is, I'll open a ticket.
Again, many thanks for your help,
--
Alexandre Dubé
Mapgears
www.mapgears.com
Index: Control.js
===
--- Control.js (revision 9573)
+++ Control.js (working copy)
@@ -117,6 +117,20 @@
*/
handler: null,
+/**
+ * Property: handlers
+ * {Array of(OpenLayers.Handler)} null
+ */
+handlers: null,
+
+/**
+ * Property: controls
+ * Controls can contain other controls. When this control is activated, all
+ * its child controls, i.e. this.controls should be activated as well.
+ * {Array of(OpenLayers.Controls)} null
+ */
+controls: null,
+
/**
* APIProperty: eventListeners
* {Object} If set as an option at construction, the eventListeners
@@ -235,6 +249,16 @@
if (this.handler) {
this.handler.setMap(map);
}
+if(this.handlers) {
+for(var key in this.handlers) {
+this.handlers[key].setMap(map);
+}
+}
+if(this.controls) {
+for(var i=0, len=this.controls.length; ilen; i++) {
+this.controls[i].setMap(map);
+}
+}
},
/**
@@ -303,6 +327,16 @@
if (this.handler) {
this.handler.activate();
}
+if(this.handlers) {
+for(var key in this.handlers) {
+this.handlers[key].activate();
+}
+}
+if(this.controls) {
+for(var i=0, len=this.controls.length; ilen; i++) {
+this.controls[i].activate();
+}
+}
this.active = true;
if(this.map) {
OpenLayers.Element.addClass(
@@ -328,6 +362,16 @@
if (this.handler) {
this.handler.deactivate();
}
+if(this.handlers) {
+for(var key in this.handlers) {
+this.handlers[key].deactivate();
+}
+}
+if(this.controls) {
+for(var i=0, len=this.controls.length; ilen; i++) {
+this.controls[i].deactivate();
+}
+}
this.active = false;
if(this.map) {
OpenLayers.Element.removeClass(
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] handler style
Hi, jessisena wrote: Hi, Anybody knows if is possible to have two differents controls Draw feature, with the same kind of handler (for example point), and everyone with their own style? That is, if I can have two controls that draw points with different styles, in the same layer. Thanks You could overwrite the activate and deactivate function of both your DrawFeatures control to add a featureadded listener to your layer. On activate, register the event. On deactivate, unregister the event. Both events could call a different function to add an attribute to the added feature, let's say type, the first control adds 1 as a value, the second 2, then you would need to redraw the feature. With all this, you could have a addUniqueValueRules to your layer's styleMap object to render your features differently, based on your type attribute. Does this make sense ? -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] DeleteFeature control
Hi, Eric Lemoine wrote: I still agree with automatic controls and handlers activation/deactivation. Attached an new patch with the simple changes needed. Is it ok ? If it is, I'll open a ticket. Ok to me. Thanks Alexandre, http://trac.openlayers.org/ticket/2196 currently unassigned Regards, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] WMSGetFeatureInfo ctrl format parameter missing
Hi, One of my coworker had some trouble using the WMSGetFeatureInfo control. The response always said Missing FORMAT property. Here's what he found on this : Section 7.3.1 of the WMS 1.1.1 specification says: Because the WMS protocol is stateless, the GetFeatureInfo request indicates to the WMS what map the user is viewing by including most of the original GetMap request parameters (all but VERSION and REQUEST). So, even if the FORMAT parameter is meaningless in the context of a GetFeatureInfo request, according to the spec it is a required parameter (as per section 7.2.2) and should be included by OpenLayers in its GetFeatureInfo requests. What do you think ? -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] Unhighlight feature + KEY_ESC : IE bug
Hi, I have a very odd behavior with the SelectFeature control in IE + keyboard handler using the KEY_ESC to unselect all features.I use a customized DeleteFeature control, who is responsible to set the feature state to delete and redrawing it. It has it's own SelectFeature control for feature selection. When unselecting by 'clicking out', it works fine. But when hitting esc, it DOES unselect all features + the unhighlight function is called, but features stay the selected color. I checked the select-feature example (1) and it doesn't have this behavior, so it looks like a combination of ESC key problem + SelectFeature Control... See a live example of the problem (using trunk) (2). I'm out of solution for this one. Any comments ? (1) http://openlayers.org/dev/examples/select-feature.html (2) http://dev4g.mapgears.com/openlayers/ie-highlight-bug/examples/ie-highlight-bug.html N.B. Problem viewed in IE7, don't know about other IE versions. -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Unhighlight feature + KEY_ESC : IE bug
Hi, I tried an other key (instead of 'esc') and the problem went away. So it really looks like a 'esc' key problem in IE. Can anyone comments about this, please ? Alexandre Alexandre Dube wrote: Hi, I have a very odd behavior with the SelectFeature control in IE + keyboard handler using the KEY_ESC to unselect all features.I use a customized DeleteFeature control, who is responsible to set the feature state to delete and redrawing it. It has it's own SelectFeature control for feature selection. When unselecting by 'clicking out', it works fine. But when hitting esc, it DOES unselect all features + the unhighlight function is called, but features stay the selected color. I checked the select-feature example (1) and it doesn't have this behavior, so it looks like a combination of ESC key problem + SelectFeature Control... See a live example of the problem (using trunk) (2). I'm out of solution for this one. Any comments ? (1) http://openlayers.org/dev/examples/select-feature.html (2) http://dev4g.mapgears.com/openlayers/ie-highlight-bug/examples/ie-highlight-bug.html N.B. Problem viewed in IE7, don't know about other IE versions. -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Unhighlight feature + KEY_ESC : IE bug
Hi, I made an example out of the select-feature.html example. I only added a keyboard handler to the SelectFeature control and it still do the problem. See the example (1). I opened a ticket for this (2). Currently unassigned and without a patch. Alexandre (1) http://dev4g.mapgears.com/openlayers/ie-highlight-bug/examples/select-feature-esc.html (2) http://trac.openlayers.org/ticket/2214 Alexandre Dube wrote: Hi, I tried an other key (instead of 'esc') and the problem went away. So it really looks like a 'esc' key problem in IE. Can anyone comments about this, please ? Alexandre Alexandre Dube wrote: Hi, I have a very odd behavior with the SelectFeature control in IE + keyboard handler using the KEY_ESC to unselect all features.I use a customized DeleteFeature control, who is responsible to set the feature state to delete and redrawing it. It has it's own SelectFeature control for feature selection. When unselecting by 'clicking out', it works fine. But when hitting esc, it DOES unselect all features + the unhighlight function is called, but features stay the selected color. I checked the select-feature example (1) and it doesn't have this behavior, so it looks like a combination of ESC key problem + SelectFeature Control... See a live example of the problem (using trunk) (2). I'm out of solution for this one. Any comments ? (1) http://openlayers.org/dev/examples/select-feature.html (2) http://dev4g.mapgears.com/openlayers/ie-highlight-bug/examples/ie-highlight-bug.html N.B. Problem viewed in IE7, don't know about other IE versions. -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Unhighlight feature + KEY_ESC : IE bug
Hi, I just noticed that the bug only exists with line polygons. Points have the good behavior. Try to draw points + lines + polygons, then select them all with a box and press 'esc' to unselect them all : they get ALL unselected but only the points get their actual default style back. An other weird behavior : if you use shift+esc, all features get drawn back to default normally... Comments would be welcomed, please. Alexandre Alexandre Dube wrote: Hi, I made an example out of the select-feature.html example. I only added a keyboard handler to the SelectFeature control and it still do the problem. See the example (1). I opened a ticket for this (2). Currently unassigned and without a patch. Alexandre (1) http://dev4g.mapgears.com/openlayers/ie-highlight-bug/examples/select-feature-esc.html (2) http://trac.openlayers.org/ticket/2214 Alexandre Dube wrote: Hi, I tried an other key (instead of 'esc') and the problem went away. So it really looks like a 'esc' key problem in IE. Can anyone comments about this, please ? Alexandre Alexandre Dube wrote: Hi, I have a very odd behavior with the SelectFeature control in IE + keyboard handler using the KEY_ESC to unselect all features.I use a customized DeleteFeature control, who is responsible to set the feature state to delete and redrawing it. It has it's own SelectFeature control for feature selection. When unselecting by 'clicking out', it works fine. But when hitting esc, it DOES unselect all features + the unhighlight function is called, but features stay the selected color. I checked the select-feature example (1) and it doesn't have this behavior, so it looks like a combination of ESC key problem + SelectFeature Control... See a live example of the problem (using trunk) (2). I'm out of solution for this one. Any comments ? (1) http://openlayers.org/dev/examples/select-feature.html (2) http://dev4g.mapgears.com/openlayers/ie-highlight-bug/examples/ie-highlight-bug.html N.B. Problem viewed in IE7, don't know about other IE versions. -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] A kind of MultiLayer container
Hi Ivan, Here's my thoughts on that topic : Like you said, I also did something similar. I had 4 different data sources that were normalized and had to use 4 Vector layers with moveend events to automatically switch from one to an other. What I though to be 'a bad idea' was to have 4 layers (all of the same kind, i.e. Vector) for a slight difference. That's why the OptionByZoom Strategy I then made (1) was better. What you're seeking to do is different. Switching from a WMS layer to a Vector layer can't be done by 'switching properties' of one layer. IMHO, you currently can't avoid having multiple layers for that, so your idea of a 'container' could be good. That doesn't need to be much complicated. You could have a dummy layer with inLayerSwitcher: true that could be your container for other layers. It could have properties/features like: layers (the layers to have together) currentLayer (set on each moveend events of layers) setCurrentLayer() (set the current inRange layer from layers, only one should be inRange at a time) addLayer() (automatic map.addLayer, moveend event registration to setCurrentLayer, etc.) and added layers should have min/max Scale/Resolution properties to have unique ranges. What do you think ? Alexandre (1) http://dev4.mapgears.com/bdga/options-by-zoom-bdga.html Ivan Grcic wrote: Hi devs, I want to ask if anyone has made something like Vector/RootContainer, a layer that would contain several layers, and every layer would activate/deactivate on different zoomLevels. Simple case: 3 (or more) layers combined in one ContainerLayer small scale: WMS raster layer larger scales: other WMS raster layer large scale: WFS vector layer Usually I always register zoomend event on map, and manually activate or deactivate layers...but it got little bit boring to do that on application level every time. I remember Alexandre did something like that but for Vector layer or http://openlayers.org/pipermail/users/2009-January/009666.html Anyone did something like that? (does mapfish maybe has soemthing like that) If not, can anyone just give few tips, so I could start developing it... TnxCheers, -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Unhighlight feature + KEY_ESC : IE bug
Alexandre Dube wrote: Hi, I made an example out of the select-feature.html example. I only added a keyboard handler to the SelectFeature control and it still do the problem. See the example (1). I opened a ticket for this (2). Currently unassigned and without a patch. Alexandre (1) http://dev4g.mapgears.com/openlayers/ie-highlight-bug/examples/select-feature-esc.html (2) http://trac.openlayers.org/ticket/2214 Any comments about this issue ? -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Select Feature - programatically select - doesn't check if feature is already selected
Hi Ivan,
Do you have an example showing when this can happen ? I've been playing
with the SelectFeature control and can't figure how you can have the
same feature added 2 times to the layer.selectedFeatures array, unless
you do it manually.
Regards,
Alexandre
Ivan Grcic wrote:
If we do several times:
selectContorl.select(feature)
feature is added to layer.selectedFeature array several times.
Should we first check if the feature is allready selected (ill open a ticket)
if (OpenLayers.Util.indexOf(layer.selectedFeatures, feature) == -1) {
this.select(feature);
}
Or we leave selectControl as it is, and leave this to user to solve it
on application level?
Regards
--
Alexandre Dubé
Mapgears
www.mapgears.com
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Query featureserver?
Hi, Kushy wrote: What if I need to put on this layer just some of them? Can I filter them in some way? I tried writing featureserver.cgi/punti?id=100, thinking it would have displayed the POI with id=100, but it doesn't work. For single selection, try : featureserver.cgi/punti/100.gml But you might want to check : [1] a smart way to only fetch features from current map (viewport) extent [2] a way to add filters in OpenLayers [1] http://openlayers.org/dev/examples/strategy-bbox.html [2] http://openlayers.org/dev/examples/filter.html Regards, Alexandre -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] ModifyFeature control - multiple selection support
Andreas, Nice. So instead of using a FeatureHandler, the future SelectControl would listen to these events instead, right ? Alexandre Andreas Hocevar wrote: Hi, I think the future way to go is something based on Tim's experiments with the FeatureAgent. See the example: http://dev.openlayers.org/sandbox/tschaub/select/examples/feature-events.html Multilayer support for ModifyFeature would e.g. still not make it possible to grab features that are entirely covered by another feature. With the FeatureAgent, you would also be able to edit such a feature. Regards, Andreas. On 2009-12-11 15:10, Alexandre Dube wrote: Hi devs, === short version === * Is there any plan to support multiple feature selection in the ModifyFeature control ? * If not, would that make sense to support it ? (Clicking features beyond the first one would enable the editing for those as well while keeping the first one selected too) === long version : the need === There's a Redling tool discussion going on on the GeoExt-dev ML [1]. Among the needs, there's the multiple feature edition. Basically, it would be possible for a user to select as many feature as they want and edit their style and/or attributes in a form, but having the possibility to edit the geometry too would be nice. After making some tests with the current trunk version of the ModifyFeature control, it's possible to select many features (with the standalone option turned on), but if a feature is already selected, selecting an other feature removes the 1st feature vertexes and reselecting it won't make them reappear. === small conclusion === I'm doubt the multi-feature edition could be that useful, but who knows... I'd like to know your thoughts on the subject, please. Many thanks, [1] http://trac.geoext.org/wiki/ux/Redlining -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] ModifyFeature control - multiple selection support
Right. The only thing left useful with the SelectFeature control is to store the selected features in the layer's selectedFeature's array. So, users would have to do that manually and as they please from there on... Sounds logical. Thanks Andreas for the pointers, Alexandre Andreas Hocevar wrote: Yes, and it would be much easier to interact with features even without the SelectFeature control. Regards, Andreas. -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
[OpenLayers-Dev] Feature.style doesn't support contexts
Hi,
I want to be able to save a OpenLayers.Style object or hash to a
vector feature. Currently, in code, feature.style exists but you must
define a hash or else it doesn't work.
My problem is that I want to be able to draw features to be used as
labels (floating text on the map). To be able to do so, I need to
define a StyleMap with a context to display the label (I manually set
feature.isLabel on featureadded) [1]
That works well, but as soon as I want to bind / save the style to
the feature, I mean set feature.style, I need to set a hash and the
feature will be rendered without the contexts.
I don't fully understand how the contexts, symbolizers, etc. work, but
my first guess would be to support OpenLayers.Style object directly in
the feature object. Does that make sense ?
Or maybe I'm doing it wrong and their's an other way of labeling
features. My goal is to create features on a cosmetic layer with a
default style, then to be able to change the style of the features and
bind it to them (I mean without using rules on the layer level, but by
defining directly the feature style)
Many many thanks,
Alexandre
// [1] START
var labelStyle = {
label: ${name},
labelSelect: true,
pointRadius: ${radius}
};
var styleOptions = {
context: {
'name': function(feature) {
var szValue;
if (feature.attributes['name'] feature.isLabel
=== true) {
szValue = feature.attributes['name'];
} else {
szValue = ;
}
return szValue;
},
'radius': function(feature) {
return (feature.isLabel === true) ? 0 : 6;
}
}
};
var style = new OpenLayers.Style(
OpenLayers.Util.applyDefaults(
labelStyle,OpenLayers.Feature.Vector.style[default]),
styleOptions
);
var styleMap = new OpenLayers.StyleMap({
default: style
});
layer = new OpenLayers.Layer.Vector(
Cosmetic, {'styleMap': styleMap});
// [1] END
--
Alexandre Dubé
Mapgears
www.mapgears.com
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Feature.style doesn't support contexts
Andreas, Eric, Cédric,
Thanks to all of you for your support. Your answers are very clear
and well detailed. I'll make the changes according to what you proposed
and come back if I have any more questions.
Thanks again,
Alexandre
Andreas Hocevar wrote:
Hi,
Alexandre Dube wrote:
I want to be able to save a OpenLayers.Style object or hash to a
vector feature. Currently, in code, feature.style exists but you
must define a hash or else it doesn't work.
That's correct and expected. Let's call your hash symbolizer.
My problem is that I want to be able to draw features to be used as
labels (floating text on the map). To be able to do so, I need to
define a StyleMap with a context to display the label (I manually set
feature.isLabel on featureadded) [1]
You can evaluate the symbolizer from the context before setting
feature.style:
feature.style = myStyleMap.styles[default].createSymbolizer(feature);
That works well, but as soon as I want to bind / save the style
to the feature, I mean set feature.style, I need to set a hash and
the feature will be rendered without the contexts.
The above snippet creates a symbolizer from the default style of the
style map, and evaluates everything from the context.
I don't fully understand how the contexts, symbolizers, etc. work,
but my first guess would be to support OpenLayers.Style object
directly in the feature object. Does that make sense ?
No. Context-based styling and symbolizers-per-feature are two
different things.
Or maybe I'm doing it wrong and their's an other way of labeling
features. My goal is to create features on a cosmetic layer with a
default style, then to be able to change the style of the features
and bind it to them (I mean without using rules on the layer level,
but by defining directly the feature style)
That makes sense, and the snippet above is the solution. You start
with a layer with a StyleMap, and to override the evaluated style for
a specific feature, you set feature.style with the symbolizer you get
from Style::createSymbolizer.
Note that if you want to change the label for such a feature later,
you need to set symbolizer.label, not feature.attributes.name.
Also note that if you want a point feature with just a label and
without the geometry rendered, it is better to set the graphic: false
symbolizer property instead of pointRadius: 0.
Regards,
Andreas.
Many many thanks,
Alexandre
// [1] START
var labelStyle = {
label: ${name},
labelSelect: true,
pointRadius: ${radius}
};
var styleOptions = {
context: {
'name': function(feature) {
var szValue;
if (feature.attributes['name']
feature.isLabel === true) {
szValue = feature.attributes['name'];
} else {
szValue = ;
}
return szValue;
},
'radius': function(feature) {
return (feature.isLabel === true) ? 0 : 6;
}
}
};
var style = new OpenLayers.Style(
OpenLayers.Util.applyDefaults(
labelStyle,OpenLayers.Feature.Vector.style[default]),
styleOptions
);
var styleMap = new OpenLayers.StyleMap({
default: style
});
layer = new OpenLayers.Layer.Vector(
Cosmetic, {'styleMap': styleMap});
// [1] END
--
Alexandre Dubé
Mapgears
www.mapgears.com
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] problem with vector Layer Feature's geometry, that is null !
Rohala,
I replied to your message from Nabble because I didn't see it in my
OpenLayers-Dev Mailing-List mailbox. I guess it's because of the big
image attached to it. I'll copy it here for convenience. See below.
BTW, your problem is more suitable for the users mailing list.
Regards,
Alexandre
Alexandre Dubé wrote:
Rohala,
If you look at the Console tag, you can see the request sent. From there,
look a the response received. Does the response have geometry ? If it
does, put a breakpoint on your format read method to see what happens and
why the geometry isn't parsed.
Regards,
Alexandre
Original message :
HHi guys
I use OpenLayers.Protocol.WFS approach for display a vector layer. this
layer include points.
This is my code :
var saveStrategy = new OpenLayers.Strategy.Save();
EducationLayer = new OpenLayers.Layer.Vector(EducationLayer Ho ha ha, {
strategies: [new OpenLayers.Strategy.BBOX(), saveStrategy],
projection: new OpenLayers.Projection(EPSG:4326),
styleMap: EduStyles,
protocol: new OpenLayers.Protocol.WFS({
version: 1.1.0,
srsName: EPSG:4326,
url: ../../cgi-bin/mapserv.exe?map=../../apps/mashar/mashar.map,
featureNS : http://localhost:3000/mashar/wfs;,
featureType: Education,
featurePrefix: MF,
schema:
http://localhost:3000/cgi-bin/mapserv.exe?map=../../apps/mashar/mashar.mapSERVICE=WFSversion=1.1.0REQUEST=DescribeFeatureTypeTYPENAME=MF:Education
http://localhost:3000/cgi-bin/mapserv.exe?map=../../apps/mashar/mashar.mapSERVICE=WFSversion=1.1.0REQUEST=DescribeFeatureTypeTYPENAME=MF:Education
})
});
with this code i can see EducationLayer features retrieved to browser
and loaded (I use Firefox with Firebug extension). but nothing displayed
on map.
When i want to see geometry property of EducationLayer such as
EducationLayer.Features[each number of array].geometry it retrieve null.
where is my wrong?
below picture explain more detail: [1]
I use Mapserver as WFS server with this configs in web section:
WEB
IMAGEPATH ./tmp/
IMAGEURL ./tmp/
METADATA
wfs_title Mashar WFS Server
wfs_onlineresource
http://localhost:3000/cgi-bin/mapserv.exe?map=../../apps/mashar/mashar.map;
http://localhost:3000/cgi-bin/mapserv.exe?map=../../apps/mashar/mashar.map;
wfs_srs EPSG:4326
wfs_abstract Some text
wfs_encoding UTF-8
wfs_namespace_uri http://localhost:3000/mashar/wfs;
wfs_namespace_prefix MF
END
END
And there is Layer definition section in map file:
LAYER
NAME Education
TYPE POINT
DATA Education
METADATA
wfs_title Education
WFS_ABSTRACT Education WFS Layer
gml_include_items all
END
STATUS DEFAULT
TRANSPARENCY 100
DUMP TRUE
CLASS
NAME 'Education'
STYLE
SYMBOL 'CIRCLE'
SIZE 2
OUTLINECOLOR 0 0 0
COLOR 45 220 182
END
END
END
This problem confused me very much. solving this problem is very
important for me.
Thanks in advance!
[1] http://n2.nabble.com/file/n4472008/error.gif
--
Alexandre Dubé
Mapgears
www.mapgears.com
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Markers and Vector Layer conflict
Alex,
Take a look at this example [1]. Vector features can be used with a
SelectFeature control to open popups. You only need to define the
externalGraphic to have images and define the geometry type to point.
See an other example of draw types.
You might be interested to take a look at this example [3] too (it's a
development sandbox for a RedLining widget in GeoExt). It uses a lot of
OpenLayers components to draw/select the features. Maybe that can helps
too.
Kind regards,
Alexandre
[1] http://openlayers.org/dev/examples/select-feature-openpopup.html
[2] http://openlayers.org/dev/examples/draw-feature.html
[3]
http://dev.geoext.org/sandbox/redlining/ux/FeatureEditing/examples/ControlerOnlyExample.html
Alex G. wrote:
Alexandre,
thanks for your thoughts. Although if I understand what you're saying
and the example correctly, this will not make the markers to pop up
with bubbles where I can put text.
I am currently placing markers with text on them where if you click on
the marker a little bubble will appear.
Here's another snippet that I forgot to include:
var click = new OpenLayers.Control.Click();
map.addControl(click);
click.activate();
var new2 = new OpenLayers.Layer.Text( 'Texts', { layerToUse:
markers, newLat: '4188741.7304207', newLon: '217101.58694106',
newTitle: Title1, newDesc: Desc1, idUser : '62', userName:
'admin', newIcon: 'images/markers/marker.png'} );
new2.parseData();
var new3 = new OpenLayers.Layer.Text( 'Texts', { layerToUse:
markers, newLat: '4182021.7304207', newLon: '210801.58694106',
newTitle: Title2, newDesc: Desc2, idUser : '62', userName:
'admin', newIcon: 'images/markers/marker-blue.png'} );
new3.parseData();
var new4 = new OpenLayers.Layer.Text( 'Texts', { layerToUse:
markers, newLat: '4179441.7304207', newLon: '219681.58694106',
newTitle: Title3, newDesc: Desc3, idUser : '62', userName:
'admin', newIcon: 'images/markers/marker.png'} );
new4.parseData();
I am not quite sure what that click function does, could it be the
culprit?
I have used this example as a base:
http://dev.openlayers.org/releases/OpenLayers-2.8/examples/markers.html
The thing is I use a form also to create new bubbles where users can
enter a title, marker icon and description and get a result similar to
the above.
Thanks again,
Alex
On Thu, Feb 4, 2010 at 3:34 PM, Alexandre Dube ad...@mapgears.com
mailto:ad...@mapgears.com wrote:
Alex,
I just looked at the SelectFeature control code and I think you
could try this solution :
Change you Marker layer for a Vector one (you can define
externalGraphic to a vector feature, see an example [1]) and then
configure your SelectFeature control with both your layers :
var select = new OpenLayers.Control.SelectFeature([vectors,
markers], options);
The SelectFeature control will create a RootContainer layer
object enabling selection on both at the same time, thus fixing
your issue. Please, tell me if that worked.
Hope this helps,
Alexandre
[1] http://openlayers.org/dev/examples/styles-unique.html
Alex G. wrote:
Hi all,
I am probably having a conflict problem with some of my
layers. I currently have 3 layers active on my installation:
- a layer containing the data from a shapefile (running WMS)
- a vector layer where users can draw
- a layer dedicated to markers.
I have noticed that if I place a marker, I cannot interact
with it afterwards unless I hide the vectors layer. The order
is correct, I load first the shp layer, then the vector one
and then the markers one.
I include here some of my code in hope that it will help, it's
mostly from examples on openlayers so there's really nothing new.
map = new OpenLayers.Map('map',{maxExtent: new
OpenLayers.Bounds(195441.084706006,4171163.51662705,240142.089176109,4203199.94421431),
maxResolution: 120, units: 'dd'});
layer = new OpenLayers.Layer.WMS( 'Landmass ',
'http://localhost:8585/cgi-bin/mapserv?map=/opt/fgs/apps/gmap-demo-cvs_MS_VERSION_54/htdocs/gmap75a.map;
http://localhost:8585/cgi-bin/mapserv?map=/opt/fgs/apps/gmap-demo-cvs_MS_VERSION_54/htdocs/gmap75a.map;
http://localhost:8585/cgi-bin/mapserv?map=/opt/fgs/apps/gmap-demo-cvs_MS_VERSION_54/htdocs/gmap75a.map;
http://localhost:8585/cgi-bin/mapserv?map=/opt/fgs/apps/gmap-demo-cvs_MS_VERSION_54/htdocs/gmap75a.map;',
{
layers: 'zak',
format:'PNG',
bbox:
'195441.084706006,4171163.51662705,240142.089176109,4203199.94421431',
srs: 'EPSG:4326'
});
lakegr_wms
Re: [OpenLayers-Dev] Markers and Vector Layer conflict
Alex,
Instead of defining the externalGraphic property directly in your
StyleMap (that affects all your features on your layer), you could
register a featureadded event to your DrawFeature control for points
and set the externalGraphic property there. You would need to redraw
your feature to affect the new style. This might look like (untested) :
var oDrawPoint = new OpenLayers.Control.DrawFeature(vectors,
OpenLayers.Handler.Point);
oDrawPoint.events.on({featureadded: onPointFeatureAdded, scope:
oDrawPoint});
var onPointFeatureAdded = function(event) {
var feature = event.feature;
var symbolizer = this.layer.styleMap.createSymbolizer(feature);
feature.style = symbolizer;
feature.style.externalGraphic = images/markers/marker-gold.png;
feature.style.pointRadius = 10;
this.layer.drawFeature(feature);
};
The remaining thing to do is to think about how to have different
markers for your features.
Hope this helps,
Alexandre
Alex G. wrote:
Alexandre,
thanks again for your valuable help!
At the moment the best idea would be to have vector points as markers,
which would make them both clickable and perfect for what I need to do.
I have added this info to the vector layer:
vectors = new OpenLayers.Layer.Vector('Vectors', {
styleMap: new OpenLayers.StyleMap({
externalGraphic: images/markers/marker-gold.png,
pointRadius: 10
})
});
And the point appears correctly with the marker icon. But I have run
into 2 problems now:
1) All my polygons and lines appear black or invisible
2) I would like to use more than one image for the markers
My controls looks like this:
controls = {
point: new OpenLayers.Control.DrawFeature(vectors,
OpenLayers.Handler.Point),
line: new OpenLayers.Control.DrawFeature(vectors,
OpenLayers.Handler.Path),
polygon: new OpenLayers.Control.DrawFeature(vectors,
OpenLayers.Handler.Polygon),
drag: new OpenLayers.Control.DragFeature(vectors),
select: selectControl
};
Is there a way to maybe pass the external image specifically to the
point control?
I am unsure about the syntax and I wasn't able to find any info
around, maybe something like this:
point: new OpenLayers.Control.DrawFeature(vectors,
OpenLayers.Handler.Point, {style: blah blah}),
If it's possible, then that solves my 2nd problem as well for
different images.
Thanks in advance!
Best regards,
Alex
On Thu, Feb 4, 2010 at 8:26 PM, Alexandre Dube ad...@mapgears.com
mailto:ad...@mapgears.com wrote:
Alex,
Take a look at this example [1]. Vector features can be used
with a SelectFeature control to open popups. You only need to
define the externalGraphic to have images and define the geometry
type to point. See an other example of draw types.
You might be interested to take a look at this example [3] too
(it's a development sandbox for a RedLining widget in GeoExt). It
uses a lot of OpenLayers components to draw/select the features.
Maybe that can helps too.
Kind regards,
Alexandre
[1] http://openlayers.org/dev/examples/select-feature-openpopup.html
[2] http://openlayers.org/dev/examples/draw-feature.html
[3]
http://dev.geoext.org/sandbox/redlining/ux/FeatureEditing/examples/ControlerOnlyExample.html
Alex G. wrote:
Alexandre,
thanks for your thoughts. Although if I understand what you're
saying and the example correctly, this will not make the
markers to pop up with bubbles where I can put text.
I am currently placing markers with text on them where if you
click on the marker a little bubble will appear.
Here's another snippet that I forgot to include:
var click = new OpenLayers.Control.Click();
map.addControl(click);
click.activate();
var new2 = new OpenLayers.Layer.Text( 'Texts', {
layerToUse: markers, newLat: '4188741.7304207', newLon:
'217101.58694106', newTitle: Title1, newDesc: Desc1,
idUser : '62', userName: 'admin', newIcon:
'images/markers/marker.png'} );
new2.parseData();
var new3 = new OpenLayers.Layer.Text( 'Texts', {
layerToUse: markers, newLat: '4182021.7304207', newLon:
'210801.58694106', newTitle: Title2, newDesc: Desc2,
idUser : '62', userName: 'admin', newIcon:
'images/markers/marker-blue.png'} );
new3.parseData();
var new4 = new OpenLayers.Layer.Text( 'Texts', {
layerToUse: markers, newLat: '4179441.7304207', newLon
[OpenLayers-Dev] Lang not in utf-8, small fix
Hi, I opened a small ticket [1] including a fix for the only lang file not in utf-8. There's a bug when using this file in IE6 while using a meta http-equiv=Content-Type content=text/html; charset=utf-8 tag. Regards, [1] http://trac.openlayers.org/ticket/2472 -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Who is interested in a Style Editor?
Hi, There are some discussion currently going on to integrate that kind of tool as a GeoExt.ux widget. See the GeoExt-dev mailing list. Regards, Alexandre Marc Jansen wrote: Hi mortac, see http://www.mail-archive.com/us...@openlayers.org/msg05213.html That is old, beta, OL 2.7 and unmaintained since Aug. 2008... I'd love to have time fgor that editor... Regards, Marc mortac8 wrote: Has anyone continued work on this? Is the original demo still available anywhere? ___ 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
Re: [OpenLayers-Dev] Printing map sections...
Hi, GeoExt has this kind of tool, see some examples at : http://www.geoext.org/examples.html#advanced-printing-with-a-form Regards, Alexandre yellow wrote: HI Guys Gals, I would like to know if there is a method or piece of code that allows us to print certain segments of the map. Is there any functionality that allows you to specify an perimiter area by co-ordinates and assembles all tiles in a large image?? Thanks. -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Get direction from route to route... draw route on map (Like GPS)
Hi, CampToCamp worked on such a widget in GeoExt.ux. Currently in a sandbox : http://dev.geoext.org/sandbox/cmoullet/ux/RoutingPanel/examples/RoutingPanelExample.html See also : http://pgrouting.postlbs.org/ Regards, Alexandre yellow wrote: Hi, I would like to know if it is possible to create an application using open layers that gives users the shortest road to a particular destination by drawing the route on the map. And if possible avoiding one-way roads. Can anyone please suggest any resources, ideas or show me a simple example. Thanks in advance. -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Hover over point - Display name
Hi,
I'm not sure what's wrong with what you're doing, but maybe a quick look
at this example [1] might help. I would use 'highlightOnly': true only
and register events instead of overwriting the native callback methods
used when hovering.
Hope this helps,
Alexandre
http://www.openlayers.org/dev/examples/highlight-feature.html
geojoe wrote:
I would like to hover over one of my layers and display the feature site_name
next to the feature like a label. I would also like to have this control
active all of the time - while pan, identify, zoomIn, ... are active.
Using the control below the overFeature code is never reached.
Help,
Joe
userHoverControl = new OpenLayers.Control.SelectFeature(
userLayer,
{
hover: true,
highlightOnly: false,
clickout: false,
toggle: false,
multiple: false,
overFeature: function(feature) {
alert(feature.attributes.site_name);
},
outFeature: function(feature) {
console.log('hover out: ' +
feature.attributes.site_name);
},
}
);
map.addControl(userHoverControl);
userHoverControl.activate();
--
Alexandre Dubé
Mapgears
www.mapgears.com
___
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
Re: [OpenLayers-Dev] Hover over point - Display name
Joe, You can't. You can only use it with Vector features. If you're planing to use WMS only, you can use the GetFeatureInfo control triggering requests when the mouse stops for a brief moment and display a div with the name of the feature hovered. Here's an other solution (still using WFS to get and draw vector features though, you'll need to make sure that you have a WFS server setup): http://www.openlayers.org/dev/examples/getfeature-wfs.html Unfortunately demo.opengeo.org seems to be down for the moment so you won't be able to see it live, but look a the source and you should be able to reproduce the same thing in your application. Basically, with the demo you can draw boxes on the map and a WFS GetFeature request is sent and the returned features are drawn as vector features on the map, looking as they were highlighted. It might be a bit too much for what you want, but it's good to see alternatives. IMHO, a WMS GetFeatureInfo request should be enough. See (instead of triggering requests on map click, make it happen on mouse move stopped): http://www.openlayers.org/dev/examples/getfeatureinfo-popup.html See also : http://www.openlayers.org/dev/examples/hover-handler.html Hope this helps, Alexandre geojoe wrote: It turns out the layer I'm using for hover is a WMS layer and the features property is NULL. How do I use hover with a WMS layer? Joe -- Alexandre Dubé Mapgears www.mapgears.com ___ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
