Area function in spreadsheet does not work for space objects anymore

[nahekul]

The area function in spreadsheets is not displaying space object areas in Vectorworks 2019. This has always worked in previous versions.
Formula in spreadsheet: =AREA((((L='Design Layer-1') & ('Space'.'11_Number'='R1'))))
Database still displays the space area correctly.
The area formula displays correctly for polygons or rectangles. 

 

Probable cause:
- Clicking on a polygon or rectangle will display the area in the OIP.
- Clicking on the space object does not display the area in the OIP. Where the area should be is blank.

V2019 Spreadsheet test.vwx

[Jonathan Pickup]

if I make a database report from scratch, I can use ='Space'.'EnergyArea' to give me the area of spaces. 

[Pat Stanford]

Or any of the following depending on your needs. The ones were the field name starts with 11 return a formatted text field. The others return a number of type Real.

 

'Space'.'Proposed Area'
'Space'.'Area'
'Space'.'Gross Area'
'Space'.'GSA BIM Area'
'Space'.'Custom Area'
'Space'.'11_Proposed Area'
'Space'.'11_Area'
'Space'.'SubtractionArea'        TEXT
'Space'.'SubtractionAreaNum'   REAL
'Space'.'MeasuredNetArea'        TEXT
'Space'.'MeasuredNetAreaNum'       REAL
'Space'.'11_Gross Area'
'Space'.'EnergyArea'
'Space'.'EnergyAreaFac'
'Space'.'SpaceCommon_NetPlannedArea'
'Space'.'SpaceOccupancyRequirements_AreaPerOccupant'
'Space'.'SpaceThermalDesign_BoundaryAreaHeatLoss'
 

[nahekul]

Yes, all the database functions still work. 

It is just the regular spreadsheet function (=AREA(('Space'.'11_Number'='X'))) that does not. 

This is due to the space object not displaying an area for the polygon in the OIP. 

 

[Pat Stanford]

That is correct. The Space object does not have an area that can be queried directly. It calculates all the different areas internally and you can them access them using the Record.Field format, but the Area (and probably Volume, and maybe the width, height, depth functions) will not return valid data for a Space object.

[nahekul]

On 10/1/2018 at 9:34 AM, Pat Stanford said:

That is correct. The Space object does not have an area that can be queried directly. It calculates all the different areas internally and you can them access them using the Record.Field format, but the Area (and probably Volume, and maybe the width, height, depth functions) will not return valid data for a Space object.

 

This has been fixed in Vectorworks 2019 SP2. 

Space objects now display the area correctly without the need to use the Record.Field format. 

[Pat Stanford]

@nahekul Thanks for continuing to check that out. And thanks to the development team at Vectorworks for making the changes necessary to have Space objects return the data expected.

[mgries]

I'm encountering a different problem related to calculating space areas, and have officially run out of brain cells on this. This seems totally screwed up to me, but I'm new to 2019, so maybe I'm missing something here...

 

When using 'Space'.'Area' in my worksheet, the values are getting multiplied by precisely 92903.384. See screenshot.

 

When using 'Space'.'11_Area', the area is reporting correct however, so there's no issue with my units or anything like that.

 

I'm trying to tabulate total areas of multiple spaces, so I need to be able to apply the SUM function to these values. The worksheet will not SUM the space areas when delivered via text field, so I need 'Space'.'Area' to work for this.

 

Also, can someone please tell me how the new database header option called "sum values" factors into any of this? Clicking this on or off doesn't seem to do much, other than add a little 'plus' symbol at the header.

 

please help me!

...and thank you!

Matt

 

[Pat Stanford]

Did you ever get this figured out? 

 

The 92903 number is about right for conversion of mm2 to ft2.

 

Check the Area Units in the Document Preferences. 

[mgries]

On 12/28/2018 at 10:05 AM, Pat Stanford said:

Did you ever get this figured out? 

 

The 92903 number is about right for conversion of mm2 to ft2.

 

Check the Area Units in the Document Preferences.

No, I'm still stuck with this. The document area units are set to sqft. Also realize that when using 'Space'.'11_Area', the area is reporting correct. So the units don't seem to be the issue. It's only when using 'Space'.'Area' that everything it goes haywire.

[Pat Stanford]

Can you post the file here or get me a link to it and I can take a look?

[mgries]

Thanks @Pat Stanford,

Here you go! The file contains a single space and a worksheet.

%22Space Area Number%22 function incorrectly reporting.vwx

[Pat Stanford]

It appears to be a bug in VW2019. I tested in SP2 and it I see the same as you. Please enter a bug report.  For the mean time, you can do the conversion manually

 

SQ MM to SQ Ft = (25.4 x 25.4 x 12 x12) = 93268.8 

 

Divide by that and you should have what you need.

 

 

 

 

[mgries]

2 hours ago, Pat Stanford said:

SQ MM to SQ Ft = (25.4 x 25.4 x 12 x12) = 93268.8

Pat, although this number is close, the values are getting multiplied by precisely 92903.384. There must be a little something else at work.

[Pat Stanford]

Maybe, but I know that the values are supposed to be stored internally as mm2.

 

By definition 25.4 mm = 1 inch. Therefore 25.4 x 25.4 = mm2 to In2

 

By definition 12 inch = 1 ft. Therefore 12 x 12 = 144 in2 to 1 ft2.

 

Are you sure all of them are scaling by exactly the same amount?  If so, then there is something else going on. If they are by different amounts, I would bet it is an effect of rounding somewhere in the floating point routines.

[mgries]

16 hours ago, Pat Stanford said:

Are you sure all of them are scaling by exactly the same amount?  If so, then there is something else going on. If they are by different amounts, I would bet it is an effect of rounding somewhere in the floating point routines.

yup,

Using the factor 92903.384, I can get all the correct areas to show up. I need to revise my initial statement though. It's not precisely  92903.384. The corrected values are only correct to the 1/100th decimal place. But to your point, whatever the fudge factor is, it seems to be consistent for all values. 

[Pat Stanford]

I did my original math wrong 25.4 x 25.4 x 12 x 12 = 92903.04

 

This is within 0.0004% of your value.

 

I will stand by my earlier statement that it is returning mm2 instead of ft2 and there is not any other factor involved other than rounding errors from the math functions used internally by VW. Digital math is rarely exact as not everything can be expressed as a power of 2. 😉

[mgries]

On 9/28/2018 at 10:50 PM, Pat Stanford said:

'Space'.'Proposed Area'
'Space'.'Area'
'Space'.'Gross Area'
'Space'.'GSA BIM Area'
'Space'.'Custom Area'
'Space'.'11_Proposed Area'
'Space'.'11_Area'
'Space'.'SubtractionArea'        TEXT
'Space'.'SubtractionAreaNum'   REAL
'Space'.'MeasuredNetArea'        TEXT
'Space'.'MeasuredNetAreaNum'       REAL
'Space'.'11_Gross Area'
'Space'.'EnergyArea'
'Space'.'EnergyAreaFac'
'Space'.'SpaceCommon_NetPlannedArea'
'Space'.'SpaceOccupancyRequirements_AreaPerOccupant'
'Space'.'SpaceThermalDesign_BoundaryAreaHeatLoss'

 

@Pat Stanford, you can add =AREA to this list!

After reporting my bug, tech wrote back to let me know they're on the case. They also offered a few alternatives to try, one of which was "=AREA". Works like a charm!

[Tim Harland]

Am I correct in thinking that the AREA function has been fixed but not the VOLUME? When I try and use the regular worksheet function 'Volume' to report the volume of spaces I get a 0 value returned? I can report volume with database rows (='Space'.'11_Volume' for example) but not in a regular function?