How do I find Building Footprint area

[DuliniRatnayake]

Hi,

I would like to know how I can get the area for building footprint created using another rule. eg.  the footprint area generated at FootPrintReach.

Thank you.

Dulini

[DavidWasserman]

Hi Dulini!

If I understand the question you are trying to get the parcel area passed to the footprint rule you created? You could try passing the area as a parameter to the next rule. For example:

Parcel-->

   setback (front_setback){street.front:NIL:remainder: FootprintRule(geometry.area)}

FootprintRule(ParcelArea)-->

    do_stuff_with(ParcelArea)

    extrude(X)

Etc. 
Or are you asking how do you determine the area of the footprint within the Parcel rule? That might be a little more difficult because the footprint rule cannot tell the parcel rule what its area is. Information cannot be sent back up the shape hierarchy. Usually we get around this with some math, python (reports API), or setting global variables in CGA. 

What is the goal generally? Just trying to understand the question. 

David

[DuliniRatnayake]

Thank you David.

I am trying to create massing for each parcel based on lot coverage and FAR , but the it should consider the setbacks to determine the building footprint area to get the building height.

As you mentioned, footprint area needs to be input to parcel rule, so how do I set global variables?

Thank you again.

Dulini

[DavidWasserman]

Ah then my first suggestion might not be in that direction. I saw an earlier thread you participated in and that had some more context. There are rules that do something like this that might be a good model. I think in the Complete Streets 2015 Project there is a Target GFA rule that does something similar. 
One idea is to use the information about the footprint and you have a target far, it might be possible to round the height to the nearest resulting area. If you want to get fancy, you could even try to have the last floor deal with rounding error with additional setbacks based on the ratios of area loss from the first set of setbacks (maybe, it won't be exact, nor should it be, buildings don't have 10 square foot top floors). The rule below does not do exactly what you are asking for, but it creates a pattern to achieve a similar goal. I can work on a better example later if this does not get  you where you want to go. 

So I understand, the goal is to determine the height of a building based on target FAR, with setbacks already understood. Essentially a rule to understand the tradeoffs between setbacks/ footprint area and a target FAR? 

/**
* File: Simple_Massing_Model_by_GFA.cga
* Created: 17 Feb 2014 08:54:32 GMT
* Author: Esri
*/

version "2014.1"

attr Floor_Height = 3.2
attr Gross_Floor_Area = 10000

@Hidden
attr gfaLeft = 0
@Hidden
attr volumeLeft = 0

gfaFromVolume(vol) = vol/ Floor_Height

Init -->
alignScopeToAxes(y)
set(volumeLeft,geometry.volume())
set(gfaLeft, Gross_Floor_Area )
print("Current Volume: " + volumeLeft)
print("Theoretical GFA: " + gfaFromVolume(volumeLeft))
print("Target GFA: " + Gross_Floor_Area )
Mass


Mass -->
case gfaLeft > geometry.area(bottom) && scope.sy < Floor_Height *1.1:
s('1, Floor_Height ,'1) Floor
set(gfaLeft,gfaLeft-geometry.area(bottom))
color(0,1,0)
t(0, Floor_Height ,0) Mass
case gfaLeft > 0:
set(gfaLeft,gfaLeft-geometry.area(bottom))
# color(0,0,1)
split(y){ Floor_Height : Floor
| ~1: Mass }

else:
color(1,0,0)
asdf.

[DuliniRatnayake]

Hi David,

My rule is little bit complicated.I want to change the footprint area as setback parameters changes.

If you check the code below, I want to populated the Area2 with the number from AREAS2 at "reports" .

attr AREA = geometry.area #PARCEL AREA

@Group("SetBacks:")
attr frontSetback = 10
attr backSetback = 5
attr sideSetback = 3
attr FAR = 0

@Group("Area:" )
attr GFloor = AREA*FAR #GROSS FLOOR AREA BASE ON PROVIDED FAR
attr LCover = AREA2 #LOT COVERED BY THE BUILDING(if get from shapefile)

@Group("Heights: ")
attr GFHeight = 5.5
attr UFHeight = 3.5

@Range ("transparent", "as is", "top and side")
attr vizMode = "as is"

@StartRule
Parcel -->
set ( AREA, geometry.area )
report ("AREA", AREA)
setback(frontSetback) { street.front : NIL | remainder :
setback(backSetback) { street.back : NIL | remainder :
setback(sideSetback) { street.side : NIL | remainder :
FootprintReach
}
}
}

attr AREA2 = 0 #FOOTPRINT AREA
attr buildingHeight = GFloor/AREA2*UFHeight

FootprintReach -->
set(AREA2, geometry.area)
report("AREA2", geometry.area)
extrude(world.y, GFloor/AREA2*UFHeight)
split(y) { GFHeight : Volume("GF") | ~1 : UpperFloors }

UpperFloors -->
split(y) { ~ UFHeight : Volume("UF") } *

Volume(volumeType) -->
case volumeType == "GF" :
color(0,1,0)
Visualization
else :
color(0,0,1)
Visualization

Visualization -->
case vizMode == "as is" :
Done.
case vizMode == "transparent" :
set (material.opacity, 0.8
)
Done.
else :
comp(f) {top : Top. | side : Side. | all : NIL }

Thank you.

Dulini 

[DavidWasserman]

Hi Dulini, 

This comes back to what I mentioned before about not being able to move back up the shape hierarchy. The information about the footprint area is not capable of being piped back up to the parcel level where footprints are being determined. I could be misunderstanding the exercise still though. 
It might be possible to modify one setback or all the setbacks by doing a setback a very small amount and look at the change in area between each setback. I am thinking you could get the information you need at basically the parcel level to make a guess on the setbacks...
This won't be exact, but you could theoretically use some combination of the geometry functions (perimeter-area ratios, planar vs non planar polygons) to deve... This could be fairly simple for rectangular polygons, but less compact shapes would become increasingly difficult to predict/extrapolate how changes in setback impact footprint area. Again this would not be exact, but could lead to limited yet workable CGA solution...This is just an idea for an approach not an actual implementation (I can take a look at it later, might be just an idea).

Idea would be: 

attr frontsetback_area_change_per_increment=0 #Assumes change in area would be constant per increment
attr function_track_change(params)= do_stuff
Parcel-->

   SetbackFront(geometry.area())

SetbackFront(parcelarea)-->
   Setback(.1) {front:PreParcelCalc1(ParcelArea)}

PreParcelCalc1-->
   frontsetback_area_change_per_increment=parcel_area-geometry.area()/.1 (change)

   Setback(.1) {right:....}

This looking at it, is an interesting idea, but I could see some pretty ruthless criticism on the complex geometry side of this idea. Clearly reductions in area to a setback would not be linear in a lot of cases and doing this for multiple setbacks could  bias the area calcs with previous changes in geometry. Also the smaller the number you use for the setback the more likely floating point arithmetic is going to be annoying to deal with. I am not even sure the idea works because the the interdependence between all the setback areas (a front setback done first would reduce the marginal area reduction caused by a side setback). There might be some way to account for that. 

Other solutions involve using loops/recursion in the python API to look at your reports for footprint area after a generation and adjust the setbacks accordingly. This would generalize across geometries. 

[DuliniRatnayake]

Thank you very much for you valuable input.

[LR]

You have to add reporting code to the rule that creates the area, e.g. like this:

attr AreaWhole = 0
attr AreaPart1 = 0
attr AreaPart2 = 0

@StartRule
Lot -->
 set(AreaWhole, geometry.area) 
 report ("AreaWhole", AreaWhole)
 split(z){scope.sz/2: Part1 | scope.sz/2: Part2}
 
Part1 -->
 color(1,0,0)
 set(AreaPart1, geometry.area) 
 report ("AreaPart1", AreaPart1)

Part2 -->
 color(0,1,0)
 set(AreaPart2, geometry.area) 
 report ("AreaPart2", AreaPart2)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[DuliniRatnayake]

Thank you.

I am going to give this a try.....