On Aug 31, 2010, at 12:57 PM, Arnd Wippermann wrote:
Hi,
The features have no values = "undefined", but a status of
"undefined". So
your comparison can not work.
I don't believe that is quite right. I reworked things based on the
example code you proposed (thanks very much, btw), and what I came up
with below does perform as I had hoped. The property-based styles
(for label and fill/stroke colors) are applied to my polygons, but not
to the ModifyFeature vertices.
var defaultStyle = new OpenLayers.Style({
fillOpacity: 0.5,
strokeOpacity: 0.8,
strokeWidth: 4,
pointRadius: 6,
fontColor: "#000000",
fontSize: "24px",
fontFamily: "Courier New, monospace",
fontWeight: "bold"
});
var rules = [
new OpenLayers.Rule({
filter: new OpenLayers.Filter.Comparison({
type: OpenLayers.Filter.Comparison.NOT_EQUAL_TO,
property: "name",
value: undefined
}),
symbolizer: {
label: "${name}",
fillColor: "${color}",
strokeColor: "${color}"
},
elseFilter: false
}),
new OpenLayers.Rule({
symbolizer: {},
elseFilter: true
})
];
defaultStyle.addRules( rules );
When the Rule is applied to any geometry without attributes,
OpenLayers.Filter.Comparison.evaluate receives an empty object {} as a
context. {}['name'] is undefined, so the NOT_EQUAL_TO condition fails
and the attribute-based styling is not applied.
I tried a few other approaches to solving this problem, but I couldn't
find any others which didn't involve hacking OpenLayers itself. Your
suggested modification of
OpenLayers.Control.ModifyFeature.collectVertices did work as hoped
for. I also whipped up an OpenLayers.Filter.Callback class which let
me supply a callback function to decide whether or not to apply
styling. I may submit that as a patch, as it seems like it would
enable many kinds of complex styling.
Thanks again for your help!
alex
_______________________________________________
Users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/openlayers-users
