CAFM polylines are a valuable data asset - especially those which have been accurately field verified. As a steward of that data, this 'housekeeping' is a requirement for a responsible implementation. Square footage tracked in CAFM ties directly to dollars, meaning that the consistency and maintenance of those polylines is as important as database itself.
FM Desktop User's Group
Message was edited by: rburns
There is a discussion here (few lines above this one) about run an EED strip routine on the polylines as a good house keeping initiative to avoid posible data conflicts with FMDesktop. I'm asking for your opinion.
In fairness, I have years of experience, techniques, and best practices regarding this specific kind of work. Probably not Mark's job to weigh in with an "Autodesk company line" about other people's old EED, beyond what BobF (pajamabob) already pointed out; that there is no immediate conflict with FMD.
I understand. Can you mention a real situation? Maybe Something of your own experience, as a case study where p-lines data were in conflict and how you overcome the situation. What the conflict was? What was causing it? How you deal with the conflict? Was it with FMD or other aplication? That way we can all apreciate the value of your contribution and discharge all the hypothetical tougths about this. You can go as tech as you want. I think we all understand the concepts very well. And by doing that we all gain extra knowledge. I' m a Facility Center user.
Since I approach this in the way that I do, I have not had the opportunity to have such a conflict. I will however share the reason that this became a noteworthy topic to me in the first place. Long before I had ever used FacilityCenter, I was an Archibus implementor. There was at that time a condition in AutoCAD wherein a drawing could accidentally get its Entity Handle value set to a very high value (on the order of a 16+ digit number). Then, any time the drawing was inserted into another drawing, that drawing's next EH value would also be indexed to a high value. There values were out of the range that Archibus was programmed to store and would cause Archibus to behave erratically. For the client in question, we tracked it down to a ball valve block that was mistakenly inserted into the polyline drawing. If memory serves, fixing the drawing required a specific series of steps and relinking to Archibus. That situation is what initially drew my attention to this issue. I have had no additional problems since then, perhaps owing to careful management of the drawing elements we allow into production CAFM systems.
Again, this topic was simply brought up in passing, relative to the comments about reuse of polylines. To me, stripping out the old data falls into the same category as removing layers from a previous Layer Standard - sure, you could leave the old layers in there, but it seems a lot more responsible to remove them.
FM Desktop User's Group
Thanks for your response. I think that overall the message is like this:
It is a good practice to clear the p-lines to avoid a possibility of conflicts. It is not something imminent but if you spent some time doing it will provably pay back because it will be worth to deal with it after DB connection.
Well, I seem to have a reputation for pointing out alternatives and not taking a clear choice. I'm going to do that here too.
My personally compulsively organized behavior would lead me to follow Robert's advice to strip old entity data.
On the other hand, if I were the custodian of polyline data at a company and I thought there were any chance of needing to revert to, or even reproduce, that FacilityCenter data, I would tend to keep the FC entity data in place.
I always run into this sort of conflict. My personality is to get rid of extraneous stuff. My software engineering friends are always telling me to leave data alone if it isn't causing an error.
There is no official Autodesk position on this.
Mark Evans Senior Product Manager AEC Division, Simulation Product Line Autodesk, Inc.