Announcement

Collapse
No announcement yet.

Naming Convention - Annotations

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Naming Convention - Annotations

    Nice work Klaus
    I`m redoing my annotation families. (according to Aaron template tutorial).
    There is no thread about this category so if it`s a loadable family i will ask here. According with "RFODraft1" we have for loadable families the style is <Category>_Type>_<Manufacturer><Descriptor>_<Hos t/Size>

    First i will explain about my anno.
    My anno files that i`ve made it some days ago have an initial name, but i think is not very good so i want to adapt to RFO style and ask what info should be in the name.

    For example are you putting the size of the text in the name? Is user proof? Or should i use the scale where each anno family should be used.

    I also have types (as you see in the names from the picture) that are left aligned or center aligned (i like more left aligned but when it`s not space in a small room maybe i will use a center aligned...). Also I have transparent ones and opaques one. I don`t want to have all this attributes in just one family because i want to decide in some of the project to keep just some styles (so being different families I can remove from the template at the start of o project let say the center opaque room tags). What is your opinion on this kind of things. I also don`t use font text in the name because is the same everywhere (Revit Text font according to tips and tricks) Finally, every tag contain all the needed combination between name,number,volume,are so i don`t feel the need to put this used parameters in the name of the anno. So what should be the name like according with the RFODraft1?

    Anno_Tag_RoomTag_1:50_LeftTransparent (1:50 can`t be in the name..Revit doesn`t want":"caracter. If i use"-" or"/" RFO doesn`t want it )

    or

    Anno_Tag_RoomTag_3mm_LeftTransparent (the size don`t looks to be user proof...is the same discussion that was here for the name of line styles..where you should name the line syle by the thing it is represent, not by the pen thickness).

    Also as you observed, annotation don`t fit in manufacturer and host part from the loadable family style.

    I need yours opinion about this kind of things.
    Attached Files
    Last edited by gaby424; May 11, 2011, 06:59 PM.

    #2
    The other annotations that i`ve made from the OOTB Architecture folder are like in the picture.

    Because there are a lor parameters involved, the name should have the parameters that the tag reads so a name should be like this?

    Anno_Tag_CeilTag_TypeMark_2mm

    Here i have the formatting style in the family types (opaque or transparent). I think i have to rethink the families to have the same system.

    An annotation thread should be opened.
    Attached Files
    Last edited by gaby424; May 11, 2011, 06:59 PM.

    Comment


      #3
      Hi Gaby. Moved the above posts to a new dedicated thread

      Personally I´m against having different sizes for different view scales... If it won´t fit on the view, it doesn´t belong there... But i realize that others have a different opinion.

      First identifier: <Anno>

      Second identifier: <Category> - e.g. Tag, Symbol (Generic), Callout, ElevationMark, GridHead, LevelHead, ViewTitle, SpotElevation, etc.

      Third identifier: <Type>

      Examples:

      Anno_Tag_WallType
      Anno_Tag_WindowType
      Anno_Tag_WindowSill
      Anno_GridHead_New
      Anno_GridHead_Existing
      Anno_ElevationMark_Square
      Anno_ElevationMark_Circle

      That said, the Annotations is probably the least important thing in this project. The Annotations play a huge part of how the drawings are represented, and each and every Company will more than likely create their own, no matter how slick we build it
      Klaus Munkholm
      "Do. Or do not. There is no try."

      Comment


        #4
        thx And if we had an annotation that contain more parameters like a room tag that is reading diferent combinations from name area and maybe volume values we will have like this:

        Anno_Tag_RoomAreaNameVolume? It`s hard to read.

        or will only be Anno_Tag_RoomParam

        and the types well be
        NameAreaVolume
        and
        NameArea

        We have to think about the types name too.

        Comment


          #5
          I´d just go for Anno_Tag_Room and then have descriptive type names.... but again, I really don´t think that it´s an important part of the Style Guide... No way on earth that we´ll get everyone to agree on naming types, and I don´t think it´s necessary either
          Klaus Munkholm
          "Do. Or do not. There is no try."

          Comment


            #6
            ah off course everybody has an in house strategy. I just wanted to know if other apply the same rules when naming the types (no spaces, underlines? between words).

            Comment


              #7
              Honestly, I´ve been very sluggish with Type naming in the past... No strategy besides making it a descriptive and userfriendly name.

              Anno_Tag_Room: Number, Name & Area
              Anno_Tag_Room: Name only

              etc.
              Klaus Munkholm
              "Do. Or do not. There is no try."

              Comment


                #8
                Why not name types by their intended use, ie.

                >ANNO_TAG_WINDOW.rfa
                >>ELEV_100
                >>ELEV_200
                >>PLAN_100
                >>PLAN_200
                etc

                >ANNO_TAG_ROOM.rfa
                >>GA_100
                >>GA_200
                >>SET-OUT_050
                >>SITE_500
                etc

                then your styles can change without requiring renaming.

                You could even do away with the scale differentiator if you had thought up better names for each use - or be overly exhaustive and even use your local standards for documentation codes?
                Last edited by snowyweston; May 10, 2011, 08:56 PM.

                Comment


                  #9
                  Nice touch. This is even more user proof. Ups that`s me

                  Comment


                    #10
                    I use the same method I always use: 00_MdR_TG_Room_100 (00 being the SfB-code used in Holland for General Annotation and markups, MdR speaks for itself, TG = Tag, description by function, intended Scale
                    Martijn de Riet
                    Professional Revit Consultant | Revit API Developer
                    MdR Advies
                    Planta1 Revit Online Consulting

                    Comment

                    Related Topics

                    Collapse

                    Working...
                    X