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

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

*Hi Rafael,

Thanks for your reply! My responses below are in bold. But first up, the
OpenLayers developers have also noticed they have mixed up style and
symbolizer in many places, see:
http://trac.openlayers.org/ticket/1845

Ideally, style would be replaced by symbolizer in OpenLayers 3.0 (at least
it is scheduled for 3.0 with #1845). Personally, I think using the
terminology symbolizer is the only sensible choice, since that is OGC
standard terminology and that is why I would favor that for GWT-OL no matter
what OL does. We are not obliged to do a 1-on-1 mapping. We should off
course think well about diverging, but sometimes it is justified in my
opinion.

Greetings,
Edwin*

*P.S.* *I encountered some Natural Docs style comments in the code. Please
comment GWT-OL with plain JavaDoc, to have the befenits from tools like
Eclipse (all the other docs are JavaDoc comments).* *Documenting is greatly
encouraged, though I do not do it everywhere either (sometimes you just want
to get stuff in :-)...)*

2009/9/17 "Cerávolo, Rafael V.B." <raf...@gm...>

>  Hi Edwin,
>
> See my comments below (in red)
>
> Edwin Commandeur wrote:
>
> 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.
> I created a class "StyleMap" (see
> http://sourceforge.net/apps/trac/gwt-openlayers/ticket/7), but I used and
> tested just on the StyleMap property of "Layer.Vector", if you could, try to
> use the "org.gwtopenmaps.openlayers.client.StyleMap" with HandlerOptions to
> see if it works.
>
> *Rafael,  I saw you created the StyleMap. The way I understand, the
StyleMap should work with HandlerOptions, and we can indeed create styles
for the map, because a style map takes symbolizers (and we wrap symbolizer*
*objects* *in* *org.gwtopenmaps.openlayers.client.Style). Yesterday, I
didn't immediately see it but the OL StyleMap is actually a SymbolizerMap.

The 'stylemap.html' example is especially misguiding, because it uses the
OpenLayers.Style constructor to construct objects that aren't styles at all.
It works because javascript sets all the properties on the object, but all
the properties are not actually properties of OpenLayers.Style. I like the
dynamic nature of JavaScript, but here you see where it can mess you up in a
large, complicate codebase (and OL is quite large now, it's awfully big for
a JS lib with over 600 kb in compressed, but not obfuscate form).
*

>
> 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.
> Yes, you're right, and know I'm a little confused too. Specially when
> looking at the StyleMap OL documentation (
> http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/OpenLayers/StyleMap-js.html).
> The OL StyleMap class has a constructor that accepts a single style object
> or a hash of styles. And the examples I saw using StyleMap, they pass styles
> to the constructor as they where of the same class of
> OpenLayers.Feature.Vector.style[default], but as you said, they are not
> objects of the type 'OpenLayers.Style'.
>
> *We are not the only ones confused. The OL developers themselves are as
well, see #1845, which I already mentioned above:
http://trac.openlayers.org/ticket/1845

*

> 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.
>
> I'm not very sure about that. The OL documentation uses the word "style" in
> many places for refering parameters and objects when they are in fact not an
> OpenLayers.Style object. So, someone that is new at OpenLayers and started
> using it directly with GWT-OpenLayers (as I did!), would expected that those
> places where the OL Docs says "style", should have a "Style" class in GWT or
> something closer to that. On the other hand if who is using GWT-OpenLayers
> have previously experience with OpenLayers.js than maybe is expected that
> the GWT Style class is the directly correspondent class for the JavaScript
> Style class.
>
> Other issue, is that changing the name of the Style class will break the
> compatibility with current code out-there using GWT-OpenLayers. We can do
> that, but we will need to put a very nice documentation about that!
> **
>
> *
**Rafael, I understand your* *concerns that people may get confused. But
actually, I think GWT-OL can take confusion away be already implementing
#1845, since it will give them different names for things that are different
and can let them see the difference*.* The JavaDoc should make it very clear
that the Vector.setSymbolizer() is equivalent to setting the style property
in OL. *

***Changing the name of Style will indeed breek compatibility with previous
code, and that should not be taken lightly, but GWT-OL is still in version
0.4. I would say that now is the time for making these kind of changes,
before we get stuck with something that we know we want to change in version
1.0 or above.*



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.


What do you think about the name StyleProperties instead of Symbolizer? I
> think it will be easier to understand when following OL examples to do the
> same thing in GWT-OL.
>
> For example, when doing the following in JS:
>
> 	var template = {
>                 pointRadius: 10,
>                 fillColor: "red"
>             };
>             var style = new OpenLayers.Style(template);
>
> Will be better to "migrate" to GWT-OL using:
>
> StyleProperties template = new StyleProperties();
> template.setPointRadius(10);
> template.setFillColor("red");
>
> Style style = new Style(template);
>
>
> than when using:
>
> Symbolizer template = new Symbolizer();
> template.setPointRadius(10);
> template.setFillColor("red");
>
> Style style = new Style(template );
>
>  Or doing:
>
>  StyleProperties styleProp = new StyleProperties();
> styleProp.setFillColor("red");
> vectorLayer.setStyleProperties(styleProp);
>
>  Instead of:
>
>
> Symbolizer symb = new Symbolizer();
> symb.setFillColor("red");
> vectorLayer.setSymbolizer(symb);
>
>
*Rafael, thanks for providing the suggestion about StyleProperties, but I am
not really convinced that such a name would improve things. StyleProperties
would mean that we start introducing our own terminology. It is confusing
why StyleProperties is separate from Style and it is not standard OGC
terminology (OL terminology maps onto OGC terminology in a lot of places).

Also, I think we should follow in the footsteps of the 'stylemap.html'
example and create an OpenLayers.Style object, when it in fact has nothing
to do with an OpenLayers.Style object. That is dangerous, because we set
properties on an an Object that also has behaviour. Also, it is a waste of
memory, because a simple Object literal would suffice in Javascript to
create the StyleMap. For example, in the 'stylemap.html':

var myStyles = new OpenLayers.StyleMap({
                "default": {  pointRadius: "${type}",
                    fillColor: "#ffcc66",
                    strokeColor: "#ff9933",
                    strokeWidth: 2 },
                "select": {  fillColor: "#66ccff",
                    strokeColor: "#3399ff" }
            });
*
*This code example sidesteps the fact that StyleMap should have been called
SymbolizerMap.

What we could do alternatively, to not break code compatibility is to
deprecate Style and provide alternative methods that we recommend. **

**If Style is deprecated you could do both in GWT-OL 0.5:

Vector.setStyle(style); //deprecated, state in JavaDoc that setSymbolizer
should be used
Vector.setSymbolizer(Symbolizer symbolizer); //recommended

Then we would need to add/implement:
**org.gwtopenmaps.openlayers.client.style.Symbolizer
**org.gwtopenmaps.openlayers.client.style.SymbolizerMap *
*
For terminology see: http://www.opengeospatial.org/standards/sld

**The OpenLayers.Style class does not need to be wrapped just yet, but could
be wrapped under:
org.gwtopenmaps.openlayers.client.style.UserStyle (see constructor)
or just:
**org.gwtopenmaps.openlayers.client.style.Style
(As an aside: OpenLayers also doesn't distinguish between UserStyle and
FeatureTypeStyle, so although the constructor of OpenLayers.Style says it
creates a UserStyle, I am not to sure if that is really the case and if it
isn't the case that it creates something than can be a UserStyle or
FeatureTypeStyle.)*
*

*

> 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
>
>  Regards,
> Ceravolo
>