Data Dictionary for Models of Built Structures
The Bos3d City Model includes a Model Collection of more than 100,000 models representing built structures. These models originate from many different sources. The Model Management Schema provides a system of attributes that can be used to understand the provenance of models and to keep track of models through their life-cycle.
The Model Catalog is a single table with a reference for each model in the structure model collection.
Table of Contents
- Concept of Built-Structure Model
- Data Dictionary for Model Catalog
- Status Classes and Model Stores
- Model Status Dictionary
- QA_Flags Dictionary
- Levels of Detail and other Recommendations for Model Structure
Concept of Built Structure Models
It is essential to keep in mind that in the context of the model collection and its catalog that each record is related to a model of a built structure. These models which might represent a single building, a part of a building, a group of buildings, or a wall, a dock, or a bridge. Referring to these as Building models leads to confusion. This conceptual definition is necessary, because of the the semi-automated means of creating models is unable to distinquish between discrete "buildings" especially when these are attached to eachother. This fact creates a difficulty when it comes to linking structure models with information concerned with individual buildings. Such a one-to-one link may be possible to make for some models. It is always possible to split or merge structure models to achieve a representation of an individual building, but this can be a labor-intensive process.
Model Catalog Attributes Dictionary
Note: field names have 10 or few characters to retain compatibility with ESRI Shapefile format.
| Model Status Attributes: : These attributes are used to determine whether or how the model should appear in various scenarios involving the time period, or planning context. These are the attributes most often used for controlling the styling of models and the attributes most frequently updated in the model management workflows. | |
| Name Text |
The name of the structure. THis may be the name of an existing or proposed structure or as a default, this could be the address taken from the parcel intersected by a model's centroid. |
| Status Text |
A phase in the lifecycle for proposed, built, demolished or renovated structures. Values of Status are taken from the Status_Code domain (see below) |
| Appear_Dt Date |
Date of the latest observation or document that confirms the current value of Status. The Appear date should refer to the same document referred to in the Appear Source fields. |
| AppearSrc Text |
The observation or document and the date that confirms the Appear_Dt.
Example: “Google Earth“ Note that the date for the document named here is inferred by the value of AppearDt |
| Disapp_Dt Date |
When the model would be turned off if a time-slider were used. Usually the date of the earliest observation that confirms that a structure has been demolished or substantially renovated. When a model relates to a group of structures, one of which has been demolished, the entire model may have its status set to History and the Disappear Date set to the Appear Date for the new model. In this case, the original model may be split to create a pocket for the new model. The remaining portions of the split model would have the same appear Date as the new model. |
| DisappSrc Text |
A short reference to the document that established the Dissap_Dt. The Disappear Date should refer to the same document referred to in the Disappear Source fields.
Example: “Nearmap“, For models with status of Proposed or Permitted Demolish, this field can be used to record observations that the structure is still there.
|
| Model Provenance Attributes:Provide the information for understanding the provenance of models as documents that have authors, contributors sources and issue dates. | |
| Model_ID Text |
A unique ID for each model. The ID is a random arrangement of seven upper-case letters and numerals prefixed with BOS_ . |
| Model_Cred Text |
This short reference to the person or enterprise responsible for creating the model. |
| ModelBatch Text |
A folder within the Archive/ModelWork folder where the original source file can be found. |
| Model_File Text |
Name of the original source file for the model. |
| ModelStore Text |
Name of the model store holding the open-format model in the Archive Repository. The value of this field is normally set automatically when producing Geodatabase and ModelStore snapshots of the collection. The ModelStore string is combined with Model_ID to create path references and URL end-points for open-format models.
|
| Model_Dt Date |
Date when the model was created. This value should reflect the date that the model was enrolled in the collection. In the case of modified models, it should reflect the date that the modified model was enrolled. This field will be used to discover updated models. |
| ModelNote Text |
This is the text that would appear as the description of the model.
This note might describe the context of the model's creation.
Examples:
|
| Model_LOD Double |
Level of detail. See table at Levels of Detail |
| Survey_Src Text |
The observations that were used for establishing the shape of the model. Should describe the responsible party and the methodology where possible.
Examples:
|
| Survey_Dt Date |
The date that the model geometry was captured or published. |
| Model Geometric & Reference Attributes:These attributes are automatically generated by the model enrollment process.
The centroid positions are critical for applications that must translate the coordinates of models form the shifted Mass state Plane coordinates to geographic coordinates with rotation. The elevation information may be used to convert model footprints to LOD1 models that may be used as place-holders in applications where efficiency is more critical than true 3D. |
|
| Centr_Lat Double |
Latitude of the model centroid (2D) in decimal degrees. Assuming WGS84 earth model. |
| Centr_Lon Double |
Longitude of the model Centroid (2D) in decimal degrees. Centroid coordinates calculated by ArcGIS using the “Inside” option. |
| Centr_X_Ft Double |
X coordinate (Feet) of the model centroid in the Metro Boston 3D coordinate system. |
| Centr_Y_Ft Double |
Y coordinate (Feet). See above. |
| Min_El_Ft Double |
The lowest elevation of the model. This may be below ground. |
| Max_El_Ft Double |
Elevation of the highest point of the model. |
| Gnd_El_Ft Double |
The elevation where the model intersects the ground. (this measure uses vertices of the 2D footprint to sample elevations. The elevation value is the lowest value from the Infotech DTM that coincides with a vertex from the model's 2d footprint. | Height_Ft Double |
The relative height from the Max Elevation of the model to the lowest corner. |
| Tile_ID Text |
ID for the tile that the model centroid falls within. |
| Parcel_ID Text |
The Parcel ID for the parcel that falls under the centroid of the model’s footprint. |
| Parcel_Lnk Text |
A url that opens the Assessor’s web map centered on the parcel that identified by the Parcel_ID. | GoogleLnk Text |
A url that brings up an oblique view of the building in Google Streetmap |
| NearMapLnk Text |
A hyperlink that brings up an oblique view of the building in NearMap. Requires a NearMap login. |
| Plan Attributes:For hand-made models in the Approved or Internal Feature Class may have attributes related to the role they play in proposals and plans. | |
| >Project_ID Text |
The Project ID in the BPDA’s Article 80 Development log. |
| ProjectLnk Text |
A URL linking model to the BostonPlans landing page for the project if applicable. |
| A80Status Text |
The latest status associated with the project in the Article 80 Development Log. This status is useful for detecting changes in status for Approved models or Internal Models that are actively under consideration. It does not map exactly to the value for Status |
| Plan Text |
For models associated with proposed or internal studies, the name of the overall plan that may cover multiple buildings, phases or scenarios. |
| Scenario Text |
For models that are part of alternative scenarios within a plan. The value for Scenario can be used to identify or select all of the models associated with an alternative scenario. |
| Phase Text |
For models within a plan or scenario that are contingent on time and/or grouped by geography. |
| LegClass Text |
This field provides flexibility of controlling symbolization of models for webscenes and other cartographic products. |
| Structure Attributes: These are attributes that refer to the real-world or proposed structure/s represented by the model. | |
| >Struct_ID Text |
If there is a table about structures, this would be a reference to the primary key of that table. |
| Struct_Type Text |
Type of structure. See domain values. Refers mostly to the physical aspect of the structure.
Must have one of the following values: Building, Bridge, Wall |
| Struct_Use Text |
Use of the structure. More specific than Type. Refers to the functional aspect of the structure. Examples: School, Library, Civic, Residential, Commercial, Subway Headhouse, Bus Shelter |
| Struct_Lnk Text |
A URL that provides more information about the structure.
For example, a Wikipedia page or a library branch page. |
| Edit Tracking Fields: Publishing a new edition of the model collection using ArcGIS involves generating new multipatch feature classes. When these are initialized, the automatically assigned Record Initialized and Record Modified fields are wiped out. These fields are critical for model management. It is also necessary to preserve the Edit_Date and Edit_Action fields for applications that need to know the last deliberate action that was taken. | |
| RecInitDt Date |
The time stamp for the creation of the table row. This defaults to the time that the feature class was issued. Automatically generated. |
| RecInitUsr Text |
The username for the person who initialized the row. Automatically generated. | RecModDt Date |
The time stamp for the last modification of the table row. Automatically generated. |
| RecModUsr Text |
The username for the person who last modified the row. Automatically generated. |
| Editor Text |
The user name for the person who did the last meaningful change to this record. NOT Automatically generated. |
| Edit_Dt Date |
The timestamp of the last deliberate edit. NOT Automatically updated |
| Edit_Action Text |
Explanation of the last deliberate edit Not automatically updated |
| QA_Flag Text |
Short code used to redirect models to procedures in the model management process. Pre-coded domain consisting of: 3D Edit, Promote Status, Demote Status, Stop, Alt |
| QA_Issue Text |
Use this field to explain any issues with the model or catalog information that may need addressing in the model management process. |
Model Status Classes and Model Stores
The geodatbase view of the Model Collection is segmented into Model Status Classes, which helps to keep clutter out of the way during model management operations. Individual multipatch features are sorted into these classes according to the value of their Status attribute. An important mechanism of the Model Management workflow is that changing the Status of models in the Stage feature classes will cause these models to be sorted into a new status class when a new geodatabase edition is pushed.
Model Store is a more general categorization of models which forms the three classes of obj-format models that are stored in the open-format model store. These are used as the validated back-up of the collection and the repository for the model download site.
| Status Class | Description |
| Existing_MP | Holds measured models of structures. Status Existing or Approved Demo. These models will be shared As-Built model Store. |
| History_MP | Holds models reflecting the shapes of structures that once existed. Status: History. These models are selected because they were replaced by newer models in the Existing_MP feature class or by models in Approved_MP that have been promoted to Under Construction or Complete.. It is not necessary to split historical models to reflect the pocket occupied by new models. Therefore, some historical models cover one building that changed and also include several neighboring buildings that did not change. Most of these models will be measured models, although some projects focused on historical representation may build hand-made models of historical buildings. These models will be shared As-Built model Store. |
| Approved_MP | Holds hand-made models reflecting projects. These These models are shared with the public having Status Approved, Under Construction, or Current. When Current models are be replaced by measured models, their status is changed to Project Complete which causes them to be sorted into the Internal_MP status class. These models will be shared Change model Store. |
| Internal_MP | Hand-made models that are created for internal investigations. This feature class holds all hand-made models created for the project review and approval process and for internal studies. Status Internal Study,Pre-File, Under Review, Proposal Superseded,Proposal Built. While hand-made models have status of Approved or Under Construction, they are part of the Approved Feature Class. When they are replaced by measured models, they return to Internal_MP with status Proposal Built are shared on public web scenes or in the model download site. they are stored in the Internal model store. |
| Alt_MP | The Alt_MP feature class holds models that represent alternative representations of structures. For example, these could be models that are higher level of detail than models featured in the Existing feature class -- such as models featuring textures. These models will be shared in the As-Built model store. Status: Alt. These models will be shared As-Built model Store. |
| Retired_MP | This status is used only during Major updates, when massive quantities of models may be replaced by improved models of the same structure that reflects no change in the geometric form. This status is not to be used during routine updates! Retired models are preserved for the purposes of possible recovery and as they reflect a valuable record of observations or creative work. |
Model Status Domain
The Model Status attribute is a category scheme that reflects the life-cycle state of the the building or proposal that the model represents. This field controls when the model is rendered in applications.
The GIS-Based model management applications use Model Status to segment the collection into feature classes that streamline applications that may be focused on the current, proposed or historic views.
| Status | Feature Class | Description |
| Current | Existing_MP | This status is for models of existing structures that are based on measurements. |
| Approved Demo | Existing_MP | A structure that overlaps with a model that has status Approved. The Approved Demo status is used to hide a model when portraying Approved projects. The building still exists according to the latest observation. This observation can be recoreded using the Disappear Source attribute. |
| History | History_MP | A measured model that has been replaced by a newer model in the Existing_MP feature class or by models in Approved_MP that have been promoted to Under Construction or Complete.
History status may be applied to models of clumps of structures where a new model is replacing part of the historical model. In these cases, the entire old model is historical. Such a model may be flagged for splitting (QA_Flag = 3dEdit) to be divided to create a pocket for the new model. The original model (the entire clump of structures) has status History. The remaining part(s) of the model will be kept in the existing collection with status Current. |
| Board Approved | Approved_MP | The building project has been approved by the planning board. |
| Complete | Approved_MP | Hand-made models of proposals. The shell of the building including external finishes appear to be complete. These models remain in the Existing feature class until they are replaced with measured models. This status is used only for hand-made models of proposed projects/ |
| Under Construction | Approved_MP | The foundation (or more) of the new building is visible. |
| Pre-File | Internal_MP | The model is a draft that has not yet been formally submitted for review. |
| Internal Study | Internal_MP | The model represents a completely fictitious scenario not an official proposal |
| Under Review | Internal_MP | The model represents a proposal that is under review by the planning board. |
| Proposal Superseded | Internal | The model represents a proposal that has been superseded by a new proposal. |
| Proposal Built | Internal_MP | The model represents a proposal that has been built. The model has been replaced by a measured model. |
| Retired | Retired_MP | See the description of Retired_MP above. |
| Alt Model | Alt_MP | The Alt feature class holds models that represent alternative representations of buildings. For example, these could be models that are higher level of detail than current models -- such as models featuring textures. These models will be shared in the As-Built model store. |
| Expunge | N/A | If a model is an exact duplicate of another model that is in the Existing collection or the new models pipeline, or if the model is corrupt and being replaced by a repaired model then setting its Status to Expunged will cause it to be disregarded in the process of building the next edition of the collection. This is the way to "delete" a model while retaining the ability for someone to go back and understand what it was and why it was deleted. |
QA Flags Domain
QA Flags are used to provisionally mark models for attention. For example when assimilating a batch of new models, it can be useful to use a spatial join to look for collisions with Existing or Proposed models in the stage collection. Or a table join with the development log may indicate a model that is likely to be a candidate for promotion from status Under Review to Approved. Models that are spatially associated with these may be candidates for status demotion, e.g. from Current to Approved Demolition. The QA flags and QA Issue fields provide a means of recording the inferences returned by automated methods so that the conditions can be investigated to confirm the correct status values and to identify other issues that may need to be cleared up. The QA Flag Wireframe view provides a way to quickly identify candidates and set the status attributes. Setting the QA Flag to Unflagged causes the candidate models to disappear from the Flagged Wireframe view.
| Code | Description |
|---|---|
| Promotion Candidate | Model is a candidate for a status promotion. |
| Demotion Candidate | Model is a candidate for a status demotion. |
| History Candidate | Models that are considered for replacement by newer models that represent a changed shape are candidates for a status change to History |
| Retirement Candidate | Models that are considerd fo replacement by newer models that have been observed more recently or may be a higher level of detail, but do not reflect a change in shape of the actual structure, are candidates for a change to status: Retired. |
| 3D Edit | For models identified as needing to be split or repaired |
| Flip Faces | Models with some or all faces that are turned the wrong way can be repaired later. |
| Remove Color | Models that have erroneous colors. |
| Expunge Candidate | Models that are corrupt or damaged which wil be replaced by repaired models from the same batch of observations are candidates for the status Expunge |
| Other | Models with some other potential issue. |
| Unflagged | This value is useful for clearing the flag value once status has been updated or whatever issue has been resolved. |
Guidelines for 3D Model Structure and Level of Detail
The architecture of this schema, where we use one Multipatch or .Obj file to represent a building, bridge or wall is well suited to handling mesh objects that represent only the exterior shell of the structure. It is preferable that the mesh be a closed “solid” that has all of its faces oriented toward to outside. Within this guideline, there are many possibilities for levels of detail – as listed in the table below.
- Models that are not closed or include two-dimensional planes with single faces are problematic as Multipatches and can behave unpredictably with regard to shading, importing, and exporting.
- We are unable to publish models that incorporate textures or materials at this time. We may be able to represent these as multipatches, but the textures or materials will have to come off when the models are exported to SketchUp or OBJ. This is an issue that we hope to address in coming revisions.
- Level of detail 3 is preferred. If models of building shells may be divided when building parts have distinct functions, like parking structures. Or when parts have different construction dates.
- Models of LOD 4 or greater require a lot of work to assimilate and may be impossible to clean up to the point of working with our system.
3D Model Levels of Detail
These levels of detail are compatible with the CityGML LOD scheme but are sub-divided according to the types of rough massing models that we commonly see shared by architects and hobbyists who share models onsites like 3D Warehouse.
| Code | Description |
|---|---|
| LOD 0 | Polygon Footprint |
| LOD 1 | Extruded Polygon Footprint |
LOD 1.5 |
Massing model made from extruded roof prints when a structure with parts that have different heights |
LOD 2 |
3D roof detail, extruded to the ground along drip-line. |
| LOD 3 | Model portrays undercuts where appropriate. E.g. entryways, porticos or arcades. |
| LOD 3.25 | Architectural details indicated by materials or image textures. |
| LOD 3.5 | 3.5 Building model expresses location of windows and entryways as 3D indentations | LOD 4 | Model is divided horizontally as individual stories | LOD 4.5 | Model divides interior spaces: rooms or zones. |