Allow specification of per-entry icons for RSS feeds

Note: the ticket link in the above description should be to #1064, not 1604.

Replying to ianmayo:

[this ticket is transposed from comments at the tail of #1604] Is there any merit in adding processing for the "category" attribute of each entry? OpenLayers could then plot an icon representing that type of event. For instance, if we had fall, camp_out and puncture category values for entries in a georss feed representing an off-road-biking journey we could show fall.png, camp_out.png and puncture.png icons at those locations.

I do not like the idea of wiring a category to a filename directly, because at the time you provide an image for a specific category, you can also provide a lookup entry in a table or something similar for it.

Alternatively an implementation could choose to use a lookup table of category versus image to use.

This seems like a better solution, although I would not limit it to the "category" attribute. Has anyone thought about offering an alternative to OpenLayers.Layer.GeoRSS using OpenLayers.Layer.Vector instead of OpenLayers.Layer.Markers? In Mapbuilder, we transform GeoRSS to GML and apply it to a vector layer. By doing so, we can also display line and polygon geometries in GeoRSS layers.

Ok, assuming our GeoRSS layer is a vector layer: we have our category in OpenLayers.Feature.attributes['category'], and we could use the style/rule framework I created for sld rendering (sandbox/ahocevar/sldRenderer). That would provide a kind of lookup table for use cases like the above, even without sld:

// style to be applied to any layer that inherits from OpenLayers.Layer.Vector
var style = new OpenLayers.Style();

var rule = new OpenLayers.Rule.Comparison({
        type: OpenLayers.Rule.Comparison.Type.EQUAL_TO,
        property: 'category'});

style.rules.push(OpenLayers.Util.extend({
       value: 'fall',
       symbolizer['point']}: {externalGraphic: 'fall.png'}}, rule));

style.rules.push(OpenLayers.Util.extend({
       value: 'camp_out',
       symbolizer['point']}: {externalGraphic: 'camp_out.png'}}, rule));

style.rules.push(OpenLayers.Util.extend({
       value: 'puncture',
       symbolizer['point']}: {externalGraphic: 'puncture.png'}}, rule));

Ok, I kept thinking about the usefulness of the style and rule framework, and here I am finally with a patch, incremental to http://trac.openlayers.org/ticket/533. It makes minor changes to three classes:

* OpenLayers.Layer.GeoRSS: new style property which will be passed to the marker, if set. Also parses the "category" tag in RSS 2

* OpenLayers.Marker: new feature and style properties. Both will be destroyed in the destroy method, to avoid memory leaks by the circular reference between feature and marker. Also, if the style property is set, it will be parsed and the marker icon will be set to the externalGraphic property of the style.

* OpenLayers.Feature: adds a reference to itself in the createMarker method. So now the marker knows about its feature, like geometries already do.

I also modified the georss.html example to show the new feature, by using the newly added georss-category.xml example feed.

Great work Andreas. I implemented a lookup utility class a few weeks ago as part of the implementation - and was in the process of submitting it as a new ticket when I chanced upon your progress.

Your strategy is more consistent with other OpenLayers code (since you wrote the sld code....). I won't submit my lookup-based IconFactory class.

In advance of our code getting incorporated into the Trunk, I'd like to start using it. Unfortunately your patch refers to changed files using an absolute path reference that's specific to your file-system. Would you be able to reproduce the patch file using relative references?

[I'm sure that would also ease the incorporation of the patch into the trunk].

Incremental patch to the patch proposed in #533; adds styling functionality to markers and uses it in the GeoRSS layer class to style items differently according to their category property.

Replying to ianmayo:

In advance of our code getting incorporated into the Trunk, I'd like to start using it. Unfortunately your patch refers to changed files using an absolute path reference that's specific to your file-system. Would you be able to reproduce the patch file using relative references?

I uploaded a new version with relative paths. Just FYI, you can also apply a patch with absolute paths by saying eg.

patch -p6 < foo.patch

where the number following the -p is the number of path segments to ignore.

There has been further development on this issue; because it is closely related to rule-based styling (sldRenderer), there is no separate patch any more. Please see http://trac.openlayers.org/ticket/533#comment:6 for a complete patch and more details.

The rule based rendering is now committed, but the way that we parse RSS feeds for the GeoRSS layer has changed as well. As a result, the parsing code that is currently in Layer.GeoRSS in this patch should be modified to apply to Format.GeoRSS instead -- and indeed, I think that the right path is probably to modify Format.GeoRSS to parse *all* additional attributes on request, like the GML Format does, using OpenLayers.Format.GML.prototype.parseAttributes(item_node) and then overriding title, description, and link with the values from the current parsing mechanism (to maintain backwards compatibility).

Bumping from review for now, until we get a chance to rewrite this to do something like the above.

Mass ticket move to 2.7 post dev meeting. If you are actively working on this task, please update this ticket with information and change the milestone to 2.6. At the time of the next IRC meeting (most likely 1-31-08), this will mean the ticket can *not* be brought back into 2.6 unless there is further feedback.