Layer configuration

[steff-o]

Closes #9

Adds the possibility to configure which layers should be available for selection. By explicitly configure a layer for selection it will select features from that layer even if it is not visible. It is possible to add several different sets of layers. If there are more than one set of layers there will be a settings button where it is possible to select which configuration that should be active. If no configuration exists, the default behavior is like before. It is also possible to add the default behavior to be one of the selectable configurations.

For documentation on how to configure this feature see readme.md in this branch.

Some bonus changes introduced in this PR:

• Upgraded turf/buffer to get rid of a bug that projects the buffer incorrectly, which specifically made the buffer smaller the further north it is.
• Refactored code regarding buttons to make use of the buttons array instead of do almost the same on each instance
• Refactored code to avoid implement the actual feature selection in every interaction eventhandler.
• Rewrote buffer modal to use a form in order to make ok button work with keyboard.
• Added feature highlight, row highlight and mouse pointer in feature selector modal.
• Moved the line buffering to before the bounding box was created in order to avoid the border case when the line is horizontal or vertical and thus gets an infinitely narrow extent.
• Display the buffer area when using buffer select.
• Added some documentation to readme.md

Limitations Due to some limitations in origo core, the bbox strategy in combination with different coordinate systems will not work when explicitly configure layers.

[jokd]

@asemoller Can you test this with your setup to see if it breaks anything?

[asemoller]

Yes, of course. I'll try to test during the week!

[asemoller]

It works well in our environment and it doesn't seem to break anything. But I have some questions/inputs.

• Do you really need "const" in the example documentation? It's confusing for administrators.
• It should be clearer in the documentation that "selectedLayers" are queryable even if they're not visible.
• Is the style for buffert area configurable? It doesn't look like it's the same blue color as default origo. (it's lot of blue objects when using this tool, maybe the buffer area should have a different style...)
• I can understand the user case explained in the issue but in my opinion it's not very logical to have one behavoir for layers when using the default click and another when using multiselect tool. If a layer have "queryable": "false" in the config file it can still be queryable if you have that layer in a layerConfiguration, is this on purpose?

Other than that, the bonus changes included in this pr are really good!

I apologize for the delay, time flies!

[steff-o]

It works well in our environment and it doesn't seem to break anything. But I have some questions/inputs.

• Do you really need "const" in the example documentation? It's confusing for administrators.

I can update the configuration example to more clearly show that configuration is done in code by adding an argument to the Multiselect() call. As such I find const highly relevant as it is the appropriate variable declaration statement.

• It should be clearer in the documentation that "selectedLayers" are queryable even if they're not visible.

Agree. I will clarify that they can be selected. See further down for the term queryable.

• Is the style for buffert area configurable? It doesn't look like it's the same blue color as default origo. (it's lot of blue objects when using this tool, maybe the buffer area should have a different style...)

Agree. I will change the default symbol and make it configurable to adapt to different backgrounds.

• I can understand the user case explained in the issue but in my opinion it's not very logical to have one behavoir for layers when using the default click and another when using multiselect tool. If a layer have "queryable": "false" in the config file it can still be queryable if you have that layer in a layerConfiguration, is this on purpose?

Maybe it's a bit confusing, but yes, it is on purpose. The way I see it there is a difference between queryable and selectable. Queryable is if it is possible to click on features in a layer and get the featureinfo displayed for that feature. selectableLayers is if it possible to select features from a layer using any of the multiselect tools. As both are presented in infowindow it is in reality pretty much the same in most cases as a side effect of selecting a feature is that its featureinfo is displayed and the side effect of querying a feature is selecting it. But in this case there is a slight difference, the multiselect click-tool is not the same as featureinfo, it is a select by point tool, which fulfills the use case described in the issue: to select all features in a list of configured layers that intersects a geometry. Adding a layer to selectablelayers does not make it queryable in the featureinfo (default click) tool.

[asemoller]

Nice changes!

• Do you really need "const" in the example documentation? It's confusing for administrators.

I can update the configuration example to more clearly show that configuration is done in code by adding an argument to the Multiselect() call. As such I find const highly relevant as it is the appropriate variable declaration statement.

I initiate multiselect like this (and it works fine):

var multiselect = Multiselect({
        tools: ['click','buffer'],
        bufferSymbol: 'red',
        chooseSymbol: 'green',
        selectableLayers: [
            {
                name: 'test',
                layers: [
                    "layer_1",
                    "layer_2",
                    "layer_3"
                ]
            },
            {
                name: 'all'
            }
    ]
});

• Is the style for buffert area configurable? It doesn't look like it's the same blue color as default origo. (it's lot of blue objects when using this tool, maybe the buffer area should have a different style...)

Agree. I will change the default symbol and make it configurable to adapt to different backgrounds.

It makes sense that you added this in the tool itself but the other styles (multiSelectionStyles) are configurable in the origo config so maybe the buffer should be placed there as well? Or maybe the multiSelectionStyle should be moved to the tool. I'm not sure what's best and it works fine as is. We can handle this in another issue if we want to be consistent.

Maybe it's a bit confusing, but yes, it is on purpose. The way I see it there is a difference between queryable and selectable. Queryable is if it is possible to click on features in a layer and get the featureinfo displayed for that feature. selectableLayers is if it possible to select features from a layer using any of the multiselect tools. As both are presented in infowindow it is in reality pretty much the same in most cases as a side effect of selecting a feature is that its featureinfo is displayed and the side effect of querying a feature is selecting it. But in this case there is a slight difference, the multiselect click-tool is not the same as featureinfo, it is a select by point tool, which fulfills the use case described in the issue: to select all features in a list of configured layers that intersects a geometry. Adding a layer to selectablelayers does not make it queryable in the featureinfo (default click) tool.

I'm not entirely with you regarding this, but I'm an adminstrator and not a developer, that may be why 😄. You're problably right and you have a user case for this so just go for it!

[steff-o]

@ase Thanks for testing. I think we can merge this now as most changes are either only used by us, or backward compatible.

Regardning the multiSelectionStyles configuration in origo (core): That is most likely a remnant from the time when the multiselect plugin was a part of the core. The setting actually applies to all selections made when using infoWindow, so the name is a bit misleading. Currently a plugin can not access the active configuration by any api call. It must "manually" open the same file and find its own settings, which makes sharing configuration complicated. That is why I did something in between here: add the styles to origo config and point them out by name in multiselect configuration to make the styles reusable.

[steff-o]

@jokd Can you merge this? I think we're done.