[Gwt-openlayers-devl] Measure control and styling in OL

[Edwin C. <com...@gm...>]

Hi Michel and Rafael,

Hi there, I like to have your input on an issue regarding styling in OL.
First I explain myself, after that I have a proposal. It all comes down to
the fact that I think it should be fixed that
'org.gwtopenmaps.openlayers.client.Style' isn't a wrapper of
'OpenLayers.Style'.

Michel made a start with the Measure control. This night (it's night here in
the Netherlands), I started out implementing the listeners for Measure and
MeasurePartial. That was the easy job and I committed it to Mercurial. After
that, I started looking at styling the Measure control and that turned out
to be somewhat more complex... This has to go via HandlerOptions (which I
created a start of class hierarchy for) on which HandlerLayerOptions can be
set that take a StyleMap... and wouldn't it be nice if we could create
styles to fill the StyleMap in code... however, as yet, we can't.

If you look at the 'measure.html' example then you will see that an
'OpenLayers.Style' object is created with a rule that takes symbolizers. The
symbolizers turn out to have the properties that our current
'org.gwtopenmaps.openlayers.client.Style' has (fillColor, strokeColor, etc).
This prompted me to look closer at the 'OpenLayers.Style' class and if you
look at the OpenLayers API doc, the style class properties do not correspond
with the properties of 'org.gwtopenmaps.openlayers.client.Style'. In fact,
'org.gwtopenmaps.openlayers.client.Style' seems to wrap a symbolizer.

As it turns out, Vector Layers in OL document they have a 'style property'
and this 'style property' is not an 'OpenLayers.Style' object (To me this is
confusing!!!), but it is the same type of object defined in:
OpenLayers.Feature.Vector.style[default]
You would expect to find a ready to use 'style object' there, but that is
not the case! The object defined in OpenLayers.Feature.Vector.style[default]
is actually a symbolizer as it is used in SLD's (have a look at the
'sld.html' example and inspect the sld variable on the Window object of the
browser with Firebug). However, OL itself does not have a complete class
hierarchy for creating a full SLD object. OL only has some of the classes
that are used in creating SLDs and lacking is a Symbolizer class/are
Symbolizer classes. Symbolizers are created in plain javascript object
notation throughout OL.

So, what is referred to as a 'style' in the context of a Vector Feature &
Vector Layer is actually a symbolizer. See also:
OpenLayers-2.8\lib\OpenLayers\Feature\Vector.js
Under:
* Constant: OpenLayers.Feature.Vector.style
you find:
* Symbolizer properties:

In the end it would be nice if we can create an SLD programmatically in
GWT-OL, but first of all I think it would be nice if we avoid the naming
confusion and use the word style in GWT-OL only to refer to something that
is an 'OpenLayers.Style' object under the covers.

The current org.gwtopenmaps.openlayers.client.Style object would than have
to be moved to some other class. For example, to:
org.gwtopenmaps.openlayers.client.style.Symbolizer

The symbolizer can have generic symbolizer state/behavior. I would like to
change the setStyle method in
org.gwtopenmaps.openlayers.client.layer.Vector  to setSymbolizer and explain
in the JavaDoc why it is named differently from the OL name.

There is no setStyle method yet on
org.gwtopenmaps.openlayers.client.feature.VectorFeature, but
OpenLayers.Feature.Vector does have a style API property. I would be in
favor to create a setSymbolizer method in GWT-OL instead of a setStyle
method.

How do you guys feel about my suggestions? Do you have any suggestions?
Currently, I have created a Symbolizer class under
org.gwtopenmaps.openlayers.client.style. Is that package name okay or do you
like org.gwtopenmaps.openlayers.client.symbolization better? The SLD spec
states: "This document explains how the Web Map Server (WMS 1.0 [1] & 1.1
[2]) specification can be extended to allow user-defined symbolization of
feature data.", but also talks a lot about styling this and that.

I would need to look more closely at the SLD and Symbology Encoding specs
from the OGC and the SLD implementation in OpenLayers to see if it would
make sense to have subclasses of Symbolizer, such as PointSymbolizer or a
BaseSymbolizer (very generic), and different Symbolizers extending that
class or one another.

Greetings,
Edwin