I would like for Innovyze to create a complete list of all the codes that can be used in XPX or XPTables, with descriptions of how they are used, and/or make it very easy to find out what those codes are.

For example, NKLASS is used in XPX to change the conduit shape. In XPX, the NKLASS codes are just numbers that correspond to particular shapes. To figure out which number is which takes making a dummy model . I was hoping that you have a full data definition somewhere that tells what all these things are.

In XPTables, however, NKLASS shows up with various text possibilities (Circular, Rectangular, etc.). A full listing of those text values would be helpful if someone is developing a database for data import/export.

Then there are some odd things like “Height of Rectangle” in XPTables. I’m not sure what that means or does, or where I might find/change it in the GUI. My thought about how XPTables is set up would be that the dialog would mirror the dialogs that you use in the GUI. Perhaps that could be a separate way to find things, with its own tree (Find By GUI), and keep the current one for those of us that already know where things are with the current system.

For Conduits, there might be a separate path for “Multi-Conduit” and “Single Conduit”, but once you open the conduit editor in MultiConduit, it seems to just be a copy of Single.

Inside the ‘conduit’ dialog, the ‘depth’ entry is probably used for several of the sub-dialogs, and it should be present in each. If the user adds it to XPTable twice, perhaps the second entry could have a warning ‘you are adding a duplicate copy of “DEPTH”, do you want two copies? (Yes, Keep Original Location, Replace Original at this Location)

Finally, some logical sorting of the values in the XPTables list would be helpful. Either alphabetically or by type (shape, height, width together), US/DS flowline together, etc. The list below is just odd, and in an order that doesn’t make sense. Why is “Name” between “US Name” and “DS Name”? US/DS Crown Elevation seem to be calculated values that can’t be edited. While those are nice to know and might be useful sometimes, they should be noted separately or identified somehow, so that if a user is trying to create a table for editing values, they can avoid them.