Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by ericjhberg

  1. First of all, let me say that the new 2024 Fence tool is such an improvement over the former functionality that I don't want to sound ungrateful when I suggest that it still needs some edits.


    I think the gate functionality is still a little clunky, but seemed to be workable until I realized that there is no easy way to quantify or add data to gates independently from the fence run they exist within. You should be able to select gates in a similar way to doors work within walls and you should be able to control their data independently from the fence line they exist within. This is extremely important when adding data tags, quantifying gates, and or reporting gate specific information.

    • Like 2
  2. True; however, for complex site models and processes that we have worked out over the years, there are speed benefits from interacting with the site model that do arise.


    Additionally, even to update Cut/Fill, you have to interact with the site model as you can't update those numbers with the Site Model is Locked using the Lock/Unlock function.

    • Like 2
  3. Thanks @Pat Stanford, I was aware of this feature, but it actually doesn't help here because

    1. Frequenty interaction with the Site Model settings and iterative updates makes Lock/Unlock cumbersome
    2. The risk of moving the site model actually comes with the interaction, so even if you lock it, when you unlock it and interact with it, the risk of moving it is still just as high.


    • Like 2
  4. It is way to easy to accidentally grab and move site models.


    You should be able to "LOCK" a site model in place the same way you can Lock a Referenced Viewport. The lock needs to allow you to manipulate and update the site model, but should prevent it from moving.


    I've asked for this before, but can't find the original thread.

    • Like 4
  5. 7 hours ago, Nikolay Zhelyazkov said:

    Just saw that you have a test file attached. Here is how I modified it using DataTagField to get what you want:

    @Nikolay Zhelyazkov...this is amazing and 100% solves the problem/question posed. I'm excited to get this into our workflow ASAP.


    BTW...I had no idea that there is a DATATAGFIELD function available and even then, that it woud use the Field Label to query specific information, but I'm super glad that it does exist. This is one of those buried functionalities that I don't know how users ever figure out its there...other than to post something like this here and get help...so thank you again!

    • Like 1
  6. 22 minutes ago, trevorgooch said:

    One thing that may help is to attach a record to the data tag, and use a link field.  Essentially, you can shuttle data from the source object into a record associated with a data tag.  This allows for all sorts of interesting opportunities, like applying a data visualization to a data tag!


    I'm intrigued @trevorgooch. We've thought about attaching redundant records to data tags, but without someway of linking them to the original data, it would still be a difficult manual data entry job to keep track and manage...with many opportunities for error.


    Your way sounds better, but I may need a little tutorial on this functionality to see how effective it could be in this case.

  7. 59 minutes ago, Vlado said:

    @ericjhberg this is pretty cool, thank you for the analysis of the problem.

    It is definitely a problem we need solved soon.

    It looks to me that, as suggested, we need a new feature or two.

    Let me consult internally, and I'll contact your.


    Thanks @Vlado for your prompt response. I really do think the "Intersects With" criteria could be far more powerful than this specific use case...especially if it could somehow return the AREA of intersection between two objects without having to actually run an intersection command. In the landscape architecture world, this need is most frequent for SHADE calculations where we need to calculate the area of a hardscape that intersects with trees. Currently the only way to do it is to break down tree symbols into base circles, duplicate hardscapes, and run intersection commands that allow for specific AREA queries. This doesn't respond well if anything changes.

  8. Alright VW Friends, we need some help troubleshooting a particular workflow that has become problematic.


    The challenge...

    How do you create a legend that is specific to the items being identified by Data Tags within a given viewport using Records and Data Tags?


    Because this is a technical question, I'm going to have to get into the weeds a little with our particular challenge.


    We have grown particularly fond of using specific custom record formats, coupled with data tags, to more easily manage callouts/keynotes in a drawing. It is very easy to create "Master" legends that summarize specific information in a variety of ways for all "similar" objects across a drawing/file using isolation techniques like class, record format, layer, etc.


    The difficulty lies in using the same record information to query a subset of those objects that appear in specific viewports, and exclude those that do not appear.


    In the landscape architecture world, it is not uncommon to have projects where improvements span multiple sheets and/or viewports. These are typically separated by match lines.


    In the image below, we have a simplified scenario where improvements are divided into (4) different viewports...



    Notice that there are (7) objects in the drawing, each attached with the same record format and identified using the fields ID# and DESCRIPTION. The large circle, which is actually clipped into two objects by the serpentine "sidewalk", exists in all (4) of the viewports. In the attachments to this post are exports of each sheet layer as an individual image where it is possible to see that data tags, placed in the annotations of each viewport, can easily identify the objects by their ID#. I've also attached the VW file used to create this example.


    QUESTION: Now...how do you populate each of the unique worksheets with the items identified by the data tags (or even those that are clearly visible in the viewport)?


    The goal, given this example, is to provide legends (worksheets) that should include items as follows:

    • Sheet 1
      • P-1
      • P-2
      • P-3
    • Sheet 2
      • P-1
      • P-2
      • P-3
    • Sheet 3
      • P-1
      • P-2
      • P-4
    • Sheet 4
      • P-1
      • P-3
      • P-4


    You will also notice that the legends (actually worksheets in VW) do not correctly indicate the objects that are visible...or even those that have Data Tags. Sheet 3 doesn't include any...this is because our methodology, up until now, has been to use the Location...is within criteria in each unique worksheet to query the objects that fall within shapes that represent each viewport (gray dashed squares). For example,

    • Schedule - Sheet 1, is querying ALL objects with 1) Record attached, and 2) Location is within Shape 01
    • Schedule - Sheet 2, is querying ALL objects with 1) Record attached, and 2) Location is within Shape 02
    • Schedule - Sheet 3, is querying ALL objects with 1) Record attached, and 2) Location is within Shape 03
    • Schedule - Sheet 4, is querying ALL objects with 1) Record attached, and 2) Location is within Shape 04


    The problem arises because the Location...is within criteria only successfully queries objects where the Center Point falls within the identified Object. This is why Sheet 3 doesn't return anything but should include P-1, P-2, and P-4. There are technically two P-1s in this viewport because the large circle is being clipped by the serpentine path, but both of their respective center points fall outside of the Shape 03. Similarly the center of P-2, the serpentine sidewalk, is in Shape 02; and the center of P-4, the rectangular deck is in Shape 04.


    We have various workarounds to try and remedy this situation using this "Location Based" workflow, but they are needlessly complicated and result in errors that are difficult to track down and timely to troubleshoot. They are not worth mentioning and the goal of this post is to try and find another, better way.


    It seams to me that a solution might already exist, but as someone who knows VW quite well, I have struggled for a long time to figure out what it could be.


    A solution that does work, but we want to avoid at ALL costs is...clipping the objects by their specific viewports so that each object is firmly located "within" each specific viewport. This is a terrible method because it destroys all sense of greater geometry, creates more opportunity for error, and does not facilitate easy revisions if geometries require editing.


    I could think of two solutions, but both are NOT CURRENT functionality within VW that I am aware of:

    1. Query Data Tags and Report Their Linkage - The problem with our workflow is that it is querying the objects...not the data tags. It is possible to place the correct data tags on each sheet, regardless of where the object's center is, and it is possible to build a query/report of specific data tags on a given sheet layer. What IS NOT possible is to link the query of a data tag to the data of the object it is tagging.
    2. Intersection Criteria - If, instead of the only location based criteria being available being either "Is Within" or "Is Not Within", potentially adding an "Intersects With" option could mitigate the issue of an objects center point driving the query results. This is functionality common to many GIS software programs and it is one that I think could benefit a lot of use cases...


    Calling all helpful users to help figure out the best workflow for this

    @Eric Gilbey, PLA @bgoff @rowbear97 @Tony Kostreski @Vlado @Pat Stanford

    Sht-1-SHEET 1.JPG

    Sht-2-SHEET 2.JPG

    Sht-3-SHEET 3.JPG

    Sht-4-SHEET 4.JPG

    VW Sheet Legends and Data Tags.vwx

  9. The Select Similar tool needs to incorporate an "Object Style" option...ideally broad enough to understand the that you are trying to select similar Object types with Similar Styles applied to them.


    This would quickly allow users to select and identify all similar objects that have the same style applied.


    The Select Similar Tool does currently have "Style" as an option, but only for Wall, Slab, and Roof Attributes. This should be much broader, and should include, but not be limited to, the following:

    • Doors
    • Windows
    • Data Tags
    • Hardscapes
    • Landscape Areas
    • Viewports (VW2024)
    • Anything else with "Style" capabilities not currently covered by the tool
    • Like 1
  10. @AlanW...Unfortunately this is something altogether different. I am familiar with the old plug-in/leader conflict and have used your solution on many occassions, but this is a problem in basic object types...lines, polygons, etc. and has nothing to do with plug-in memory. I have notified VW of the problem and they have confirmed and are supposedly working on a solution.

    • Like 1
  11. I have been talking with VW staff on this issue over JIRA, but essentially have traced it down to a bug. There is actually different functionality on this issue in Windows vs. MacOS.


    On Windows, starting in VW 2022, the Make All Attributes by Class option will add an endpoint style to ALL objects and the only way to remove it is by manually removing the endpoint style...defeating the Make All Attributes by Class benefit.


    On MacOS, this does not occur and the functionality of previous versions remains in tact where Make All Attributes by Class DOES NOT affect the endpoint style of objects, but endpoints can be added to objects manually.


    Obviously, the differentiating functionality across versions of the program means that this is an issue, and I only see two ways of resolving it.

    1. Match the current Mac behavior (which was the typical behavior pre-2022) and make it so that endpoint styles do NOT respond to Make All Attributes by Class settings.
    2. OR (preferable)...just add a None option to the Class settings for endpoint styles...allowing for users to specify certain classes that my want endpoint styles to be by class, while others more typically can be set to none. If you choose this route, behaviors on both platforms should match though.
  12. Pacific Coast Land Design, Inc. (PCLD) is seeking a motivated and skilled landscape design professional to join our award-winning firm. The studio, located in beautiful downtown Ventura, specializes in regional projects throughout Ventura County, Santa Barbara County, and Northern Los Angeles County. With an emphasis on public space, PCLD is proud to have contributed to the development of a broad range of community serving projects in our region. 


    As we head into our 40th year, this is an exciting opportunity to join the creative and dynamic staff of our growing firm. PCLD offers opportunities to engage in every aspect of the practice. From design detailing and 3d rendering to project management, community engagement, grant writing, and even business development; we encourage everyone to take part, and be a part of our collective effort to provide our clients and the communities we serve with premier service.  


    A well-positioned candidate will be a self-motivated and collaborative team player, with strong written and verbal communication skills and well-developed design and technical acumen.


    We are a fully intergrated Vectorworks office, leveraging the platform's BIM and 3D modeling capabilities for everything from concept development through construction documentation.


    For more information about the job posting and to apply, visit https://www.pc-ld.com/careers



    A professional degree in landscape architecture or related field of study from an accredited university. Must be legally eligible to work in the U.S.A.

  13. Thanks @Pat Stanford. You're right, I just checked this out in SP3 and it appears to be "fixed"...meaning it at least reverted back to prior functionality where markers were not activated as a part of Make All Attributes By Class.


    While I think this functionality is fine and matches the way we have used the program forever...I didn't have an issue with the idea that maybe markers could/should be activated for certain specific classes through Make All Attributes By Class...only if that were the case, then None should also be an option in the Class Settings.


    Anyway, as long as it stays this way, I guess I'm still fine with it.


    Thanks again.

  14. On 4/22/2022 at 6:14 PM, jeff prince said:

    until we start detailing or doing enlargement plans that are more related to the human scale.


    Thanks @jeff prince for chiming in. I completely agree, but we since we eventually have all our details and human scale elements in the same file, we definitely need to be able to dimension things architecturally from the get go...and I don't like my ADA compliance details reading 2.8333 feet (34") or my horizontal width dimenions reading 5.00 (would prefer 5'-0").


    If only we were collectively brave enough to go metric...life would be so much simpler.

  15. We are finally transitioning to VW2022 and noticed that the line endpoint style (i.e. arrow, dot, etc.) is always visible on objects that are set to Make All Attributes by Class. It appears that this is intentional since in previous versions, the ability to have endpoints visible under when setting objects to use the class settings wasn't possible and had to be controlled on individual elements. 


    That said, it doesn't appear that there is anywhere to set a class style to have NONE as an option for the endpoint style? You can individually set objects to have no endpoint, but this defeats the purpose of the Make All Attributes By Class.


    It seems that VW solved one problem by creating another...and the solution is to add the ability to have a endpoint style be set to None in the class settings.


    Am I missing something?

    • Like 2
  • Create New...