[OpenLayers-Dev] Random Colors on Vector Features?

Tim Schaub tschaub at openplans.org
Mon Mar 3 15:29:54 EST 2008


Hey-

Christopher Schmidt wrote:
> On Sun, Mar 02, 2008 at 10:44:24PM -0700, Tim Schaub wrote:
>> Christopher Schmidt wrote:
>>> I have a set of vector features. Each time I create a new feature, I
>>> want that feature to be styled such that it has a random color, chosen
>>> from a list of colors supplied by me. 
>>>
>> Setting a symbolizer directly on a feature still works.
> 
> Ah, okay. This isn't deprecated? I had assumed that since I knew how to
> do it, I was probably doing it wrong ;)
> 
> Anyway, my problem with this approach had been that when I tried it,
> selecting the feature didn't change the style to indicate the feature
> was selected.  Maybe I was doing something wrong; I assumed I just had
> to do something more complex, but it sounds like I just screwed
> something else up that caused it to not work. Thanks for the feedback on
> that.
> 

Yeah, setting symbolizers directly on features leaves you with the 
rendering intent problem that StyleMap is meant to address.  More below.

> 
>> In the future, I think it would be good to encourage the use of 
>> FeatureId rules.  This could be facilitated by having layer.addFeature 
>> (to be written) optionally take a symbolizer.  
> 
> Why limit this to addFeature instead of just adding it to addFeatures?
> If I pass a list of features, the symbolizer is added to the stylemap for
> each of them. (Note that addFeatures will take a single feature and add
> it: it doesn't have to be an array, I just didn't see a reason for
> adding another function just for the name.)
> 

Of course, adding it to addFeatures makes sense as well.  Specifically, 
it makes sense when you want to create multiple FeatureId rules that use 
the same symbolizer.

>> I'm curious about your use case.  I don't have a good idea how common it 
>> is to want to style a feature in a way that has nothing to do with its 
>> attributes.
> 
> I'm making a Facebook-API based "friends map" of users hometowns, by
> ...
> since when they stack on top of each other, it's hard to know how many
> are really in a stack.

Sounds cool.  I would guess that you'll not be adding much meaning to 
the map if you symbolize a pile of markers with random colors.  I think 
grouping and using marker size to represent multiple markers is more 
intuitive.  In the end, I bet more people can make sense of markers if 
they are symbolized by something meaningful about the feature they 
represent.  This has nothing to do with GIS, just common sense.

> 
> I don't see a useful way to make this work as an attribute filter. A
> FeatureID filter would be fine, but I'm not sure I understand the
> benefit of a FeatureID based filter over usig a symbolizer directly, so
> long as I want a fixed selection style (not based on FID). Perhaps
> there's some aspect of this I'm not understanding.

You're right, if you want each feature to have a symbolizer that you 
generate at construction, you can tack that symbolizer on to the 
features themselves.  And if you want all features to look the same when 
selected (regardless of what they looked like before they were 
selected), then you have no use for anything more than a selectedStyle 
attribute on the select feature control.  These are pretty narrow 
requirements, and I'm glad that the library now supports a lot more 
control over style than this.

> 
> In general, there's a fair amount of data that doesn't have attributes
> which lead to useful variations in styling: instead, the desire is, in
> my mind, for a 'unique values' style. You've done that to some extent
> (with Andreas) in a couple examples, but they didn't seem to apply
> trivially to this case. Another example I can think of is Google
> Maps-style location listings with a marker with a letter on it: I want
> to iterate through the features, and for each one I want to grab the
> marker with the next letter on it, and use that. This isn't based on an
> attribute, and the fid might be some ID which is specific to the feature
> (rather than the order), so there's nothing that makes it easy to filter
> based on the attributes, I don't think.
> 

Yeah, I think all of what you've said here would be handled by my 
suggestion for:

layer.addFeatures(
     feature,
     {
         symbolizer: {
             externalGraphic: "marker_a.png",
             pointRadius: 10
         }
     }
);

Which does the same thing as the old-school:

feature.style = {
     externalGraphic: "marker_a.png",
     pointRadius: 10
};
layer.addFeatures(feature);

In this case the benefit of using a StyleMap (which the new method does 
and the old method doesn't) isn't seen until you want a different 
symbolizer for a different rendering intent.

layer.addFeatures(
     feature,
     {
         symbolizers: {
             default: {
                 externalGraphic: "marker_a.png",
                 pointRadius: 10
             },
             select: {
                 externalGraphic: "marker_a_select.png",
                 pointRadius: 10
             }
         }
     }
);

Which is not possible using the old-school ways.

Tim

> Regards,




More information about the Dev mailing list