What's New? The BPDA GIS Department has made many changes to make it easier for neighbors and makers of all kinds to collaborate on the application, improvement and extension of the city model. Click here to read more about it!
The Boston Planning and Development Agency (BPDA) maintains a 3D model of the city as a visualization and analytical tool for understanding ideas related to the future of neighborhoods. The BPDA shares the Boston 3D city model in several formats intended to facilitate collaboration between diverse communities who have an interest in understanding places in the city as they have changed or as they may be changed.
We all understand the necessity of a 2D base map for understanding context of information. The Boston 3D city model provides a reference framework for understanding the shape and visual connections among places, objects, ideas and events. The three-dimensional aspect of places can be characterized by terrain features, trees, and the shapes of buildings. Assembled, these simple components provide a picture of the interconnectedness of places and things that happened or may happen nearby.
There are many applications that make use of city-models -- including simple exploration or recognition of places, presentation of before-and-after scenes that demonstrate the juxtaposition of proposed or historical scenarios with the current view. Alternate scenarios may also be used for evaluation of sight-lines, view corridors and shadow impacts of new development. The 3D reference framework is also useful as a resource for understanding places as they were, as a frame for understanding historical documents and accounts -- an application which will redeem the value of well-preserved data as time goes by.
The BPDA city model is designed to facilitate collaboration. Planners and designers can integrate BPDA data into independent models and design studies. Where this work leads to improved and updated building models, our sharing architecture makes it easy for collaborators using a variety of tools to put their work together to make an improved city model as we work together to make an improved city and region.
The word interoperability refers to sharing data among tool-sets that have specialized capabilities and limitations. The three predominant tool domains inthe city modelng space include: Commercial Geographic Information Systems, Commercial 3D Modeling tools, and Open Source Modeling and Archiveal Pipelines. One very general goal of an interoperability strategy is to support workflows in which a variety users can import the BPDA's shared model components into their tools; and to provide a setting within-which diverse collaborators can create new information, that can in turn be integrated into independent city-models and archival systems -- including the BPDA's model management system. A successful interoperability strategy will accomplish these synergies with a minimum of information lost in translation or time-consuming hand-off adjustments. The ideal of completely lossless data sharing interoperabilty is known as a "Round-Trip" lossless exchange.
The Boston and Cambridge city model management systems make use of the ESRI ArcGIS platform of Geographic Information System (GIS) to assimilate information from a vareity of photogrammetric surveys to generate a highly detailed Terrain Model, Planimetric Ground-Plan, Trees layer and a collectiion of Building Models. In the case of Boston, the 16,000 buildng models have many sources, from simple polygons that have been extruded, 3d buildng models with detailed roofs, which have been created frm stereo imagery, and many models that have been hand-made by the BPDA's Urban Design Technology Group.
The backbone of the GIS model management system is a scalable database that is unlimited in terms of spatial scope, level of detail, and the ability to mix any number of alternative represetnations of the same terrain, trees and buildngs. The GIS database attaches attributes to 3D features that may be used to systematically mix and match model components to reflect past, current and future scenarios. By representing features, like building models as elements of a database, the GIS model management system is well-suited for curating collections of models that are tagged according to their original sources, or specific time period or level of detail for which a particular model should be rendered or exported.
ArcGIS has a lot going for it as a tool for organizing vast amounts of data. The ESRI geodatabase format maintains relationships between geometric objects with attributes in flat tables. On the other hand, tools that designers favor use to create and modify detailed 3D models employ a flexible hierarchal data organization of nested geometric objects. Most design-oriented tools are limited in terms of their spatial extent and the size of the data-sets that they can handle without problems. None of these tools will import or export 3D models form ESRI's proprietary data formats.
ESRI also has its own pipeline for visualizng 3D city models on the web. ArcGIS On-Line is an excellent visualization tool for publising and viewing products of the 3D city model. But it is an expensive tool that is out of reach for most people. Alternative city-model viewers, like Cesium, ThreeJS or MapBox have no import pipeline for ESRI Geodatabases that carry 3d objects. To better engage with diverse user communities, the BPDA regularly issues the active view of the city model in formats that make it easy to make lossless tound-trip exchanges with the tools that collaborators use.
One of our ideals for exchanging pieces of the city model is to have a one-step import process for loading a complete city model of a place as a single file. Most modeling tools used by designers are capable of importing SketchUp format models that include terrain, groundplan, building models for a limited area (5,000 foot tile). The sketchup models have a useful object hierarchy that maintains named distinctions between the components, including uniquely-identified buildng models. You can learn more about our SketchUp format tiled models by reading Boston 3D Tiled Sketchup Models.
The benefits of Sketchup format discussed above do not make up for the fact that the SketchUp format requires a proprietary tool-kit to import and export. Open-source applications that do not import SketchUp. And as a general rule design tools, other than SketchUp don't export SketchUp models.
To assure that the BPDA city model can be used in most modeling applications and long into the future, we provide each of the components in formats that can be assembled and manipulated by open-source modeling tools and data transformation pipelines. We have chosen the Wavefront Object (.obj) format to fulfil this role for Building and Terrain data. Almost every 3D design tool will import and export .obj format, and there are well-supported open-source tools that will convert .obj files into practically any other format, including Cesium GlTF, OGC 3D Tiles, MapBox and ThreeJS. Wavefront Object format is used for the export of Boston 3D Terrain Tiles and Boston 3D Building Models.
When importing Boston 3D city model geometry in .obj format, specify that the Z axis is Up and the Y axis is Forward. Otherwise, the geometry wil appear to be side-ways.
Building models are assoociated with attributes that reflect the provenance and the temporal scope of the model and other information that may be useful for associating a model with information about actual buildings or for locating the model in different coordinate systems. Sharing this information outside the world of ESRI ArcGIS requires that the 3d buildnig models models shared via SketchUp or Wavefront Object format have unique identifiers that can be used to look up model attributes from a CSV table. Our interoperability framework includes a city-wide CSV attribute table for all models. Similar tables are included for the models in each tile and with incremental city-wide updates. A data dictionary for our CSV attribute table is included near the bottom of Boston 3D Building Models.
A key component of the city-model the interoperability and versioning strategy is the use of unique model identifiers that stick with building models as they are exported, imported, revised and retired. These identifiers make it easy to compare independent versions of pieces of the city model. Model identifiers are particularly useful for exchanging collections of 3D models with design-oriented modeling tools or in non-proprietary archival or exchange formats. In these exchanges, the 3D model objects are tagged with their model ID, which provides a unique key to a table of model attributes.
In the Boston 3D model, model identifiers are composed of a "BOS" prefix and a 7-character string comprised of random letters and numerals. This system makes it easy to to avoid collisions or duplication of identifiers while building a collection of models that originate from different sources. There is no requirement that other collaborators use the same ID scheme. But it is necessary to use an ID that is unique within the collaborator's name-space. and the ID should be a modest number of characters so that it can be used as a file name for our .obj exports and as a group name for the tiled .skp models. The 7-character random strings have a probability of 1 in 64,000,000,000 of being repeated. It is easy to generate these strings with a one-line Python function, or The random.org String Generator
Multiple models of the same building
It is important to distinquish between Model Identifiers and Building Identifiers. Because of limitations in the photogrammatic procedures used to collect 3D data, 3d models of "buildings" are often models of building groups or buildng parts. It is not easy nor is it necessary to split and merge each of the 3D building models to force a one-to-one with the tax assessor's conception of buildings. To avoid confusion avoid the tempting but confusing use of the term "Building ID" when discussing Model Identifiers.
The BPDA city model includes many models that do represent distinct buildings. All of the hand-made models created by the Urban Design Technology Group represent recent large projects link to records in an Article 80 Buildings table. The model identification scheme allows us to manage models that represent different versions of the same building -- at different levels of detail or stages of rennovation.
One aspect of the interoperability and collaboration plan is to provide a means for collborators to share updates systematically. A brute-force approach to updating would be to issue a completely new model snapshot periodically. In Independent collaborators replace entire tiles each time they want to update. Users have let us know that when they have invested work in their local models, it is very tedious to integrate updates with this wholesale update method.
Our new interoperability scheme provides an incremental versioning strategy that makes it easy to share revisions with users who want to integrate updates selectively into their independent city models. This system also makes it possible for libraries and historians to efficiently update archival systems.
Here is how it works:
The method of applying updates to shared models described above is one example of the benefit of collaborators using the same coordinate system in their independent models. A shared coordinate system ensures very precise placement of models with a minimum of time-consumuing guess-work on the part of collaborators.
New tile-grid is extendable and nearly true north.
Surveyors and engineers in Massachusetts prepare their drawingus using the Massachusetts State Plane Coordinate System with coordinates expressed in Feet. The origin of the State Plane grid liesoutside the state, which makes for coordinate references that have more than 7 significant digits which creates a problem for most 3D modeling tools. The creators of AutoCAD, 3DsMax, Rhino, SketchUp and Blender recommend moving geospatially referenced geometry closer to the origin to avoid problems of precision when creating, transforming or rendering.
To facilitate a culture of collaboration, the BPDA has chosen an origin to the South-West of the city, at Longitude 71.21933W, Latitude: 42.213362N ror a local origin. The coordinate domain created by this origin includes Cambridge, Brookline and Somerville inthe positive quadrant and keeps all of these cities within a coordinate domain suitable for all popular design tools.
Using the BOS_Shift
The Boston 3D Tile Grid layers are provided in the Bos_Shift coordinate system and unshifted state-plane feet. These layers include tile boundaries and tile centers and a point for the grid origin. These layers can be uesful for checking and for precisely moving geometry from official survey documents into the common Bos_Shift coordinate system.
The BPDA would like to engage with a variety of users in the development of its city model. Our new model sharing strategies are new and need to be tested. At this stage we can recommend a few different workflows for users of design tools that wish to share their models with the BPDA:
SketchUp does not import .OBJ format without a free third party plugin. For quickly exporting building models form ArcMap to SketchUp, you can use the Multipatch to Collada tool with the Outoput Coordinate system set to the Bos_Shift coordinate system. These models will register precisely with the Boston 3D Tiled Sketchup models.
At this stage of planning for a shared city model of the Boston area, itcan be useful think a little beyond the scope of this project's immediate goals. For example, we can anticipate a need to export data for use in the successful open source 3D globe tool-kit, Cesium.
We also should look forward to the ways that 3d models can be managed independently and collectively -- a problem area that will probably lead us into the area of digital asset management systems and open source check-out and check-in workflows that allow collections of models to be curated and continually pushed forward into the future and backward as a tool for visualizing and organizing information about the future city and past situations and ideas. A distributed asset management system will allow independent creators to develop assets that include the sort of metadata that can be easily posted to catalog systems that include facilities for check-in and different levels of local and centralized curation for assets and scenes.
We have chosen the Wavefront Object format as our modifiable asset exchange. Most tools are capable of reading and writing a reliably digestible .OBJ -- which is a very faithful record of vertices, edhes, face normals and textures. OBJ, however, is not considered the best medium for quick web-based rendering. The COLLADA consortiom has devised the GlTF (GL Transmission Format) as an optimized high-performance way of sharing high-performance preview proxies of 3D assets. Kronos Consortioum declares that the purpose of GlTF is to be like the JPEG of 3D. Not recommended as the format for preserving modifiable assets. Nevertheless, GlTF is likely to be another sort of asset that may be generated as a proxy for the reliably modifiable .OBJ assets.
GlTF seems to have legs as the means of handing 3d assets to viewers that make use of the HTML5 in-the-browser viewers -- very popular, for example for uploading interactive 3D avatars and gadgets to Facebook. Another good thing about GlTF is that it includes georeferencing and temporal referencing and temporal capability -- which happens to be very well supported in Cesium.
For now it is out-of scope to work through all of the details of exchange our city model geometry and attributes with GLTF. But we have done enough research to determine that it will be possible to derive GlTF with cesium-compatible georeferencing information from our scheme for sharing models as .obj files and CSV tables for model attributes.
The Boston city model-sharing scheme are designed with the objective of creating an environment of shjaring and re-use of assets across a wide variety of tools. For the moment, what we have is the beginning of a rough framework for sharing city model components and for issuing revisions. As this system develops, it will be desirable to keep and use 3D models along with other systematic observations of buildings through time -- 3D models are simply digital documents that imortalize observations made at a specific time, like photographs. There is no reason that the collecton of models could not be systematically archived in systems not unlike library repositories. The same sort of archival technology that allows contributors to attach attributes to photographs can be used to build or make use of some combination of the capabilities of 3D warehouse and GitHub.
For now, without explaining all of the details, we will just point out that our scheme for publishing the tile-wise collections of models with attributes and for issuing incremental updates will be compatible with syndicated/federated archival schemes that automate many aspects of the curation of the memory of past states and speculative ideas that have been generated in the context of the ecosystem of diverse users and tools that are involved in the city-modeling process.As of yet, we have not discussed ways that contributors can attach attributes to models outside the context of GIS. archival systems will interaqct with our update strategy and historical applicaions. The best way to capture the synergistic value of distributed use and development of the city model will be if there is a single framework that addresses the needs all of the important collaborators.