FMDesktop (Read Only)
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Polylining and BOMA Standard

40 REPLIES 40
Reply
Message 1 of 41
josrios
1658 Views, 40 Replies

Polylining and BOMA Standard

I read that FmDesktop doesn't need plining because it automatically recognize de spaces. But for those whom understands BOMA, you know that each space type has a different perimeter or bounding line depending if its a floor common space, building common , vertical or usable area. How the automatic room recognition of FMDEsktop deals with the BOMA standard?
40 REPLIES 40
Message 21 of 41
mark.evans
in reply to: josrios

A couple of points here...

I don't have all of the information with me since I am travelling, but I would suggest that you look closely at spaces in ADT 2007. ADT 2007 actually has rules to automatically create BOMA standard spaces. It can also implement the DIN standard in Europe.

Second, dig deep into Revit 9.1 and you'll find an option panel to control how rooms are defined: face to face versus centerline, etc.

Finally, if you have polylines already for FacilityCenter, don't touch them. You can use them again in FMD. Use the Facility Link application with your AutoCAD. You can pretty darn quickly load those polylines straight into FMDesktop. If you decide to switch to ADT spaces or build a new building with Revit, just do that for the new construction. FMDesktop doesn't care what mix of various CAD or models you use. Mix ACAD, ADT and Revit all.

Watch soon for a couple of whitepapers on the FMDesktop web sites. One describes the various tools you can use to define the spaces. A new one will talk about how to implement BOMA standards.

Mark Evans


Mark Evans
Senior Product Manager
AEC Division, Simulation Product Line
Autodesk, Inc.

Message 22 of 41
josrios
in reply to: josrios

Will you recomend to go with FMD ? My current CAFM software licence is costing me too much.
Message 23 of 41
Anonymous
in reply to: josrios

lol... just to clarify... do you know Mark works for Autodesk?
I would certainly hope he'd recommend going with the product. 😜


Also, Thanks Mark, I'm happy to know that about Revit, after the
discussions at AU, I thought it was all just paint to paint with no
choice, but, technology moves forward! I look forward to the whitepapers.

Melanie Perry
***not all who wander are lost***
http://mistressofthedorkness.blogspot.com

josrios wrote:
> Will you recomend to go with FMD ? My current CAFM software licence is costing me too much.
Message 24 of 41
josrios
in reply to: josrios

LoL To myself!!!

I should have noticed that, but I was so concentrated in my needs. Well, then Mark is the one who can help me to obtain a trial version of FMD. My actual FM tool is costing me too much and Ii'm looking for a replacement. FMD is 1rst in line for evaluation and then Archibus. So Mark, Help me here!
Message 25 of 41
mark.evans
in reply to: josrios

Jos,

I am the Product Manager for FMDesktop. If you will send me an email (mark.evans@autodesk.com) with your contact information, including your location, I'll put someone in touch with you about a trial.

Mark Evans
Autodesk


Mark Evans
Senior Product Manager
AEC Division, Simulation Product Line
Autodesk, Inc.

Message 26 of 41
Allerian
in reply to: josrios

Bob - It should be mentioned that if you are actually reusing polylines you previously linked in another CAFM program, you should strip the extended entity data before linking to FMD.
-Robert
Message 27 of 41
josrios
in reply to: josrios

Hi:

Can you go deeper on this? I want to know!
Message 28 of 41
Allerian
in reply to: josrios

Sure thing josiros. Almost every cad/database linking program ever made uses the "extended entity data" feature of AutoCAD. Apologies if I get too technical here: In the background of AutoCAD, there is quite literally a "database" of entities that make up your drawing file. For each kind of entity there are "group codes" that define the object. A Line will have two group codes that define its start and end. For example, a line that goes from 0,0 to 10,5 would have a group 10 code defined as "0,0", and group code 11 defined as "10,5". Do a little research on this topic if you're interested - I'm really simplifying it here.

Long story short, there is another set of group codes called "extended entity data" whose group codes being with 1000 and above. Those codes can hold longer string and numerical values and are used by programmers to tie a polyline to a database. When you are planning to move polylines from one CAFM system to another, it is important (but not always required by the manufacturer) to clear the polylines of the data from your old system. There are several ways to do it, the easiest of which is the XData Strip routine in the "Toolpac" third-party AutoCAD add-on.

You're welcome to contact me if you want to discuss this in detail. Promise I'm not trying to sell you anything 😉

-Robert
FM Desktop User's Group
http://www.fmdugi.org
Message 29 of 41
josrios
in reply to: josrios

Hi!

I understand your point and the AutoCAD DB . What I dont get is why to clear -up the p-lies? You write: -"When you are planning to move polylines from one CAFM system to another, it is important (but not always required by the manufacturer) to clear the polylines of the data from your old system." Why do I need to do that? The way I see it, the P-line object has many records. Each p-line object has its own ID code, thats how the CAFM software relates to it. The information will be extracted from it and incorporated to the CAFM DB almost all the times by data sync. But once your data link between your CAFM system and your p-line is terminated, you can related it to anything else. I'm not an expert but I'm almost sure that you can related it to multiple applications as you do with regular DB records. I have not mastered this topic. Can you bring some light? I will love to learn more about this!
Message 30 of 41
Allerian
in reply to: josrios

An excellent question. While it is true that the polylines could hold multiple definitions from different CAFM system (or other data-related apps), it becomes a question of minimizing the potential for a problem. If one day you are having a problem with your FMD cad link and the support guy says, "hey, there's this other EED in your polylines", you may face unforseen challenges. A quick polyline strip is cheap insurance. Few if any CAFM makers have created routines to simply re-use the EED created by a competitive product.

Having done this very conversion (FC to FMD), I'll shed a little more light. Moving drawings from Facility Center to FMD goes like this (just the highlights for brevity's sake):

Create a label in your FC setup that simply has the Room Number. Save out each drawing's polylines and Room Number labels to new drawings. Run an EED strip routine on the polylines.

Convert your database from FC to FMD (no small task, have an experienced professional do this step).

In FMD, follow the standard Data Link/New FM Layout/Drawing Log procedure to connect the drawing. Then use Convert to Spaces, selecting the "old" FC labels as the Room Number text. FMD will then connect the polylines to your converted db and you're ready to rock.

-Robert
FM Desktop User's Group
http://www.fmdugi.org
Message 31 of 41
pajamabob
in reply to: josrios

As a housekeeping task, you are correct, stripping excess XData is a good idea. As for functioning with FMDesktop, there is no need for this to be done.
Message 32 of 41
Allerian
in reply to: josrios

Acknowledged, Bob.

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.

-Robert
FM Desktop User's Group
http://www.fmdugi.org Message was edited by: rburns
Message 33 of 41
josrios
in reply to: josrios

I see your point now! But I would like to have Mike Evans in this discussion to get his oppinion. This is very interesting. Maybe we should take it out as another topic.
Message 34 of 41
josrios
in reply to: josrios

Hi Mark!

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.
Message 35 of 41
Allerian
in reply to: josrios

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.
Message 36 of 41
josrios
in reply to: josrios

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.
Message 37 of 41
Allerian
in reply to: josrios

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.

-Robert
FM Desktop User's Group
http://www.fmdugi.org
Message 38 of 41
josrios
in reply to: josrios

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.
Message 39 of 41
Allerian
in reply to: josrios

Agreed. We are talking about 1 minute worth of work per drawing. Cheap insurance in my book.
Message 40 of 41
mark.evans
in reply to: josrios

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


Mark Evans
Senior Product Manager
AEC Division, Simulation Product Line
Autodesk, Inc.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report