Request for Comments-22: Vector-data support in Monteverdi

From OTBWiki
Jump to: navigation, search


  • 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 otb::GlVectorActor.

Monteverdi does not provide any support of vector-data. However, this was anticipated when designing mvd::StackedLayerModel containing mvd::AbstractLayerModel which is a base class of mvd::VectorImageModel and could also be used as a base class for future mvd::VectorDataModel.

Desired features
Vector-Data Support

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.
Vector-Data Rendering

OTB-Ice provides the following attributes to configure vector-data rendering:

  1. Color
  2. Alpha/Translucency
  3. Fill ON/FF (if Area type)
  4. Border ON/OFF (if Area type)
  5. Line-width (if Area or Line type)
  6. Point-marker size (if Point type)

These attributes could be reworked such as:

  1. RGBA fill color (if Area type or Point type rendered as a circle)
  2. RGBA outline color
  3. outline width (if zero, outline is not rendered)
  4. radius/size (if Point type)

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

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?

2016-01-25-qt designer-object editor.png


  • 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?





Corresponding Requests for Changes