Jump to content

ericjhberg

Member
  • Posts

    562
  • Joined

  • Last visited

Reputation

423 Spectacular

3 Followers

Personal Information

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

Recent Profile Visitors

2,969 profile views
  1. 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.
  2. 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.
  3. 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.
  4. I do...the problem is this involves a new Dimension Style...and I need to apply it to hundreds of stock design details that are already mapped to Document Unit standards. I'm hoping to avoid that effort. Additionally, this shouldn't be the reason independent unit control in Site Modifers, Site Models, and Grade Objects can't/shouldn't be realized.
  5. 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.
  6. Since the ability to link grade objects became available, the Grade Tool has really become a workhorse for parameter based Site Model/DTM workflows. That said, it would be great if more functionality could be added to it/improved Make most of the Settings... available for editing directly from the OIP...particularly the General settings and ability to toggle between Elevation, Downward Grade %, Upward Grade %, Downward Ratio (rise/run), Upward Ration (rise/run), and Elevation Change. Right now, you have to enter the extra dialog box anytime you need to reset a parameter for a grade object (that is for Downward Grade %, Upward Grade %, Downward Ratio (rise/run), Upward Ration (rise/run), and Elevation Change) Provide the ability to LOCK certain parameters once set. For example, after I set an object to use the Downward Grade at 2%, I want the ability to lock that parameter. Usually these are parameters that are set to compliance minimums, maximums, or best practices, and I never want them to change. This functionality could become extra useful when connecting multiple Grade Objects, essentially allowing subtle changes at precise locations to ripple through a network and change throughout. Obviously, this could case "breaks" in the parameters when everything is locked and the end result is that a locked parameter at the other end of the network can no longer be kept, but this is not too dissimilar from the mins/max settings in the Stair Tool. My biggest gripe with the grade tool (and other tools in the Site Model suite) are that the units cannot be controlled independently of the Document Units in the same way that Stake Objects function. This is a no brainer. Landscape Architecture in the US, with some exceptions, revolves around architectural scales for horizontal layout and engineering scales for vertical (i.e. feet and inches for horizontal, decimal feet for vertical). The Stake Tool already does this perfectly, just please extend that functionality to Site Models, Site Modifiers, and the Grade Tool...we've been waiting forever and there are no shortage of Wishlist Requests for this. @Vlado @Eric Gilbey, PLA @Tony Kostreski @Bryan G.
  7. I posted something similar in troubleshooting...
  8. 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?
  9. @Piotr Karczewski...completely agree! The irrigation tools were rolled out in 2017 and there have been 0 updates since. It's been largely forgotten and needs some serious attention if it hopes to remain a relevant and productive portion of the VW toolset.
  10. I love the functionality of Data Tags, they have completely changed our documentation workflow and data tracking, for the better. That said, I wish there were a few functionality upgrades. I'll post them in separate posts, so for this one...how data tags work on sheet layers in recognizing objects. It is clear that when adding a data tag in Viewport Annotations that it is designed to find the geometric center of the object, which may be fine for small or relatively "square" objects. Where this gets challenging is for objects that often span multiple viewports or asymmetric objects. For example, if you applied a Data Tag to the letter 'C', the Data Tag would be positioned in the void of the letter, not on the edges. The best practical example I have is a trail project where a long, linear trail is broken into several (10-20) different viewports with matchlines. To adequately identify the trail object (a single, closed polygon), the Data Tag tool will only find the object in the viewport that contains the geometric center point...not every viewport where the object is visible. To combat this, you have to break the object into a separate polygons per viewport. This is less than ideal becuase you have to break up geometry that should be simple, which enters opportunity for error in multiple ways. Even then, if multiple competing long, linear objects exist in one viewport, Data Tags defer to stacking order in the Design Layers to select which object to apply a tag to...making application of Data Tags almost impossible. You can use the Select Eligible Objects Mode to place all the Data Tags, but then positioning the leaders/arrows to accurately point to the correct object becomes an exhausting effort. Instead, Data Tags should be designed to recognize the edges and/or the fill of objects, not the geometric center point.
  11. I wish there was a way (maybe there is?) to format a calculation to return the area in common between two intersecting objects. I know that it is possible to calculate this area after performing an Intersect Surface command, but that workflow doesn't support iterative design very well. If the objects move, the area intersection changes, and you have to redo the entire workflow. This would be an amazing calculation for things like Tree Shade calculations, often required by permitting jurisdictions (and now integrated into the CalGreen Building Code). The calculation is essentially an intersection of the Graphic Tree diameter with areas of paving divided by the entire area of the paved surfaces. If the trees move around or you need to add/subtract, there is no way to easily re-perform this calculation without a bunch of duplication and destructive actions.
  12. I actually don’t know. Another consultant/contractor provided it for one of our projects and I didn’t get to ask.
  13. Maybe I missed the point, but the exhibit I shared is a way of visualizing the depths of cut/fill, not specific to contours. This is a functionality I wish VW could perform, but currently cannot. if you’re looking for a way to show both contours and cut/fill, then yes, duplicating the site model or using a site model snapshot is the only way.
  14. @jpccrodriguesUnfortunately no. I just posted this as an example of what we would love to produce if Vectorworks had the capability.
  15. I'm not sure that this is with contours, but rather as a gradient of more cut, to more fill. Something similar to the attached rough site plan where deeper reds = more cut and deeper blues = more fill. Ingore the green overlay.
×
×
  • Create New...