Let’s discuss a couple of questions that accumulated recently on various aspects of properties in general:
- Properties in DWF export
- Mapping Revit and IFC properties
- Storing a table in a project
- Updating versus adding new extensible storage schemas
Before getting to that, I’ll briefly mention the happy fact that I yesterday went on my first outdoor climb for a while, up the Balmflue south ridge, a nice long route of 16 rope lengths in the Swiss Jura hills close to Solothurn, just above the
Balm ruins.
Properties in DWF Export
Questions:
1. The ‘Type’ properties created through a shared parameter in Revit are not exported in DWF. Only instance properties from a shared parameter are exported. Any idea?
2. Furniture and other family instances have a ‘room belonging’ property that you can schedule in Revit, but this property can’t be found in the DWF. Any idea of how to get this info in the DWF?
3. Surface area and volume are not displayed when exported to DWF in the DWF Room properties. Is it normal? Is there a way to get it?
<!–
1. The ‘Type’ properties created through a Shared parameter in Revit are Not exported in DWF. Only Instance properties from a Shared parameters are exported. Any idea?
>Yes. I think types are not exported at all, only instances. Therefore, there is no place to attach the type properties to. does that make sense?
EDG: Is it as designed you think? It’s strange that the type properties are not exported. It seems more like a bug or a non-tested stuff. As Instance Properties are exported, normally Type Properties should be exported.
2. A Furniture in a room has a Room belonging property that you can schedule in Revit but this room belonging property can’t be found in the DWF. Any idea of how to get this info in the DWF?
>Yes. You could define a shared parameter as an instance property and copy the desired data into that.
Alternatively, you could write an application using the DWF toolkit to post-process the DWF file to add the desired data yourself.
EDG: The issue is that it’s a manual process and you’re losing all the benefits of Revit’s parametric engine and its associated DWF export.
3. Surface and Volume area are not displayed when exported to DWF in the DWF Room properties. Is it normal? Is there a way to get it?
> Yes. You could defined a shared parameter as an instance property and copy the desired data into that.
EDG: Again, the issue is that it’s a manual process and you’re losing all the benefits of Revit’s parametric engine and its associated DWF export. And if the data changes, you have to change it manually which is very risky.
–>
Answer: Since Revit 2013, shared parameters for family instance can be exported to DWF.
So far, though, for family types, only system parameters can be exported:
Custom parameters, i.e. family parameters and shared parameters, cannot be exported:
For room area and volume, did you check the following DWF export settings?
Once properly set, these properties ought to show up:
Response: Thanks for your help.
I just checked the Area and Volume export options and so it works now!
Fine.
For the other questions, if it’s as designed, no worries, we’ll find another way to get this.
Mapping Revit and IFC Properties
Question: We are currently looking at mapping IFC properties against Revit type properties.
I understand from the
COBie community
(Construction Operations Building Information Exchange) that Autodesk have already gone through this exercise.
Where can I find more information about this?
Essentially we are transferring our shared parameter file into an online database, so any work already undertaken would be hugely beneficial.
Answer: The best resources to look at are the notes provided by the open source IFC for Revit project, e.g.:
The first item in particular includes a PDF document covering the COBie to IFC mapping that might be of use.
Storing a Table in a Project
Question: I’m working on a daylighting analysis plug-in and using extensible storage quite heavily in my implementation.
I’m currently saving some data with each Floor object, but I would like to change this to store the data in more of a table format, with one entry per floor, and save this as an object with the model.
I thought I read somewhere on your blog about how to save a singleton data object using ES, but I can’t find the post now.
I know how to create array objects in ES, but I’m not sure what to store the data with.
I thought I’d read that ProjectInfo is not the best place, but again, I can’t find where I read that, so I may be mistaken.
Can you give me some pointers, or send me the link to the relevant blog post, if I’m remembering correctly that I read it on your blog.
I think I found my answer. I want to use the DataStorage object. I found your entry on it. If you have any other advice for me, please share it, but otherwise, I think I answered my question.
Answer: Yes, absolutely right, using a DataStorage element is optimal.
That also keeps your data nicely packaged and tucked away to avoid interfering with others in a workshared environment, as explained in Scott Conover’s AU class on
Revit add-ins that cooperate with worksharing.
Based on that, I no longer recommend using the ProjectInfo element at all.
Updating Versus Adding New Extensible Storage Schemas
Question: I have released a version of my software that uses schemas to store data.
I am now working on my next version. I need to expand my schemas to store more data.
When I add data, I can create a new schema and transfer my data to it, or I can create another schema.
Creating another schema seems simplest. Are there any drawbacks to creating another I should look out for? I continue to do this and end up with a large number of schemas, will there eventually be space or time costs?
Answer: I assume your issue has to do with extensible storage schemata.
“Create a new schema and transfer my data to it” and “create another schema” sounds almost like the same thing to me.
In any case, and luckily simplifying the issue, I can tell you for sure that you do not really have any choice.
If you need to make any changes whatsoever to an extensible storage schema, the only possibility you have is to define a completely new one.
There is no way to alter an existing one, as explained in the detailed discussion on
deleting and updating an extensible storage schema.
An example of defining a new schema to replace an existing one and transferring data from the old schema to the new one is provided by the UpgradeSchema sample included in my Autodesk University 2011
extensible storage class and lab.
Finally, I put together a list of all The Building Coder
extensible storage topics for you.
Question: Let me clarify a little further.
I have a schema with ten fields. I need to add one more.
I can create a new schema with eleven fields. That requires me to transfer the data (which as you add more fields, is tedious at best and error-prone at worst). It also results in duplicate data. Not sure if the extra data in old projects would ever become a concern.
Or, I can create a new schema with one field. Now I have two schemas with eleven fields between them. Are there any problems with having lots of active schemas on an element? What if I continue to do this as the program evolves, and end up with five or ten or twenty schemas?
Or, and this is what I came up with after I sent the email, what if I create a map field where I store all my data? Then I have a single schema with a single map. If I have to update one value, I have to pull out the whole map, change one value, then put it back. Is the performance on that significantly different from updating just a string or int field?
Answer: Oh, now I see what you mean.
Your idea of a map sounds perfect to me.
The other would certainly also work, but sounds much more complex, with unlimited growing complexity as time goes on.
I like the idea of maintaining one single map and one single schema much better.
The only one who can say anything about the relative performance of the various options is you.
Please
benchmark it,
and let us know what you find out.
Leave a Reply