RSD Format Documentation

Disclaimer: The RSD format is subject to change. While we have done our best to ensure that RSD files created since TestFit 1.0 will still load in the most recent version of the software, we make no guarantees about what future versions of RSD files will look like. Most new releases of TestFit will update the format in a small way, typically by adding a few new fields to some of the objects listed below.

This document is intended to provide enough information to get started parsing an RSD file. For sake of brevity, it does not document every single piece of data in the file. Some data has been replaced with ellipses to keep it shorter.

This document was last updated to describe version 36 of the file, which was released with TestFit 2.17.

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

ID Name Geometry Type
0 Garage Polygon
1 Corridor Centerline Line
2 Amenity Space Polygons
3 Firewall Line
4 Stair Polygon
5 Lift Polygon
6 Unit Polygon
7 Balcony Polygon
8 Common Area Polygons
9 Facade Polyline
12 Cutline Line
13 Garage Void Polygon
14 Driveway Centerline Line
15 Parking Row Polygon
16 Parking Gap Polygon
17 Parking Ramp Polygon
20 Footprint Polygons
21 Driveway Polygons
23 Parking Curb Polygons
26 Core Polygon
27 Unallocated Area Polygon
33 Road Centerline Spline
34 Road Parking Line Lines
35 Road Lane Direction Arrow Lines
36 Road Lane Divider Line
37 Road Crosswalk Lines
38 Road Greenbuffer Polygons
39 Road Sidewalk Polygons
40 Road Driveway Polygons
46 Setback Polygon
49 Module Grid Lines
50 Road Bus Lane Polygons
51 Road Parking Row Polygon
52 Parapet Polyline
56 Townhouse Green Polygons
57 Site Exit Point
58 Unit Driveway Polygon
59 Bathroom Polygon
60 Bathroom Sink Polygon
61 Bathroom Urinal Polygon
62 Bathroom Toilet Polygon
63 Bathroom Accessibility Toilet Polygon
64 Bathroom Plumbing Wall Polygon
65 Stair Riser Lines
66 Stair Gap Polygon
67 Door Lines
68 Office Lease Polygon
69 Office Core Polygon
70 Parking Column Polygon
71 Unit Unallocated Area Polygons
77 Roof Polygons

 

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.

 

Custom Building Element Data Fields

Name id0
Amenity Space Index into the site.opts.amenities array
Unit Index into the site.units.unit_templates array
Facade Facade Subtype, documented below
Parking Row Number of parking stalls

 

Amenity Space Subtypes

ID Name
0 Conditioned
1 Unconditioned
2 Retail
3 Void

 

Facade Subtypes

ID Name
0 Garage
1 External
2 Internal
3 Garage Liner
4 Balcony