Row Classification Script

[carl3ZPF6]

It has been a while since I have written code (I am a mechanical engineer) but I think this is a simple problem. At my job we put things in various rows and we need to be able to quickly classify rows. Let me explain: we will get an autocad file shown rectangles in rows like the following. Note when I am talking about rows I am talking about the up and down rectangles (Opposite of row/ column in spreadsheet sense).

I need to color code and count rows of the following distinct categories:

• Long Length Exterior rows (Rows that have less than 3 rows to the right and/or left of them )
• Long Length Interior rows( rows that have other rows 3+ to the left and 3+ to the right)
• Long length Overhang rows (rows that have short length rows in front of them, similar to exterior row rules 3 rows from the left or right will be considered an overhang row)
• Short length exterior rows (same rules as exterior/ interior for long length rows)
• Short length interior rows (same rules as exterior/ interior for long length rows)

Currently we manually color code them into different layers then we can use autocad to count the rectangles in each different categories see color coding below:

Blue= Long Row Exterior Magenta= Long Row Overhang Red= Long Length Interior Green= short length interior Cyan= short length exterior.

This is easy enough for small files but these get very large and tedious for large sites, and to further complicated things, sometimes there are 3 length categories (short, medium, and long). Looking for an easy way to automate this process, I dabble in C++ and VBA and I feel like this should be rather simple, I just don't know where to start. this does not need to be done withing Auto cad and I can export the files as images or whatever is necessary.

[pendean]

COUNT command in newer AutoCAD versions not work for this task (if I understood your need correctly of course)?

auto color coding is not a feature of the program OOTB, you might be able to program that but you need to identify more parameters first.

[carl3ZPF6]

COUNT is what I use now but I have to manually put the rectangles on each layer. I am looking for a way to automate that.

[pendean]

Automating generic pline shapes selection that you alone call inside/outside/whateverside but the program only sees as generic pline shapes would be limited to tools like SELECTSIMILAR, QSELECT, FILTER and COUNT in AutoCAD.

Unique Blocks with Attributes give you more lots more control options, perhaps even specialized toolsets objects (if your type is available) would add ever more automation too in the vertical versions of AutoCAD.

Perhaps you can do more with each set if they were each a Dynamic Block?

[Michiel.Valcke]

are your rows always stacked in that direction? Are they closed polylines? Are the dimensions fixed or are they relative to each other (in other words: is a short row always the same size, or could it be a long row in another setup?) Is the difference in size between a short & long row always consistent or could you have short/medium/long rows in a single design? Are there other objects (non-rows) in your designs? Are the rows always on a unique layer (without other non-row objects on the same layer?)

I'm thinking that depending on your answers to the above you could have a relatively easy app:

Select x closed polylines (rows) - calculate the center point for each, sort them by x value (so the first one is the most left, etc...) then you will have your polylines in a list from left to right (or vice versa) then check the rules, what is the length, is it with the first 3 on beginning or end of the list, if it is long, is there a short one to the left or right, etc...   and based on those rules change the color or layer of the affected polyline.

[carl3ZPF6]

Rows are always in the direction shown. Rows are all closed polylines. Sizes can vary depending on size and the relative differences can very a bit. generally medium= 2*short and Long= 3*short. No non rows are in this file, rows are on their own layer.

[Michiel.Valcke]

your rules above only talk about long length and short length rows, how about medium length rows, how do they need to be color coded. 

Within a single design, are all short length rows exactly the same length? same question for long and medium length rows.

[carl3ZPF6]

Medium rows can be shaded by short rows so they have an overhang category. Then they follow interior and exterior the same way. Within one file all larges are the same length the same goes for mediums and shorts.

[Michiel.Valcke]

so would this logic be correct:

I take 3 rectangles from the left, check their relative length (short/medium/long)
-> give them a color based on their relative length (S / M / L)
take my 3 rectangles from the right, check their relative length (short/medium/long)
-> give them a color based on their relative length (S / M / L)

take the inner group of rectangles, for each rectangle check their length and compare it with 3 rectangles to the left and with 3 rectangles to the right.
-> option A: If on either side there is a rectangle with a shorter relative length it would have a color based on its length and the fact that it is an overhang category (M-overhang / L-overhang)

-> option B: If on neither side there is a rectangle with a shorter relative length it would have a color based on its length and the fact that it is an interior rectangle (S-interior / M-interior / L-interior)

[carl3ZPF6]

Yes that logic follows to me

[Michiel.Valcke]

try the lisp in attachment: 

Some caveats:
- the routine changes the colors of the plines directly, it does not move them to another layer, in the code it is described how you can change this.

- I chose my own colors for the medium polylines, the other colors I copied from your example, you can change the colors chosen in the code as long as you use indexed colors. True colors are not useable with the code as is.

- it compares the length of the polyline, not the length of the row, so it presumes that the polylines also have equal width

- it takes into account a scenario with a short/long row setup or a short/medium/long row setup. If there are more than 3 different lengths, you will not get the results you desire.

- It sorts based on the x-value of the polyline's geometric center, so you cannot sort multiple sets of rows at once, you have to repeat the routine for each set.

- I used some sub-routines from other forum members (thank you Lee-Mac) and linked to the source in the code. Do not remove those attributions, it's just respectful to make the correct attributions.

- the command is "sortrows" if you want another command you can add the following code:
(defun c:YOURCOMMANDNAME ( / ) (c:sortrows))

- if you need further edits, I encourage you to venture into Autolisp, it is not so difficult, and there is a dedicated forum right here: https://forums.autodesk.com/t5/visual-lisp-autolisp-and-general/bd-p/130

[carl3ZPF6]

This looks amazing, thank you so much. However, when I try to duplicate what you did in the video I get this returned "ARQ-SUBR-CALLBACK.3 (nil 0)" and nothing changes color, is there a setting I need to enable or other subroutines I need to download? See attached test file I was using. Also color changing the rows wihtout putting them in different layers may be a problem, what I was doing was counting all the objects in each layer to get a total count of each type (using select similar and count selection).

[Michiel.Valcke]

I left in the error handler so you could figure out why something is not working. Apparently your polylines have an elevation, so my method to calculate the centroid does not work. I'll write a fixed version and share it later.

[carl3ZPF6]

Thanks Michiel, I ran the program on test polylines that I created and the logic is sound. After you account for elevation can you point me in the direction of how to run this subroutine for an entire file? As you can see from my test file these get quite large, and having to apply this to each row block would be better than the manual method, but it would still be quite time consuming.

[carl3ZPF6]

The only issue I found in logic is the program does not know how to handle rows that are all one size, this block for example. Is there a way the program can determine short medium and long, then store these values so it knows how to process rows that are all one type? I think the program currently defaults to thinking the whole row is short when there is only one length selected.

[Michiel.Valcke]

There is something strange with your dataset.

I made the changes so the first time you start the routine you'll be asked to pick a short row and a long row. As long as these are known the routine will no longer ask this. If you want to clear the picked values from memory, use the command "clearlengths"

The routine also no longer used the centroid as reference, but takes the lowest x-value of all polyline vertices. This way elevations are no problem.

When I try this on a dataset of my own making, it works fine, but when I try it on your dataset, I keep getting weird results and I haven't figured out why yet. Maybe someone smarter than me over at the autolisp forum might have an idea how to improve upon this, or what in your dataset is causing this isue. I unfortunately don't have anymore time this week to work on this.

[carl3ZPF6]

I agree I ran through a bunch of example in files I created from scratch and never got bad results, with the exception of angled rows as shown below (I think this is just a result of how overhang rows are being defined). My test files seem to be introducing error somehow. I will post on the forum and further investigate.

[carl3ZPF6]

I think one of the reasons it is messing up my test files is that there are some rows in my files that are different widths so those polylines are different lengths.

[Michiel.Valcke]

that could explain other errors, but if you look at the properties of those polylines, they do have the same length value, so it must still be something else

How is your data created? is it created manually, is there another routine creating the data, is it an export of some sort from another program?

[carl3ZPF6]

Sometimes they are given to me in autocad format, sometimes I have to import them from a PDF, but those random rows are orange in the test file (every 5 rows or so) are the smaller width rows, so I do think it has something to do with that. Perhaps there needs to be a bit of a tolerance range for small medium and large.