Jump to content

ericjhberg

Member
  • Posts

    575
  • Joined

  • Last visited

Reputation

457 Spectacular

5 Followers

Personal Information

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

Recent Profile Visitors

3,953 profile views
  1. Hoping someone can help me create a node that sets input objects to All Attributes by Class...that also includes the class texture.
  2. @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!
  3. 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.
  4. 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.
  5. 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
  6. 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
  7. 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.
  8. @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.
  9. 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.
  10. 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 EDUCATION REQUIREMENTS 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.
  11. 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.
  12. I just wanted to repost this to see if any progress has been made on adding a None option to the line endpoint style inside the class options dialog. It would really solve the problem and allow us to continue our use of Make All Attributes By Class effectively.
  13. And I thought of a 4th functionality I would love to see in a grade object... 4. the ability to create a curved line grade object. Currently you can do this with a Site Modifier used as a sloping contour, but it won't link to anything...oh wait...and a 5th 5. Grade objects should be able to link with site modifiers as part of their network. This would create an amazing suite of interchangable site modeling tools.
×
×
  • Create New...