RSD Format Documentation

General

Since TestFit 2.07, RSD files can be parsed by a JSON library. Different parts of the file are versioned differently to reduce code duplication in TestFit's internal parser. Whenever the data for a specific object changes, we will bump that object's version if it has one.

TestFit will not read arbitrary JSON data. When loading RSD files, TestFit enforces additional constraints that a traditional JSON library will not enforce. This guide is intended to help other programs read TestFit's data, not to help generate data that TestFit will read.

In order to make parsing the file more efficient, most arrays are preceded by a count. For instance, the views array has a matching num_views field. Unless you use a custom JSON parser, these fields can be ignored.

Unless otherwise specified, all geometry is stored in feet or meters relative to the plan's origin.

TestFit uses the x and y axes to describe 2D geometry with the positive x axis pointing East and the positive y axis pointing North.

Root Object

The root object stores the list of plans and other metadata that isn't associated with any particular plan. It contains the main version for the RSD file; however, other objects within the file may have their own version numbers.

{
    "version": 36,                   /* Version number */
    "measure": "imperial",           /* Measurement system: either "imperial" or "metric" */
    "allow_binary_data": false,      /* Used to reduce file size for bug report files */
    "image_cache": { ... },          /* Site & unit underlay images embedded as base64 */
    "bg": { ... },                   /* Background data including the map and underlay images */
    "num_views": 1,
    "views": [ ... ],                /* Data for custom 3D views */
    "num_plans": 1,
    "selected_plan": 0,
    "plans": [ ... ]                 /* An array of plan objects, documented below */
}

Plan Object

A plan in TestFit includes a road database, a road network, and 0 or more sites. It also stores the geographic origin used as the basis for all geometry within the plan's road network and sites.

{
    "origin.x": -96.798146,          /* Geographic longitude of the origin. */
    "origin.y": 32.776400,           /* Geographic latitude of the origin. */
    "roads": { ... }                 /* Road database */
    "bldg": { ... },                 /* Building object for road geometry, documented below */
    "num_sites": 1,
    "selected_site": 0,              /* Index into the site array.  This value can be larger
                                      * than the number of sites if no site is selected. */
    "sites": [ ... ]                 /* Array of site objects, documented below */
}

Site Object

A site contains all of the input and output data involved in solving a site.

{
    "boundary": {                    /* User-provided property line */
        "n": 4,
         "points": [
            { "x":  18.21, "y":  -18.21 },
            { "x":  87.44, "y": -245.46 },
            { "x": 467.92, "y": -142.67 },
            { "x": 406.44, "y":   85.92 }
        ]
    },
    "opts": { ... },                 /* Preset object, documented below */
    "units": { ... },                /* Unit database */
    "zoning": { ... },               /* Zoning profile data */
    "deal": { ... },                 /* Financial deal data */
    "bldg": { ... },                 /* A building object, documented below */
    "sln_cnt": 1                     /* Approximate number of massing options available */
}

Preset Object

A preset stores the numerical parameters that govern the site. Since there are quite a lot of parameters, we will only highlight a few here that are commonly used in rendering a site or tabulating areas. However, most of the parameter names will match an entry in the 'building input' panel of TestFit's GUI.

{
    "version": 24,                   /* This object is versioned independently from the file */
    "floor2floor": 11.500000,
    "parapet_height": 4.000000,
    "num_amenities": 1,
    "amenities": [
        {
            "name": "Amenity",
            "merge_levels": false,
            "type": 0,               /* Amenity Space Subtype, documented below */
            "color": "#978027ff"
        }
    ],
    "balcony_height": 4.000000
}

Unit Database Object

A unit database stores all of the data created within TestFit's unit editor. For sites with dynamic units enabled, a unit database is generated on the fly based on the dynamic unit parameters. This is the same data that is stored as custom unit databases in .kop files. Only a few parameters are shown here.

{
    "num_unit_templates": 1,
    "unit_templates": [
        {
            "role": "inline unit",
            "name": "S1",
            "color": "#3fa8f5ff",
            "beds": 1,
            "baths": 1.000000,
            "category": 0            /* Index into the unit_categories array below */
        }
    ],
    "num_unit_categories": 4,
    "unit_categories": [
        {
            "abbreviation": "S",
            "name": "Studios"
        }
    ]
}

Building Object

A Building is a generic container for TestFit geometry. Despite the name, it isn't limited to just a typical 'building' - it is also used to store all the data for a road network. A Building contains 2 lists - the vertices and the elements.

{
    "version": 33,
    "num_verts": 4,                  /* Number of vertices in the building */
    "verts": [                       /* Vertex data */
        { "x":   0.00, "y":   0.00 },
        { "x": 179.98, "y":  48.13 },
        { "x": 419.95, "y": 112.31 },
        { "x": 599.93, "y": 160.44 }
    ],
    "num_elems": 11,                 /* Number of elements in the building */
    "elems": [                       /* Element data */
        {
            "type": 33,              /* Building element type, documented below */
            "num_verts": 4,          /* Number of vertices in this element */
            "verts": 0,              /* Index of the first vertex of this element
                                      * in the building's 'verts' array. */
            "num_holes": 0,          /* Number of subsequent elements that describe
                                      * a hole in this element's Polygon. */
            "id0": 0,                /* Custom data field #1, documented below */
            "id1": 0,                /* Custom data field #2, reserved for future use */
            "levels.start": 0,       /* First level this element appears on */
            "levels.count": 1        /* Number of levels tall */
        }
    ]
}

Tables

Many data fields of the objects described above store numeric ID's. The tables below map these ID's to their meaning.

Element Types

Geometry Types

Name	Example	Description
Polygon		A singular closed polygon in counter-clockwise orientation.
Polygons		A polygon with 0 or more holes. Holes will have clockwise orientation.
Line		A singular line.
Lines		1 or more lines. The number of vertices for these elements will always be even; the number of lines is half of the number of vertices. Subsequent lines may or may not be connected to each other.
Polyline		2 or more connected vertices. These should not be used as closed surfaces, although sometimes the first and last vertex may be equal to create the appearance of a closed polygon.
Spline		1 or more connected Quadratic Bézier curves. When multiple curves are present, the last control point of a curve will be re-used as the first control point of the following curve.
Point		A singular point.
Pivot		Describes the location, rotation, and scale of an object.  These elements contain an ordered sequence of 3 vertices: the origin and 2 points u and v along the axes of the object's coordinate system.  The difference from the origin to point u provides the width dimension and axis of the element; the difference from the origin to point y provides the depth dimension and axis. If the cross product of u and v is negative, then the object is also mirrored.

Custom Building Element Data Fields

Amenity Space Subtypes

Facade Subtypes