Opened 8 years ago
Last modified 8 years 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)
Change History (12)
by , 8 years ago
Attachment: | layers-sublayers.png added |
---|
comment:1 by , 8 years ago
follow-up: 3 comment:2 by , 8 years ago
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.
follow-up: 4 comment:3 by , 8 years ago
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 by , 8 years ago
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 ...
follow-up: 6 comment:5 by , 8 years ago
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.
follow-up: 7 comment:6 by , 8 years ago
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 by , 8 years ago
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 by , 8 years ago
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.
comment:9 by , 8 years ago
Keywords: | gsoc-core removed |
---|
comment:10 by , 8 years ago
Keywords: | hierarchical layer added |
---|---|
Priority: | normal → major |
Summary: | Allow hirarchical layers → Allow hierarchical layers |
I can see advantages of this idea. OTOH it makes it more complex for the users.