[OpenLayers-Dev] Rule subclasses and 2.6

[Tim Schaub]

Christopher Schmidt wrote:
> On Thu, Apr 03, 2008 at 10:21:39AM +0200, Andreas Hocevar wrote:
>> On Thu, Apr 3, 2008 at 6:14 AM, Tim Schaub <tschaub at openplans.org> wrote:
>>>  The new style work includes the addition of OpenLayers.Rule and
>>>  subclasses.  The base Rule class corresponds well to the sld:Rule
>>>  element in the SLD spec (min/max limits constraints, symbolizers, etc.).
>>>
>>>  The subclasses of Rule (Comparison, FeatureId, and Logical) correspond
>>>  well to ogc:Filter elements in the Filter Encoding specification.
>>>  Though our Rule subclasses can have a symbolizer, an ogc:Filter knows
>>>  nothing of a symbolizer - in SLD, an ogc:Filter element is a child of an
>>>  sld:Rule that has a symbolizer.
>> To me, a logical step would be to have one Rule class, which has
>> minScale, maxScale, symbolizer, and a filter property. There would be
>> a new class OpenLayers.Filter with subclasses with the filter-related
>> code of the current Rule subclasses. I think that is in line with what
>> you think.
>>
>>>  1) Do no mark Rule subclasses as part of the API.  Later, change them so
>>>  they are Filter subclasses and require that they be added to a Rule
>>>  (with a symbolizer) for things like styling.  They could also be used
>>>  alone (without rules) for things like WFS.  This would also require
>>>  changing the georss-flickr.html example (that uses Rule.Comparison) and
>>>  the wiki page on styling.
>> I am in favour of that option. We do not encourage people to touch
>> rules directly anyway (except for the georss-flickr example).
>>
>> Also, the proposed change does not look like too much work to me.
> 
> I must be missing something.
> 
> We've got significant new functionality that allows you to style
> features based on their attributes via the Style/Rule system, a I
> understand it.
> 
> This allows me to, for example, take a list of places named Cambridge,
> around the world, with their population values, and give them different
> sizes and colors according to population:
> 
>   http://crschmidt.net/mapping/cambridge-geojson.html
> 
> As much as I feel that the current system is somewhat complex, I do
> think it's pretty cool. Not a lot of code, given how much has to be
> done: it's not an easy problem to solve. This seems to me to have a
> clear benefit for thematic mapping: it fits neatly into what used to be
> forced into the application space, I think.
> 
> I can't figure out how to do this without using OpenLayers.Rule
> subclasses.
> 
> Are we saying we're going to not make a committment to supporting
> applications written against this system in 2.6 going forward? That my
> cambridge-geojson example may break in the future?
> 
> I understand that perhaps we chose the wrong name. I'm cool with that;
> we may want to change it in the future. But from what I understand,
> Filters would replace Rule subclasses pretty directly: there wouldn't be
> some *other* kind of Rule.Comparison that we would want that namespace
> for, it would just be moving to Filter.Comparison instead. (If I'm wrong
> on this, that would be good to know.)
> 

The OpenLayers.Rule class comes from the sld:Rule element.  A rule in 
SLD has optional constraints on scale (sld:MinScaleDenominator and 
sld:MaxScaleDenominator), typically has symbolizers (for Point, Line, 
Polygon, etc), and optionally has an ogc:Filter element.

In the Filter Encoding spec (where you find the description of 
ogc:Filter elements), there are a number of types of filters.  These 
include comparison filters, feature id filters, and logical filters.  In 
OpenLayers (currently) the subclasses of OpenLayers.Rule map directly to 
these types of ogc:Filter.

The problem is not only one of naming.  An sld:Rule *has* an ogc:Filter. 
   So a rule can have a feature id filter for example.  In OpenLayers, 
an OpenLayers.Rule.FeatureId *is* a rule.

The difference is that rules have things like scale constraints and 
symbolizers.  Filters do not have scale constraints and symbolizers.  A 
filter is the child of a rule.  A filter is not a rule.

So, OpenLayers.Rule.FeatureId would become OpenLayers.Filter.FeatureId. 
  This filter could be used for more than just styling - it could, for 
example, be serialized and used in a WFS query.  This has nothing to do 
with styling.

So yes, your cambridge example would break in the future.  Instead you 
would do something like:

var rule = new OpenLayers.Rule({
     symbolizer: {"Point": {"fillColor": "fuchsia"}},
     filter: new OpenLayers.Filter.Comparison({
         type: OpenLayers.Filter.Comparison.GREATER_THAN_OR_EQUAL_TO,
         property: "Population",
         value: 10000
     })
});

// or

var rule = new OpenLayers.Rule({
     symbolizer: {"Point": {"fillColor": "fuchsia"}},
     filter: new OpenLayers.Filter.Logical({
         type: OpenLayers.Filter.Logical.AND,
         filters: [
             new OpenLayers.Filter.Comparison({
                 type: OpenLayers.Filter.Comparison.LESS_THAN,
                 property: "Population",
                 value: 100000,
             }),
             new OpenLayers.Filter.Comparison({
                 type: OpenLayers.Filter.Comparison.GREATER_THAN,
                 property: "Population",
                 value: 0,
             })
         ]
     })
});

The difference is that rules have symbolizers and a filter (optionally). 
  Filters do not have symbolizers.  A logical filter has child filters.

My question was whether we wanted to
1) change this before 2.6, or
2) change this after 2.6.

If we change after 2.6, then we decide whether to wait for 3.0 or 
whether to release with the rule subclasses as not part of the API 
(subject to change).

I'm happy to write up a patch if we want to do this before 2.6 (which I 
do of course*).

Tim

* In the future, I'm also in favor of branching in advance of a release 
so we don't release brand spanking new features with unstable interfaces.

> Given that, I don't see how stating that we will maintain these classes
> going forward hurts us. If users find that they transition their
> applications, they can simply exclude the Rule subclasses from their
> personal build profile, and they'll have the support they need. Heck, we
> could even pull them out of the default build profile, with specific
> instructions on how to keep them around, if file size is the concern.
> I do believe that we should not require application authors who write
> against this code in 2.6 to have to change their applications before
> they can use 2.7. If we go that route, in my opinion, we're abondoning
> the feature for this release... before it's even been used.
> 
> Regards,