Jump to content
  • 15
ericjhberg

Stake Tool - Read Elevations of Objects in Addition to Site Models

Question

18 answers to this question

Recommended Posts

  • 0

I second this.  I've called tech to try to explain/ask about this.  I don't think they ever understood what I was asking for.  This tool is pretty useless for any kind of civil plans because of this missing ability.

  • Like 2

Share this post


Link to post
  • 0

Third this, in addition, the ability to tie to Design Layer Elevation Levels or Story Levels or Stories. As they can be placed on the drawing and if RL's/FFL's change, corresponding labels update automatically.

  • Like 2

Share this post


Link to post
  • 0

Fourth. Stakes are for "Finished grades" Setting the grade to the bottom of a hardscape assembly is not a finished grade.

 

Also, please see my request for unit selection for the Grade Tool similar to the being able to set the units for the Stake Tool. It would make the Grade Tool much more useful.

 

 

Share this post


Link to post
  • 0

Good afternoon everyone!

 

@ericjhberg @lgoodkind @twk @EricK @Pan.Gad @jg@swcm 

 

Why cannot we do the same thing, only with the datatag tool? Same thing, but flexible in the way the output is written. 

 

The only problem - the current datatag tool cannot callout elevations, Z distance from elevations, and levels in stories (which is what you want). 

The flexibility of the datatag tool is that you can arrange the information any which way you want without using the stake datatag information. 

 

The stake tool is only useful in this case if you were to use GIS information, is this something that's also integrated into the workflow?

Share this post


Link to post
  • 0

Hi all,

I know it doesn't respond directly to the discussed solutions, but I have been using 3D loci to check the Z value. 3D loci can be then converted to stakes to show the levels in plan. In the OIP one can then change the display mode from elevation to Description/ Elevation and add ToW, for example.

 

Nevertheless, checking the wall levels could be made more simple.

Share this post


Link to post
  • 0

@Samuel Derenboim,

 

Thanks for your thoughts and suggestions about the data tags.

 

I am using these for annotation of symbols and plugin objects, but I have the fact that you need to create separate styles for each sort of annotation. What I like in AC is that one can insert fields within a text string - whether it's just a text box or multileader. I have been using that for keeping an eye on areas of playgrounds in my projects or counting plants. No styling required. Ok, apart from multileader style, but this is just annotation appearance, rather than the content.

Another thing about data tags is that the text inside is so inflexible. If you have your fields arranged in rows, then when your text is wrapped the lower fields won't adjust and be obscured by the text field above.

I really wish VW look into that seriously, because at this moment annotation is very clunky and inflexible.

Share this post


Link to post
  • 0

Michal, you can put all your fields into one text box, then you won't have the problem of fields overwriting each other. You can also insert a text string among the fields without any problem. Here, my text strings are "No." and "Press Return Here", and the other data comes from fields. Here's an example:
image.png

This is a Plant object, and I have just made a tag, which lists the Qty, Latin Name, Spread, and then some other text, then, on the next line, the Scheduled Size.

I'll paste screenshots to show how this was set up, but it is just ONE text box, and therefore it expands and contracts as required to display the data from the Plant. Including a return at the end of the first line of the field definition, forces the following data onto the next line.

 

image.png

Share this post


Link to post
  • 0
On 7/18/2020 at 11:38 AM, Michal Zarzecki said:

Hi all,

I know it doesn't respond directly to the discussed solutions, but I have been using 3D loci to check the Z value. 3D loci can be then converted to stakes to show the levels in plan. In the OIP one can then change the display mode from elevation to Description/ Elevation and add ToW, for example.

 

Nevertheless, checking the wall levels could be made more simple.

You can insert a Stake in a 3D view on any 3D geometry whether it is a wall, or extrude, or a Hardscape, and it will report the elevation of that point. There is no need to create 3D loci first.

The Data Tag will also report the height of the bounding box of any 3D object, using the #ΔZ# function, (found under the Object Functions list in the Data Tag definition). This works perfectly for anything where the height is constant. The #IPZ# function can be used to get the base elevation, but you should be wary of this because the Insertion Point Z may not be the base of the object (symbols, or extrudes, for example). IPZ is also relative to absolute 0 and not the layer elevation. For Walls, there are also specific functions that can be used to get the average height, but a data tag using specific wall functions will only work on walls. The above functions will work on anything that has 3D geometry.

Remember, you can also use Grade Objects to report elevations on 3D objects - again these will snap to existing geometry in a 3D view. They can also be used to modify the site.

 

And, Stake objects and Grade objects can be used as Hardscape Surface modifiers to set specific elevations on the hardscape and modify the surface to get the grades you want. When they are encapsulated within a Hardscape, they will report the elevation relative to the hardscape elevation, so I recommend you keep this at 0.

  • Like 1

Share this post


Link to post
  • 0
9 hours ago, Tamsin Slatter said:

you can put all your fields into one text box, then you won't have the problem of fields overwriting each other. You can also insert a text string among the fields without any problem. Here, my text strings are "No." and "Press Return Here", and the other data comes from fields.

 

Yes, I know all that and yet one still needs to create a particular data tag styles for different objects. My reflection was that this could be much more flexible, if the fields available in data tag could be inserted inside any text or callout object.

 

Another thing is that it seems that Data Tag object's width cannot be manipulated in the same way callout can. There are no vertices that allow the text box within the tag to be stretched.

 

I don't want to dwell too much on the pros and cons of data tags and their formatting, as that's not the thread's topic, but I am happy to discuss it in detail.

  • Like 2

Share this post


Link to post
  • 0

Thanks for clarifying Michal.

You are correct that if a Data Tag is reporting fields from a particular record, or set of object parameters, then there must be a style for each object type. However, if you are using one that uses Object Function, General Function, or Incrementing value as the Data Source, then such a tag can be used on any object where the function is relevant. You can also include a string.

 

And, if you make the tag layout By Instance instead of by Style, you can change the text in each, but of course you do have to get through a number of layers of dialog to get to each one. I can certainly file an enhancement request on this element, and the desire to reshape the bounding box of the tag itself.

 

In this particular thread, the conversation was about using the Data Tag for a Z value, and the example I showed does that without needing a separate style - but with certain caveats that different objects behave differently. I think the Stake is the safer way to do this, and as it can be applied to any 3D vertex in a 3D view, will do the job.

  • Like 1

Share this post


Link to post
  • 0

Thanks for all the input folks. 
 

I think the idea in the thread is that the Stake tool is a powerful and existing tool that with a few tweaks could really assist in drawing production work flow in a way the LAs work in real life. I’ve been waiting to incorporate these tools in our office work flow but they are too clunky to effectively use and a custom tag requires too much input on the user’s part to be deployed as a tool office wide. There’s only so much training we can take on.

Share this post


Link to post
  • 0

@Tamsin Slatter I hope that this and the other request mentioned above for the Grade tool is enough of a hint that the Stake and Grade tools are very limited in their usefulness for efficient workflow integration. Grading is a hard enough concept to grasp without the tool getting in the way.

Share this post


Link to post
  • 0

@EricK Thanks for the response. I am still unsure what problem is with the Stake. It CAN read the elevation of objects that are not the site model. I am not sure how it could do this in Top/Plan when the object below the cursor might have multiple elevations. Take a stair object for example - which point would the stake choose to annotate? If you click on the point in 3D, it will report the elevation happily. The Grade tool will do the same thing.


Could you give us a clear list of how you would like the tools to work and what you feel is missing. There are comments in this thread that the tool is "pretty much useless", which doesn't help our developers. We would love to understand exactly what the issues are, hence my responses. 

Sometimes, there is a misunderstanding of how a tool actually works, hence my explanations can shed light on things and unlock a workflow for someone. Sometimes not, in which case, we really want to understand what you would like, and what the desired workflow would be. I will then put together an enhancement request as appropriate.

  • Like 2

Share this post


Link to post
  • 0

Thank you all for your input into this thread. I do understand the frustration, when tools (either software itself or commands within) rather than help, require more education to use it. At the end of the day we are in business (landscape or whatever) and we need computers to aid our work and make it efficient, not add to it.

I love the concept of 3D modelling and parametric design. Unfortunately, the learning curve is quite steep and, as @EricK mentioned, some tools require too much input and parametrisation before they can even be used. This is often the initial time investment and then the resource can be used elsewhere, but where projects vary significantly, repetition of the process is difficult to avoid. I think this may be fine for architects, who need to produce rich documentation, but in landscape industry, this seems often to be too much and not offer value for money. At least for the time being.

In the practice I work for, we decided to go VW so I tend to make the most of it and learn every day. It just get uncomfortable when my employer starts asking why simple things take me longer than before. 

 

Now, regarding the stake tool and grades, I have been using these for the time being to report on the levels and coordinates. Designing levels with grades is quite ok, thanks to the fact that a network is being created. What I found missing for the time being is the ability to find a distance based on the start level and gradient. I need to calculate that first, which sort of kills the point of the tool. The second thing is the ability to update levels both ways, once the grade is inserted - in such cases, I need to redo the grade in the other direction.

 

I haven't seen stakes to return elevation of 3D objects. They seem to provide options for reading elevation either from exiting or proposed model. Hence I tend to use 3D loci first.

 

What we tend to do and need is annotation of elevation of objects such as walls, kerbs, fences etc. and a tool which can do that easily would be anticipated from a sophisticated software. I think stakes work ok in plan, but then the same information needs to be annotated in sections and elevations. For the latter I have been using the Benchmark Elevation Tool, but with mixed satisfaction. I particularly struggle with the layout of information within the tool when in left orientation. I need to find some tutorial on using this one.

 

What are your workflows guys? What would you recommend?

Share this post


Link to post
  • 0
Posted (edited)

@Tamsin Slatter 

 

Your suggestions for the tag tool regarding the bounding boxes is an excellent idea, don't know if you already submitted this enhancement, but I second the motion to add that feature (along with @Michal Zarzecki  I presume).

 

I agree that the tag tool needs multiple additional functions in order to use some of these things properly. Particularly, the feature that is sorely missing is simply getting the tag to read the Z in reference to the story. It should also understand what level in the story it might be referencing. This pertains to one of the questions you ask - how would you do it in plan mode?

In my opinion there are two ways - either copy the z value of the symbol in reference to the floor elevation (not absolute zero), or copy the elevation of the level the symbol or PIO is on - i.e. - ceiling elevation, FFE elevation, T.o. slab elevation etc.. in both a numerical format and perhaps also callout the level itself, that way if it needs to be changed from the tag level, it can easily be done so. These two things can be done in plan mode without going into 3d or providing a working plane for the object you are referencing. This might be particularly useful since i have a feeling you guys might be integrating levels in symbols as well (or so i presume)

 

Just a thought. What do you think?

Edited by Samuel Derenboim

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...