Modify

Opened 2 years ago

Last modified 12 months ago

#12872 new enhancement

Allow hierarchical layers

Reported by: michael2402 Owned by: team
Priority: major Milestone:
Component: Core Version:
Keywords: hierarchical layer Cc: Don-vip, bastiK, stoecker

Description

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.

Attachments (1)

layers-sublayers.png (13.6 KB) - added by michael2402 2 years ago.

Download all attachments as: .zip

Change History (12)

Changed 2 years ago by michael2402

Attachment: layers-sublayers.png added

comment:1 Changed 2 years ago by stoecker

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

comment:2 in reply to:  description ; Changed 2 years ago by 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.

comment:3 in reply to:  2 ; Changed 2 years ago by 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.

comment:4 in reply to:  3 Changed 2 years ago by 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 ...

comment:5 Changed 2 years ago by 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.

comment:6 in reply to:  5 ; Changed 2 years ago by 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.

comment:7 in reply to:  6 Changed 2 years ago by 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.

comment:8 Changed 2 years ago by 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.

Last edited 2 years ago by michael2402 (previous) (diff)

comment:9 Changed 12 months ago by Don-vip

Keywords: gsoc-core removed

comment:10 Changed 12 months ago by Don-vip

Keywords: hierarchical layer added
Priority: normalmajor
Summary: Allow hirarchical layersAllow hierarchical layers

comment:11 Changed 12 months ago by Don-vip

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to michael2402
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.