Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Numerical ID #154

Open
Snoreledge opened this issue Mar 30, 2023 · 2 comments
Open

Numerical ID #154

Snoreledge opened this issue Mar 30, 2023 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@Snoreledge
Copy link

Snoreledge commented Mar 30, 2023

Is there a plan to standardise the method for assigning numerical digits to the second part of a device name i.e. the <building_unique_incremental_number>, given that they can be assigned using spatial or discipline-specific scoping methods?

In the specification, there's an example given - in a 20-story building, lighting fixtures on zone 1 of level 3 can share the same first part of the name (e.g., LT-103####) with the subsequent integer numbers being attributed incrementally. However, there is currently no standard approach to assigning numerical digits when a building has minus levels, mezzanine floors, and terraces and ground floors that are zero-padded (00)

Even just an order of how these numerical numbers can be made up would be a benefit i.e.

I have plenty of project examples where this has presented a problem with possible solutions that could be proposed if needed.

@RitaLav RitaLav added the enhancement New feature or request label Mar 31, 2023
@TheFridgeShaman
Copy link
Collaborator

Hi Sam,

we find that standardising the numerical part of the name can easily turn counterproductive for project that don't require that much complexity. BNDS should stay generic on that and only prescribe the checks on duplication of naming and compliance with the regular expression.
It's interesting that in the industry we are all experiencing the same challenges, made me think of this.

If it helps, this is what my colleagues and I generally do:

Use almost always use a building identifier at the beginning of the name. For projects that consist of one building, we still use the dummy digit 1. Where applicable we also use a different digit for the exterior/landscape/site elements.

We generally don't use a zone identifier. MEP zones are often still work in progress when we start the naming and architectural zones can be treated the same as buildings if you want.

We generally use the following level identifiers:

Basement B2: 98
Basement B1: 99
Ground floor: 00
First floor: 01
Second floor: 02
....
Roof level: previous level +1

For mezzanine levels we either use the identifier of the level before (GF: 00, GF Mezz: 00) or we use a completely different number not used in the rest of the project (e.g. 55).
Both solutions have pros and cons.
Please note that we can use zero padded numbers for the levels because anyway we have either the building identifier (which is never 0) or 1 as a dummy digit.

We often get the comment that instances have long names (6 digits, often 7 for the luminaires) but there's not much we can do about that. FM and other teams generally pick up the pattern very quickly and find it useful once it's there.
Our assets don't follow the bottom to top level order when ordered alphabetically and despite that we all still sleep at night.

Where not necessary, in the same project we allow for simplified names if the above is not needed, so that different teams can solve the naming quickly, independently and painlessly. E.g. if it's one building with 3-4 lifts, it's easier to call them ELV-1, ELV-2... instead of ELV-100001, ELV-100002...; same thing for other assets that appear in limited numbers like generators or air handling units. In parallel we have luminaires tagged as LT-103123 and that's never been an issue.

That's probably it.
Please let us know your questions and if you can share we look forward to knowing more about your solutions!

@RitaLav
Copy link
Collaborator

RitaLav commented Nov 1, 2023

perhaps we could add this as a separate/additional .md file called 'examples/example use cases', so that it can be consulted even if not part of the spec? Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants