LevelId is null

[KM_Yotsuha]

A pipe has Reference Level，why is the LevelId Property goes to  null?

[longt61 · Accepted solution]

You need to look up the correct parameter or property for it since each Revit element save its level at a different place. It could be LevelId, ReferenceLevel, HostId etc.. depending on what element type it is.

Just use Revit lookup and open its Parameter or ParameterMap and find the text that displayed to user, then determine which builtin parameter/ user define parameter that matches it.

[RPTHOMAS108 · Accepted solution]

That's odd when you create a pipe in the UI it populates the LevelId on the class. It may be related to how the pipe was created i.e. was it created with the API? If so it may be something that needs looking at to bring the API in alignment with what the UI is doing for pipe creation.

As @longt61 you can refer to the backing parameter that is showing the level in the property grid but would be nice to know when LevelId for a pipe is populated or not and why.

[jeremy_tammik · Accepted solution]

Yes, some elements have no level id, including pipes, cf.:

https://thebuildingcoder.typepad.com/blog/2019/03/assigning-a-level-to-an-element-missing-it.html

[longt61]

I mainly work with Structural and Architectural elements, thus I am not certain about MEP elements and MEP system, this is just an opinion. I do believe that the LevelId is populated or not depend on the how the element is create by API.

For example, there are more than 1 way to create a Structural beam/ framing or a Structural column, and the argument for each method is different. Some method are meant for a certain kinds of element, yet you can still use it for other kinds (at least from older version of Revit API).Some parameters are updated AFTER the instance has been created (such as view name for drafting views). Some parameters are updated after the transaction has been commit/ document has been regenerated.

I have not encounter any official document that explains why it is the way it is and how to know which element need to be updated its parameter in a certain way/ order, though you can find plenty of useful and trustworthy advices and solution from @jeremy_tammik  's blog. My fuzzy guess is that this confusing parameter update process is due to the inheritance of Revit classes, the initial intention of element design and the regeneration of geometrical appearance that can make some parameter valid to be updated. However, a guess is a guess, and I agree that a detailed documentation is better than we dev have to learn by trial and mistakes.

[jeremy_tammik]

I agree that documentation would be great. Unfortunately, none exists, not even internally, afaik. I think it has just evolved the way it is.

[RPTHOMAS108]

@longt61 In this instance the LevelId is a property of the class which has a value when you create a pipe in the UI and doesn't have one in some 'other' unknown to me circumstances. Additionally the 'Reference Level' parameter does have a value when LevelId doesn't so what information (Parameter) is the LevelId property of the class referring to? This knowledge (what the class property is looking at) is understood by those that maintain the API I would have thought.

I agree there are many methods of adding items such as family instances which populate different parameters and sometimes don't include the level. However this is a system family and is level based, although I'm also not myself specialising in MEP elements. I also don't know the history of the object i.e. sometimes a family instance can lose it's level so perhaps so too can a pipe although when a family instance loses it's reference level it reports that as none.

This to me comes down to inheritance and if I can trust a property on the base class: if a Duct and a Pipe have a LevelId property but the Pipe LevelId is sometimes null when the Pipe has a level then how can I use the base class property when I'm looking at the LevelIds of both Ducts and Pipes together in one set? If you can't trust the LevelId property then when can you use it? There are cases of inherited class members that do nothing on an inherited class but this isn't one of those cases i.e. the LevelId of the Pipe sometimes has a value.

I can probably accept the ambiguity of this with FamilyInstances given the wide range of things they represent but Pipes are less abstract in terms of level behaviour.

It may also be a situation that has now been fixed I don't know, i.e. I don't know what Revit version was used to exhibit the original behaviour above:

[Samuel.Arsenault-Brassard]

A good way to get insight is to export the built-in parameters for each categories

It's a complete mess 😎

We need two things:

• A unified parameter that indicates the level
• A separate way to identify if an element is GEOMETRICALLY between certain levels

Ex: Is the wall physically present between level 1 and 2?

This solves for walls that are hosted on level 1, but the boundary only makes it appear on level 25

I can't believe we don't have a unified level system for clash coordination, how are you even supposed to select all elements that are geometrically present between floor 1 and 2?

[jeremy_tammik]

For most elements, you can simply intersect their bounding with a horizontal slice of space bounded by the upper and lower level elevations, cf.

https://thebuildingcoder.typepad.com/blog/2019/03/assigning-a-level-to-an-element-missing-it.html