• State Not Answered
  • Replies 6 replies
  • Subscribers 144 subscribers
  • Views 1550 views
  • Users 0 members are here

[OR Survey] DIST Code Anomaly

caddcop
Offline

When using the DIST Code in InRoads Survey, the 90 degree angle that was turned was always based upon the last segment, even if that segment was also from a DIST code.

Here is a segment of TDS Codes:

SS,OPSHA101,FP3608,AR237.530673,ZE85.251278,SD95.31124,--BLDG ST
LS,HI5.3,HR0.22
SS,OPSHA101,FP3610,AR240.0644,ZE87.4410,SD68.84,--BLDG DIST 20
LS,HI5.3,HR5.0
SS,OPSHA101,FP3611,AR219.3019,ZE81.3606,SD49.74,--BLDG 
SS,OPSHA101,FP3612,AR195.3658,ZE83.2306,SD60.22,--BLDG DIST -15.2
SS,OPSHA101,FP3613,AR194.4847,ZE81.4130,SD41.98,--BLDG DIST 5.25
SS,OPSHA101,FP3614,AR191.0711,ZE81.2841,SD37.18,--BLDG 
SS,OPSHA101,FP3615,AR99.2230,ZE87.5654,SD33.3,--BLDG DIST 1.0
SS,OPSHA101,FP3616,AR94.4027,ZE88.2610,SD37.78,--BLDG DIST 15.50

So after it draws the first two points, the DIST 20 adds a 20' segment and a 90 degree angle to the right, from that last segment. Then it draws two more points and on the second point, the DIST -15.2 draws another segment 15.2 ' long, but at a 90 degree angle to the left. So far, so good. The next shot draws another point with a segment from the end of the DIST created segment but when it tries to apply its DIST 5.25, the segment it draws is at a 90 degree angle from a "virtual" segment the current point (3613) to the last "actual" point (3612) instead of using the DIST created segment.

In this one figure, this warped output, when compared to InRoads Survey output, occurs twice. 

In this image, the Red Arrows point at the Open Roads results and the Green Arrows point at the InRoads Survey Results. The Orange Arrows show the last two actual points and the general direction of the "virtual" segment that the DIST angle is measured from.

 

  • 0 Offline

    I don't like to just agree on a problem without either elaborating or providing substance. Otherwise I'm just complaining. However I have experienced this sort of issue with the DIST, Elevation, UpDown and JoinPoint command as well. Because of the issues with importing raw survey observations we stopped using the raw data import workflows. I would also check the reduced coordinates from SS4 to a known good. We had unit issues with importing FBK files. Warning results may vary.

  • 0 Offline in reply to cliff

    So what do you import and where does it come from?

    At the previous two firms I worked at that were dual CAD (Bentley/Autodesk) we had adopted our local DOT Alpha Codes (where I am now) and also that all surveys were processed in InRoads Survey. And most firms used TDS RW5/RAW as their file format.

    • Did we often edit the raw data files - yes. Some edits could not be accomplished in program. It was also often quicker to look for informational notes from the crew in the raw file and to make any edits that they pointed out before importing the data.
    • In the early days, we would create a point dump to use as a PNEZD file to create the points in the DWG file and use the 2D linework for the figures and either triangles or 3D breaklines to build the DTM for the Autodesk side. Later, LandXML provided the terrain model and only the 2D linework and points were needed. 
    • Eventually, we could use a custom Survey report and create a PNEZD file with control codes as Civil 3D 2010 could be configured to use most InRoads codes, building survey figures, points and a terrain element from the 3D figures.

    I'm not sure what my approach would be if I was there with ORD, as the Survey Reports are nowhere near as powerful and flexible. The linking/control codes are not preserved from the raw data in an easily exported format.

    Most firms don't seem eager to get  into another software to process raw data before bringing it into Open Roads.

    Charles (Chuck) Rheault
    CADD Manager

    MDOT State Highway Administration
    Maryland DOT - State Highway Administration User Communities Page

    • MicroStation user since IGDS, InRoads user since TDP.
    • AutoCAD, Land Desktop and Civil 3D, off and on since 1996
  • 0 Offline in reply to caddcop

    Hello Chuck. Simplified survey workflow below:

    1. download Trimble JXL file from collector.

    2. Process raw data to coordinates NEZD format. We use StarNET software for adjustme

    3. Import NEZD file to SS4 or ORD platforms, the coordinates have feature codes and linework codes as well.

    5. If going to Civil 3d we use LandXML. Be aware the line coding is utilized during survey figure creation on import of the LandXML in both SS4, ORD and C3D software. We have unified the line coding on both platforms, well mostly the Bentley software is less capable in processing their own linking codes.

    Again results may vary. Hope that helps.

    Cliff

  • 0 Offline in reply to cliff

    Other than Starnet, what is used in step 2 to process JXL file?

    Charles (Chuck) Rheault
    CADD Manager

    MDOT State Highway Administration
    Maryland DOT - State Highway Administration User Communities Page

    • MicroStation user since IGDS, InRoads user since TDP.
    • AutoCAD, Land Desktop and Civil 3D, off and on since 1996
  • 0 Offline in reply to caddcop

    Chuck,

    StarNET has built in convertors for most of the well known raw file conversions. Our state DOT has been slowly adapting their workflows to be more generic allowing for a wider range of software solutions and field equipment. Below is a menu of what convertors are available. I like the software. ORD seems to like the NEZD files compared to raw data. One concern is the open nature of the observation database. I personally screwed up about 500 trees by deleting the a point used as a backsight. Didn't notice it until submittal day. Not good for schedule. Shortly after that I decided to move away from importing raw data into a dgn file.

Communities
Support and Services
Training and Learning
Social Media