I phrase this a bit differently. JSON is about storing structured data. It can be in a dictionary format (key/value pairs), or it could be in a list format, or it can be a mix of the two. Most of the time we see key value pairs as they are easier to work with. If I sent you a random list of data you’d have to guess what was stored at each index in the sequence, while if I sent you a dictionary the key would inform you what the data was for. As JSON is very frequently used for interchange of data (over the web or between desktop applications) the dictionaries are more consistently used in terms of data extraction. When JSON is used internally to a process the list version can work just fine. This pages has some good info to start with: JSON
So @cintiamiranda21, knowing this and that you want to go out to JSON, the question becomes “How do you want your data structured?” We can’t answer that, but we can give some thoughts.
One method I have seen is a list of rooms stored as a dictionary, which have keys for Unique ID, Element ID, Name, Number, and Geometry. This graph will build just that using only out of the box nodes (no need for any 3rd party packages which is nice). Note that because an object can have multiple geometries I am storing that information as a list rather than a single element.
Export to JSON.dyn (28.7 KB)
Note I am moving the solids instead of the room boundaries, floor surfaces, whatever. The concept of ‘ToSolidDef’ applies to whatever geometry you want to serialize, however there are some limits which you’ll find as you experiment. One thing to note is that polycurves serialize as individual segments which then have to be joined back together on deserialization. You may prefer using a dictionary so you can call for a room by name, unique ID, or something else instead of having to iterate over the list to find the one you want.
Once written out, you likely will want to parse it into something else at some point. The second graph will do just that.
Import from JSON.dyn (15.4 KB)
