Toposurface points can't be specified directly with sea level elevations

[dbroad]

Please test and confirm these findings(2019.2 Revit).

1)Relocating the project moves the levels, the project coordinates, and the project model geometry to any desired elevation above sea level. So far OK.

2)If a project has been moved to 100'-0" above the site coordinates (suggested reference for sea level), then adding a toposurface still requires manually subracting the level 1 elevation from all points in order to get the job to work. There is no way to specify site coordinates with a toposurface. They are always relative to level 1.

3)Unclipping and moving the project coordinates back down to sea level has no effect  in being able to enter coordinates as sea level.  Neither does an unclipped move in the project coordinates affect project based contour labels.  It does, however, affect the level elevations. Editing and adding new points to a toposurface after relocating the project coordinates while unclipped is still relative to level 1, not to the project base coordinates.

To me, these are fundamentally serious flaws in the ability to transfer contour lines from a site plan into the project to build topography.  The only work around I've found is to move the toposurface vertically up to edit/add sea level points and then to move them back down once completed.  I would love to be proved wrong. I've looked at all the documentation and videos that I can. Once modeled, the contour labels can be relative to site coordinates, which is acceptable.

Suggestions:

1)Revit should allow toposurface points to be entered relative to site coordinates in addition to project coordinates. The coordinates should be able to be switched during point entry.

2)An unclipped move in the project coordinates should affect project based contour labels and reporting toposurface point elevations.

[ToanDN]

It has always been that way. That is why they suggest to model the topo in a separate site model so you don't have to move it up an down when modifying points.

I agreed that there should be an option to enter the points relative to the Survey Point instead of the Project Internal Origin.

[barthbradley]

Toposurface's "Absolute" internal points are not relative to Project Datums. They are Relative to the Internal Origin of the Project (e.g. the Project Base Point's Startup Location).  Points placed "Relative to Surface" points are exactly that -- Relative to the surface of the Toposurface.  

...Regarding Contours: Their "Elevation Base" can also be set to "Relative", meaning that you could also add a "Sea" Level and reference that level as the Elevation Base for the Contours.  Typically, when the Site is Modeled in the Architectural, we place another Level at the Internal Origin named "Sea Level". Then when we move down the Toposurface, we move the "Sea Level" with it .   

[dbroad]

Thanks. Yes, I understand that.  But the project origin should be adjustable. It shouldn't just be stuck on the starting position.  In fact, if the project is relocated while clipped, it does change.  The reference origin however, doesn't change when unclipped.  I don't see any advantage in that behavior wrt toposurfaces. If I were in AutoCAD and wanted to switch coordinate systems or move the origin, for point entry purposes, its a snap. Point entry can also be relative or absolute. This limitation of always being to an obsure origin that doesn't even match the project origin(if unclipped) doesn't make sense for existing condition toposurfaces.  For new points in a contour region, specifying elevations relative to the level 1 makes a lot of sense.

I also understand, as I said, that contour labels can be relative to the project origin or to the site origin.  But point entry should also be possible referencing sea level, since that is how the survey points come in, not just relative to level 1.

 Typically, when the Site is Modeled in the Architectural, we place another Level at the Internal Origin named "Sea Level". Then when we move down the Toposurface, we move the "Sea Level" with it .   

There is no need for adding a level datum for sea level since a survey point is a datum that can already serve that purpose. In fact, I even tried to set up a second site view that referenced a sea level datum and it made no difference. Toposurface points are always relative to the level 1 datum unless that has been moved up or down separately from the project origin.  For the particular site, I'm working on, the finish floor level is 268.5 feet. Moving toposurfaces up and down to accomodate point entry limitations is unnecessarily time consuming.  It also requires a visual style of wireframe vs shaded/hidden to keep the toposurface from hiding the project.

BTW, when editing a toposurface, points can be relative to the toposurface or absolute. Haven't got that one figured out though.

[barthbradley]

---

@dbroad wrote:

  In fact, if the project is relocated while clipped, it does change. 

---

Not true. It's just smoke and mirrors. When you relocate a Project, you are actually moving the Survey Point.  

[barthbradley]

---

@dbroad wrote:

BTW, when editing a toposurface, points can be relative to the toposurface or absolute. Haven't got that one figured out though.

---

You know, you ought to learn more about placing points Relative to Surface, which is primarily how we do Finish Grading. I think it might alleviate some of your frustration. But, I agree, if the Rough Grading Plan is revised and I need to revise the Toposurface in the Project  --  after it has been moved -- then the easiest why to do that is to move the Toposurface (with "Sea Level") back to origin zero, change my Project Units to Decimal Feet, and then Edit Toposurface  to add, remove or modify existing point elevations -- and then move the Toposurface back to where it belongs in the Project.  Of course, there is another solution:  Model the Project at it's "true" Elevation and never move the Toposurface.    

[Anonymous]

Who cares if it's always been that way!? It's a serious flaw! Everyone who uses Rev it should be screaming and hissing about it until something changes. 

[SteveKStafford]

It's another reason I use a separate model for site/topo as others have mentioned. I treat the site model as the actual site. The survey North is "up" in the Site model and the contours are at their real elevation. I use one level for sea level so anything I model can reference that hosting level as a convenience. Toposurface points can be manipulated using their actual elevations. Then I link the building to site and move/rotate/elevate so it matches our intended ground floor elevation. This way it is very simple to change the building relationship to site. While working in the bldg model I can also link the site model.

Another way to deal with it is to model the building at elevation, whatever the intended ground floor elevation is. This way the topo is at its actual elevation...along with the building. It's harder or more cumbersome to revise if the ground floor elevation changes much or worse if the building orientation changes. I find it is much easier to move a building around on site as a link than moving the site around under the building when they are created together in the same model.

[barthbradley]

---

@Anonymous wrote:

Who cares if it's always been that way!? It's a serious flaw! Everyone who uses Rev it should be screaming and hissing about it until something changes. 

---

I must have missed something. What should we be "screaming and hissing" about?   What "serious flaw"?  

FWIW: we're ready when you are. We've got some good screamers and hissers too.  Just let us know what we're fighting for.  

[tkJBQ78]

completely agree with you .. This is BS. Shortcomings like this should not exist for so long. Now its 2022 and I have the same problem.