Question - Room renumbering based on Nearest Point on UV

[dakotahlucas]

Hi there, I’m working on a graph that I just can’t get over the finish line. I have a project with many floors and many thousands of total rooms and we’ve determined it is critical to get room numbering consistent based on rough location on the floor plate.

My strategy: Create a bounding UV grid that has numbers associated to each individual point. Take all rooms on the active view (find their center point) and set the room number parameter based on the closest UV point.

I’m really struggling to associate a value to the points that I can then define the room number with. I have a feeling list.map is the solution but I just for whatever reason cannot wrap my head around functions and haven’t been able to get it to go anywhere.

I’ve included a greatly simplified version of my graph below for reference. In my example I’m trying to figure out how to best assign the value 83 and 84 to the generated points. (Which represent room center points)

Room_Renumber_Global_v0.dyn (230.7 KB)

[jacob.small]

Why not do this a bit differently?

Surface.UVParameterAtPoint will give you the UV at the point of each room. From there you can pull the U value by 0.1 (or any other value you desire for the number of X distances) and round the value to get the ‘row’ number, and then do the same for the V value to get the ‘column’ value. You can then multiply the column value by the number of rows to get the intended sequence, or otherwise work out your number.

That would be N tests per room with no additional geometry creation. Your current method produces MN lines and then does MN equality checks and none of that will be quick.

[dakotahlucas]

Thats a good call. In my real graph I’m minimizing the amount of operations by only pulling distances off of UV’s that fall within the room boundaries. But to your point I could definitely adjust this to solve with some math instead of drawing objects. I’ll play with that more…

Do you think that route gets me to closer to associating a number value to each of the UV points and assign that as a room number?

[jacob.small]

So I am going to ask this directly, as the details of your answer matter more than anyone would likely admit. We don’t need an answer, but you must think it all the way through…

Do you actually want to renumber rooms this way?

deep breath

I ask that directly as many will say ‘yes’, but then when they look at a real project or the next project they are on the method falls apart.

I can talk about ‘renumbering’ things for an hour straight. In fact there are at least four workshops where I did so… which is to say that I have some experience in this space.

I typically see companies follow a numbering strategy that is relative to other datum elements. That is often ‘sequence’ based (order of objects from the logical start point - think about the station and offset values used in linear structures, or hotel rooms along a corridor) or relative to another datum (group rooms by level, building quadrant, nearest grid intersection, etc.). When a ‘relative to surface’ method has been used the first thing that mattered was usually the origin of the surface.

In these cases you sometimes have point 1 at the bottom left corner (the first example), sometimes at the bottom right (second example). This will be determined by how your surface is built. You also move ‘bottom to top’, but may want to go left to right instead. This sequence will be determined by which parameter is used as the first input for the associative function of the point at parameter.

In all cases, scale makes variation difficult. Does the small closet on the north west corner want to be number fifteen even though it is only accessed off the main corridor which is number zero? Or does the small thing become a series after the larger thing it is accessed from. Does the one wide or tall room throwing off the sequence matter, or can we ignore it as people won’t orient themselves in the space but only off the plan?

In most cases, the use of a relative vector is more meaningful as a result. You can determine the origin point by grid intersection, build a vector to each room location, and then sort by distance along the X or Y axis, group by fraction thereof, and sort the groups by the Y or X axis. You can also transform these vectors even get advanced and sort things relative to another origin based on a property of the original item (group the vectors by the nearest control vector, perform a transform, and then sort - group - sort as before in the subgroups).

This method isn’t that far off what I outlined before, and it enables so much more than you get with UV parameterization.

The only drawback is that it does not enable us to sequence the numbers by order of experience (the hotel room numbers along the corridor which I mentioned before). Those are a whole new method of discussion…

[dakotahlucas]

Totally appreciate asking the question to think a little bit more about my intentions. I agree that this is maybe a pretty unconventional way to number rooms and maybe isn’t how we would do things on a smaller scale project. This direction came out of an early BIM coordination meeting with a number of consultants and the GC with the goal of making it “easy” to locate rooms on our nearly 100,000sqft floor plates. This is also somewhat rooted in dramatic last minute changes where rooms are added, removed, joined or split deep into CDs when our room numbering was well established and changing those numbers would drastically change drawing sets or introduce new numbers into foreign areas.

This started with the idea of naming rooms based on their nearest grid intersections but it quickly became obvious that finer resolution would be needed. The end goal is really just about ensuring that when someone says room “##-345” (## being the floor designation) its at the same spot in the stack whether its an office, a janitors closet or a pantry. If that room gets changed later, no sweat… we insert a new room associated to its new nearest UV points and it still aligns with the floors above. We are now at a point where we started to do it manually and it very quickly became a burden so I was hoping to find a way to at least somewhat automate this process.

Also, these numbers are purely for coordination and construction only and the actual room displayed numbers will vary based on our clients actual use case and requirements. (They number rooms based on departments and business centers and their standard has no association to the building at all)

[GavinCrump]

As strange as this method is I have also had other jobs demand it before, as they use these during delivery then assign the actual FM number at the end. Weird, I know.

@dakotahlucas a much easier way of going about this that I have used is that you instead establish a grid origin point. You then get the room location and subtract the x and y values of the origin from its own.

From there determine the grid spacing, divide the x and y values by said value, round then multiply by it. You will get the nearest ‘grid’ values without needing any geometry.

[jacob.small]

@GavinCrump

@dakotahlucas a much easier way of going about this that I have used is that you instead establish a grid origin point. You then get the room location and subtract the x and y values of the origin from its own.

That’s the vector method which I was describing before.

[GavinCrump]

Mm similar I guess, still using abstract geometry though vs just numbers.

I appreciate theyre just number structs in principle though, so close enough.

[dakotahlucas]

Alright, I retooled my strategy a bit based on your suggestions. The code block below carries a vast majority of the graph doing all the calculations in one place. The rest of the graph is just pulling in the bounding grids, the rooms in the view and defining the “resolution” (grid size) and finally assigning a room number. The resolution value basically makes sure the grid never gets too large which could result in two rooms ending up with duplicate numbers.

With the resolution set to 60" and a max room number character count at 4 the max theoretic floorplate is 495’ x 495’ which should satisfy a vast majority of our work.

Thanks for the push to defining grids mathematically, that certainly sped things up and reworked how I thought about numbering. My room numbers now are in an XY format (“##-XX.YY”) which is slightly less arbitrary than using the indexes I originally was intending. Added benefit I could just pull gridline counts direct from the math and convert to strings.

\

Room_Renumber_Global_v1.dyn (76.8 KB)

[jacob.small]

This is a VERY nice example of the concept and a great tool! Well documented to boot!

As an added bonus you can expand it to deal with those other conditions as/if they come up without too much trouble (i.e. the L shaped building where the grid wants to twist).

Great work!