We are standardizing our offices detail as they are being used. If we need a detail, we'll standardize it. We want the new standardized details to go into the new CSI naming format. LandFX comes with this format, but includes a lot of details in it from manufacturer and even old projects that it appears that Dave Farmer worked on during the early years. We want to append our folder structure with this new SCI sub-folder system.
Can we get a copy of a clean CSI format structure (folders AND sub-folders but without any details) and directions as to how to APPEND not replace our structure to include this new folder structure in it?. So we will have the old files in our existing structure and the newly modified, standardized files in the new CSI structure.
Can we get a copy of a clean CSI format structure (folders AND sub-folders but without any details) and directions as to how to APPEND not replace our structure to include this new folder structure in it?. So we will have the old files in our existing structure and the newly modified, standardized files in the new CSI structure.
Steve,
Your timing is something out of this world. We have it in the calendar to discuss our CSI division standards tomorrow morning!
You bring up one of the bigger head scratchers here... How does the system handle our default structure AND allow you to customize these sections to your own standard, all while leaving the details in the proper places? As it sits right now, the system will carry any details in the FX Detail section down into the appropriate CSI division so you see all details available to you. These details are separated and organized with little headers so you can see where the details are originating from (and your details within that folder will be at the top). And obviously, these details and folders aren't going anywhere since they follow the same on demand downloading magic as our blocks folders.
If you have any thoughts on the matter, we would love to hear them. We will keep you posted on what comes from tomorrows meeting.
Your timing is something out of this world. We have it in the calendar to discuss our CSI division standards tomorrow morning!
You bring up one of the bigger head scratchers here... How does the system handle our default structure AND allow you to customize these sections to your own standard, all while leaving the details in the proper places? As it sits right now, the system will carry any details in the FX Detail section down into the appropriate CSI division so you see all details available to you. These details are separated and organized with little headers so you can see where the details are originating from (and your details within that folder will be at the top). And obviously, these details and folders aren't going anywhere since they follow the same on demand downloading magic as our blocks folders.
If you have any thoughts on the matter, we would love to hear them. We will keep you posted on what comes from tomorrows meeting.
I spent a half hour on composing a dissertation for you this morning. When I got to work, I noticed that somehow it didn't post. Here's the bullet list format without the support language:
1. Detail folder to be tied to project preferences rather than server installation.
2. Detail folder will accept cut-n-pasted paths including URL's rather than forcing the user to "Select a shared network folder". If we are going to be forced to use a drive letter (which I'm not completely against), LandFX should document how the user is to map off-site folder destinations such as Dropbox, i Cloud, SharePoint and OneDrive. Oh and maybe FTP sites too.
3. Allow us to add folder structures to our data base. For instance, If we want to keep the LandFX folder structure, but want to add (append it with) another complete structure.
4. Maybe there's documentation somewhere on LandFX, but I couldn't find out how to delete a whole folder, sub-folder and details at once. It appears that we have to first delete all of the details, then delete that blank folder, then do the same with all of the sub-folders, then do the same with all of the other branches of that folder before we can delete the parent folder. This would take hours with our irrigation folder structure. If LandFX doesn't provide the support to do such, is there a third-party developer that can be used to delete, cu-n-paste (and otherwise manipulate the database)? In my opinion, the Details database is extremely important, but it is equally difficult to modify. A decision to follow a certain folder structure (or even worse people creating their own haphazard folders) seems almost impossible to recover from. It seems like one has to start over and then open every single detail to refile it. Does that sound crazy, or is iut just my perspective?
This is a daunting task. If items 1 and 2 can be addressed, that would be a great start.Right?
-s
1. Detail folder to be tied to project preferences rather than server installation.
2. Detail folder will accept cut-n-pasted paths including URL's rather than forcing the user to "Select a shared network folder". If we are going to be forced to use a drive letter (which I'm not completely against), LandFX should document how the user is to map off-site folder destinations such as Dropbox, i Cloud, SharePoint and OneDrive. Oh and maybe FTP sites too.
3. Allow us to add folder structures to our data base. For instance, If we want to keep the LandFX folder structure, but want to add (append it with) another complete structure.
4. Maybe there's documentation somewhere on LandFX, but I couldn't find out how to delete a whole folder, sub-folder and details at once. It appears that we have to first delete all of the details, then delete that blank folder, then do the same with all of the sub-folders, then do the same with all of the other branches of that folder before we can delete the parent folder. This would take hours with our irrigation folder structure. If LandFX doesn't provide the support to do such, is there a third-party developer that can be used to delete, cu-n-paste (and otherwise manipulate the database)? In my opinion, the Details database is extremely important, but it is equally difficult to modify. A decision to follow a certain folder structure (or even worse people creating their own haphazard folders) seems almost impossible to recover from. It seems like one has to start over and then open every single detail to refile it. Does that sound crazy, or is iut just my perspective?
This is a daunting task. If items 1 and 2 can be addressed, that would be a great start.Right?
-s
These are all excellent points, and should be taken care of handily. As follows:
1. Yes, the plan is to have something akin to a checkbox in the Detail Preferences, to have the Library location apply to all preference sets or just this one.
2. We have multiple issues with accessing XML files via a UNC or URL path, so that is probably going to be out. You will need to map drives to these locations. You can see our documentation on how to do that here.
3. This is the plan, and the initial dialog box mockup has already been completed. The Projects screen will have the ability to view the project list via the same hierarchy of folders as in the Detail Explorer.
4. To delete a whole folder at once, this is best done from Windows Explorer. Folders within the Detail Explorer still need to be deleted one at a time, although this is also pending an improvement in functionality.
--J
1. Yes, the plan is to have something akin to a checkbox in the Detail Preferences, to have the Library location apply to all preference sets or just this one.
2. We have multiple issues with accessing XML files via a UNC or URL path, so that is probably going to be out. You will need to map drives to these locations. You can see our documentation on how to do that here.
3. This is the plan, and the initial dialog box mockup has already been completed. The Projects screen will have the ability to view the project list via the same hierarchy of folders as in the Detail Explorer.
4. To delete a whole folder at once, this is best done from Windows Explorer. Folders within the Detail Explorer still need to be deleted one at a time, although this is also pending an improvement in functionality.
--J
Just getting started here on organizing detail folders. Looks like CSI will be the way to go for us too...
There used to be a saying about the old Alaskan Highway (which has since been paved). It went like this: "Beware. Choose your rut carefully. You'll be in it for hundreds of miles."
Based on my experience, deciding on a standard filing structure for your LandFX details would come with a similar warning. This is a major reason that we have recently (over the last year) shifted to the CSI standard that appears to be the most common and ever growing industry standard (multidisciplinary). It's what I would recommend.
Below is an excerpt of a conversation that I had recently with a newer LandFX user. I post it because it may be of value to others.
___
Did you notice that category that we had called “Agency”? That’s where we keep agency specific details (like their standard details). However, if we are modifying a detail, for instance the distance that a tree has to be from hardscape before using a root barrier, we will save it as a new detail in an existing category and in the “description” section, while saving the detail, we’ll give it a description such as “Root barrier 6’ clear” or "Root barrier 8’ clear”.
We do not save/organize details by project (which is not to say that saving details to a project is not a good idea. That's just a completely different discussion). That’s the old way to do things before we had the details organized. We used to ask “What project was that in which we used the so and so detail?” – That just doesn’t seem like a good way to save details to me. I’d rather save them by category and description using some kind of organizational structure that is descriptive rather than project specific. As an example, if I’m a new person that is helping in your office and I have no history with previous projects, what advantage would it be for me to see a detail under a project name? Presumably none. Right? On the other hand, if I see a description that says root barrier 6’ clear, I have an idea of what it may be.
___
Not part of the excerpt:
One more thing. I'm hoping that LandFX comes out with their updated CSI folder structure VERY SOON. All of us that are currently using CSI are setting up our own sub categories. I don't know how many of us have tried to modify categories or subcategories of a detail file structure within LandFX, but let me tell you it is about the chunkiest, most restrictive elements of LandFX. It's not just next to impossible to change it once you've started to add subcategories, it can be a down right scary thing to do. Legacy projects WILL be affected.
That's why I hope that LandFX (A....a) will hasten its efforts in this area. Not just for us, but for all of the other users who are already moving to the CSI standard.
Good luck my friends.
Based on my experience, deciding on a standard filing structure for your LandFX details would come with a similar warning. This is a major reason that we have recently (over the last year) shifted to the CSI standard that appears to be the most common and ever growing industry standard (multidisciplinary). It's what I would recommend.
Below is an excerpt of a conversation that I had recently with a newer LandFX user. I post it because it may be of value to others.
___
Did you notice that category that we had called “Agency”? That’s where we keep agency specific details (like their standard details). However, if we are modifying a detail, for instance the distance that a tree has to be from hardscape before using a root barrier, we will save it as a new detail in an existing category and in the “description” section, while saving the detail, we’ll give it a description such as “Root barrier 6’ clear” or "Root barrier 8’ clear”.
We do not save/organize details by project (which is not to say that saving details to a project is not a good idea. That's just a completely different discussion). That’s the old way to do things before we had the details organized. We used to ask “What project was that in which we used the so and so detail?” – That just doesn’t seem like a good way to save details to me. I’d rather save them by category and description using some kind of organizational structure that is descriptive rather than project specific. As an example, if I’m a new person that is helping in your office and I have no history with previous projects, what advantage would it be for me to see a detail under a project name? Presumably none. Right? On the other hand, if I see a description that says root barrier 6’ clear, I have an idea of what it may be.
___
Not part of the excerpt:
One more thing. I'm hoping that LandFX comes out with their updated CSI folder structure VERY SOON. All of us that are currently using CSI are setting up our own sub categories. I don't know how many of us have tried to modify categories or subcategories of a detail file structure within LandFX, but let me tell you it is about the chunkiest, most restrictive elements of LandFX. It's not just next to impossible to change it once you've started to add subcategories, it can be a down right scary thing to do. Legacy projects WILL be affected.
That's why I hope that LandFX (A....a) will hasten its efforts in this area. Not just for us, but for all of the other users who are already moving to the CSI standard.
Good luck my friends.
I concur with you on the reasoning for going with the CSI folder structure.
My concern is in having someone modify the "Standard" detail that resides in the CSI folder. Say it happens to be a Tree Planting Detail. This detail may be used across many projects. If someone changes that detail per some plan check comments and saves it without a new name, then potentially an already approved project could have the detail unwillingly revised. That's my dilemma.... I'm thinking that the CSI folder is the starting point for all details. These are then browsed for and copied into a Project Detail Folder.
I understand that this would create duplicate details, one in the CSI folder and then another in the Project Detail Folder. Wondering what would be the best approach for managing the cast detail library which will only continue to grow.
My concern is in having someone modify the "Standard" detail that resides in the CSI folder. Say it happens to be a Tree Planting Detail. This detail may be used across many projects. If someone changes that detail per some plan check comments and saves it without a new name, then potentially an already approved project could have the detail unwillingly revised. That's my dilemma.... I'm thinking that the CSI folder is the starting point for all details. These are then browsed for and copied into a Project Detail Folder.
I understand that this would create duplicate details, one in the CSI folder and then another in the Project Detail Folder. Wondering what would be the best approach for managing the cast detail library which will only continue to grow.
Rob,
I agree with your reasoning. This is the "Completely other discussion" that I was speaking of. There's more thought that you will have to put into this, but I'd strongly consider NOT adding project names to your detail file structure. There is no place for that in the CSI naming convention.
We don't copy details to the project folder and I don't have time to discuss this right now, but it is a very good discussion over a cold one. There are definitely pros and cons to each practice, but since we have been using the CSI format, we've definitely been better organized and are better prepared to have staff come in and know where to find drawings.
I'll let Amanda correct me it I'm wrong, but I think that if you copy the detail to the project, it will look there first rather than the location where the original detail is stored. So, it's up to you, or your staff to decide if the modification is an improvement to the existing detail, or should be another separate detail that should be added to your library. If it's an updated (better) version, then you should have little concern about having other projects reference the updated detail. If it's a new detail, for a different situation (agency or configuration) then it should be saved as a new detail and will not influence any previous instances.
It's really hard to discuss this without entering into the discussion as to whether your details are saved to the project (which again is different from saving to another subsection in your detail folder structure). September is a ways away, so maybe we should get together sooner over a cold one to discuss this. :-)
Again, my advice is to go with CSI and stick with the categories that are set forth there. It's a pretty good standard with pointier heads than me have developed (or are developing (such as A.a..a).
I agree with your reasoning. This is the "Completely other discussion" that I was speaking of. There's more thought that you will have to put into this, but I'd strongly consider NOT adding project names to your detail file structure. There is no place for that in the CSI naming convention.
We don't copy details to the project folder and I don't have time to discuss this right now, but it is a very good discussion over a cold one. There are definitely pros and cons to each practice, but since we have been using the CSI format, we've definitely been better organized and are better prepared to have staff come in and know where to find drawings.
I'll let Amanda correct me it I'm wrong, but I think that if you copy the detail to the project, it will look there first rather than the location where the original detail is stored. So, it's up to you, or your staff to decide if the modification is an improvement to the existing detail, or should be another separate detail that should be added to your library. If it's an updated (better) version, then you should have little concern about having other projects reference the updated detail. If it's a new detail, for a different situation (agency or configuration) then it should be saved as a new detail and will not influence any previous instances.
It's really hard to discuss this without entering into the discussion as to whether your details are saved to the project (which again is different from saving to another subsection in your detail folder structure). September is a ways away, so maybe we should get together sooner over a cold one to discuss this. :-)
Again, my advice is to go with CSI and stick with the categories that are set forth there. It's a pretty good standard with pointier heads than me have developed (or are developing (such as A.a..a).
Rob,
I'm a fan of coordinated dual CSI and Project folder structures, myself. I like to keep standard details linked to CSI folders always so that any changes to standard details ripple into past projects that reference them. This is the big controversial decision - a lot of offices don't want past projects to be auto-updated.
I personally felt the pros vastly outweighed the cons. I didn't see fixing glaring errors in a past-project's detail that was already approved to be an issue. For instance, there was once a gate detail that, as drawn, was not physically possible to open the gate.
Fixing it across the board instantly was therefore a great benefit, and I decided that if anybody complained that the detail changed, I'd deal with it on a case-by-case basis. No cases where somebody (contractor or otherwise) complained about it ever came up.
Now, I'm one of the biggest CSI cheerleaders, but there's definitely a time and place for a project-specific detail. I like to limit that to only details that couldn't possibly EVER be used in another project, such as a entry feature with the name of the subdivision on it, or a custom sculpture. Now they may be based on a standard detail, like a standard pillar detail that you customized to add the initials of your client in a cast plaque. I just like to keep one-time use details out of the CSI folder so they don't accidentally get used again. It also keeps the clutter to a minimum.
A lot of users elect to make copies of everything, though, like you're contenplating. They maintain a single standard detail that gets updated with any fixes to problems with it, but make a copy each time its used in the project folder to make sure any future changes don't affect past projects. It ends up working very well, too, and has the benefit of constantly making copies of old versions to go back to if an improper edit is discovered.
Having maintained an office detail structure while being a project manager, I needed to make it a habit on myself to always double check the details that are placed on the final plan to go out to make sure firstly that the correct detail I wanted used was actually used, and that there are no errors I can see on the detail being used. That check helped me constantly re-evaluate our standard details on a project-by-project basis, helping them evolve with evolving field experience. Edits were always done on the original standard detail. With copies, you'd need to then apply those changes to other projects as needed as well. It could be a lot of editing.
As for the new updated CSI structure - thanks for the prodding, Seaweed. It gave me some ideas on how to roll out the CSI folder structure updates in a way that works with the existing CSI libraries out there.That's mostly what I've got left to work out before releasing it.
-Amanda
I'm a fan of coordinated dual CSI and Project folder structures, myself. I like to keep standard details linked to CSI folders always so that any changes to standard details ripple into past projects that reference them. This is the big controversial decision - a lot of offices don't want past projects to be auto-updated.
I personally felt the pros vastly outweighed the cons. I didn't see fixing glaring errors in a past-project's detail that was already approved to be an issue. For instance, there was once a gate detail that, as drawn, was not physically possible to open the gate.
Fixing it across the board instantly was therefore a great benefit, and I decided that if anybody complained that the detail changed, I'd deal with it on a case-by-case basis. No cases where somebody (contractor or otherwise) complained about it ever came up.Now, I'm one of the biggest CSI cheerleaders, but there's definitely a time and place for a project-specific detail. I like to limit that to only details that couldn't possibly EVER be used in another project, such as a entry feature with the name of the subdivision on it, or a custom sculpture. Now they may be based on a standard detail, like a standard pillar detail that you customized to add the initials of your client in a cast plaque. I just like to keep one-time use details out of the CSI folder so they don't accidentally get used again. It also keeps the clutter to a minimum.
A lot of users elect to make copies of everything, though, like you're contenplating. They maintain a single standard detail that gets updated with any fixes to problems with it, but make a copy each time its used in the project folder to make sure any future changes don't affect past projects. It ends up working very well, too, and has the benefit of constantly making copies of old versions to go back to if an improper edit is discovered.
Having maintained an office detail structure while being a project manager, I needed to make it a habit on myself to always double check the details that are placed on the final plan to go out to make sure firstly that the correct detail I wanted used was actually used, and that there are no errors I can see on the detail being used. That check helped me constantly re-evaluate our standard details on a project-by-project basis, helping them evolve with evolving field experience. Edits were always done on the original standard detail. With copies, you'd need to then apply those changes to other projects as needed as well. It could be a lot of editing.
As for the new updated CSI structure - thanks for the prodding, Seaweed. It gave me some ideas on how to roll out the CSI folder structure updates in a way that works with the existing CSI libraries out there.That's mostly what I've got left to work out before releasing it.
-Amanda
Thank Amanda and Steve....
I am leaning towards the duplicate structure. I'd prefer no to have old details updated, kind of an archival process in a way. A big issue with updating all details is that it could negatively affect cost for construction. A lot of our clients go out to bid on projects and then request that an future changes be identified with a Delta and Cloud. If someone else makes a change to a detail and then it isn't updated with a Delta & Cloud, there would be repercussions. A contractor could claim the changes were never picked up and therefore wasn't bid properly.
Steve, I do like your idea of getting together over a cold one though.... It's on me this time! Amanda, you're more than welcome to join in too. It is a bit of a ways from SLO though....
I am leaning towards the duplicate structure. I'd prefer no to have old details updated, kind of an archival process in a way. A big issue with updating all details is that it could negatively affect cost for construction. A lot of our clients go out to bid on projects and then request that an future changes be identified with a Delta and Cloud. If someone else makes a change to a detail and then it isn't updated with a Delta & Cloud, there would be repercussions. A contractor could claim the changes were never picked up and therefore wasn't bid properly.
Steve, I do like your idea of getting together over a cold one though.... It's on me this time! Amanda, you're more than welcome to join in too. It is a bit of a ways from SLO though....
Probably shoulda shared this with you two... I've attached a PDF of how I think the file naming will go, would like some feedback.
Will be arranging our projects by job numbers, see any issues with that?
Will be arranging our projects by job numbers, see any issues with that?
- Page :
- 1
There are no replies made for this post yet.
Contact
- Land F/X
Our software tailors AutoCAD® to the needs of landscape architects, irrigation designers, and other professionals. We automate your most tedious tasks and ensure accuracy, giving you more time to design.