Allow hierarchical layers

[michael2402]

Currently, JOSM uses one global layer list.

There are many layers that depend on other layers (validator results, audio tracks along GPX, ...).

I suggest to split the layers in different types:

• Main layers that represent a single data type. Those are the OSM layers, GPX tracks, background imagery, ...
• Sublayers that depend on one of those layers

Only main layers can be active layers.

I would suggest the following sublayers:

• Validator results as single sublayer of OSM layers
• Audio layer as sublayer of GPX layer

I want to render the sub layers independendly from the parent layer and directly above the parent layer. The visibility setting is independent for the parent/child layer (we can e.g. add an interit checkbox there).

The problems I see:

• Merging of e.g. audio layers from different tracks will not be possible any more (does anyone use this)
• You cannot sort the sublayers to be on top of other main layers. This won't be a problem for the validator, since the active edit layer is always drawn on top.
• The audio playback assumes there can be an active audio layer (although I probably need to rewrite part of this to make the PlayHeadMarker a temporary layer)

This is only a rough draft so feel free to provide feedback and state if this is a desired feature or if it reduces usability.

[stoecker]

I can see advantages of this idea. OTOH it makes it more complex for the users.

[bastiK]

Replying to michael2402:

There are many layers that depend on other layers (validator results, audio tracks along GPX, ...).

Can you give more examples? My impression is that this feature would have fairly limited scope as most layer types are independent.

[michael2402]

Replying to bastiK:

Replying to michael2402:

There are many layers that depend on other layers (validator results, audio tracks along GPX, ...).

Can you give more examples? My impression is that this feature would have fairly limited scope as most layer types are independent.

I searched through more code and there only seem to be more temporary layers (map mode, ...). Those are the only two that are currently explicit layers in JOSM.

We might add support for more of these in the future: We can e.g. add a "Hidden objects" layer to a data layer to show the data that was hidden (layer is simply hidden on default). We can e.g. add a waypoints layer as child of the GPX layer to allow for easy hiding (and opacity change) of the waypoints.

But you are right, this feature would not be needed often, this is why I asked.

[bastiK]

Replying to michael2402:

We might add support for more of these in the future: We can e.g. add a "Hidden objects" layer to a data layer to show the data that was hidden (layer is simply hidden on default).

This would allow different filters for different osm-data layers. In addition, we could save the filters in a session file and reload them without messing with a global list of (active and inactive) filter presets.

We can e.g. add a waypoints layer as child of the GPX layer to allow for easy hiding (and opacity change) of the waypoints.

It is certainly awkward that two layers are created when you open one file. This could be improved by grouping the layers. However, then both traces and waypoints should be treated on equal footing (compare ​layer groups in Photoshop).

But you are right, this feature would not be needed often, this is why I asked.

Overall, I feel that it would be a large investment (development, maintenance, added complexity for users) for little gain. But still an improvement, so if you are determined, why not ...

[wiktorn]

I can see an use case for this with WMS layers. I could use the hierarchical structure so user may choose, which layers she/he wants to have visible, and which not.

[stoecker]

Replying to wiktorn:

I can see an use case for this with WMS layers. I could use the hierarchical structure so user may choose, which layers she/he wants to have visible, and which not.

Please explain.

[wiktorn]

Replying to stoecker:

Replying to wiktorn:

I can see an use case for this with WMS layers. I could use the hierarchical structure so user may choose, which layers she/he wants to have visible, and which not.

Please explain.

I rather think about this as an interaction design - not multiple class instances. I have some WIP that makes wms_endpoint imagery sources just as good as current wms. Then - if we are actually working with WMS service that has many layers, I could use this scheme to allow change of layers, that are shown, as we will have the list of the layers from GetCapabilities document.

[michael2402]

My current idea is to use the LayerManager for this. Every layer has such a managed list of sub-layers.

I would add the following method to the Layer class:

    /**
     * Returns a LayerManager that represents the sublayers of this layer. You can normally not add any sublayers directly to the list but this layer will provide methods to add supported sublayers.
     * @return The layer manager.
     */
    public LayerManager getSubLayers() {
        if (layerManager == null) // better in constructor:
            layerManager = createSubLayerManager();
        return layerManager;
    }

    /**
     * Create the {@link LayerManager} object to be used for sublayers. Called once after layer construction.
     *
     * @return A LayerManager instance. You may use your own implementation.
     */
    protected LayerManager createSubLayerManager() {
        return new LayerManager();
    }

The sub-layers can then be reordered using the normal move operation.

The LayerList collects all layers and sublayers and keeps track of the hierarchy depth to display the padding. The LayerList needs to keep track of the LayerManager used for the item to send the move/remove operation to. We can add canRemove()/canMove() methods to the layer manger to make it generic. I don't really see the need to be able to collapse items for now, but it would be relatively easy to convert the list to a tree.

[Don-vip]

Ticket #14266 has been marked as a duplicate of this ticket.