syncpoint
Layer concept
Technically a layer, group or context can be represented using a tag as an attribute of an object. So all objects tagged with the same value, belong to the same layer or group. Maybe typed tags are useful, so that one object can only belong to one layer or group. On the flip side using such typed tags, it's not possible to group already grouped elements and build so a tree like structure.
The representation in the user interface can be different. A group of objects can be represented as tree or list like interface or something else, with the option to filter the structure using tag names.
We need an easy to understand concept which feature layer is currently 'active'. Meaning, which layer will receive edits and new features. While editing in principle is possible for all layers at the same time, adding a new feature must target one specific layer.
On the high level, I see two approaches:
- A fixed set of typed layers implicitly determines which features can be added where
- Choosing target/active layer is delegated to the user
While being less flexible, I lean towards the first approach. I think flexibility and complexity are pretty tightly linked here. So probably a valid question is, how much complexity we want to expose to the user. We should discuss this, find pros and cons for each method.
Well, I think it might be hard to understand for users which (typed) layer receives which features. Also finding possibly complex rules for 'feature routing' can become challenging. I prefer 'Choosing target/active layer is delegated to the user' because it is both easy to understand and easy to implement.
@ThomasHalwax With 'routing' you mean choosing the correct layer for any feature to add?
Layers for sure is an easy to understand concept for creative people working with raster/vector graphics programs. In this context layers are a ubiquitous concept known for decades. But how much of this idea do we have to expose to C2IS users? Yes, we always will have a (base) map layer, possibly multiple (transparent) overlays with additional geographic/METOC information. But those are read-only and cannot be modified.
Maybe we should step back a little and ask what the purpose of tactical layers would be?
Proposal (implementation level)
- Features are no longer stored in layers, but in documents.
- A tagging system is used to group/categorize features inside a document.
- Grouping can be implicit, e.g. derived from feature properties.
- User can explicitly group features by assigning system or user-defined tags.
- Tags may have an optional type, e.g. 'tactical overlay'.
- Business rules can limit/define possible feature/tag relationships.
This is just a rough idea, but should provide great flexibility for designing the application UI. For example
- If we do want the user to assign a feature to exactly one 'tactical layer', she has to choose or create one before adding features to the document.
- Features are exported as another document with optional tags filters applied.
- Features are imported from other documents with optional tags filters applied.
- Features can be exported as a single named layer (GeoJSON).
- Features can be imported from layers (GeoJSON).