Data Tag Field Syntax - Math

[AndrewBeres]

Hello, I am wondering if there is a data tag syntax guide floating around out there that I have not been able to find. I understand from other forum posts that worksheet functions are possibly accessible from data tags now? If this is true, I am not able to get them to function. Any help is greatly appreciated.

 

Here is my specific issue:

 

We have a data tag used for life safety plan calculations, pretty simple. We input the area factor and the use for each space and use the spaces area to calculate the number of occupants and display that in the tag. This works well, however we want to round the occupants up to the next integer value when there is a fraction. I have been able to round the number down, but per standard practice when calculating occupants you always take the number up to the next whole number(since you cannot have a fraction of an occupant in the building).

 

Inorder to complete the math for the number of occupants, we do (space.area) / (load factor). I have seen people add .49 to this so that the number will always round up, but after I do the addition of .49 I cannot seem to get the number to round. I have tried a few different ways to complete the =round() but none have work for me in a data tag. 

 

Here is my tag field definition:

#Space#.#AREA#/#Space#.#11_Proposed Area# +0.49

 

Here is the tag for reference (in this case i want the 8.743 to display as 9): 

 

Again, if there is a syntax guide out there I would love to have it for reference, otherwise any help with this specific problem is greatly appreciated. 

 

 

[bcd]

Try this:

#Space#.#11_Proposed Area##doc area_0_1#

 

[AndrewBeres]

23 minutes ago, bcd said:

Try this:

#Space#.#11_Proposed Area##doc area_0_1#

 

That works to get me the proposed area in a whole number, but i need to do the division (area / proposed area), and then round that number up to the next whole number. 

 

 

[Tom W.]

1 hour ago, AndrewBeres said:

I understand from other forum posts that worksheet functions are possibly accessible from data tags now? If this is true, I am not able to get them to function.

 

Anything placed between #WS_ and # will work in the tag as if written in a database worksheet row for the tagged object.

[bcd]

It looks like the Proposed Area #Space#.#11_Proposed Area# is being recorded as a real number rather than an area - so the division (& rounding) isn't working correctly.

Edited May 8, 2023 by bcd

[AndrewBeres]

That solved it. Thank you!

 

Here is the working field definition for record: 

#Space#.#AREA##doc area_0_1#/#Space#.#11_Proposed Area##doc area_0_1# +0.49

 

 

[Scott C. Parker]

Great data tag. Thanks for sharing the string. 

This reminds me of a venue that needed a label added near exit doors on a drawing to show the fire marshal how many inches of exit door opening were allotted to the total planned occupancy (number of chairs) of an event.

[kevin.hayward]

On 5/8/2023 at 2:46 PM, AndrewBeres said:

In order to complete the math for the number of occupants, we do (space.area) / (load factor). I have seen people add .49 to this so that the number will always round up, but after I do the addition of .49 I cannot seem to get the number to round. I have tried a few different ways to complete the =round() but none have work for me in a data tag. 

 

I use the +0.49 if I want to round to the nearest whole number. OK, this is pseudo code:

 

int((a/b)+0.49) is going to round the result to the nearest integer, up or down.

 

I think you'd need to add 0.99 to your result to ensure you always round up.

 

 

[AndrewBeres]

okay, i have another one for ya. Now we are creating a tag to calculate the number of occupants at a bar. (1 occupant per 24"). I am looking to draw a line and access the area then divide that by 24" and of course always round up. 

 

Here is my current definition which does everything except the addition of the 0.49. Wondering if this is a real number/document distance issue again.. any help is appreciated. 

 

#PERIM##in_2_0#/24+0.49

 

 

 

[AndrewBeres]

On 5/8/2023 at 11:32 AM, bcd said:

It looks like the Proposed Area #Space#.#11_Proposed Area# is being recorded as a real number rather than an area - so the division (& rounding) isn't working correctly.

 

okay, i have another one for ya. Now we are creating a tag to calculate the number of occupants at a bar. (1 occupant per 24" linear). I am looking to draw a line and access the perimeter then divide that by 24" and of course always round up. 

 

Here is my current definition which does everything except the addition of the 0.49. Wondering if this is a real number/document distance issue again.. any help is appreciated. 

 

#PERIM##in_2_0#/24+0.49

[hollister design Studio]

A bit off topic - I was sent here by @Jeff Prince

 

 

I'm trying to round a landscape area data tag and he mentioned you had listed the proper syntax here...

I'm not quite getting where the rounding formula is stated anywhere above.

 

 

The suggested formula by the 'define tag field' menu is:

 

 #Landscape Area#.#area##prec_0#

 

After looking at all your posts I tried #prec_0_2# but that just adds a "_2" to the end.

 

I tried throwing "round" into the equation in various places, but no success.

 

 Any thoughts?

 

 

 

On 5/8/2023 at 6:46 AM, AndrewBeres said:

...I am wondering if there is a data tag syntax guide floating around out there that I have not been able to find...

 

An official guild would be so helpful - as it is now, those of us that are trying to learn syntax are at the mercy of the old guard - usually @Pat Stanford - taking the time to help out.

Pat is great, and very responsive, but he can't be the only source - the man has to sleep sometimes!

[Tom W.]

In a Data Tag try #WS_(INT(AREA/10)*10)+10# SqFt to round up to nearest 10 or #WS_(INT(AREA/100)*100)+100# SqFt to round up to nearest 100.

 

 

[hollister design Studio]

Thanks Tom

 

I changed the formula to:

 #Landscape Area#.#area##WS_(INT(AREA/10)*10)+10# SqFt

 

I got this result:

 

Unfortunately, no rounding at all.

[Tom W.]

Don't change the formula. You can't combine Data Tag functions + Worksheet functions.

[Pat Stanford]

On 5/3/2024 at 10:52 AM, hollister design Studio said:

#Landscape Area#.#area##WS_(INT(AREA/10)*10)+10# SqFt

I think you are displaying the 'Landscape Area'.'Area' from the first part and the formula in the WS_ is incorrect.

 

Try:

 

#WS_Int('Landscape Area'.'Area'/10)*10+10# SqFt

 

Which is very close to @Tom W.'s suggestion.

 

For trouble shooting, include both lines in the Data Tag Definition to make sure you are getting what you want. This is what I used in testing. Each line in the Tag Define Tag Field dialog box will display as a separate line in the tag.  Start simple and work toward the eventual goal.

 

[Tom W.]

26 minutes ago, Pat Stanford said:

 

Try:

 

#WS_Int('Landscape Area'.'Area'/10)*10+10# SqFt

 

That's a good point. Presumably 'area' just gives you the 2D area whereas 'landscape area.area' gives you the 3D surface area... which may or may not be an issue depending on the circumstances 

[hollister design Studio]

19 hours ago, Pat Stanford said:

For trouble shooting, include both lines in the Data Tag Definition to make sure you are getting what you want.

This is a great suggestion!

I was getting frustrated having to edit, save changes and get back to the main design space - and then not have it work and redo the whole process.

This is so simple - thank you!

 

And thanks for the verbiage!

[DBruhnke]

On 9/20/2023 at 3:46 PM, AndrewBeres said:

 

okay, i have another one for ya. Now we are creating a tag to calculate the number of occupants at a bar. (1 occupant per 24" linear). I am looking to draw a line and access the perimeter then divide that by 24" and of course always round up. 

 

Here is my current definition which does everything except the addition of the 0.49. Wondering if this is a real number/document distance issue again.. any help is appreciated. 

 

#PERIM##in_2_0#/24+0.49

@AndrewBeres Came here looking for this exact issue.

Have been trying to get the #WS_ROUNDDOWN to work

Since the length of a booth at 49" will not fit 3 humans, we always round down.

 

This DT Formula works using the length of the line.

#WS_ROUNDDOWN((LENGTH/2), 0)# OCC#

Divide by 2 feet (24") because I'm not sure how to extract "LENGTH" as inches

If you disagree with the ROUNDDOWN, you can always set it up to ROUNDUP

 

When using the exact same formula using PERIM, it fails on lines but works on polylines (rectangles too) for some reason.

#WS_ROUNDDOWN((PERIM/2), 0)# OCC#

Not sure why adding the ROUNDDOWN for PERIM fails on lines. Because you can use PERIM on a line to extract the length.

It's only the addition of the #WS_ that causes the issue.

More than likely it's operator error.

[Pat Stanford]

I think the problem is the OCC#.

 

The Octothorpe (#) is used as the delimiter in Data Tags to specify what is data fields.  

 

You look like you are trying to use it just as part of a text string, but the interpreter is looking at it and saying the # are unbalanced.

 

Try:

#WS_ROUNDDOWN((PERIM/2), 0)# OCC NUM 

 

and see if that works.  If it does and you really really want to display as OCC# let me know and I will see if we can figure out a way to make it happen.

[DBruhnke]

13 hours ago, Pat Stanford said:

If it does and you really really want to display as OCC# let me know and I will see if we can figure out a way to make it happen.

@Pat Stanford Thanks for the reply.

Surprisingly, with the # at the end or removed the text (OCC) still appears. Perhaps due to the space added in front of the text?

Either with or without, the PERIM function appears to not provide results for lines.

The formula is working on polylines and rectangles. Just not for lines.

Example File with test DataTag for reference.

This one was created for bench seating at 18"

DataTag PERIM Line 2024-08-15.vwx

[Pat Stanford]

Use Length instead of Perm.

 

I have not looked at your file. I will try to take a look later today.

[DBruhnke]

On 8/15/2024 at 9:50 AM, Pat Stanford said:

Use Length instead of Perm.

 

That's what we are doing and so far, no issues.

Apparently a line does not have a perimeter. 😉