Fix missing vector legends in grid when sorting

[chrismayer]

This ensures that the vector legends draw in a grid column won't disappear when the grid is sorted.
When updating the legend (which is triggered by sorting) now the default feature object for the given geometry type is used instead of directly passing the given feature to the renderer (fixes #266).

I guess the root cause is somewhere in the deep of our parent libraries but this will fix it. Since the FeatureRenderer class screams for a re-write (feature rendering with OpenLayers is much easier than it was in early 2015) I suggest to merge this.

I also adjusted the feature grid example to show that this also works with other geometry types than points.

Please review.

[marcjansen]

I fear this is not the right fix, even though it works for the inline example.

In an application we have, this makes things worse:

Before:

After:

with an error thrown: FeatureRenderer.js?_dc=1489651106312:452 Uncaught TypeError: me[(("get" + geom.getType(...)) + "Feature")] is not a function

Probably because the geometry is MultiPolygon?!

If I understand the diff correctly, whith ypour changes we would simply loose the possibility to use an actually passed feature for the rendering (which might make a lot of sense when you look at polygons). This is also something which is not tested right now, I fear

I will think about this a bit further… but if you come up with something, that'd be much appreciated.

[chrismayer]

Hi @marcjansen!
It seems we have several problems here:

1.) The geometry type MultiPolygon (and other MultiGeom types) doesn't seem to be supported as default geometries in the FeatureRendere yet.
2.) I was not aware that it is possible to render other geometries than the default ones with the applied style object. This is of course broken by the changes of this PR.

Handling 1.) would not be a problem. Fixing 2.) would restore the old (but broken while sorting) behavior.

EDIT: I am also not sure if we need the rendering of passed features. I never missed this.

[marcjansen]

There are even more issues, as the rendering is way too complicated with a dedicated map etc. OpenLayers has more lightweight ways of doing this...

The rendering of passed features is quite nice for polygons...

[chrismayer]

rendering is way too complicated with a dedicated map etc. OpenLayers has more lightweight ways of doing this...

That's what I meant in the PR description by

Since the FeatureRenderer class screams for a re-write (feature rendering with OpenLayers is much easier than it was in early 2015)

So, how do we proceed on this?

[marcjansen]

So, how do we proceed on this?

Good question. I think we need to keep the rendering of specific features, as this is the complete purpose of the feature renderer, we are not talking about a specific gx_featurecolumn, but we are talking about application logic (e.g. in our own examples). Maybe we find time to look at this during FOSSGIS?

[chrismayer]

I think we need to keep the rendering of specific features, as this is the complete purpose of the feature renderer,

Oh right, I mixed this up with the SymbolizerColumn. Of course we need to render features in their whole fashion.

Maybe we find time to look at this during FOSSGIS?

That's exactly what I thought. It's easier to solve this face-to-face.
BTW: I started playing around a bit with the canvas rendering context of OL in the FeatureRenderer. Looks promising, but brings other problems (of course 😉)

[marcjansen]

Is the original issue still present? if so, we should have a chat about this anytime soon.