• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 2 replies
  • Subscribers 141 subscribers
  • Views 862 views
  • Users 0 members are here

SUDA and Survey Data

Mark Plum
Offline

Folks:

I am curious as to how the community is handling survey data as regards utility information (existing water lines, tel Lines, sanitary sewer lines, valves, etc. and additionally storm Inlets, manholes, etc.) in combination with SUDA feature definitions. We currently have a proposed SUDA library with all of our proposed utility/ stormwater/ sanitary sewer information built into it which is working fine on the design end of things, but our survey dumps are strictly survey codes tied to line and cell features. In SS2, we used InRoads Storm and Sanitary to create existing networks from the survey data which was rather cumbersome, but which did provide good results (basically recreating the surveyed utility information within the SDB format).

Are you folks running two SUDA dgnlibs (one for proposed and one for existing utilities data), or are you using a single SUDA library which contains both existing and proposed utilities data? Finally, is there a manner in which to tie the survey codes directly to SUDA feature definitions (i.e., when the survey dump occurs, the codes tie directly to SUDA plan and 3D models and create true existing networks through Survey Processing in situ). 

Thanks!

Mark

Parents
  • 0 Offline

    Hey Mark:

    Starting with the dream: It was once planned by Bentley, hopefully still is, to tie SUDA and Survey feature definitions together such that processing survey also produced a SUDA model. It is not there yet.

    But, It is more efficient than the old InRoads workflow (and GEOPAK).  Your process will be to use the extract graphics command to produce the SUDA model. Even a oncey-twosey approach is pretty quick. Example: Pick all the waterlines, extract graphics command, voila SUDA waterlines.  Keep the survey data in a separate DGN and reference to the SUDA dgn.

    Things get super efficient when you use filters.  Works on the same principle as Create Terrain Model using filters except you are creating utilities instead of a terrain. The filters segregate things by symbology and/or feature definition allowing you to potentially create an entire SUDA model in one operation.  This presupposes that your survey data is consistent and predictable of course.

    What libraries do you need?  you will have all the following libraries to accommodate this: (I doubt I am telling you anything here you don't already know.)

    1. Survey Feature definitions
    2. Non-Drainage Utilities feature definitions - sometimes my client has asked for exiting to be separate from proposed, but not always. The key distinction is that these are things which do not require a hydraulic model nor hydraulic calculations. water, sewer gas, cables of all sorts.
      1. Include the extract graphics filters here IMO
    3. Drainage feature definitions (including sanitary sewer) - it seldom makes sense to separate existing and proposed.  And, it is important to including gravity sanitary sewer here because:
      1. You can ONLY have one repository for hydraulic prototypes, which is specified by SUDA_Seed_File=. Thus, anything that ever potentially needs to be analyzed hydraulically must be contained in this library:
        1. Sanitary sewer existing and proposed
        2. Drainage existing and proposed.

    Robert Garrett
    Senior Consultant

    www.envisioncad.com

Reply
  • 0 Offline

    Hey Mark:

    Starting with the dream: It was once planned by Bentley, hopefully still is, to tie SUDA and Survey feature definitions together such that processing survey also produced a SUDA model. It is not there yet.

    But, It is more efficient than the old InRoads workflow (and GEOPAK).  Your process will be to use the extract graphics command to produce the SUDA model. Even a oncey-twosey approach is pretty quick. Example: Pick all the waterlines, extract graphics command, voila SUDA waterlines.  Keep the survey data in a separate DGN and reference to the SUDA dgn.

    Things get super efficient when you use filters.  Works on the same principle as Create Terrain Model using filters except you are creating utilities instead of a terrain. The filters segregate things by symbology and/or feature definition allowing you to potentially create an entire SUDA model in one operation.  This presupposes that your survey data is consistent and predictable of course.

    What libraries do you need?  you will have all the following libraries to accommodate this: (I doubt I am telling you anything here you don't already know.)

    1. Survey Feature definitions
    2. Non-Drainage Utilities feature definitions - sometimes my client has asked for exiting to be separate from proposed, but not always. The key distinction is that these are things which do not require a hydraulic model nor hydraulic calculations. water, sewer gas, cables of all sorts.
      1. Include the extract graphics filters here IMO
    3. Drainage feature definitions (including sanitary sewer) - it seldom makes sense to separate existing and proposed.  And, it is important to including gravity sanitary sewer here because:
      1. You can ONLY have one repository for hydraulic prototypes, which is specified by SUDA_Seed_File=. Thus, anything that ever potentially needs to be analyzed hydraulically must be contained in this library:
        1. Sanitary sewer existing and proposed
        2. Drainage existing and proposed.

    Robert Garrett
    Senior Consultant

    www.envisioncad.com

Children
Communities
Support and Services
Training and Learning
Social Media