I got it working : 2 select features, 1 select on click, the other
highlight only on hover... Both could select, but select on hover and
click at the same time is not useful.
I didn't need to have each control to have their unique array of
selected features to do so. The concept of "selected
Eric Lemoine wrote:
> Sorry, the above should read: "I'm not suggesting to change the
> feature's render intent".
>
> --
> Eric
>
Hey Eric, users,
First question : How do change a feature's style with the renderIntent
value without changing the feature's renderIntent ?
layer.drawFeature(fea
Hi Eric.
Yes, I realize that and would love to see it.
Since interaction use cases were part of the conversation, I just
thought you might be interested in an example of a select/hover/
styling use case that a built-in solution should be able to address.
It seems to me it would be a very co
Yeah, we can't solve that issue without storing some state in a
location shared by every control, the feature itself seems the good
spot.
Eric
2009/1/21, Alexandre Dube :
> Hey Eric, Ivan,
>
> That issue could occur if both controls would actually change the
> renderIntent of the feature ( with
Hi Amos
What we're trying to do here is come up with code design that doesn't
require creating new controls.
Eric
2009/1/21, Amos Hayes :
>
> We've had to implement separate select and hover functionality on top
> of select feature. If you like, have a look at this work in progress:
>
> http://a
We've had to implement separate select and hover functionality on top
of select feature. If you like, have a look at this work in progress:
http://atlas.gcrc.carleton.ca/kitikmeot/
--
Amos Hayes
Geomatics and Cartographic Research Centre
Carleton University
aha...@gcrc.carleton.ca
+1.613.520.2
Hey Eric, Ivan,
That issue could occur if both controls would actually change the
renderIntent of the feature ( without actually selecting the feature ).
Let's assume that you can only have one feature hovered at a time (
only one feature can be hovered by the mouse). That said, we could h
Hi
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 hav
Hi Ivan, Eric,
I was actually thinking a similar idea. The more I thought about it,
the more I thought about copying/pasting the SelectFeature control, make
some changes to the copy and name it HighlightFeature. But Eric's idea
is much better.
Having the control itself know which feature
On Mon, Jan 19, 2009 at 10:19 PM, Eric Lemoine wrote:
> On Mon, Jan 19, 2009 at 3:30 PM, Alexandre Dube wrote:
>> Hi Eric,
>>
>> I took a look at the SelectFeature control. Now I understand what you
>> meant and it makes sense. Also, it's also making sense to have this control
>> have the poss
Hi Alexandre and Andreas,
A while ago I created a proof of concept where I simplify the features
with FeatureServer (FS) [1] depending on the resolution.
Chris Schmidt was so kind to point out that the tolerance for
simplifying is directly related to the map resolution.
What I do is add an extra
On Mon, Jan 19, 2009 at 3:30 PM, Alexandre Dube wrote:
> Hi Eric,
>
> I took a look at the SelectFeature control. Now I understand what you
> meant and it makes sense. Also, it's also making sense to have this control
> have the possibility to highlight on hover or on click.
>
> "beforefeature
Hi Eric,
I took a look at the SelectFeature control. Now I understand what you
meant and it makes sense. Also, it's also making sense to have this
control have the possibility to highlight on hover or on click.
"beforefeaturehighlighted" and "featurehighlighted" events make sense,
but a
On Mon, Jan 19, 2009 at 2:53 PM, Eric Lemoine wrote:
> On Mon, Jan 19, 2009 at 2:34 PM, Alexandre Dube wrote:
>> Hi Eric,
>
> Hi Alexandre,
>
>>
>> I don't think we should use a renderIntent value. The main idea of the
>> Highlight feature is to change the style of a feature only when the mouse
On Mon, Jan 19, 2009 at 2:34 PM, Alexandre Dube wrote:
> Hi Eric,
Hi Alexandre,
>
> I don't think we should use a renderIntent value. The main idea of the
> Highlight feature is to change the style of a feature only when the mouse is
> hover it and only that.
I meant that when the feature is
Hi list,
I changed the name of this control for HighlightFeature ( thanks to
Yves ). See the changes below :
Alexandre Dube wrote:
> Hi list,
>
> I just want to share a sample of Handler.Hover usage I do. The result
> is a Control.Hover I use to change the style of features hover the mous
Hi Eric,
I don't think we should use a renderIntent value. The main idea of
the Highlight feature is to change the style of a feature only when the
mouse is hover it and only that. If we change the renderIntent of a
feature, when the mouse is no longer hover it, to what renderIntent we
set
Hi
As I see it:
The HighlightFeature control is configured with a renderIntent. When a
feature is hovered or clicked, the control triggers a
"beforefeaturehighlighted" event, redraws the feature (using the
renderIntent), and trigger "featurehighlighted".
What do you think?
PS: I have to say tha
Yves Moisan wrote:
>
> Having a select control and a "highlight" control
>
Control.Highlight : that's the obvious word I was looking for the class
name. I haven't thought about it at all ().
Thanks Yves,
--
Alexandre Dubé
Mapgears
www.mapgears.com
_
> But, actually, there are so many people needing that thing that it may
> be valuable to have it in trunk.
Having a select control and a "highlight" control that just styles
features so that you know which one you have info for without actually
selecting it plus having an efficient strategy to d
Andreas Hocevar wrote:
> Hi Alexandre,
>
> On Thu, Jan 15, 2009 at 7:52 PM, Alexandre Dube wrote:
>
>> Yeah, I saw your example a couple of days ago. It's a great tool. As
>> vector features are longer to draw than samples images generated by WMS
>> requests I find this quite useful.
>>
>> Th
Hi Alexandre,
On Thu, Jan 15, 2009 at 7:52 PM, Alexandre Dube wrote:
> Yeah, I saw your example a couple of days ago. It's a great tool. As
> vector features are longer to draw than samples images generated by WMS
> requests I find this quite useful.
>
> The slow rendering of vector features ha
Yeah, I saw your example a couple of days ago. It's a great tool. As
vector features are longer to draw than samples images generated by WMS
requests I find this quite useful.
The slow rendering of vector features has been one of my worries. A
common practice is to normalize the geometry for
Thanks Eric for your comments,
As you said, it was not too hard to build. My first thought was that
a SelectFeature control actually "select" the feature ( change its
renderIntent to "select" ) so a selected feature gets drawn with the
"select" style. That was not what I had in mind at firs
Hi,
On Thu, Jan 15, 2009 at 6:10 PM, Eric Lemoine wrote:
> Thanks for sharing your code Alexandre.
>
> I thought about a Feature control in the past. That control would use
> a Feature handler internally and would be configured to work either in
> hover or click mode, just like the SelectFeature
Thanks for sharing your code Alexandre.
I thought about a Feature control in the past. That control would use
a Feature handler internally and would be configured to work either in
hover or click mode, just like the SelectFeature control. But, as
yours, it wouldn't select features, but just trigge
Hi list,
I just want to share a sample of Handler.Hover usage I do. The result
is a Control.Hover I use to change the style of features hover the mouse
without selecting them and display a popup at the same time. You could
also register events on "hoverfeatureset" and "hoverfeaturereset" to
27 matches
Mail list logo
