[OpenLayers-Dev] Random Colors on Vector Features?

[Christopher Schmidt]

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. 
> > 
> > I see a couple of examples for 'unique style value' stuff, but that
> > requires some unique attribute on my feature; I want to serialize the
> > features later, so I don't want bogus attributes attached to them.
> > 
> > Can I set a Style() object directly on the feature with my fillColor
> > specified? Do I have to do something else? 
> 
>      var colors = ["red", "orange", "yellow", "green", "blue", "purple"];

        Seperate issue, but I'm pretty sure that these colors won't work
        as a fill in VML, only in SVG: We probably want to turn these
        into hex codes in our existing example to ensure it works in IE.
        Unless I'm wrong about IE not supporting colornames, which is
        possible, but I know I bumped into something like that before.

>      var features = new Array(20);
>      var x, y, fill;
>      for(var i=0; i<20; i++) {
>          x = Math.random() * 360 - 180;
>          y = Math.random() * 180 - 90;
>          fill = colors[Math.round((colors.length - 1) * Math.random())];
>          features[i] = new OpenLayers.Feature.Vector(
>              new OpenLayers.Geometry.Point(x, y), null,
>              {fillColor: fill, pointRadius: 5}
>          );
>      }
> 
> 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.


> 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.)

> 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
downloading the friend data, geotagging the town name with metacarta's
locationfinder lookup, and then displaying the data on the map. The
features have useful attributes -- specifically, name -- and also a FID,
but the name obviously doesn't form an attribute that's useful to filter
on. (Note that this is not "GIS" data, just data that makes sense to
display on a map.) I'd like to color the users so that there is some
differentiation: I don't know how I'll do it in the end, but I just want
to provide a visual indicator that there is variation in these features,
since when they stack on top of each other, it's hard to know how many
are really in a stack.

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.

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.

Regards,
-- 
Christopher Schmidt
MetaCarta