topic Re: PROPERTIES: Issues just getting started in Project data & BIM

PROPERTIES: Issues just getting started

Aurasphere — Sun, 11 Feb 2024 18:27:18 GMT

Well after decades using listing...one of the best but cubmersome features, I am trying to migrate stuff to using properties which the first couple of tuts...well it couldnt do it without fudging eg Room Illumination...but thats another issue (you CANNOT easily run priced BOQ from properties

I am simply trying to do the following but Im not getting something about the flow of datatypes and its certainly not obvious or friendly from my perspective but maybe its the siltation from listings

1. I choose area datatype and do a basic if statement to extract gross site area from a zone

Error!

Re: PROPERTIES: Issues just getting started

Toper Barrientos — Thu, 08 Feb 2024 05:16:52 GMT

HI.. YOU need to include area unit to 0.00 value.. e.g 0.00m2 , or 0.00ft2,etc in order to match all your variable types.

fr here :

Re: PROPERTIES: Issues just getting started

Barry Kelly — Thu, 08 Feb 2024 05:27:48 GMT

It is just a small thing but easy to miss - the units for all outcomes must be an area.

IF (Zone Category= "Site", Calculated Area, 0 m2 )

If the zone category is not "Site", then it must be 0m² and not just 0.

Barry.

Re: PROPERTIES: Issues just getting started

Aurasphere — Thu, 08 Feb 2024 05:27:48 GMT

Cheers

Never had to deal with supplying formatted datatypes...weird from previous ie GDL

so an appended eg 'm2' applies the formatting...interesting

I watched a bunch of GS vids on youtube and I dont recall seeing any of this...but I had on 1.5x

Thanks

Re: PROPERTIES: Issues just getting started

Barry Kelly — Thu, 08 Feb 2024 05:29:13 GMT

@Toper Barrientos ,

You beat me to it!

Barry.

Re: PROPERTIES: Issues just getting started

Aurasphere — Thu, 08 Feb 2024 05:29:25 GMT

Thanks

ok but you dont have to cast the type though right? ie 0.0

I thought GS always used FP which is why FP = FP was always a no no

It would have been good for the vids to make this very easily missed point clear

Re: PROPERTIES: Issues just getting started

Toper Barrientos — Thu, 08 Feb 2024 05:47:46 GMT

@Aurasphere , @Barry Kelly 🙂

let's just say GDL has its rules.. as well as expression-based properties has its own.

something an State has its own jurisdiction.. "i should adhere to their rules-- else i suffer"

I wonder why GS cudnt make a global ruling for this. 🙂 , nonetheless--pretty enjoyable to dabble on this.

Re: PROPERTIES: Issues just getting started

Toper Barrientos — Sun, 11 Feb 2024 18:39:11 GMT

In reverse, when deriving a linear value ,e.g--say fr a volume unit data , u wud need to cancel unit area like>>"volume/m2" to make the result become a length value. OR say a unitless value = "volume/1M3" .. very tricky indeed.

Re: PROPERTIES: Issues just getting started

poco2013 — Thu, 08 Feb 2024 05:56:29 GMT

FYI: To add to which everyone has already said: In any expression, Archicad first error checks the expression by first checking that all return values are applicable (classified) for the intended element type, then checks if all return units match that selected as the return unit. If any variable fails, the expression is deemed invalid. It does not matter if a variable can not be reached in the logic.

There are also occasions when you just want to return a number, as in returning a calculated currency value based on area or length, etc.. In that case, you simply divide out the final unit to return no units. i.e. (area m2/ 1 m2) -- returns just a number. Archicad does not have a currency unit -- so you have return a number or convert it to a string

Re: PROPERTIES: Issues just getting started

Aurasphere — Thu, 08 Feb 2024 06:05:30 GMT

I think the frustration for me is that its still using all the formatting for strings etc and very familiar but STR is left out. To make is more confusing, it seems that its looking for the subscript as the cast identifier...even weirder

I can see properties could be very good but relying on the pipelines of data that are either still incomplete or dont work; re the yt room illumination example

It is just not even close to a listing replacement but it seems suitable for other kernel like piping

BUT

you can access any of it via GDL and STILL cant access project info other than wrapping it

Re: PROPERTIES: Issues just getting started

poco2013 — Thu, 08 Feb 2024 06:25:45 GMT

Expressions do have a couple of string handling functions to make the conversion easier, but formatting the expression to obey all the rules, can be very cumbersome and confusing. A much easier approach and perfect for calculating illumination considering different types of bulbs and different room criteria is to use a Python script which can address all properties and account for all criteria. The downside of Python scripts is that they are manually initiated and can not write to the schedules. You can, however, create and format a external schedule and then copy/paste that into Archicad layouts as a figure. Again a manual operation. Not quite what you want. i think we all miss the versatility of the List schedules

Re: PROPERTIES: Issues just getting started

Aurasphere — Thu, 08 Feb 2024 06:32:06 GMT

The room illumination issue wont be fixed with python because the api is so limited and as far as I know is also missing the info to make it work...properly. Try using glazed doors and differentiating them to contribute to the illumination...to start with.

My point about lists is nothing like illumination...I had fully priced BOQ with orders running out of archicad as well as direct write to text file linked into builders orders and account database...there are no new tools even come close to replacing it. Pity...i first saw a German project using it which inspired me and spent a couple of years doing it...anyway...is what it is. Full pricing updates done in excel, written to the costings text file that archicad was using....soo good.

Re: PROPERTIES: Issues just getting started

poco2013 — Thu, 08 Feb 2024 13:42:07 GMT

Obviously,I am not understanding your question. I mentioned illumination because you did. But i recognize that your aim in calculation is not what I had assumed. I only mentioned the same since i did created a illumination application years ago to calculate room illumination and power usage based on industry standards. - a simple task with the limitations noted above. I should also point out that everything that is available to the C++ API is also available to the Python API, abet with degrees of effort, which is the "rub". Obviously, Python can not calculate the illumination through glass because that info is not available to Archicad. (unless,of course, that info is embedded in the GSM object). However, Python does have easy read/write access to excel files, SQL/JSON databases and has its own native GUI (tkinter) ability. But it has limited or no ability to write to Archicad other than through custom properties, which is also by design by Graphisoft. Perhaps, more info would help us and Graphisoft understand your requirements?

Re: PROPERTIES: Issues just getting started

Aurasphere — Thu, 08 Feb 2024 20:25:52 GMT

Sounds like a great app that you did.

My point was more about things appearing great but when you start drilling the detail...well they can appear 'half baked'

Im not a great programmer but more about creating the abstract principles of operation based on overview...

With the api, I believe the C++ has access to a lot more...what I have seen of Python...it seems to be quite limited

eg I want to create a simple toggle to switch MVO?

Nothing to get to it.

The legacy listing is perfect although a WYSIWG editor for the graphic formatting would have made it a much bigger success

Cheers and thanks for the interest

Re: PROPERTIES: Issues just getting started

Aurasphere — Thu, 15 Feb 2024 20:10:25 GMT

So what about the other way around?

Im trying to create a number but part of the expression is volume...why is this error happening...do I have to cast it somehow?

Re: PROPERTIES: Issues just getting started

Barry Kelly — Thu, 15 Feb 2024 20:10:47 GMT

If you want the output to be a number, then you have to convert your volume to a number by dividing it by 1m³.

Barry.

Re: PROPERTIES: Issues just getting started

Aurasphere — Wed, 14 Feb 2024 05:24:16 GMT

Thanks again Barry; appreciate it.

And everyone is ok with this???...Ive done a lot of languages but this is...well just crazy... forces me to go back to GDL/Listing. Its just madness 😞

Let everything be an FP and convert on output...seriously.

I would have words to the devs after the usual path of passing it on to newbs for evaluation and testing...right?

Re: PROPERTIES: Issues just getting started

Aurasphere — Thu, 15 Feb 2024 20:12:31 GMT

Back to gdl...except it looks like you can interrogate sub components of a complex wall in the schedules...but only front and rear...or components but seems no way in GDL???

Has anyone actually used of this for serious scheduling

eg Masonry is calculated on volume

I need to interrogate every element that contains a particular masonry building element volume

Then do the calcs to get unit numbers...

EDIT: On top of that, if the wall is a custom complex profile, then there is no name for the sub components...why?

GDL:

Anyone?

Re: PROPERTIES: Issues just getting started

Aurasphere — Thu, 15 Feb 2024 20:15:11 GMT

Sorry I dont mean to be rude in any way...just so frustrated that simple stuff is so overly complex and has not been factored down by good abstract design

Im actually just trying to get the surface area of a sub component in complex wall but looks like its not going to be simple...of course Im missing something but like I said...why is it not refined?

So in this case below, why would it still be in error?

and based on the logic of the example provided, here ie target = area, therefore I need to divide by 1m3 (as unit) and then convert that to m2 for target format?

Re: PROPERTIES: Issues just getting started

poco2013 — Wed, 14 Feb 2024 23:34:03 GMT

I believe your missing a multiplication sign between your cal and 1 m