Jump to content
nahekul

Area function in spreadsheet does not work for space objects anymore

Jim Wilson

Issue resolved in 2019 SP2

Message added by Jim Wilson

Recommended Posts

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

Screen Shot 2018-09-28 at 3.02.52 PM.png

Screen Shot 2018-09-28 at 3.02.43 PM.png

Screen Shot 2018-09-28 at 3.02.17 PM.png

Share this post


Link to post

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'
 

Share this post


Link to post

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

 

Share this post


Link to post

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.

Share this post


Link to post
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. 

  • Like 1

Share this post


Link to post

@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.

Share this post


Link to post

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

 

space_areas_WTF.png

space_areas_WTF.png

Share this post


Link to post

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. 

Share this post


Link to post
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.

Share this post


Link to post

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.

 

 

 

 

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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. 

Share this post


Link to post

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. 😉

Share this post


Link to post
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!

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×