Features, Styling and Rendering

[Andreas Hocevar]

Hi,

after thinking about and looking at my code for styles and rules
(http://trac.openlayers.org/ticket/533, sandbox/ahocevar/sldRenderer)
as well as everything around it again and again, especially after Tim
asked me about ideas on how to implement KML StyleMaps, I came up with
the following conclusions and questions:

* #533 is not ready for review yet, because the way styles are stored
in layers, features and controls should be reconsidered in OpenLayers
in general. So if anyone wants to review my work, please do only look
at OpenLayers.Format.SLD, OpenLayers.Style and OpenLayers.Rule (plus
subclasses), those I would consider ready for trunk. The rest is about
applying and using styles, and there is a lot of open questions here.

* IMO calculating styles should happen in renderer.drawFeature (and
not in Layer.Vector.drawFeature, Control.SelectFeature.select and
Marker.draw and probably other places where it is now - in general,
not only in my sandbox)

* Having said that: why do vector features not have a draw method like
markers? (not related to my work). Shouldn't either Feature have a
drawMarker method, or Feature.Vector a draw method? And why do we have
markers anyway? Isn't rendering something that should happen at the
level of geometries, not features? And isn't drawing markers just a
different way of rendering point geometries? So maybe, instead of a
Feature having a Marker, Feature should be the same as Feature.Vector,
but can opt to have its geometries rendered by a new Renderer.Point
instead of Renderer.SVG or Renderer.VML?

* KML style maps are a good thing. And I think styles in OpenLayers
should generally be hadled as style maps somehow. Every method that
calls renderer.drawFeature should not pass a style, but a
renderingIntent. This would be a one-time assignment of which key from
a style map to use, and switching styles back and forth (like
currently in the Control.SelectFeature.select method) would not be
needed any more, e.g.

feature.style = {
    "default": defaultStyle,
    "select": selectStyle
}

layer.renderer.drawFeature(feature, "select")

--> draw feature with style["select"], with style being a style map of
OpenLayers.Style and "select" being a well known style key for
selected features. This is also something that SLD uses in a similar
way, because we have UserStyles with different names there. A
UserStyle in SLD is mapped to OpenLayers.Style, and the name of the
rule would be the key under which to add it to a style map. And guess
what: this is exactly what OpenLayers.Format.SLD is doing. So we have
style maps already, but we do not use them in layers, features or
whatever.

I hope that after these statements, people will come up with
discussion, ideas and solutions. Unfortunately, I'm a little bit short
on time at the moment, but I have not given up on the whole styling
thing yet.

Regards,
Andreas.
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev

[Eric Lemoine]

On Nov 16, 2007 10:00 PM, Andreas Hocevar <[hidden email]> wrote:
> Hi,

Hi Andreas

Overall, your ideas sound good and valuable to me.

See my inline comments.

>
> after thinking about and looking at my code for styles and rules
> (http://trac.openlayers.org/ticket/533, sandbox/ahocevar/sldRenderer)
> as well as everything around it again and again, especially after Tim
> asked me about ideas on how to implement KML StyleMaps, I came up with
> the following conclusions and questions:
>
> * #533 is not ready for review yet, because the way styles are stored
> in layers, features and controls should be reconsidered in OpenLayers
> in general. So if anyone wants to review my work, please do only look
> at OpenLayers.Format.SLD, OpenLayers.Style and OpenLayers.Rule (plus
> subclasses), those I would consider ready for trunk. The rest is about
> applying and using styles, and there is a lot of open questions here.
>
> * IMO calculating styles should happen in renderer.drawFeature (and
> not in Layer.Vector.drawFeature, Control.SelectFeature.select and
> Marker.draw and probably other places where it is now - in general,
> not only in my sandbox)
>
> * Having said that: why do vector features not have a draw method like
> markers? (not related to my work). Shouldn't either Feature have a
> drawMarker method, or Feature.Vector a draw method? And why do we have
> markers anyway?

Makers were added in OpenLayers before all the vector stuff. I think
that's the reason of these inconsistencies between markers and
features. Also, note that OpenLayers.Marker doesn't inherit from
OpenLayers.Feature.

> Isn't rendering something that should happen at the
> level of geometries, not features?

pgiraud and I discussed this a while back, and we both agreed than
Renderer should not define drawFeature but only drawGeometry.
Currently, Renderer.drawFeature() does all the work of retrieving the
feature style and feature id and pass these to
Renderer.drawGeometry(). I think this work should belong to the
upper-level layer - possibly OpenLayers.Feature.draw() as you're
suggesting.

> And isn't drawing markers just a
> different way of rendering point geometries? So maybe, instead of a
> Feature having a Marker, Feature should be the same as Feature.Vector,
                                            ^^^^^

You mean Marker here, don't you?

> but can opt to have its geometries rendered by a new Renderer.Point
> instead of Renderer.SVG or Renderer.VML?

With the external graphics stuff, I'm not sure it's worth bothering
adding Renderer.Point. I agree that it's a bit strange to rely on
vector renderers (SVG and VML) for markers, but do we really want to
have two different ways to render markers?

> * KML style maps are a good thing. And I think styles in OpenLayers
> should generally be hadled as style maps somehow. Every method that
> calls renderer.drawFeature should not pass a style, but a
> renderingIntent. This would be a one-time assignment of which key from
> a style map to use, and switching styles back and forth (like
> currently in the Control.SelectFeature.select method) would not be
> needed any more, e.g.
>
> feature.style = {
>     "default": defaultStyle,
>     "select": selectStyle
> }
>
> layer.renderer.drawFeature(feature, "select")
>
> --> draw feature with style["select"], with style being a style map of
> OpenLayers.Style and "select" being a well known style key for
> selected features. This is also something that SLD uses in a similar
> way, because we have UserStyles with different names there. A
> UserStyle in SLD is mapped to OpenLayers.Style, and the name of the
> rule would be the key under which to add it to a style map. And guess
> what: this is exactly what OpenLayers.Format.SLD is doing. So we have
> style maps already, but we do not use them in layers, features or
> whatever.

How would that work for user-defined styles?

Thanks,
--
Eric
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev

[Andreas Hocevar]

Hi,

thanks Eric for your comments.

On Nov 22, 2007 1:42 PM, Eric Lemoine <[hidden email]> wrote:
> On Nov 16, 2007 10:00 PM, Andreas Hocevar <[hidden email]> wrote:
> Makers were added in OpenLayers before all the vector stuff. I think
> that's the reason of these inconsistencies between markers and
> features.

I think so, too. And making Marker, Feature and Feature.Vector more
consistent is definitely a thing to be considered not before
OpenLayers 3.0 IMO.

> Also, note that OpenLayers.Marker doesn't inherit from
> OpenLayers.Feature.

I know. As I understand it, OpenLayers.Marker can be looked upon as a
renderer for OpenLayers.Feature, but I'm well aware that it can also
be used separately.

> > And isn't drawing markers just a
> > different way of rendering point geometries? So maybe, instead of a
> > Feature having a Marker, Feature should be the same as Feature.Vector,
>                                             ^^^^^
>
> You mean Marker here, don't you?

No, I mean OpenLayers.Feature. Currently, we have OpenLayers.Feature
and OpenLayers.Feature.Vector, and my question was if those should
maybe be merged into one (again, nothing to be concerned of before
3.0). Let me sum up the things that they have in common and what is
different:

* Feature.Vector has a geometry and a style. In Feature, similar
information is stored in lonlat and data.icon.
* Feature.Vector has attributes, Feature has data. This is the same,
except that data has the icon (=style information) in it.
* Feature has a popup, Feature.Vector only dummy methods
createPopup/destroyPopup
* Feature.Vector is rendered using a layer it is contained in, Feature
using a marker created out of lonlat and data.icon

> > but can opt to have its geometries rendered by a new Renderer.Point
> > instead of Renderer.SVG or Renderer.VML?
>
> With the external graphics stuff, I'm not sure it's worth bothering
> adding Renderer.Point. I agree that it's a bit strange to rely on
> vector renderers (SVG and VML) for markers, but do we really want to
> have two different ways to render markers?

I would totally agree, if only vector layers would not prevent click
and hover events from being received by layers below
(http://trac.openlayers.org/ticket/434). With points rendered as
images, you can have several marker layers and do click action on any
of them. With points rendered as vectors, you can only have that in
the uppermost layer. Unfortunately, I do not have an idea on how to
change vector layers in a way that would allow to receive click/hover
events on more than one layer.

> > * KML style maps are a good thing. And I think styles in OpenLayers
> > should generally be hadled as style maps somehow. Every method that
> > calls renderer.drawFeature should not pass a style, but a
> > renderingIntent. This would be a one-time assignment of which key from
> > a style map to use, and switching styles back and forth (like
> > currently in the Control.SelectFeature.select method) would not be
> > needed any more, e.g.
> >
> > feature.style = {
> >     "default": defaultStyle,
> >     "select": selectStyle
> > }
> >
> > layer.renderer.drawFeature(feature, "select")
> >
> > --> draw feature with style["select"], with style being a style map of
> > OpenLayers.Style and "select" being a well known style key for
> > selected features. This is also something that SLD uses in a similar
> > way, because we have UserStyles with different names there. A
> > UserStyle in SLD is mapped to OpenLayers.Style, and the name of the
> > rule would be the key under which to add it to a style map. And guess
> > what: this is exactly what OpenLayers.Format.SLD is doing. So we have
> > style maps already, but we do not use them in layers, features or
> > whatever.
>
> How would that work for user-defined styles?

Instead of storing a single style with a feature, we would store a
style map. In current trunk OL, this could be a hash of style hashed,
keyed by renderIntent (like the style constant in
OpenLayers.Feature.Vector). In the case of my OpenLayers.Style work,
it would be a hash of OpenLayers.Style, again keyed by renderIntent.

By saying "we have style maps already", I meant that SLD can have many
named styles for one named layer (think of style names as renderIntent
keys). This is similar to KML style maps.

Does that answer your question?

Regards,
Andreas.
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev

[Christopher Schmidt-2]

On Thu, Nov 22, 2007 at 03:09:37PM +0100, Andreas Hocevar wrote:

> > > And isn't drawing markers just a
> > > different way of rendering point geometries? So maybe, instead of a
> > > Feature having a Marker, Feature should be the same as Feature.Vector,
> >                                             ^^^^^
> >
> > You mean Marker here, don't you?
>
> No, I mean OpenLayers.Feature. Currently, we have OpenLayers.Feature
> and OpenLayers.Feature.Vector, and my question was if those should
> maybe be merged into one (again, nothing to be concerned of before
> 3.0).

Absolutely. The fact that there are two different implementations of
Feature -- or that Vector features are 'Feature.Vector' -- is somewhat
silly, but is led by my attempt to make things as familiar as possible.

> I would totally agree, if only vector layers would not prevent click
> and hover events from being received by layers below
> (http://trac.openlayers.org/ticket/434). With points rendered as
> images, you can have several marker layers and do click action on any
> of them. With points rendered as vectors, you can only have that in
> the uppermost layer. Unfortunately, I do not have an idea on how to
> change vector layers in a way that would allow to receive click/hover
> events on more than one layer.

I think we have some ideas for that: Specifically, the geometry
intersection code that Tim was working on may make it in at some point.
If that happens, we no longer need to depend entirely on browser events
for capturing clicks, and we can do more fancy things with select
controls.

However, there is still a significant disconnect between markers --
which use events registered per item -- and Features, that will be hard
to reconcile.

There's also the fact that Safari 2 is still prominent -- heck, I
consider Safari 1.3 supported -- and doesn't have SVG support. Until
then, we have a need to support the markers/SVG dichotomy. (I say this
speaking for all our users, and especially MetaCarta, for whom the
ability to put markers on the map is imperative.)

Regards,
--
Christopher Schmidt
MetaCarta
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev

[Eric Lemoine]

On Nov 22, 2007 3:21 PM, Christopher Schmidt <[hidden email]> wrote:

> On Thu, Nov 22, 2007 at 03:09:37PM +0100, Andreas Hocevar wrote:
> > > > And isn't drawing markers just a
> > > > different way of rendering point geometries? So maybe, instead of a
> > > > Feature having a Marker, Feature should be the same as Feature.Vector,
> > >                                             ^^^^^
> > >
> > > You mean Marker here, don't you?
> >
> > No, I mean OpenLayers.Feature. Currently, we have OpenLayers.Feature
> > and OpenLayers.Feature.Vector, and my question was if those should
> > maybe be merged into one (again, nothing to be concerned of before
> > 3.0).
>
> Absolutely. The fact that there are two different implementations of
> Feature -- or that Vector features are 'Feature.Vector' -- is somewhat
> silly, but is led by my attempt to make things as familiar as possible.
>
> > I would totally agree, if only vector layers would not prevent click
> > and hover events from being received by layers below
> > (http://trac.openlayers.org/ticket/434). With points rendered as
> > images, you can have several marker layers and do click action on any
> > of them. With points rendered as vectors, you can only have that in
> > the uppermost layer. Unfortunately, I do not have an idea on how to
> > change vector layers in a way that would allow to receive click/hover
> > events on more than one layer.
>
> I think we have some ideas for that: Specifically, the geometry
> intersection code that Tim was working on may make it in at some point.

Chris,

You mean that it's not the dom element that's used to determinve the
selected feature but the event position. Example: event occurs at
point (x,y) and feature A and point (x,y) intersect so feature A is to
be considered by this event?

--
Eric
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev

[Christopher Schmidt-2]

On Thu, Nov 22, 2007 at 03:48:22PM +0100, Eric Lemoine wrote:
> You mean that it's not the dom element that's used to determinve the
> selected feature but the event position. Example: event occurs at
> point (x,y) and feature A and point (x,y) intersect so feature A is to
> be considered by this event?

Yep.

I don't consider it a 'sure thing' yet, but I think that it's possible
we could go that way for users who need multiple-layer selection/events.

Regards,
--
Christopher Schmidt
MetaCarta
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev