Request for Comments-22: Vector-data support in Monteverdi
- 1 Status
- 2 Content
- 2.1 What changes will be made and why they would make a better Orfeo ToolBox?
- 2.2 When will those changes be available (target release or date)?
- 2.3 Who will be developing the proposed changes?
- 3 Community
- 4 Corresponding Requests for Changes
- Author: Stéphane ALBERT
- Submitted on 22.01.2016
- Open for comments
What changes will be made and why they would make a better Orfeo ToolBox?
The purpose of this RFC is to present and discuss integration of vector-data and underlying features in Monteverdi and OTB-Ice.
Brief code status
Vector-data files could be read using OTB and/or OGR. Vector-data files can contain several vector-data layers.
OTB-Ice provides basic vector-data rendering through the use of
Monteverdi does not provide any support of vector-data. However, this was anticipated when designing
mvd::AbstractLayerModel which is a base class of
mvd::VectorImageModel and could also be used as a base class for future
Monteverdi should be able to load and display vector-data files supported by OGR and OTB. Basically, Monteverdi may provide a way to edit basic rendering attributes of vector-data.
Monteverdi should provide a user interface to:
- load vector-data file (File/Open vector-data)
- drag-n-drop of files from filesystem etc.
- display it in the layer-stack
- move it within the layer-stack
- remove it from the layer-stack.
Monteverdi might provide an user interface to:
- select which vector-data layers (contained in vector-data file) must be loaded.
- Vector-data layers (contained in vector-data file) could be displayed as several items in Monteverdi layer-stack.
- They could be rendered in the image-view, each using their own rendering attributes (see below).
- They may be moved independently among images within the layer-stack.
OTB-Ice provides the following attributes to configure vector-data rendering:
- Fill ON/FF (if
- Border ON/OFF (if
- Line-width (if
- Point-marker size (if
These attributes could be reworked such as:
- RGBA fill color (if
Pointtype rendered as a circle)
- RGBA outline color
- outline width (if zero, outline is not rendered)
- radius/size (if
These attributes are stored in
otb::GlVectorActor. They could be moved into a separate attribute data-structure. So, they could be shared between
otb::GlVectorActor, some style data-structure, Monteverdi and/or OTB. Moreover, this data-structure could be used for sharing IO.
Adding more rendering/customizing attributes could be discussed.
Vector-data editing consists in editing the rendering attributes via the Monteverdi user interface. Such as for image information, they could be added as some more columns of the layer-stack. This solution would loose lots of (widget) screen space by displaying empty cells: vector-data attributes in image rows; image information in vector-data rows.
This point leads to discuss the design of which information (image/pixel, vector-data rendering attributes, common information) is displayed, accessed or edited via the layer-stack. Moreover, in order to keep the layer-stack extensible (and keep complexity and maintenance low), specific information should be kept aside. Especially if some more data type would need to be supported by Monteverdi in the future.
To sum up: which information is relevant to be kept in the layer-stack and which one should go into specific widgets?
More general question: does Monteverdi need a generic but more complex attribute key/value editor widget (based on
QTreeView) such as the one in Qt designer?
- Would allow to edit any data-structure easily wihout redesiging the inferface each time
- Would enhance user learning curve (less time to learn how to manipulate the widget)
- Would add some complexity to implement (vs. time saved when adding new attributes)
When will those changes be available (target release or date)?
Who will be developing the proposed changes?