Issue #1,069 | The Business Side of CAD | October 12, 2020
Click to subscribe by email
by Dave Edwards and Matt Stachoni
Dave Edwards: Even with a common file format, things are nearly impossible without a common data format or at least common data naming.
Case in point: I hand my architectural model to a furnishing consultant and to a medical planner. They use their own developed libraries of content; each could have data fields for the same information using different names. Once I receive the model back, how do I then combine the fields to do scheduling and cost analysis.
Matt Stachoni: Using Revit? It's relatively easy. Furniture and medical equipment consultants/vendors often use Revit family libraries from the manufacturers of the products they sell. Any manufacturer who develops a bespoke content library for professional use will likely implement their custom data as a series of Shared Parameters within the families.
Shared Parameters are designed to be shared between multiple projects and families, scheduled, filtered, exported to ODBC, appear in tags, and so on, so standardization is a key planning item. Within a given vendor library, the Shared Parameters should be the same, so you should not have one furniture family with a "Desk Width" parameter and another with a "Width of Desk" or "Desk is This Many Inches Wide" parameter or other such nonsense.
Disclaimer: I'm not guaranteeing anything, obviously. Revit users are just as capable as AutoCAD users of doing horrible, horrible things, but in this case it's actually more work to do it wrong. Custom family parameters which are not Shared cannot be scheduled or used in tags, so it's in their best interest to use standardized Shared Parameters just to get their work done.
You should be able to simply link the furniture model into your architectural model and create a schedule of furniture/equipment, and have those proprietary Shared Parameters exposed in the schedule creation dialog box. Just be sure to check the "Include elements in links" box at the bottom of the Fields tab. You can also combine parameters to appear in a single cell of a schedule as well.
Of course, there is no standardization between manufacturers, so if you have three different furniture manufacturers on a job you could end up with the "Desk Width" / "Width of Desk" / "Desk is This Many Inches Wide" nightmare.
You cannot rename Shared Parameters within a project, but you can rename parameters (fields) to a standard name in the schedules, so you may have to create separate schedules per manufacturer. You could export the schedules to Excel and combine them there to create a master, and/or use Dynamo to perform some home-brewed hocus-pocus to get the results you need.
Dave Edwards: Thanks for the response. I was familiar with most of those workarounds, but they can be a pain. And during my time as a BIM Manager, they weren't all available (such as combining fields in a Schedule).
Using a single set of Shared Parameters by multiple firms often never has the chance to happen because-- shared with whom? If you're a consultant working with many architects, which set of Shared Parameters to do you use to create yours with? As in your example, having no naming standard can be horrible to overcome and I ran into that often.
What I proposed (many, many years ago) was a Linked Parameter Mapping Table. You could assign a table which mapped the names of Parameters to a set of standard names when it was attached any file you had linked into your project. This would require a bit of setup, but could then be used on multiple projects with the same consultant in the future. Schedules using Libraries created with a divergent set of Parameters could be created using standard Revit procedures, etc. Not a great solution, but one which wouldn't require Libraries to have been built (or rebuilt) with the same Shared Parameters or any external data manipulation.
Matt Stachoni: Yeah, combining fields in a schedule is fairly new, and of course there's always Dynamo for stuff Revit doesn't do out of the box if you have the 3,024 hours to learn it.
But there's no compelling reason to expect anyone's Shared Parameters name will match anyone else's name. Unless they came from the same Shared Parameters file definition, two parameters from different projects (even with the same name) are completely different parameters from Revit's standpoint, and you cannot ever create a schedule with such parameters that would appear in the same column. That's not how Revit's parameter subsystem works.
Remember that the Family Editor environment is completely outside of the Revit Project environment, and the two do not talk to each other. The term Shared Parameter doesn't imply anything beyond the ability for that parameter to work in families, including tags, and be exposed in the project environment for scheduling. That's it. It has nothing to do with what company you belong to or your business relationship with anyone else.
As a furniture manufacturer or consultant working with many architects, the only Shared Parameters I'm worried about are the ones I need to create for my families. I may or may not use an internal standard naming system, but that's just to make my life easier.
Family Parameters that you define in the Family Editor cannot be exposed to the project as a whole, except from within the family's Type Parameters palette/dialog or as instance parameters you can view/edit in the Properties Palette. You cannot schedule a Family Parameter or include it in a tag, because neither the schedule nor the tag family knows what you are talking about.
Likewise, you can assign a Project Parameter to a category, which is then present in every element instance within that category, but only inside of the project environment. For example, if you add a Project parameter called "Door Panel Type" to the Doors category, you can then add data to it when you select any door, as well as schedule it (because the project understands that parameter), but the parameter does not appear in the family editor, nor can you add that parameter to a tag family because, as with Family Parameters, Revit doesn't know what you are talking about outside of the project.
Shared Parameters bridge that gap. When you define a Shared Parameter in the Shared Parameters dialog, it is best to think of it as essentially defining a dictionary entry. The Shared Parameters File contains all of the SP "definitions" each of which contain a few pertinent pieces of information:
· The Revit GUID [globally unique identifier]
· The parameter name
· Its data type
· Optional description
· And so on
The Shared Parameter GUID ensures each Shared Parameter in existence has its own unique 32-bit identifier number, which is the only thing Revit really cares about with any parameter you create. That's how you can create a hundred valid Shared Parameters with the same name, data type, description, and so on; Revit is only ever concerned with the GUID and the name doesn't matter.
· When you add a Shared Parameter to a component family, you pull in the GUID information so it understands the parameter fully.
· When you create a tag for that component, you also pull in the same Shared Parameter data (i.e. GUID) so both the tag and the family are able to reference exactly the same information.
· When you bring the family into the project, the Shared Parameter comes along for the ride and is exposed to the project, and every case of this Shared Parameter has the same GUID no matter the context, which is what Revit needs and is how you can schedule and tag it.
There is nothing special about the Shared Parameters file itself, except that it stores the complete list of Shared Parameter definitions you typically use in your projects. Shared Parameters are a one-way street from the Shared Parameters file to the project or family.
Changes to the Shared Parameters file (the "definitions") do not update themselves in the project or families, so you would need to get it right the first time, or spend lots of hours redefining the parameter in every family you previously created (one argument for organizing and standardizing Shared Parameters when creating a manufacturer library _before_ you model anything). You can also delete the Shared Parameters file, then go to Shared Parameters and export every Shared Parameter in your project or family out to a new file which is one way to get foreign Shared Parameters into your content.
Thus, naming standards may be nice to have but aren't really required for the end user. A manufacturer's standard convention may be to prefix all of their Shared Parameters with a 2-3 letter prefix, e.g. "ES-" for Global Industry's "Evolve Systems" line, which identifies those Shared Parameters as their's to the uninitiated.
As long as you can keep the manufacturer's parameters differentiated from one another (so you aren't dealing with multiple copies of the same parameter name), you should be OK. But expecting every manufacturer to use one standard would be ridiculous and unworkable, and in the end it's simply not required anyway. The only use case I could see is where you want to schedule all of the furniture and want the same set of parameter names to be used for size, cost, and so on. But like I said, if you filter your schedules by manufacturer and modify the field header text, you are 99.9% there without any Dynamo gizmodic jiggerwaddling.
Alternatively, you could create a single schedule that has everyone's pricing parameter fields (which are all different), and group everyone's price parameters under a single "COST" heading and change each manufacturer's pricing parameter header name to the manufacturer's name.
- - -
Dave Edwards heads up Dave Edwards Consulting, while Matt Stachoni is BIM Manager at Tutor Perini Building.
And in Other News
Here are some of the posts that appeared on our WorldCAD Access blog recently:
· Standards for collecting point cloud data
worldcadaccess.com/blog/2020/09/standards-for-collecting-point-cloud-data.html
· A.I. for classifying point clouds
worldcadaccess.com/blog/2020/09/aiforclassifyingpointclouds.html
You can subscribe to the WorldCAD Access blog RSS feed through feeds.feedburner.com/WorldcadAccess.
Letters to the Editor
I read your reader's comment about the Generic CADD ebook and your reply, and realized I'm still earning a few dollars from my 2003 book on AutoLISP and the 2011 update. That buys me a cup of coffee every month, and I love coffee.
To whomever is purchasing my Kindle books: thank you! I don't know if Autodesk will ever invest in LISP again, but it was fun while they did.
- David Stein
The editor replies: It is helpful when an AutoCAD function doesn't change. My biggest selling ebook was on dynamic blocks, which haven't changed in a decade. Today, I do bespoke ebooks, where a CAD company pays me a lump sum to write a book specific to them.
Mr Stein responds: I wasn't aware that was even a thing. That makes sense, from a marketing aspect. Nice!
Re: Addressing the problems of digital twins
In constructech we see change, possibilities for efficiency, and an explosion of hype. The core issue with "twins" is the core challenge of tech in construction: understanding the difference between physical reality and the data that describes it.
If I create a full-scale animotronic version of myself (a la Disney or 19th century automatons) is that my "twin"?
-Leo Schlosberg (via WorldCAD Access)
Re: Open Design Alliance opens up the Revit file format
I am looking for ways of reading or writing a Revit file formats. Could you please provide any information regarding the above and if there is any documentation available?
- A.B., England
The editor replies: This is the only source for reading and writing Revit files independently of Revit: https://www.opendesign.com/products/bimrv
To date, the read side is well implemented, the write side is a more difficult project and is only partially available. Note that this is for writing your own software. If you don't want to do that, then consider a CAD program that reads RVT files, such as BricsCAD V21 (due out end of October), ARES 2020, and other programs that have implemented RVT-read
Re: When the cursor gets erratic, it's the mouse's nano-receiver at fault
Let me add an interesting, contemporary twist to this problem. As has been much described in these comments, my Logitech M705 started misbehaving and became almost impossible to use. Changed the batteries to no avail.
Decided to Google the problem and found this thread as a result. After reading all the original post and subsequent comments, I decided to try the USB extender cord. While preparing to do so, realized I had installed a Cam Link 4K [for connecting cameras live to computers] in the USB port adjacent to the Logitech receiver. Unplugging the Cam Link, instantly the mouse resumed its normal behavior with no problems. Reinstalled the Cam Link and the mouse's erratic behavior immediately returned.
I moved the Cam Link device to another USB port away from the Logitech receiver. Problem solved!
- Ed (via WorldCAD Access)
- - -
My Logitech MX Master 2s started to act sporadic on my Macbook Pro. Instead of continuing to use the unifying receiver and/or extension cables, I merely went to the Mouse preferences and hooked it up as a bluetooth mouse.
Now it is working fine, and I have a spare useless receiver in a drawer.
- Scott Duchin (via WorldCAD Access)
Thank You, Readers
Thank you to readers who donate towards the operation of upFront.eZine:
· Malcolm Davies: "Thank you for continuing your interesting. newsletter. Stay well!"
· Robert Sweeney
To support upFront.eZine through PayPal, then the suggested amounts are these:
· $25 for individuals > paypal.me/upfrontezine/25
· $150 for small companies > paypal.me/upfrontezine/150
· $750 for large companies > paypal.me/upfrontezine/750
Should Paypal.me not operate in your country, then please use www.paypal.com and the account of grabowski@telus.net.
Or mail a cheque (US$ or CDN$ only, please) to upFront.eZine Publishing, Ltd., 34486 Donlyn Avenue, Abbotsford BC, V2S 4W7, Canada.
Contact!
upFront.eZine is published most Mondays. This newsletter is read by nearly 5,000 subscribers in 70 countries. Your comments are welcome at grabowski@telus.net; deadline for submissions is every Saturday morning. Letters sent to the editor are subject to publication. Read our back issues at www.upfrontezine.com.
Editor: Ralph Grabowski
Copy editor: Heather MacKenzie
Advertising starts at US$680 per two weeks. Wanted ads by the unemployed are free. Other rates available. To request a copy of our media kit, download your copy of the PDF from upFront-Media-Kit.pdf. Article reprint fee: $420. Contact grabowski@telus.net for advertising.
· To subscribe, send the message 'subscribe upfront' to grabowski@telus.net.
· To change your address, send both your old and new email addresses to grabowski@telus.net.
· To unsubscribe, see instructions below.
*4805
About
Copyright © 2020 by upFront.eZine Publishing, Ltd. All rights reserved.
Legal. All trademarks belong to their respective holders. "upFront.eZine," "The Business of CAD," and "WorldCAD Access" are trademarks of upFront.eZine Publishing, Ltd. Letters to the editor may be edited for clarity and brevity. Translations and opinions expressed are not necessarily shared by upFront.eZine Publishing, Ltd.
By accessing this newsletter in any manner, you agree to settle disputes by arbitration within the city limits of Abbortsford, British Columbia, Canada with an arbitrator selected by upFront.eZine Publishing, Ltd.
Our mailing address:
upFront.eZine Publishing, Ltd.
34486 Donlyn Avenue
Abbotsford BC
V2S 4W7
Comments