Survey not Processing on Open Roads Disaster

I have an issue where my files stop recognizing the new survey point that I import. 

The issue is some times will bring in the points but I will not create the linework, I can't create the linework since changing the link code does nothing.  Also, I have had this happen more than once where certain codes are not recognized so the points will not come in all together no error shown since the codes are valid codes just not processed. none of the times is the surface updated or created.

I have spent three days trying to troubleshoot this issue to no avail. Does anyone have similar problems that they have been able to fix?

I have tried recreating the drawing with a clean seed file, which worked for a while, and then it stopped altogether so I am back to the beginning. any help would be nice. I have made sure the feature definitions are all set up correctly. 

Parents
  • A few questions come to my mind:

    • What types of survey files are you importing? Raw data or coordinates? 
    • Is the data not processing as in the import fails?
    • Is all of the data going into the same field book?
    • Have you run compress on the file?
    • Are you working in a DOT workspace?
    • ORD version?
    • Sample data?
    • Screen shots of survey project settings?

    I had an issue a year or more ago that my ascii files would not import to ORD, no matter the size or format. It shut me down for almost a month. We made a few changes to Windows10 memory settings and it started working again. I dealt directly with a Bentley account manager as this was a serious problem. I'm personally not so sure it wasn't a combination of memory settings and Windows updates that caused the issue. Long story short we never nailed down the source of the issue.

  • I am importing .csv files with Point names, Northing, Easting, and Elevation 

    No, the Points show up but the linework is not drawn and it can't be manipulated once its process 

    Yes the data is going into the same fieldbook 

    I have compress the file 

    yes I am working on UDOT's Workspace 

    ORD Version 10.09.00.91

    .csv files i will add in later post 

    It's hard to show really the issue but technically I can't edit any of the points to change their code, example if it's a start point I can't switch to a start pc or an endpoint so whatever comes in that it's it. 

    Another example is where it brings in the points but nothing is drawn out 

    Here the points are in but the line won't be drawn out and can't be manipulated to do so unless I draw a line manually which defeats the point. 

    let me know if you have any other questions 

  • Did I see in another post you were having issues with Project Wise? Is this issue related to that? 

    Project settings in ORD are critical the survey workflow. I sent over the default settings for FDOT. Are you familiar with these settings?

  • I downloaded and looked at the data. Nothing looks out of the ordinary for ascii data format. I assume you have you project configured to use your linking codes. I highlighted what I think are linking codes in your sample data.

  • Everything in the file seems fine. I really don't understand the issue and is driving me insane I am way over the hours for this task so now is all on my own time. which would be fine if I had a path forward but I don't yet. So I guess ill just keep dealing with this disaster.  

  • Was the software working before? I did notice a setting in your prefs different than what I use. The other options for this setting do directly impact how the data is edited post import.

  • In the FDOT example image, the Link Code Position is Before Link Code, while your example CSV and your image shows After Point Field Code. This is critical, but only during import.

    I started evaluating Open Roads Survey back in Ss2 when it was called Data Acquisition. Generally, once I got the correct settings, it has worked very well.

    Reviewing the Point Lists and Survey Details usually reveals why a figure is being drawn vs not being drawn.

    A lot of contributors to these pages recommend setting the Linear Feature Linking to Force Point List Features. The result of using this setting is identical to manually changing a figure to a Point List. Using this does not affect the Link Code Linking Method, but makes it easier to edit a figure using the reverse figure tool as well as a number of other figure editing tool. While that may or may not change the results you are seeing, it does make it easier to use the tools to finish up any linework issues. 


    Charles (Chuck) Rheault
    CADD Manager

    MDOT State Highway Administration

    • MicroStation user since IGDS, InRoads user since TDP.
    • AutoCAD, Land Desktop and Civil 3D, off and on since 1996
Reply
  • In the FDOT example image, the Link Code Position is Before Link Code, while your example CSV and your image shows After Point Field Code. This is critical, but only during import.

    I started evaluating Open Roads Survey back in Ss2 when it was called Data Acquisition. Generally, once I got the correct settings, it has worked very well.

    Reviewing the Point Lists and Survey Details usually reveals why a figure is being drawn vs not being drawn.

    A lot of contributors to these pages recommend setting the Linear Feature Linking to Force Point List Features. The result of using this setting is identical to manually changing a figure to a Point List. Using this does not affect the Link Code Linking Method, but makes it easier to edit a figure using the reverse figure tool as well as a number of other figure editing tool. While that may or may not change the results you are seeing, it does make it easier to use the tools to finish up any linework issues. 


    Charles (Chuck) Rheault
    CADD Manager

    MDOT State Highway Administration

    • MicroStation user since IGDS, InRoads user since TDP.
    • AutoCAD, Land Desktop and Civil 3D, off and on since 1996
Children
  • Thank you, I can try that. this is the way we have done our import for the last year or so and the weird thing is it will process in certain areas but I won't process it in others so is recognizing the codes but it just stops recognizing the points after a while and no edits can be made after that rendering the file useless 

  • What is the max number of points you can import before the software fails?

    Is there an error message associated with the issue?

    Have you deleted the user prefs as shown in this video https://youtu.be/FSB5ko_u4hw

    Have you put in a service ticket with Bentley?

    While working through my own import issues with ORD Bentley had me delete my feature definitions and re attach them via the Project Explorer.

    I don't want to run you in circles but it does help to know as much as possible about the issue so others can help if possible. Just a few thoughts.

    Cliff

  • This is interesting, I think there is a lot of issues when processing survey data in ORD I have not yet completed a project without encountering a major issue that completely blows up. Did you ever get his solved? what did you do? Sound very familiar to what I am encountering? I have reached out to Bentley but to no avail. So far I have recreated the File a couple of times tried different things and we have resorted to reprocessing the data in Inroads and try to deliver that route but that is redoing the project all over again. 

  • I'll speak in bullet points to be concise:

    • First I reached out to the DOT in my state to let them know we are having issues. Sounds like your working on a large corridor that requires significant effort to rebuild or process. Not knowing what your level of experience or rank within your organization I cant guide your response to this issue beyond letting folks know you have encountered a major bug in the software and you are working closely with Bentley and maybe others to resolve the issue.
    • I made a few changes to the import workflow:
      • create a new dgn file for each ascii file. import the same named ascii file into the new empty dgn file. 
        • if this seems to be working I would expand the amount of data incrementally with each dgn.
        • work local. Do not work in a folder located in desktop or my documents folders. 
        • Delegate the import process to pc's that may not have the issue.
          • in my case I was able to call in favors from outside sources and use other staff members machines that didn't seem to have the issue. They would then just send back the dgn file with the points imported. Make sure you provide them a blank dgn with the correct project settings for importing.
    • When you get the stand alone dgn files back begin importing / merging the data into the container file. In ORD the JSON format maybe the most viable in this situation because of the point list line work edits.
    • Keep detailed notes about the issue so as you can justify the time to your employer, client and state DOT, if needed. 
    • adjusted Windows 10 memory settings. This was a huge help.
    • verify your pc is updated with the most recent version of Windows 10.
    • In my issue I had to drop shared cells to normal cells then compress the dgn. Then reimport a massive amount of point data. This project had well over 500,000 points and probably double that. Think urban Miami corridor with lots of Lidar extraction.

    Read through that see if it makes sense or if any of it may help. Working systematically to reduce the unknowns is the only logical way to get back on track. I know the stress can be overwhelming but slowing down and digesting the work will bring results and at this point you may have no choice. Don't take any of this as condescending I'm just speaking from the seat of experience. 

    ORD does have issues but it can be extremely efficient and productive when producing design survey deliverables. There is hope.

    Cliff