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

[ericjhberg]

When using the stake tool, you currently have the option to "Set Elev to Site Model" as a way of creating spot elevations for a grading plan. This is great when documenting the surface of a site model for high points and such, but often the elevation we are looking to document is actually a feature such as finish surface, top of wall, bottom of wall, etc. These items are placed on top of a site model, so a stake object trying to query their top elevation will only return the elevation of the underlying site model.

 

There should be a way for the stake tool to recognize modeled elements in the drawing to pull this information into its reference.

[lgoodkind]

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.

[twk]

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.

[EricK]

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.

 

 

[Michal Zarzecki]

In the practice I work in we have only recently started using VW Landmark as the first step towards BIM.

 

Having trialled a number of landscape packages I must admit I am quite disappointed about the translation of the physical process of thinking of and designing site levels and drainage into the digital processes within software packages.

 

The way we usually do it is by working out the spot levels and falls, based on the existing levels, FFL, drainage strategy. Basically, we calculate everything and try to make sure it's compliant and would drain efficiently. I was hoping that software would do part of it for me and I could annotate the resulting levels on a plan.

 

In the process, I was shocked to learn that stakes do not read elevation from hardscape objects/ surfaces, walls etc. These are basics!

 

I was modelling external steps recently and had a really hard time understanding what level the landings were at etc.

 

I then tried to find a tool to actually allow me to read the spot levels from the resulting design. Another struggle. I needed to read the elevations from the end of slopes to hardscape slabs, figure out what levels that actually was and use a stake as a marker. Perhaps someone here can advise on the better way?

 

I really wish that the developers take these requests seriously into consideration, since at the moment we need to do workarounds rather than being supported by the software. 

[EricK]

On 6/19/2019 at 6:16 PM, Michal Zarzecki said:

I really wish that the developers take these requests seriously into consideration, since at the moment we need to do workarounds rather than being supported by the software. 

This. This request is two years old now. I can't believe this hasn't been addressed. It makes site modelling near useless and the workflow from concept to drawing non existent. If a dev wishes to reach out to me for some explanation of what is needed here, I welcome it.

[jg@swcm]

I agree - we should have this.

[Samuel Derenboim]

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?

[Michal Zarzecki]

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.

[Michal Zarzecki]

@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.

[Tamsin Slatter]

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:

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.

 

[Tamsin Slatter]

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.

[Michal Zarzecki]

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.

[Tamsin Slatter]

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.

[EricK]

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.

[EricK]

@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.

[Tamsin Slatter]

@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.

[Michal Zarzecki]

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?

[Samuel Derenboim]

@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 July 31, 2020 by Samuel Derenboim

[Laura Stone]

On 7/19/2020 at 12:47 PM, Tamsin Slatter said:

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.

This is a problem for me, have been experimenting with hardscapes and like the way they can be modified with stakes, but surely there is a way for those stake elevations to report relative to the project datum so that in plan view they can form part of a levels drawing?  otherwise it's repeat work adding the levels manually.

 

Laura

[mMurrey]

@ericjhberg  @Tamsin Slatter

I think a great first step would be "send to" options. Send to surface,  Send to Hardscape, Send to Wall. This would make it easy to place stakes in plan view, then send and place them at the proper elevation. 

 

Currently we place 3d stakes on hardscapes as use them as site modifiers. We use a data tag to callout those elevation on sheet layers. We have constant problems with Aligned Hardscapes as surface modifiers (DTM hangs and will not update or is VERY slow), so we find it more efficient to use the Aligned modifiers to create our hardscape layout, slope, etc, then place the 3d stakes as needed to grade the site.

 

The challenging part of this workflow is we have to modify the location of the 3d stakes as we modify the hardscape elevations and slopes. It would be great if we could do it plan view in one simple click.

 

Just a thought...

MLM

[hollister design Studio]

@Tamsin Slatter

On 7/20/2020 at 6:43 AM, Tamsin Slatter said:

...Could you give us a clear list of how you would like the tools to work and what you feel is missing...

Just getting back to this thread after marking it as 'interesting' last year...

 

A couple of notes that I think might help the stake tools usefulness as a spot elevation marker.

 

• Ability to adjust text attributes from OIP.
• Ability to set text attributes (size, font, etc)  in stake tool settings.
• Text 'overrides' - like the dimension tool - for those times when the model is just wrong but you don't have the time to change it!
• Ability to use Text styles.
• Ability to adjust rounding precision and other unit settings separate from Document Units preset.
• Ability to save Stake Object Styles!

A silly request - I really like @digitalcarbons plumb bob symbol!

...having that point is so much nicer than the extrude of the stake tool in 3D - that plumb bob really communicates when doing a walk through with clients too.

 

 

Final thought - maybe this functionality should just be a tool separate from the Site modifier and Site model data tool?