Jump to content

ericjhberg

Member
  • Posts

    581
  • Joined

  • Last visited

Reputation

472 Spectacular

5 Followers

Personal Information

  • Occupation
    Landscape Architect
  • Homepage
    http://www.pc-ld.com/
  • Location
    United States

Recent Profile Visitors

4,428 profile views
  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.
  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.
  3. Thanks @Pat Stanford, I was aware of this feature, but it actually doesn't help here because Frequenty interaction with the Site Model settings and iterative updates makes Lock/Unlock cumbersome 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.
  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.
  5. Hoping someone can help me create a node that sets input objects to All Attributes by Class...that also includes the class texture.
  6. @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!
  7. 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.
  8. 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.
  9. 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: 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. 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 VW Sheet Legends and Data Tags.vwx
  10. 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
  11. Reboosting this request. In the landscape world...if the wall tool is our go-to, we almost exclusively have to determine the top of wall condition. The ideal scenario would be to integrate that feature with the wall itself, eliminating the need for a redundant slab/hardscape/extrude, etc. to perform the top function. Additionally, integrating footing options into the walls would be a tremendous step forward too.
  12. @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.
  13. 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. 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. 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.
×
×
  • Create New...