When we were building CxAlloy TQ we knew we wanted a flexible, powerful system for locations. We didn’t want to just have a list of rooms and a “Location” field on an issue. We wanted to be able to express the relationships between locations and to deeply integrate them with equipment, issues, checklists, and tests. This desire grew out of specific uses that we wanted make possible, including:
- Getting a list of all issues on a floor, including issues associated with equipment on that floor.
- Getting a list of all equipment in a building on a multi-building project.
- Making it natural to create locations like “Roof” and “Garden” that didn’t fit well into the Room Name/Room Number model.
- Creating checklists based on a location instead of equipment for room walkthroughs or similar applications.
- Allowing the creation of relationships between locations, but not require those relationships.
- Seeing easily the related room, floor, and building for equipment or items associated with that equipment.
In coming up with solutions that addressed these needs we were greatly aided by the work done for the COBie standard (you can read more about our integration with COBie here). In particular their concept of “spaces”, a broader concept than “rooms”, was a great insight.
Besides calling rooms “spaces”, the basics of locations work as you’d expect – buildings contain floors, which in turn contain spaces. Importantly, you don’t need a building or a floor to add spaces. By allowing you to add spaces first and then connect them to floors later (or not at all), we make the software faster and more flexible. When you are adding equipment and realize you need to add a new space, it’s much nicer to be able to add the space right then without having to worry about what floor and building it’s in, especially since you may not have created the building or floor in CxAlloy TQ yet.
Earlier incarnations of CxAlloy TQ had both an “Equipment” and “Location” field for issues. As we put together the current version we realized that having both fields is redundant. If the equipment has a location and the issue is connected to the equipment, shouldn’t we know the location? CxAlloy TQ is much smarter now – for example, let’s say you create an issue for AHU-1 which is in Room 101. When you create an issue for AHU-1, you don’t need to add “Room 101” to the issue because it’s implied by the connection to AHU-1. And not only that, we know it’s on the first floor in the main building!
Of course, these connections aren’t that useful unless you can use them to organize your issues. We knew that and carried this concept into our filters and sorts. For example, if you filter your issue list to the first floor, you’ll see issues connected to equipment on the first floor right along with issues connected to spaces on the first floor and issues connected to the floor itself. You can sort by location as well. And, like with all of our filters and sorts, you can generate a professional PDF of the filtered and sorted set.
Finally, you want to be able to see these relationships as you work with issues, equipment, and other items. We do this by having a list of related location information showing you that not only, for example, is an issue connected to AHU-1, but it is also in Room 101 on the first floor of the main building.
I’ve been focusing primarily on issues and equipment, but CxAlloy TQ lets you take locations even farther by integrating with Checklists and Tests. All of the same functionality that I’ve outlined for issues is available for Checklists and Tests. This really opens up their potential uses.
The flexibility and power that locations in CxAlloy TQ affords – while still being easy to use – is really quite remarkable. I hope I’ve been able to show you a little of the benefits that CxAlloy TQ and its location model can bring to your projects.