[OpenLayers-Dev] Features, Styling and Rendering

[Eric Lemoine]

On Nov 16, 2007 10:00 PM, Andreas Hocevar <andreas.hocevar at gmail.com> 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