[OpenLayers-Dev] Problem with the developpement of a "overlay Strategy"

[Eric Lemoine]

Good suggestion. I erroneously thought graphicZIndex was for external
graphics only. Good to know :-) Eric

2008/10/28, Tim Schaub <tschaub at opengeo.org>:
> Hey-
>
> Jerome Freyre wrote:
>> Hi everybody,
>>
>> Currently I am trying to developp a new strategy (based on
>> OpenLayers.Strategy.Cluster) that can modify the order of features (bigger
>> features go downer and small one go higher) to display features with
>> correct
>> "overlay" or "superposition".
>>
>> To do that, I found that I have to order my features.
>>
>> Actually, I am loading my features with HTTP protocol (see:
>> http://www.nabble.com/Problem-with-Protocol-HTTP-and-vector-layer-tt20088456.html
>> ;) ).
>>
>> My "sort algorithm" seems to work because it is ordering features based on
>> the "overlayAttribute".
>>
>> The problem appears when I select a feature that is "downer". When I
>> unselect it, the feature goes "higher" than the smaller one and stays like
>> this.
>
> Sounds like this could be accomplished with rule based styling.
>
> You could set the graphicZIndex property of a symbolizer based on your
> feature attributes.
>
> See the ordering example for use of graphicZIndex.
> http://openlayers.org/dev/examples/ordering.html
>
> See the StyleMap example for use of rule based styling.
> http://openlayers.org/dev/examples/stylemap.html
>
> For a convenience method to deal with unique value rules, see the unique
> styles example.
> http://openlayers.org/dev/examples/styles-unique.html
>
> And, if a 1:1 mapping between attribute values and z-index doesn't work
> for you, you might be able to use the context based symbolizer evaluation.
> http://openlayers.org/dev/examples/styles-context.html
>
> Finally, if you do need to sort your features, your strategy should set
> the graphicZIndex property.
>
> Tim
>
>>
>> Has somebody got an idea to resolve this problem?
>>
>> My strategy function :
>> ============================================
>>         if(this.features.length >= 2) {
>>
>> 			var tempArray = this.features;
>> 			//alert('count = ' + this.features.length);
>> 			for (var i=0; i<this.features.length; i++) {	
>> 				for(var j=this.features.length-1; j>i;j--) {
>> 					//alert('Comparaison de ' +
>> this.features[j].attributes[this.overlayAttribute] + ' et ' +
>> this.features[j-1].attributes[this.overlayAttribute]);
>> 					if (parseInt(this.features[j].attributes[this.overlayAttribute]) >
>> parseInt(this.features[j-1].attributes[this.overlayAttribute])) {
>> 						var tmp = this.features[j];
>> 						this.features[j] = this.features[j-1];
>> 						this.features[j-1] = tmp;
>> 					}
>> 				}
>> 			}
>> 		}
>>
>> 		alert('count = ' + this.features.length);
>> 		var attr = "";
>> 		for(var i=0; i<this.features.length; ++i) {
>> 			attr += this.features[i].attributes[this.overlayAttribute] + ' \\ ';
>> 		}
>>
>> 	if(this.features.length > 0) {
>>                  this.clustering = true;
>>                  // A legitimate feature addition could occur during this
>>                  // addFeatures call.  For clustering to behave well,
>> features
>>                  // should be removed from a layer before requesting a new
>> batch.
>> 				 this.layer.removeFeatures();
>>                  this.layer.addFeatures(this.features);
>>                  this.clustering = false;
>>              }
>> ============================================
>>
>
>
> --
> Tim Schaub
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>