GIS   MapServer   PostGIS   SDI   Training   Web GIS

Long Description of Thuban Feature Requests

Feature: Proportionate Circle Symbols

Request (in 2004): Extend Thuban with the ability to correlate the symbol size (diameter as well as area) to a field. For the area this means that the diamter should be proportionate to the square root of the variable value.

Implementation plan:

• extend GUI to allow for specification of symbol sizes (2h)
• Size Attribute for ClassGroupProperties (2h)
• extend .thuban format to allow storing/loading the new point symbol feature (4h)
• extend renderer to draw symbols of different sizes (1h)

Costs: 1.000 Euro net.
Interested requestors: 1

Feature: Handling Simple Symbols in Thuban

Request (in 2004): Extend Thuban with simple vector symbols for point data. It must be possible to have triangles, squares, diamonds etc.

Implementation plan:

Thuban's support for symbols is very simple currently. There's only one type of symbol, a circle of a fixed size. The fill and stroke can be changed with classifications. Below is an outline of a way to extend this to very simple symbols with other shapes than circles but whose colors are still determined like the fill and stroke of the circles now.

Thuban comes with a set of predefined symbols in Resources/Symbols. Each symbol is an SVG file containing one group with a non-zero number of children. Children may only be paths which only use a small subset of the capabilities of SVG's paths, e.g. only M and L commands. It might be worthwhile for the convenience of users creating symbols files by hand to also support circles, rectangles, polygons and other more specialized SVG-elements.
The symbols are used only for the paths. Styling attributes are not allowed. The styling used is determined by the Thuban classification just like it is for the circles now. In fact the circles are effecively a special case (and thus it might be good to support circle elements in the SVG from the start). A future extension could be to allow styling attributes but to ignore them when the classification defines fills or strokes and to draw the symbols in their original colors otherwise.

The size of the symbols is determined as follows. The symbol will be scaled uniformly to fit into the unit square. When drawn by a renderer it will be scaled to a size more suitable for output. For compatibility with the current Thuban versions, this means that they're scaled to 10 pixels the screen and 10pt for postscript output (the radius of the circles is currently 5 units).

The user may put user specific symbols into a user specific directory, perhaps ~/.thuban/symbols.

.thuban files:

How should symbols be handled in .thuban files? In general there are two approaches.

1. The symbols are identified by their name.
   This means there would have to be a predefined set of symbols that could never be changed in future thuban versions. User defined symbols would only be known at some installations and thus .thuban files may not load correctly when they are transferred from one installation to aother.
2. The symbol definition could be saved to the .thuban files.

   This would be similar to how e.g. dashes and arrows are handled in Skencil files. The symbols would be stored effectively in their svg representation. The precise details would have to be worked out.

   The main advantage is that .thuban remain as portable as they currently are.

   The symbols are written to the .thuban files near the start of the file before any map. Each symbols has an id that identifies the symbol withing the .thuban file. Classifications simply reference the id of the shape they use, much like layers reference shapestores. Obviously the cldata element needs a new attribute, "symbol".

Symbols are objects containing a hierarchy of graphical shapes. At first this is just a list of path and maybe other object types for circles and other primitives.

Rendering:

All renderers would have to be extended. A good way would be to extend the BaseRenderer class with a generic method that draws a shape onto a DC. All the derived classes would have to do is to make sure that that method is called. How a shape is drawn to the DC is, from the derived renderers' point of a view an implementation detail.

Tasks and efforts:

• Implement symbol objects. This includes:
  - class Symbol
  - class Path
  - class Circle
  (6h)
• Implement symbol library.
  Essentially an object representing a collection of Symbol objects.
  (2h)
• Implement SVG loading.
  Only a few elements are needed and we can borrow some code from Skencil. We need to search a few directories and load all symbol files we find into a symbol library.
  (4h)
• Extend the renderers
  The baserenderer renders a symbol on a DC. Only polygons and circles with fixed brush and pen. Derived renderers need to be extended accordingly but they can just delegate to the base renderer.
  (4h)
• Symbol Attribute for ClassGroupProperties
  Add the symbol as an attribute to the ClassGroupProperties instances. (4h)
• Save/Load .thuban files
  The symbols themselves and the classifications need to be written to and read from .thuban files.
  (6h)
• GUI for Classification symbol
  SelectPropertiesDialog has to be extended to let the user select the symbol from a list of symbols. Subtasks:
  - list of symbols (4h)
  - symbol preview widget/image (2h)
  - SelectPropertiesDialog (2h)
  

Costs: 4.000 Euro net.
Interested requestors: 1