Property expressions. Add or substruct measured areas and user defined areas?

[Carlos Schwarz]

Hello everybody,

Not sure if someone has asked this already but I can't find it:

We are trying unsuccessfully to create a property with expression that would provide in a schedule the difference between a measured area and a target area. Is that possible? What we have done so far is to create a new property defined as "target area" and then we define that value in the properties of each zone, we want to have a schedule listing the "target". the "measured" and the "variance" areas.
The problem is that the expression gives as an error (indicated in red when we input the two properties), is it an issue with the type of data (value vs measurement) despite both are defined as areas? If so, is there any way around?

Thanks!
Carlos

[Laszlo Nagy]

Can you post a screenshot of these Expressions you have created? Then we can try the same and test it, see if we can come up with a solution.

[Tim Ball]

I have tried creating another property that converts area to a string, but it doesn’t seem very predictable and so far it’s not reliable.

Maybe some more examples from GS of how that procedure works would help. A basic conversion of any property to a number you can then use in a calculation would be a real help.

I have also found that when the conversion works, it will not add up in a schedule.

Maybe a webinar about expressions would help?

This is a potentially brilliant step forward but it will perhaps take time to understand the mathematical approach needed to make it work consistently.

[poco2013]

Tim wrote:
I have tried creating another property that converts area to a string, but it doesn’t seem very predictable and so far it’s not reliable.
Maybe some more examples from GS of how that procedure works would help. A basic conversion of any property to a number you can then use in a calculation would be a real help.
I have also found that when the conversion works, it will not add up in a schedule.

i have found expressions to be both predictable and reliable. But there are some very strict rules of usage.
Likely your just violating some rule without knowing why. If you submit some examples, i'm sure the problem areas could be cleared up. There are a number of limitations regarding expressions and most of the misunderstandings lie in that area.

The property units will always correctly add up in a schedule if the units are handled properly. e-mail me if you have any specific questions?

[Tim Ball]

Having checked the examples on the GS help site I can see the mistake I made, but I don't really understand the difference it makes. My maths dates from the early 70's and we didn't do these types of calculation then!

As an example I want to get a simple total build cost for my project so I have the following properties:

Build Cost Rate is a number

{Property:Zone/Measured Area} * {Property:Spec/Build Cost Rate}
that returns a total in m2
I have restricted the expression using the custom edit to apply to spaces only

then
STRCALCUNIT ( {Property:Spec/Area x Build Cost} )
that returns a total without units as a string
but in the zone schedule it will not add up
again restricted to spaces only

However if I change 1st expression to
{Property:Spec/Build Cost Rate}/ 1 m2 * {Property:Zone/Measured Area}
adding the / 1m2
it works fine and adds up in the schedule because its recognised as a number

So to convert the data to a number you can divide by the unit - is that right?

Next challenge is to create different build cot rates for different zone types and then use an IF to apply the formula

[poco2013 · Accepted solution]

Correct

To covert any unit to a raw number, just divide by the data unit as in: area/ 1 m2 or length/ 1 m, etc, Basically your just canceling out units. Schedules will not sum strings only numbers. Only similar data units as in ALL areas, volumes, or raw numbers. Remember raw numbers do not carry units. The end result must match the data type of the expression. Likewise, you can convert any raw number to a data type by just multiplying ( 25* 1 m = length) You can not mix units in a schedule sum.

You do not have to convert a data unit to a string to be summed in a schedule -- just that all unit must be the same. One problem is that Archicad does not have a currency data type -- so you have to use a raw number. If you want currency in your schedule as in $1234.00 you have to convert to a string and concat (join) the currency marker. No way to do that with a sum in a schedule - bummer.

On the plus side, you can mix imperial and metric units if the same dimension and Archicad will figure out the conversion.

[Tim Ball]

Thanks I came to the same conclusion about the unit cancel formula after I posted