This document discusses a series of scripting tools that were created to enable data-driven design to support large-scale scenario planning projects. These tools are intended to integrate GIS and CityEngine to enable the creation of large amounts of 3D content to support urban planning/geodesign projects. The content created can be used to create images as part of cut sheets (to be used with data-driven pages), or linked to web content in web maps (by providing content for pop-ups or web scenes to link to). The focus of the workflow proposed here is streets, but the scripts also support projects related to buildings/lots/zoning visualization.
Still building page, more edits to come.
The intent of these scripting tools is to enable data-driven design on a massive scale by leveraging GIS and CityEngine in conjunction. There are great examples of how GIS data can be leveraged to create great 3D content to support transit oriented development, scenario planning efforts, or even an aviation facility's operations. However, preparing this data often involves gathering and processing aerial imagery, high-resolution terrain data, georeferenced footprints/planimetric buildings, and so on to create a complete urban model. My point is that building context for a 3D urban model takes time: so much time that it is hard to justify in a project-oriented setting without a long-term interest in a certain area.
However, the idea behind these tools is to make context be provided by associating content to an individual entity either being displayed within a web map or as part of cut sheets associated with the entity. So the context is provided by your application, and the selected records (streets/lots/buildings) are enabled to show pop ups or hyperlinks that go to their associated content. In some contexts, this leads to massive time savings, and enables a larger scale to work with. The reasons why this might be preferable include 1) web maps allow you to efficiently share large sets of data by compartmentalizing 3D content to only be shared when it is inspected in the web map (similar in concept to tiling GIS data) and 2) there is not as much time dedicated to preparing and gathering information that supports sharing 3D urban scenes thus enabling more time to focus on analysis or the story your application is trying to tell. Generally, the main idea is using CityEngine for what it is really good at: creating content, unimaginable quantities of content.
As an example, ~200 images of street cross sections are provided within the "BatchExportImages.zip" that demonstrate how these tools and concepts can be leveraged. The cross sections were essentially made randomly, but it was completely database driven, I never touched the attributes of these street segments once. Imagine developing street design/policy proposals for entire counties, each demonstrated with its own 3D model to communicate key concepts.
The 6 python scripts within the CityEngine Tool Kit are broken down by software to be used with:
CEBatchWebSceneExport.py: Batch export of web scenes of individual CityEngine Layers to create consumable content. Example at this link.
CEBatchLayerImageExport.py: Batch export of snapshots of individual CityEngine Layers to create consumable content. All of the cross section examples from this script are in the "BatchExportImages.zip" attached.
For more information about the tools read the help documents within the "Help" directory.
Cross sectional data for street centerline files is very rare, and generally the databases to support this do not really exist. However, it is expected that as time progresses, more and more transportation asset information will be digitized.
These tools are still in development, and some of the bugs encountered were dealt with in ways that were not elegant (but they worked). Suggestions and thoughts are appreciated.
Create 3D models of proposed zoning/design scenarios by parcels or footprints and batch create web scenes or images of the individual lots that are linked to a web map or used as part of cut sheets of a location.
Create 3D models of 3D Cross Sections of streets as part of a multimodal street plan. Ideally, down the line these tools can be used in conjunction with custom goal-based methodologies to optimize street design for entire regions.
PrepareCEStreetAssociations
PrepareCEBlockAssociations
Other Pages:
Complete Street Rule Documentation & User Guide.pdf
Esri Complete Street Rule Discussion-Feedback?
If you are interested about pursuing projects that is related to this work or provide feedback feel free to email D.Wasserman@fehrandpeers.com.
This looks very promising and I am sure it will be very useful just like your complete streets rule. I am hoping to test drive this very soon. For sure, more questions to follow up after initial testing.
David,
This rule is absolutely useful for whoever interested in the CompleteStreet Rule. I am glad that you made a smart move to make data preparation easier on the GIS side. I can definitely see the potential of this package being used together with data driven pages, high-speed super computing, etc. You might have just offered a method that we can apply to link other rules and their data easier. This package could have the potential to become a template that populate the exact attributes needed in the rules. Just a thought.
Great job!
That is the workflow I envision too! These tool's applications can be very general!
David, this is a really cool set of tools! I appreciate you sharing with everyone.
I have never used CityEngine and wonder if it would be applicable with what I primarily do (support pre-construction of roadway projects - mainly state highways).
Thanks Adrian! They still need a little more work (as I mentioned to you before haha), but they work from start to finish. 😃
I will actually be presenting at the UC about the project application in CA.