Removal of ol.FeatureOverlay #3758

ahocevar · 2015-06-03T10:38:12Z

With an option to disable the spatial index of ol.source.Vector, and a map option for ol.layer.Layer to render on top of other layers without adding it to the map's layers collection, and a way to manage features of an ol.source.Vector in an ol.Collection, we can get rid of ol.FeatureOverlay.

This simplifies code in many places, and it also improves date line handling, which was not possible with ol.FeatureOverlay.

Fixes #3704.
Fixes #2386.

probins · 2015-06-03T11:28:03Z

externs/olx.js

+ * Sets the layer as overlay on a map. The map will not manage this layer in its
+ * layers collection, and the layer will be rendered on top. This is useful for
+ * temporary layers. The standard way to add a layer to a map and have it
+ * managed by the map is use {@link ol.Map#addLayer}.


probins · 2015-06-03T11:41:40Z

a quick comment. As mentioned in #3737, a featureoverlay isn't needed in several of the examples if the select interaction is used instead; this also simplifies those examples. #3757 enables that, so it might be better to merge #3757 and change those examples first. Then they would no longer need to be changed in this PR. ISTM this would be better than changing them here, and then changing them again as and when #3757 is merged.

elemoine · 2015-06-03T12:01:25Z

src/ol/source/vectorsource.js

+ */
+ol.source.Vector.prototype.bindFeaturesCollection_ = function(collection) {
+  goog.asserts.assert(goog.isNull(this.featuresCollection_),
+      'bindFeatuesCollection can only be called once');


bartvde · 2015-06-09T10:40:05Z

externs/olx.js

@@ -2471,6 +2472,14 @@ olx.interaction.DrawOptions.prototype.freehandCondition;


 /**
+ * Wrap the world horizontaly on the sketch overlay. Default is `false`.
+ * @type {boolean|undefined}


horizontaly -> horizontally

bartvde · 2015-06-09T11:26:41Z

I have 2 remaining questions which might be addressed simply by docs:

how does someone remove an unmanaged layer? setMap(null) ?
how is z-index managed if you have more than 1 layer unmanaged?

Since I'm not too familiar with the renderer code, it might be good to have someone more knowledgeable wrt the renderer code look specifically at the rendering changes as well. But I'll leave the call up to you @ahocevar

ahocevar · 2015-06-09T12:15:43Z

@bartvde:

how does someone remove an unmanaged layer? setMap(null) ?

Exactly. I added this information to the API docs, and also added a unit test to verify that it works properly.

how is z-index managed if you have more than 1 layer unmanaged?

This is indeed the only breaking change after the removal of ol.FeatureOverlay. All feature overlays shared a single replay group, so zIndex was effectively stacked per map. All vector layers, even when unmanaged, are separate, so each layer stacks zIndex separately. I added this information to the upgrade notes.

probins · 2015-06-09T12:47:58Z

externs/olx.js

+ * When set to `false`, the features will be maintained in an
+ * {@link ol.Collection}, which can be retrieved through
+ * {@link ol.source.Vector#getFeaturesCollection}.
+ *


I would add that the spatial queries for extent/coordinate only work if set to true

probins · 2015-06-09T12:54:29Z

There's another change that I think should be mentioned in the release notes: if you were using a FO getFeatures returned a collection whereas in source.Vector it returns an array. Apps will have to take this into account. I have always found this a bit confusing. interaction.Select returns a collection too. IMO it would be better if this was consistent, though as these are marked as stable, perhaps it's too late to change.

ol.layer.Vector can now manage both an RTree and a Collection of features. The new useSpatialIndex option allows to opt out of RTree management, and the new ol.Collection type of the features option allows to opt in for Collection management.

When a layer is configured with a map, it will be added on top of other layers, and not be managed in the map's features collection. The layerState will have an 'unmanaged' flag for such layers. For vector layers, this flag is used to not skip any features.

This also introduces a wrapX option to the Draw, Modify and Select interaction.

ahocevar · 2015-06-09T13:48:55Z

@probins:

There's another change that I think should be mentioned in the release notes: if you were using a FO getFeatures returned a collection whereas in source.Vector it returns an array. Apps will have to take this into account. I have always found this a bit confusing. interaction.Select returns a collection too. IMO it would be better if this was consistent, though as these are marked as stable, perhaps it's too late to change.

I added that to the upgrade notes. You're right, it would be more consistent to use getFeatures wherever an array is returned, and getFeaturesCollection when a collection is returned. But since getFeatures is marked stable with different return types on ol.interaction.Select and ol.source.Vector, we have to live with this inconsistency for now.

ahocevar · 2015-06-10T12:25:44Z

@bartvde:

Since I'm not too familiar with the renderer code, it might be good to have someone more knowledgeable wrt the renderer code look specifically at the rendering changes as well. But I'll leave the call up to you

The only change to renderer code is the removal of the map replay group, which was only used by ol.FeatureOverlay. Do you feel comfortable reviewing this, just to verify that I did not remove more or less than necessary. I'm adding an upgrade note about the removed replay as well.

Edit: this replayGroup was never exposed to the API, so there is no need to mention it in the upgrade notes.

bartvde · 2015-06-10T12:30:42Z

I did review it @ahocevar and it looked good to me.

ahocevar · 2015-06-10T12:32:40Z

Thanks @bartvde. Is this good to merge?

bartvde · 2015-06-10T12:33:10Z

LGTM

Removal of ol.FeatureOverlay

elemoine · 2015-06-11T07:42:00Z

Shouldn't unmanaged be added to ol.layer.State?

ahocevar · 2015-06-11T07:43:21Z

Good call @elemoine. I'll create a pull request.

ahocevar · 2015-06-11T07:46:32Z

See #3787 @elemoine

elemoine · 2015-06-11T07:48:07Z

Quick note: proviously, all the feature overlays attached to a map were equal from the "feature render order" point of view. It's not the case with "umanaged" vector layers. "Unmanaged" vector layers are ordered: the features of the first "unmanaged" vector layer will be drawn below the features of the second "unmanaged" vector layer, etc.

ahocevar · 2015-06-11T07:50:06Z

@elemoine True. I mentioned that in the upgrade notes.

bartvde · 2015-06-11T07:50:59Z

@elemoine do you know of a use case where this will be problematic? We couldn't think of one.

elemoine · 2015-06-11T07:52:45Z

@elemoine do you know of a use case where this will be problematic? We couldn't think of one.

The problem is related to components that create vector layers internally (e.g. select interaction).

tschaub · 2015-06-12T05:19:58Z

WOW

elemoine · 2015-06-15T14:08:53Z

The problem is related to components that create vector layers internally (e.g. select interaction).

In our application we have independent components, each using a FeatureOverlay with a specific style. The components could share an "unmanaged" vector layer, but I wonder how we can make the components use specific styles. We'll probably need to use per-feature styles, which will make our code messier.

ahocevar · 2015-06-15T14:35:18Z

@elemoine As long as your styles don't use zIndex, there should not be a difference between unmanaged vector layers and feature overlays. If you rely on zIndex, you could also leverage an index for distinct feature groups. Assuming you had

var overlay1 = new ol.FeatureOverlay({
  style: /* ... */
});
var overlay2 = new ol.FeatureOverlay({
  style: /* ... */
});

overlay1.addFeature(feature1);
overlay2.addFeature(feature2);

you could now do something like

var layer = new ol.source.Vector({
  source: new ol.source.Vector(),
  style: /* ... */
});
featuresIndex = [{}, {}];
function addFeature(feature, index) {
  layer.getSource().addFeature(feature);
  featuresIndex[index][goog.getUid(feature)] = feature;
}
function removeFeature(feature, index) {
  layer.getSource().removeFeature(feature);
  featuresIndex[index][goog.getUid(feature)] = undefined;
}

addFeature(feature1, 0);
addFeature(feature2, 1);

In the styleFunction you just check for the feature whether it is in featuresIndex[0] or featuresIndex[2], and style it appropriately.

elemoine · 2015-06-15T14:51:37Z

As I said, currently, each component has its own FeatureOverlay and its own style. The components are independent and don't know about each other. It looks to me that, in the code you provided, the code that creates the shared vector layer knows the number of components, and it should know how each component wants to style its features. So, at this point, I honestly don't think this represents a good solution to my problem.

elemoine · 2015-06-15T15:06:35Z

Maybe I can build an API/abstraction around your "index" idea. Any consumer of that API would first ask the API for an identifier or something. It will then use that identifier in subsequent operations like setStyle, addFeature, removeFeature and clear. That may work. Maybe that's what you had in mind.

ahocevar · 2015-06-15T15:37:12Z

That sounds good @elemoine, much smarter than the app level solution I suggested above. Thanks!

probins · 2015-06-18T16:29:54Z

There's a difference in display behaviour with this change. If you go to http://openlayers.org/en/master/examples/select-features.html and select the hover option, there's an annoying flickering as the cursor passes over the features. This doesn't occur with http://openlayers.org/en/v3.6.0/examples/select-features.html
Is it constantly adding/removing the feature from the selection layer?

ahocevar · 2015-06-18T16:32:49Z

This is a bug. Thanks for reporting @probins. I'll create a separate ticket for that.

ahocevar force-pushed the remove-featureoverlay branch 3 times, most recently from c163fcf to f1679ff Compare June 3, 2015 11:13

probins reviewed Jun 3, 2015
View reviewed changes

elemoine reviewed Jun 3, 2015
View reviewed changes

ahocevar force-pushed the remove-featureoverlay branch from f1679ff to ded64fe Compare June 3, 2015 12:28

probins mentioned this pull request Jun 5, 2015

Standardise draw/modify descriptions #3763

Merged

bartvde reviewed Jun 9, 2015
View reviewed changes

ahocevar force-pushed the remove-featureoverlay branch from ded64fe to 512523f Compare June 9, 2015 11:26

ahocevar force-pushed the remove-featureoverlay branch from 512523f to 827f82a Compare June 9, 2015 11:30

probins reviewed Jun 9, 2015
View reviewed changes

ahocevar added 5 commits June 9, 2015 15:44

Get rid of ol.FeatureOverlay

53d5d8c

This also introduces a wrapX option to the Draw, Modify and Select interaction.

Make sure that #clear() keeps the collection in sync

57e1dda

Make clear how to remove an unmanaged layer from a map

9acd652

ahocevar force-pushed the remove-featureoverlay branch from 025f383 to 9acd652 Compare June 9, 2015 13:44

ahocevar added a commit that referenced this pull request Jun 10, 2015

Merge pull request #3758 from ahocevar/remove-featureoverlay

fad3cf9

Removal of ol.FeatureOverlay

ahocevar merged commit fad3cf9 into openlayers:master Jun 10, 2015

ahocevar deleted the remove-featureoverlay branch June 10, 2015 12:33

elemoine mentioned this pull request Jun 11, 2015

ol.FeatureOverlay removal camptocamp/ngeo#236

Closed

marcjansen mentioned this pull request Jun 11, 2015

Remove docs referring to removed feature overlay #3791

Merged

tschaub mentioned this pull request Jun 12, 2015

Add 'unmanaged' to ol.layer.LayerState #3787

Merged

ahocevar mentioned this pull request Jun 18, 2015

Hover selection causes features to flicker #3819

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Removal of ol.FeatureOverlay #3758

Removal of ol.FeatureOverlay #3758

ahocevar commented Jun 3, 2015

probins Jun 3, 2015

probins commented Jun 3, 2015

elemoine Jun 3, 2015

bartvde Jun 9, 2015

bartvde commented Jun 9, 2015

ahocevar commented Jun 9, 2015

probins Jun 9, 2015

ahocevar Jun 9, 2015

probins commented Jun 9, 2015

ahocevar commented Jun 9, 2015

ahocevar commented Jun 10, 2015

bartvde commented Jun 10, 2015

ahocevar commented Jun 10, 2015

bartvde commented Jun 10, 2015

elemoine commented Jun 11, 2015

ahocevar commented Jun 11, 2015

ahocevar commented Jun 11, 2015

elemoine commented Jun 11, 2015

ahocevar commented Jun 11, 2015

bartvde commented Jun 11, 2015

elemoine commented Jun 11, 2015

tschaub commented Jun 12, 2015

elemoine commented Jun 15, 2015

ahocevar commented Jun 15, 2015

elemoine commented Jun 15, 2015

elemoine commented Jun 15, 2015

ahocevar commented Jun 15, 2015

probins commented Jun 18, 2015

ahocevar commented Jun 18, 2015

Removal of ol.FeatureOverlay #3758

Removal of ol.FeatureOverlay #3758

Conversation

ahocevar commented Jun 3, 2015

probins Jun 3, 2015

Choose a reason for hiding this comment

probins commented Jun 3, 2015

elemoine Jun 3, 2015

Choose a reason for hiding this comment

bartvde Jun 9, 2015

Choose a reason for hiding this comment

bartvde commented Jun 9, 2015

ahocevar commented Jun 9, 2015

probins Jun 9, 2015

Choose a reason for hiding this comment

ahocevar Jun 9, 2015

Choose a reason for hiding this comment

probins commented Jun 9, 2015

ahocevar commented Jun 9, 2015

ahocevar commented Jun 10, 2015

bartvde commented Jun 10, 2015

ahocevar commented Jun 10, 2015

bartvde commented Jun 10, 2015

elemoine commented Jun 11, 2015

ahocevar commented Jun 11, 2015

ahocevar commented Jun 11, 2015

elemoine commented Jun 11, 2015

ahocevar commented Jun 11, 2015

bartvde commented Jun 11, 2015

elemoine commented Jun 11, 2015

tschaub commented Jun 12, 2015

elemoine commented Jun 15, 2015

ahocevar commented Jun 15, 2015

elemoine commented Jun 15, 2015

elemoine commented Jun 15, 2015

ahocevar commented Jun 15, 2015

probins commented Jun 18, 2015

ahocevar commented Jun 18, 2015