Open Vector Standards

VectorSection aims to enable innovations in using and sharing engineering and graphics data. To that end, we need a new set of formats which are specifically designed for random access, shared updates, and atomic changes. These formats are the "hubs" of VectorSection's converters.

There have been other efforts to define open standards, and there are certainly some non-open standards to choose from. VectorSection comes from the idea that standards without connections to existing data are impractical. If we define standards in terms of running code and real-world usage rather than committee compromises, we can evolve concise data schemas which closely mirror actual usage.

Serialization Format

The semantics of the data (the "meaning" of in-memory data) is the important part of a standard. But we need to have some way to store and exchange the data. We are currently using YAML for serialization because it maps cleanly to data structures in most programming languages, is easy for humans to read and write, has many robust code libraries available, and adds very little overhead to the data.

Streams and Atoms

atomized stream
    |-- 0.yml
    |-- 1.yml
    |-- 2.yml
    |-- 3.yml
    |-- DIRTYPE
    |-- drawing
    |-- layers/
    |   `-- 0.yml
    `-- styles/
        `-- 0.yml

Traditional serializations have been a simple "brain-dump" of the program's in-memory data structure or possibly a more "human readable" export format. This single-file approach works fine for resuming your work, but the file is actually a collection of entities. When you try to collaborate with others, merging independent changes to multiple entities is difficult because the file is your "atom".

The Open Vector standards treat individual entities as atoms, meaning that conflicting changes only occur when they are made to the same entity. We can still have "files", but a collection of atoms in one "file" is simply a stream. Streams are convenient for sending data across the network or between programs on pipes, but not as suitable for simultaneous editing and change tracking as a database would be. OV streams can be "atomized" into a directory structure as shown on the right.

Each entity (and metadata definition) defines an atom with a unique identifier. The graphical entities (circles, lines, etc) occupy the top-level of the tree along with some header data and the format identifier (DIRTYPE), while sub-parts and metadata are stored in subdirectories. A tree structure on disk is not the only way to atomize a stream of data, but it is a very simple scheme which has immediate utility while being easily understood by users and programmers. Thus, the notion of a directory tree is central to the design of the OV standard formats.


The OV standards need to encompass more than one paradigm of vector data. For example: a surface modeler (such as for visualization or gaming) operates on a different set of concepts than a solid modeler (for engineering design and analysis), a drafting program, or a graphics layout program. Given a single standard schema, each of these applications would be quickly overwhelmed by foreign concepts from the other applications such as nuances in the entity definitions (e.g. NURBS vs BREP) and metadata like lineweight or paper size. At the same time, data like the location and radius of a circle should be able to be transferred between these applications without losing dimensional accuracy. To this end, multiple "profiles" are defined by the OV standards and designed to be bridged by the VectorSection converters.

Core Profiles

The following profiles are the starting point for the OV standards and each of them is being implemented in VectorSection:

Open Vector Drafting
2D and 3D explicit drafting, polygon surfaces, explicit solids (e.g. .dxf, .dwg, .dgn). Formerly referred to as "Rhizopod" or "rzp".
Open Vector Triangles
A simple collection of triangles (e.g. .stl)
Open Vector Printing
2D pre-press/print formats (e.g. .svg, .ps, .pdf, .xar). Formerly referred to as "Chromista" or "crs".

All material Copyright © 2005-2008 Eric L. Wilhelm.