CityEngine vs Drone2Map

Ever since Drone2Map was released, I've wanted to play around with its functionality to see what it could do. When the Esri South Africa Midrand moved to a new office it was the perfect opportunity to capture drone images and run it through Drone2Map. I also decided to create a CityEngine model of the building (using entirely procedural modelling) to compare it with. 

Drone2Map

Drone2Map is an easy to use desktop application that allows you to create an accurate 3D representation of the area in a couple of easy steps:

Step 1:

Open Drone2Map and choose the type of project (2D or 3D) that will be created. A 2D mapping project allows you to create two dimensional datasets including Orthomosaic imagery and a DSM. In order to create 3D datasets select the 3D mapping project. This extends the 2D mapping by also enabling creation of 3D point clouds, 3D textured mesh and a 3D PDF.

Step 2:

Select the Processing Options tab and select the 3D features to be created. Keep in mind that the number of dataset types to be exported will increase the processing time. In this example I have selected a LAS point cloud, .obj and a scene layer package.

Step 3:

Click on the Run button to start the processing. Once the processing has been completed, the 3D textured mesh is added to the scene.

The image below compares the output mesh (right) to the original drone image (left). Once the 3D scene package has been completed, it can be uploaded to ArcGIS Online. Click here to view the 3D Textured mesh in the ArcGIS Online scene viewer.

CityEngine

The next step was to create a rule to create the office in 3D, creating all the geometry aspects from procedural modelling. The fact that no 3D models (like .obj or collada files) were used in the CGA rule, really shows the power of what is possible with procedural scripting (even though the stairs look a bit funny). The video below shows what the rule looks like in CityEngine:

Finally the we can compare the Drone2Map 3D textured mesh to the procedurally created building in a CityEngine webscene. I'll let you decide which one looks better.

View the 3D Web Scene

CityEngine & ArcGIS Pro combine to show CCTV coverage in 3D

Happy 2016!!

Once again I failed to post as regularly as I would have liked towards the latter part of 2015. Hopefully I can mange my time better in the new year...(no promises). 

I was asked to create and co-present a presentation at the Esri Africa User Conference plenary session in November 2015 which shows the value of 3D GIS. I thought it is a good place to start the 2016 Urban Scene blog posts.

The aim the presentation was to show the location and coverage of CCTV cameras in downtown Johannesburg, as well as how changing some of the camera attributes (like angle, direction and length) can increase the covered areas. CityEngine was used to create the CCTV coverage rules, and ArcGIS Pro's analysis abilities were utilised to determine the covered areas.  

 CityEngine:

Step 1 was to create a CityEngine rule that creates 3-dimensional pyramid shapes representing the visible area of each camera. The CGA rule is shown in the images below:

Attributes

The attributes used by the Rule file are described in the image above. Note that the Width and HorizontalRotation attributes derives their values by calling the getWidth and getRealDirection functions, respectively.

The getWidth function uses the Pythagorean mathematics to calculate the width (length of the opposite triangle side) by using the CameraAngle and ViewLength attributes.

The getRealDirection function converts the azimuth attribute (N= 0, E = 90, S = 180, W = 270) so that the coverage area has the correct real-world direction.

Rules

The image below show the rather simple rules used to generate the viewing area:

• Object: The Object rule uses the i-function to transform the CCTV point to an existing triangular Collada shape and then calls the Rotate rule.
• Rotate: The rotate function uses the VerticalRotation and HorizontalRotation attributes to change the angle of the viewing area, before calling the Scale rule.
• Scale: Finally the Scale rule scales the viewing are according to the Width, VerticalHeight and ViewLength attributes. The rule then centers, colours and changes the transparency of the 3D viewing area.

ArcGIS Pro

The second part of the presentation showed how these CityEngine rules can be implemented in ArcGIS Pro for further analysis. The examples are listed below

• Display the 3D view areas alongside existing 3D content (such as buildings) in ArcGIS Pro.  

• View feature information in a pop-up. This can include attributes, pictures, videos or HTML attributes such as an i-frame of the Google Street View.

• Calculate the % of the area covered by the cameras. The image below shows the Before and After scenes after additional cameras were added. We can analyse the coverage of the new additions and compare the calculated values to the previous scenario.

Building Simple Urban Development rules Post 4: "Section" (b)

I've had a couple of questions after my previous post about reporting at floor level. One of the questions was: Instead of creating mixed floor use randomly, is it possible to specify the floor usage of each floor manually?

So, here is my answer:

Yes... to a certain degree :)

I decided to create a new rule file, rather than expanding on my existing rule (as per my previous posts). So....lets start:

The aim of the rule is to create 2 to 4 "sections" in my building that will have different zoning attributes (selected manually by the user).

Splitting sections

Attributes

• Firstly, I created attributes for the building and floor heights. 
• Second step was to create attributes for the number of floors that each "section" will have (for example section1NumFloors = 4)
• Step 3: Create zoning attributes for each section 
• Step 4: Create a numerical attribute to determine the height of each section (by multiplying the floor height with the number of floors) This attribute will be used when we split the building vertically

Functions

The next part describes the functions for this rule:

• getFloors: Determines the total number of floors of each building by dividing the building height by the floor height and returning an integer
• testFloors: This functions checks that the total number of floors of all the "sections" are less than the number of floor returned by getFloors. If the total is less than the maximum floors, the building will be divided into 4 sections. If the number of floors exceed the maximum, one section at a time will be removed until the number of floors is less than the maximum. (I could probably have worded that better....)

Rules

Finally we get to the cool part! The rules:

1. Lot--> Extrudes the building according to building height and splits it into a top part and side parts
2. SplitBuilding--> This rule uses testFloors as a guide and splits the floors vertically into sections (either 2; 3; or 4 sections)

At this point our building is divided into 4 sections.

Each section calls the appropriate nested split function, for example Section1Floors

• Section*Floors--> These rules splits each section repetitively vertically until the end of the section has been reached. Each one in turn calls the SetZoningSection rules
• SetZoningSection--> These rules assigns zoning type of the floor to disply each zone differently.

So to conclude: it is possible to assign individual zoning types per section manually. By dividing the building into sections we have made the rule a bit more robust, as the number of floors per division can also be changed manually. One can always extend this rule to include more "sections" but for most uses I think 4 should be enough.

Thanks for the comments regarding this series.
If you have any additional comments, questions or suggestions regarding this post please feel free to add them below.

Building Simple Urban Development rules Post 4: Reporting on Building Floors

Up to this point in the Building Simple Urban Development series we've had a look at designing parts of the city. Extending on the previous post where I added detail to our rules (in the form of parking), this week I will have a look at creating reports at floor level.

In most cases a building is occupied by various inhabitants. In the example used during this post, we will imagine that each building can have a "Mixed" zone type. These buildings have different uses per floor, these will include Commercial Use, Residential Use and Unspecified. I will also create reports showing revenue generated by all floor types (using the floor area).

Individual Floor Usage

Attributes

In this post, there was only 5 attributes added (see the image below). These were:

• CommercialFloorUse: The % of floors that will have a commercial use
• ResidentialFloorUse: The % of floors that will have a residential use
• CommercialRevenueSquareMeter: Revenue generated per square meter of commercial use
• ResidentialRevenueSquareMeter: Revenue generated per square meter of residential use
• VoidRevenueSquareMeter: Minimum Revenue  lost per square meter

     **Another disclaimer: Just ignore the bad attribute naming convention....I didn't spend too much time on the attribute names

• I also added a "Mixed" type to the ZoneType attribute that we created in Post 2.

Attributes

Rules

Only two rules were added during this post: ColorFloors and ColorFloors2 (once again great usage of my naming convention).

• ColorFloors checks if a floor has a "Mixed" ZoneType, and calls the ColorFloors2 rule if it does. It also creates a report for all floors created. To read more about reports, click here.
• ColorFloors2 uses the CommercialFloorUse and ResidentialFloorUse attributes to determine the usage of each floor by applying the "p-function". The remaining floors  are assigned a usage of Unspecified. The rules also create reports on each floor usage as well as the potential revenue generated.

Rules

Reports

The reports that are created with the new rules can be seen in the image below. The N, Sum and Avg, columns returns the Count, Sum and Average of each floor or floor revenue, respectively.

• All Floors displays the count of all floors (excluding the ground floor) 
• Commercial Floors, Residential Floors and Unspecified Floors returns the count for each floor usage type
• Commercial Floors Revenue and Residential Floors Revenue returns the count of each floor type as well as the estimated revenue generated by each (as a sum and average). The revenue is generated by multiplying the square meters of the floor (getArea in the image above) with the price-per-square-meter for the specified floor type (e.g. CommercialRevenueSquareMeter) 
• The Unspecified Floors Revenue calculates the estimated amount of revenue lost by having a unspecified/void floor. 

Reporting per Floor

Building Simple Urban Development rules Post 3: Adding Detail (Parking)

In the 3rd post of the Building Simple Urban Development rules series, we'll have a look at extending the rules by adding more detail.

In the previous post we divided our building into 4 "types", Commercial, Industrial, Residential and Parks (coloring each one individually). In this post we'll have a look at adding parking areas to our buildings.

Procedural Parking in CityEngine

But first we'll make a couple of assumptions:

• Parking areas will only be assigned to half of all Commercial buildings
• Parking areas will start from the floor and will extend to a quarter of the building height.
• We will add ramps between the parking floors on both sides of the building (up and down)

Attributes

Following the same template for the rest of the post series, we'll first have a look at the attributes added during this post.

Attributes

From the image above, the attributes that were added include:

• useHeight ( remaining building height after the parking has been subtracted)
• floorHeight (random number between 2.8 and 4 meters)
• parkingHeight (roughly a 1/4 of the building height)
• rampObject (a Collada file for the ramps)
• Textures
• Counts for reporting purposes

Rules

There were quite a lot of rules added during this post. The first half of the rules are shown below

Rules added (part 1)

These are:

• ErrorTracking: Defines whether a building exceeds its height restriction
• SplitBuilding: Guides 50% of all Commercial buildings to create parking
• ExtrudeFloor and ExtrudeFloor2: Uses the bottom part of an extruded building (while discarding the sides and top parts) and extrudes it inversely (-Height)
• CheckDimensions: Verifies that neither sides of the footprint polygon exceed 60% of the length of the other. This helps to cancel out lop-sided buildings
• HasParking: Checks if a building exceeds it maximum height and splits it accordingly:
• If it exceeds the max: The building is split into a groundfloor, parking, remaining height and an error
• If it doesn't exceed the max: It is split into a groundfloor, parking and remaining floors
• RemainingFloors: Counts and reports on the number of non-parking floors. Splits the remainder of the building into floors and color it
• CreateFloor: Counts and reports the number of parking floors and uses the bottom part of the floor "cube" to create parking floors.

The second part describing the rules in this post is focused on splitting each floor horizontally into parts in order to create Ramps, General Parking, Ramp Platform and Pillars respectively (see image below).

Splitting the Parking Floors

I think it would be best to look at the above image step-by-step:

1. 50% of all Commercial buildings are defined as having parking available
2. Roughly 25% (bottom 1/4) of the building is split into parking floors, and then split again into sections
3. First, the parking floor is split into three parts (from top to bottom in the image). A ramp on the left, general parking and a ramp on the right
4. Each ramp is then split into three parts (from left to right). A ramp platform at the top, the actual ramp, and another ramp platform at the bottom
5. Similarly each ramp platform is split (again) to create pillars.

I know, I know....another long post. So grab a quick cup of coffee and lets wrap this up...

The rules showed in the image above are:

• ParkingRamps: Splits the parking floor in 3 parts (ramp, parking, ramp)
• ParkingMain: Textures the general parking area
• ParkingRampsLeft & ParkingRampsRight splits each ramp into 3 parts (platform, ramp, platform)
• Each of the ParkingPillar* Rules splits the 4 platforms (4 corners of the building to create pillars)
• ExtrudePillar: Extrudes the pillar upwards
• AddRamp: Adds ramps, either upwards or downwards. This rule calls a Collada file and rotates it accordingly
• Texture: Generic rule that takes a path name to an image as input and applies the texture to the shape

*Disclaimer: This example was made only to show the ability of using procedural rules. These methods are not perfect (far from it) so use the information and techniques on your own risk. 

Building Simple Urban Development rules Post 2: Applying Scenarios

I started my previous post by talking about New Years resolutions, and posting more often....I then went on to publish the follow up post 6 months later.... My apologies for the very late response.

In my previous post I started look at the basics of CityEngine to create easy-to-use rules that incorporate  commonly found Urban Development rules. This post will extend that theme by applying various scenarios to a city. The post shows the ease at which CityEngine quickly updates the 3D content using different sets of attributes.

Applying different Zoning scenarios on the same data

Continuing from the 1st post of this series, we'll start by adding some more attributes. The first two attributes in the image below specifies the themes that will be applied to the scene.

• Scenario: This attribute defines the Zoning theme that will be applied to the scene; either predominantly Residential, Commercial, Industrial or Mixed
• ErrorScenario: If true, the scene will show buildings that exceed its height restriction. If set to false, the scene does not allow the buildings to exceed the height restriction at all.

The remaining new attributes are:

• ZoneType: Assigns a percentage of the shapes to a ZoneType, according to the specified Scenario
• Height: This attribute is determined by the getHeight function (described below)
• HeightRatio: Assigns a value to HeightRatio according to the ZoneType. This value will be used later by the getHeight function.
• MaxHeight: This is the height restriction associated with each ZoneType 

Adding rule attributes

This post adds one function to the rule, namely the getHeight function. The height is determined by multiplying the HeightRation with the square root of the shape area.

Functions

Finally, the Rules that were added were:

• CreateBuilding: If the ZoneType is "Parks", go-ahead and color the shapes green, else call the ExtrudeBuilding rule
• ExtrudeBuilding: If the ErrorScenario is set to true call ErrorTracking, else compare the building height to the maximum height. 
• If height exceeds the max, extrude the building to the max, otherwise just extrude the building according to the height. (So to recap: if the ErrorScenario is set to false, the height exceeding errors will not be visible)
• ErrorTracking: Checks whether the Height attribute exceeds the MaxHeight, if it does it will call the SplitBuilding rule.
• SplitBuilding: This rule splits the building into a top (and colors it) and then into sides (which calls the ValidateBuildingHeight
• ValidateBuildingHeight: This rule splits the sides of the building horizontally at the maximum height. Everything below this split is colored according to the ZoneType while the parts exceeding the maximum height is colored as red.

New Rules

To see the ErrorScenario theme in action, have a look at the video below.

Building Simple Urban Development rules Post 1: Coverage areas

First thing first... Happy New Year! I've got a feeling that 2015 will be a big year for 3D.

After the long off period, I find it difficult to start being productive straight away... I'd much rather focus on a little bit of 3D first.

Normally when writing a blog post I get a bit carried away and end up writing very long posts. So I've decided to start writing shorter, more to the point posts. This will probably help me write more often...call it a New Year's resolution if you want :)

Building Simple Housing Development rules

The focus for this series (for lack of a better word) will be back to the basics in the sense that it will focus on Urban Development (CityEngine's original purpose believe it or not).

It is probably worth mentioning that I am expanding this series as I go along, so I have no idea what will be the follow up post, or how many parts there are - guess we'll find out together.

Post 1: Coverage areas

In short, coverage areas (in this post anyway) refer to the percentage of the lot/property area that is covered by a building footprint. As I am not from a town planning background, I don't necessarily need to know about the HOW and WHERE of using coverage areas, I only want to be able to represent the rules procedurally. The best way of achieving this is to create a robust RuleFile that can be used with a number of different inputs.

Coverage refers to the % of property that is covered by a building

The first part of creating the rule files is - as in most cases - is setting up some attributes and functions. Normally writing a rule file is an iterative process, and this part will most probably be re-visited.

   

In the image above, we can see two coding blocks for attributes and functions. Lets start from the top and work our way down:

The first line creates a constant called Area. The value of Area is determined by calling the getArea function. The getArea function in turn executes a CE system function (geometry.area()), which returns the surface area of the property. Area is set as a constant so that it can not be changed by the user.

The ValidArea attribute value is determined by the getAreaValidation function. This function checks if the area of the property is larger than 100 m² and returns a 1 if is, otherwise it returns a 0. This attribute will be used at a later stage to ignore areas that are too small.

The remaining attributes define values for the Minimum Coverage, Maximum Coverage and the offset area.

The image above shows the simple rules to procedurally represent coverage areas.
The First step (Lot) is to check whether the area is large enough to contain a building. The second part (TopArea) makes sure the rule works with the top part of the the property.

The FootprintOffset rule then creates an offset using the OffsetDist attribute. The offset size can be changed as needed by the user. It then calls the SplitFootprint rule.

The SplitFootprint rule applies different rules to each of the shapes created by the offset tool: border and inside. The border is colored RED, while the inside shape calls the CheckCoverage rule.

Lastly, the CheckCoverage rule checks whether the Coverage (new shape area ÷ original area) is within the Minimum- and Maximum Coverage range. The tool also display the Coverage in a report that can be seen in the Inspector window in CE (see video below). If the Coverage is within the valid range, it is displayed as Green, else it is colored yellow.

The video below shows how the coverage area changes dynamically when the attributes are altered. You can see the changes in the area (Yellow vs Green), as well as the report (Coverage) when the Maximum Coverage, Minimum Coverage and Offset attributes are changed.

Rugby Analysis in 3D

After 3 months of distractions and traveling I had to actually force myself to sit down and write this post. That is why the post (mostly about sport statistics) comes a couple of days before the end of the tournament that is the focus point of the post. My apologies. In any case...I finally had a chance to sit down and play around with CityEngine again. Being a big sports fan (rugby in particular) I thought it would be a cool to find a way to use CityEngine to display sport stats in a new way.

The Rugby Championship is rugby championship with four participating countries: South Africa, New Zealand, Australia and Argentina. Each team play two matches against all opponents home and away, resulting in 12 championship fixtures.

I decided to create a CityEngine web scene for each fixture. The web scenes shows an aerial image export (from ArcGIS.com basemap), a 3D model of the stadium (from Trimble’s 3D warehouse) and a polygon drawn manually in CityEngine which will be used to visually display the stats of the game by assigning a CGA rule.

The Rule

Step 1:

Creating attributes

The first step of the rule was to create attributes for the Home Team, Away Team and the Stats to Display (1^st half, 2^nd half, and Full Time). These attributes are used in later parts of the rule to add the team logo, as well as for the stats.

Step 2:

More attributes

The next set of attributes represents the actual statistics of the match. The stats were obtained from Rugby Stats - www.rugbystats.com.au

The attributes below represents percentage time in opponent’s half, percentage time in Own half and percentage possession for the First Half, Second Half and Full Time.

More attributes...

Step 3:
Display stats

The CGA rule starts by reading the Home team, Away team and which statistic type to display from the attributes. Next the rule splits the polygon horizontally into 2 parts according to the territorial attributes, as seen in the image below as the Split rule.

The Split rule (to show territory)

More territorial advantage = Greater area of the polygon

Each block is then extruded according to the percentage possession of the ball. 

Higher % possession = Higher block 

Finally, add a 3D model of each stadium as obtained from Trimble's 3D warehouse and its done! This is a simple example of how CityEngine can be very versatile. It is a quick rule, set up once, which I then used multiple times (10 so far). And it is really not difficult.

Have a look at the links below to view the web scenes:

Australia vs New Zealand - 16 August
South Africa vs Argentina - 16 August
New Zealand vs Australia - 23 August
Argentina vs South Africa - 23 August
New Zealand vs Argentina - 06 September
Australia vs South Africa - 06 September
New Zealand vs South Africa - 13 September
Australia vs Argentina - 13 September
South Africa vs Australia - 27 September *
Argentina vs New Zealand - 27 September


Congratulations to the All Blacks that clinched the title last weekend. As well as to the Springboks for taking sweet revenge on the Aussies. I will upload the final 2 web scenes after this coming weekend's games.

*This scene does not have a 3D Model of the stadium    (because I couldn't find one of Newlands in Cape Town)

Levels of Detail - Building Interiors

I've been focusing on CityEngine CGA rules for building interiors lately. The aim was to create a rule file (or set of rule files) to create a generic layout of a building from 2D shapes at various levels of detail (LOD).

The image below shows various levels of detail of the same shape.

The levels are:

Level 0: The first image (although not actually a LOD) shows a plain 2D shape in its original form.

Level 1: This is simply an extrusion of the building footprint. As the shape does not have any height values associated with it (in this example), the rule file chooses a random height value.

Level 2: This LOD takes the extruded block from Level 1 and divides it into a roof (which creates a simple roof ledge) and sides (which are split horizontally into floors as well as vertically into windows and ledges). An attribute called floor_height is created and implemented by the rule file to split the sides into equal floors.

Level 3: The 3rd LOD creates a detailed 2D layout of each floor. Although in this example the floors are all identical, I plan to extend the rule by creating layouts floor based on floor number (for example creating commercial layouts for ground floors; office spaces for the three following floors and create a residential layout for the remaining floors. For this example all the floors are allocated as office spaces. Each room is color-coded according to the specified use: Blue - Office ; Yellow - Hallway : Red - Conference Room ; and Green - Printer Room.

LOD 3

Level 4: The final level of detail extends the previous levels by displaying a much higher level of building floor utilization. The focus of this LOD is to place, rotate and align building furniture (mostly Collada features obtained from SketchUp 3D warehouse) on the various floors. This LOD also creates stairs which links floors vertically.*

Conference Room

Stairs

Offices

The various LODs were created by selecting the appropriate Level from a rule attributed named LOD. This is what the attribute looks like in the code, as well as the Inspector window:

LOD attribute

This scene is a great example of how CityEngine provides the ability use attributes (and when there is none...create attributes) to dynamically assign various scenarios to the same 2D data and generating 3D geometries.

Explore the scene here.

P.s. If you are bored of the usual office life you can always replace the humans with cyborgs...

*I might have a look at displaying elevators next ;)

The light at the end of the Tunnel

A very important aspect of urban design is the ability to model underground infrastructure. Most of this blog's posts are about CityEngine's ability to model urban infrastructure above ground level, however this post will have a closer look at different ways of modeling infrastructure, depending on the position above (or below) the earth's surface.

View from inside the tunnel

Large amounts of urban infrastructure is located underground. These range from electrical-, water-, and waste management elements. The focus of this post will look at how transport networks (railways) can be located above as well as below the ground.

The first step is to determine what the study area's surface looks like. This can be done by adding a heightmap (.tif) image as a terrain layer.

10 m terrain image

After your data infrastructure data is added to the scene, select the features and go to Graph > Align Graph to Terrain > Select the Height map (your terrain) and click on finish.

Now that the data is aligned to the surface of the earth, we can do a simple check, to see whether the data is located underneath or above the surface.

The rule developed in this post was similar to the Redland Redevelopment Rail Guideway rule, which can be downloaded here.

By inserting a small piece of code to the existing CGA rule, we can check if the features are located above or below the terrain and model it appropriately.

heightOverTerrain = convert(y,scope,world,pos,scope.sx,scope.sy,scope.sz)-elevation

@StartRule
Platform--> case heightOverTerrain > 0:
 Divide_Platform
else:  TunnelSplit

TunnelSplit--> comp(f) {top: Tunnel}

Tunnel--> i("Tunnel.dae") s(scope.sx + 5, scope.sy+5, 10)center(xy) Yellow

The code above does the following:

• Creates a heightOverTerrain function which takes the z-value of the geometry and subtracts the terrain value to determine the height above the terrain. If the value is less than 1, feature is below the surface. You can read more about the convert function at the CityEngine Online Help. 
• Platform --> is inserted as the StartRule. The rule calls the heightOverTerrain function to check if the feature is located below or above the surface. 
• In case the heightOverTerrain value is > 0, the Divide_Platform rule is called, which in turn creates railway and trains along the top part of the surface, and pillars on the bottom part of the graph shape.
  
•  In case heightOverTerrain < 0 (which means the feature is below the surface), the Tunnel_Split rule is called. This rule assigns and scales a Tunnel.dae asset to the top part of the shape and colors it Yellow.
  

By inserting this small piece of code at the @StartRule of the CGA, CityEngine dynamically checks whether to build underground tunnels or above ground railways every time that the shape is edited, depending on the location of the feature regarding the terrain.

You can view the web scene here.

  

NetCDF in CityEngine

What is NetCDF?

If you are like me and completely lost to the meaning of NetCDF when you first heard of it, the following internet descriptions might help...

"NetCDF (Network Common Data Form) is a set of software libraries and self-describing, machine- independent data formats that support the creation, access, and sharing of array-oriented scientific data." -Wikipedia

Still not sure? NetCDF and ArcGIS:

"ArcGIS versions after 9.2 support NetCDF files that follow the Climate and Forecast Metadata Conventions and contain rectilinear grids with equally-spaced coordinates. The Multidimensional Tools toolbox can be used to create raster layers, feature layers, and table views from NetCDF data in ArcMap, or convert feature, raster, and table data to NetCDF." - Also Wikipedia

The fundamentals of NetCDF are explained here.

For the purpose of this blog post a NetCDF file stores multidimensional data in a grid format. The focus of this example converted the NetCDF files to point features using ArcGIS GP tools.

2D points to 3D points

After converting the NetCDF files to point features, the resulting dataset was a points feature class which had numerous points in a grid format. The points represent wind conditions over time. The attributes included X and Y -coordinats; elevation; time; windspeed; and wind angle.

Using the elevation attribute and the Feature to 3D by attribute tool, the points were converted to 3D enabled points with Z values.

2D Point Features

3D Point Features

Using the data in CityEngine

The Z-enabled point features were exported to individual feature classes per date stamp. This was done in order to add the feature classes as seperate layers in CityEngine.

A simple rule file was created to assign a 3D arrow object to each point. The CGA rule then angles the cone according to the windangle attribute; colors the cone on a greenToRed color ramp basis in according to the windspeed attribute.

The code:

attr windangle = 0

attr windspeed = 0

attr maxwindspeed = 6.75

attr windcolor = windspeed/maxwindspeed

Lot --> i("Arrow/Arrow_object.obj")

color(colorRamp ("greenToRed", windcolor))

s(200, 400, 200)

r(270,windangle,0) 

center(xz)

CGA Wind Rule applied in CityEngine

The Result

The result is a 3D web viewer where you can compare wind data (showing speed and direction) in a grid format, as it changes over time.