Hi!
I have somewhat recently created a script which generates 3D Solids of pipes and manholes, based on stakeout data (Points and 3D Polylines). However, the script is held together by lists of unfathomable varying depths, as well as hopes and prayers.
However, in very recent times I discovered dictionaries - a concept that frightened me to the core a week ago. As such, I am now hoping to clean up the spaghetti code by extracting information from my nested dictionaries.
Anyway, as stated I have created nests containing various object types, and I’m looking to foolproof it, as the layer information could be scattered all over the place.
First off - how do I compare my layers to the dictionaries? I attempted to convert the value to string, then compare it to the layers (in the code block in the top right), however the string is an absolute mess.
I then attempted to run it through List.Compare, with no avail. After a few hours of trying and failing, as well as browsing this forum and Google franticly, I hope somebody could point me in the right direction.
In the attached screenshot, I am hoping to filter my layernames through the rightmost subdictionary, which contains gravity pipes. As illustrated, the 0-index of my shown layers contain “OV”, which should match them with the third dictionary within the rightmost Dicitonary.Value node.
Any help would be greatly appreciated, thank you!
Hi @petter.christensen,
Could you give an example of the output that you’re hoping to achieve? You could mock up the desired result in a code block, for example, and then we can work backwards from there.
I think it would help illustrate if you’re trying to (a) filter the data in the code block based on the dictionary keys, or (b) filter the dictionary keys based on the data in the code block.
1 Like
Hi, @zachri.jensen, thanks for the swift reply!
I’m working on creating a dictionary in Excel (not implemented fully yet), containing;
- Different object types as Keys
- Different string values isolating various objeject types (StormwaterPipe, SWP, SP for instance for stormwater pipes).
- Whether a pipe is gravitational or pressurized.
- Materials with their inner and outer diameter.
I currently have the abovementioned information scattered in code blocks throughout my script to filter the layer names to sweep the solids correctly, however if this works as I hope, I could make the script a lot more compact.
I have tried to scetch up a master view, with examples from stormwater pipes and sewer pipes.
The top block is an example of a layer name, and the leftmost nodes are examples on how I hope to structure my data.
Basically, will this be possible? And what blocks would be best to filter my layer names against the dicitonary?
Thanks!
Update. I have managed to collect all my data into a spreadsheet, with a root level and five sublevels (6 columns in total).
The first four columns are more or less containers to sort my information, and the last two contain material thicknesses and diameters.
I realized I could sort this information using a series of List.GetItemAtIndex, List.RestOfItems and List.GroupByKey.
It’s definitely possible, and it’s not too heavy on the script (as of yet).
Thus I’m wondering, could dictionaries make this easier?
The top row of the attached (probably a bit small) image. I could proceed to sort out the rest of the information following the same pattern, however, if dictionaries could make this easier I’d definitely try that approach.
For example, for my pipes, I have the following categories
Object - Pipes - Gravity/Pressurized pipes - Water/Stormwater/Drainage/Sewage/Unclassified pipe - Then a bunch of keywoards that could filter out the different pipes from layer names.
If nothing matches, it should be unclassified.
For pipe materials, I have:
Object Property - Pipe properties - Materials - Nominal diameter - Inner diameter - Outer diameter.
I know this is probably a lot of text, but I hope it helps to highlight what I’m trying to achieve.
Basically, I’d like to build out my database in Excel, and to be able to classify AutoCAD objects based on layers, and use that information to sweep them using correct materials and thicknesses.
Certainly doable; built similar with a company a few years back, but it only did gravity networks. As far as how…
Dictionary.ByKeysValues would work for each row in the file ( watch list levels) and if you have headings in the excel file even better. Then build another dictionary for each object type you process, and then append each dictionary object (each a row in excel) to the respective key in the parent dictionary. You can then call ValueAtKey for ‘structure.round’ from the dictionary and get the dictionaries for all of that object type, each of which can return any parameter you have by way of another ValueAtKey node.
However this is where the simplification ends. Eventually you need a massive set of nodes to parse all the data of any one type completely and generate the subcomponents required to create the object.
But significant simplification can be attained by converting each of those sets of nodes to a single custom node (.dyf) which you can then package and deploy internally or via Dynamo’s package manager. That DYF can take in a single dictionary, parse to the matching type key, and return all components, or the original dictionary with the ObjectId and a GUID property appended so you can write back to excel for future data validation.
All of that comes at the cost of adding new hurdles to development (you have to manage dependencies in the environment for your users across versions and likely produce package versions for each build), but it will make the graph lighter, easier to maintain, easier for newcomers to use and build with, and faster executing.
Thanks for the summary, @jacob.small!
That might be a bit beyond my understanding currently. I did, however, manage to sort out my data.
I ended up spreading it across several sheets, and as such do one import per sub category. It’s way easier for me and my colleagues to manage (with our current understanding at least), and it allowed me to cut back on a lot of unnecessary columns.
Thanks for the replies, though, I’ll take a crack at creating dictionaries using my current setup.
1 Like