During my grduation project I became aware of the lack of open source power system symbols. The symbols themselves are pretty well standardized, and are used in many different technical materials. Yet you cannot simply go to a site like OpenClipart.Org and obtain any particular power system shape you’d like to use.

To bring change that status quo I started an initial attempt to create a universal set of power system shapes. In its current state only some shapes have been made, for the Dia editor as a target.

This project halted because all shapes were coded by hand, hindering re-use between shapes, and hindering a multi-target approach

The ultimate goal is to support multiple target platforms, to cover most use-cases:

Targets

  • Dia (via sheets)

  • LibreOffice Draw (via a plugin)

  • LibreCAD

  • QCad

  • Inkscape (more general)

Also each shape could have a number of varieties associated with it, depending on the orientation, the region of use, and the level of detail it describes.

It seems that all these use-cases could be covered by using a subset of the SVG standard, as the Dia shape syntax is rooted in the SVG syntax.

Revival

If this project were to be revived, which I hope it will be, I’d propose to use a different strategy for dealing with the shapes. By breaking up the shapes into its underlying components, and by writing generators for multiple output formats, the required human effort can be reduced, whilst at the same time the output can be increased.

Shape components

Shape components should describe the parts a shape is made of. It would equate to writing paths and object similar to SVG, although the information could be coded in a meta-format. Ideally shape components should be able to use other shape components in their definitions to create a level of inheritance. In addition basic translations like offset, rotation, and scaling should be supported to make the most of this inheritance. Also the ordering of other shape components is needed. Maybe the SVG native format would support this from the get go, but than it can be questioned if this best suits a multi-target approach.

Shapes

Shapes would consist of a multitude of [Shape components], ordered but not necessarily nested, as the nesting is already available for the shape-components. In addition to the shape drawing, it would contain information about the naming and the supported output formats.

Sheets

Sheets would contain multiple shapes, and concern the distrubution of theses shapes. For example there might be sheets containing all available shapes, but also there could be sheets containing just shapes for a particular view level (transmission level, distribution level, individual phases).

Implementation

Currently my best bet on the implementation would be to use some XML manipulation library. Recently I’ve acquired some knowledge in Clojure, which might be a suitable target for this project as well.