DTMs and Vertical Elevations

[willofmaine]

I've created a DTM, using real-world elevations.

The first floor of the building is at Vectorworks' World Z=0.

I've moved the DTM down (vertically) so that it is coordinated with the building (can't move the building up at this point, as all the viewports, etc., would need to be re-aligned).

When the DTM is moved down, its contours continue to display their correct vertical elevations. But...

Stake objects seem to use the Design Layer's Z=0, rather than the DTM's Z=0. How do I get stake objects coordinated with the DTM's vertical elevations?... (Physically they're in the correct place, but their numbers are way off...).

Thanks, Will

[willofmaine]

Moving the DTM's Design Layer up and down, rather than the DTM itself, seems to solve the problem...

[CipesDesign]

Will, this conundrum has frustrated me for years. Not the specific problem you point out, but the basic how-to of setting up a Site Model and buildings. I have tried various ways of dealing with it. FWIW, my current method is to use all "real" numbers, starting with the survey (import). So all the design layer elevations are set to where they will actually sit on the Site Model. Still not a perfect solution, but it's very workable.

I understand that you don't want to move all the design layers, and I understand why. [Although, you do know the exact distance that everything would need to be moved - you could just move the crops, then annotations... There might be a little math to do to adjust for different scales, etc.]

I don't use Stake Objects very often, but I wonder, have you tried Send To Surface with them? Or perhaps selecting them and moving them up/down the same amount?

Good Luck!

[Bob Holtzmann]

The way I understand this, if the Site Model's bottom side, or base elevation is 522'0", then use this for the Z elevation of the Design Layer it's on, right? Then you can use Floor Level Design Layer Z elevations as actual survey elevations.

I hope it's as easy as that.

Edited August 6, 2014 by Bob-H

[CipesDesign]

I would respectfully disagree. In your example, I would need to place each individual wall at some base elevation other than zero, otherwise the wall(s) would end up literally buried in the Site Model. Or have I misunderstood your comment?

[willofmaine]

Hi Peter & Bob,

Thanks for your responses. Peter, there's no question that using real-world vertical elevations is the way to go (with the possible exception that if you've got a mountain site at 4,000', Vectorworks may not like to get so far away from it's 0,0,0 origin...). Unfortunately, projects are often started with their buildings at Z=0 and/or when vertical site information is not yet available. Yes, I could move all the design layers and viewports up or down, but that's far from ideal.

When I posted that moving the DTM's design layer up or down seemed to resolve the issues, I'd experimented in a blank file: I used some stakes to create a quick DTM and moved it's design layer down 100' (so that its Elevation relative to the ground plane was -100'). Contours and "Set elev to site model" stakes worked as expected. Though when entering the DTM and editing its source data, in the OIP the Z value of the stakes were about double what was expected (as it turns out, their Z values were their expected elevations PLUS the 100' that the design layer had been moved down...).

So, when I returned to my project file (with great optimism...) I moved the DTM's design layer down and created my DTM. And it didn't work... the surface of the DTM was about 100' too low, there were no contours, the "hull" was much taller than the DTM, and stake objects were returning unexpected negative numbers. Yet entering the DTM, its source data were all at the correct Z elevations, according to the OIP...

FINALLY, I put the two together: in my project file, I entered the DTM, and moved all of the source data up 100'. And it worked. So, at least now I will be able to create a DTM without having to move the building and its viewports up or down.

Bottom line, if you move the DTM's design layer up or down to coordinate your DTM with your building, you also need to enter the DTM and move it's source data, in the opposite direction, by the same distance (so that the source data's Z values don't match the Z values of the DTM's surface...).

Wow, what a tremendous amount of time this "intuitive" conclusion has cost me...

Bob, I think if you're setting your building's design layer elevations at actual real world ("survey") elevations, you'd want to put your DTM in a design layer that has its Elevation at 0 with respect to the ground plane, use real world data to create the DTM, and skip all of the silliness described above...d

PS - Around here 4,000' feet is a mountain. But I guess in Denver it's a valley... Maybe VW's difficulties with being far from its origin are my imagination and/or a thing of the past...

Thanks, Will

VWIS023

[Diamond]

Hi Gents,

Coming in a bit late here. We commonly work with a number of buildings on a site, and I have been bitten with this same challenge over the years, and have made all the same mistakes outlined here. I believe there is only one way to get around this, and I recommend this technique for our staff on all projects going forward. As Will has stated, Vw can get a bit freaky when units are so far away from origin.

I keep the site model file separate to the building file(s). Ground floor for each building is almost always set to zero (unless there is an adjoining building requiring otherwise). I then reference the buildings into the site plans/terrain model, and raise and rotate the buildings as required, to make their position correspond to real world survey coordinates. Also if I need to export out a site plan in DWG or IFC, this is the file I do that from, once again, so the model's position corresponds to real world co-ords. Critical when working on a consultant team on other software.

Hope that helps.

[Patrick Fritsch]

Here is a well detailed video on DTM creation and how to avoid common hiccups like the far from origin. Really good.

Novedge Webinar #108: Creating & Editing Site Mod?:

[Diamond]

Hi again,

Have been doing some more research on this. The Novedge webinar was very good. OzCAD.com.au has some great videos on origins, and there is an Origins PDF on VSS that was very helpful. The centre on import for the site survey was a great key that I had been missing. I think there are three scenarios, and three factors guiding the scenarios.

The three factors are;

-Skill level of team.

-Size of project.

-Location of project.

The three scenarios are;

-For a small project, draw everything in one file at world RL's and world rotation (before the rotated top/plan views were available, this was almost impossible for all but the Vw pro). I think this is simplest for IFC export.

-For projects not set at high RL's ( i.e. not on a mountain), keep the building(s), and survey files separate, but their real RL's. This enables team work, and by splitting up the project, creates a level of protection against file corruption.

-Still my prefered method is to keep the site at real RL's, and reference (raise and rotate) each building into the site model. That allows for quick changes through each stage (editing the ground heights and rotation in the site model-not the building file) , and it makes each individual building simpler to work on, esp. when roaring around the model, working at right angles, ground is alway set at zero etc, which is advantageous for teams with members of elementary understanding. The downsides are; that it does create complexity for those that do not understand references; and may create complexities for IFC export that I am not aware of.

Can anyone see any holes in my thinking? Thanks again.

Edited September 4, 2014 by Diamond