What are the capabilities of COGO points for Open Roads?

I recently completed a task that took advantage of COGO points in Power InRoads Ss2. I have found a myriad of traditional and non-traditional uses for COGO Points over the years.

Over time, as I understand it, Open Roads will incorporate more and more of the native Civil/Site tools until at some point, there will only be Open Roads. Will Points in Open Roads have all of the capabilities of COGO Points in the native tools?

Believe it or not, we still find uses for ICS input files. And I recently needed to filter my points with an XML Report based upon a Fence. Will these continue to be available?

I guess, if there were no plans for this, I'd like to make a motion that the capabilities of traditional COGO and the native XML Reports are carried forward into Open Roads. Please feel free to second the motion if you agree.

Parents
  • The best way to make sure your needed workflows are covered is to describe specific use cases. A statement such as "I need Openroads points to do everything that InRoads cogo points can do" is not really very helpful because we have no idea what sorts of creative uses you might have devised.

    For example, you mention that you have uses for ICS files. What problems are you solving by ICS files?

    Report based on a fence? already there, but perhaps you have specific workflows that are not working?

    You get the idea. If you can describe your needs in the form of a use case, workflow or problem then it is easier for us to determine a solution to be developed or describe a solution already in place.

    It is also important to keep in mind that OpenRoads is a new toolset with new capabilities (such as 3D and preservation of design intent). Thus, it is very often the case that a more efficient solution is possible but is different than your traditional workflow.

    Robert Garrett
    Senior Product Engineer
    Bentley Systems Inc.



  • Just came across this thread and wanted to provide you with some potential issues we may face at DelDOT if COGO is not going to be supported in the future versions of OpenRoads, either SS4 or Connect versions.

    Here are some instances where we utilize COGO:
    1) Accessing the data in the raw survey file for displaying on the plan sheets (Ex: Running a report on the traverse points for use on the horizontal and vertical control sheets). An XML report is run via COGO, formatted with an XSL stylesheet and then displayed in the sheet file (Dgn).

    2) Accessing the data in the raw survey file for retrieving individual shot notes or feature attributes. (Ex: Run a report of all utility pole shots to extract owner identity, pole label numbers, type of pole, etc.). An XML report is run against the survey data (alg) to extract this information and then distributed to the utility companies for either verification or intent notice.

    3) Accessing the data in the exported survey file (alg) to establish links between property monuments and the existing right-of-way baseline. The use of COGO is vital to our organization for defending our decisions and designs in potential legal suits. The COGO "tracking" of how the property mosiacs were established and the layout/design intent is critical to this process.

    4) Accessing the data in the exported survey file (alg) to establish links to the monuments, established right-of-way baseline and the individual properties is similar to item #3 above, both in making sure the layout/design intent is documented, but also reproduceable via an import file through COGO.

    5) There are other uses within DelDOT for COGO as well, such as extracting individual point data for design layout in the field and critical point stakeout purposes.

    Not sure if your team at Bentley is thinking through these types of issues and how they will be implemented in the future versions, but wanted to get on the record and provide you with possible scenarios were the elimination of COGO will surely cause the end user of your products more work, and not less, which is typically the purpose for enhancing the applications.

    If there are workarounds or other methods for achieving the same end results that you would care to share, I'd certainly entertain those options too.
  • I have to agree with everyone's viewpoints on the keeping of cogo points in InRoads. If the developers take this command out of the software there would be a lot of unhappy campers.

    -Joe

    Joe Lukovits

    User Since TDP in the 80's,

    Vax based Unix Workstations - Interpro32,

    from the Intergraph Corp.

     

     

  • It's been a little while since I've checked these boards, but I fully agree with keeping some form of ics COGO that can imported as a script file. If there is a newer way to replicate this, great. But if not, then don't remove it. Over the last 15 years, many people have written off using COGO as an "old-school" way to set r/w lines, existing reference lines, eop's, etc. Yet, time and time again, I still see poorly drawn files with both InRoads and C3D, wrong Sta/Offset callouts, and such using the "newest" workflows, often because someone mis-snapped to something.

    But the main point is still the documentation of "how" and "why" you created something. I can guarantee that the engineer will not completely remember why they did something 1, 2, 10 years later, let alone someone else trying to understand. If someone else finds something that doesn't match the as-builts and doesn't understand it, they'll just assume that you drew it wrong. The ics file not only shows you how you created something, but adding comments can explain why you did it that way. This is documented all in one place and can be drawn automatically as a by-product, which reduces drafting errors. I was just teaching this to my staff the other day, where we had a property boundary to draw from a legal description. We held the calculated bearing between two surveyed section corners instead of the rounded bearing on the title report, explained where all of the data came from, and documented this in the ics file.

    I am all for advancing new technology and software efficiency, but that efficiency shouldn't come at the expense of good documentation.
Reply
  • It's been a little while since I've checked these boards, but I fully agree with keeping some form of ics COGO that can imported as a script file. If there is a newer way to replicate this, great. But if not, then don't remove it. Over the last 15 years, many people have written off using COGO as an "old-school" way to set r/w lines, existing reference lines, eop's, etc. Yet, time and time again, I still see poorly drawn files with both InRoads and C3D, wrong Sta/Offset callouts, and such using the "newest" workflows, often because someone mis-snapped to something.

    But the main point is still the documentation of "how" and "why" you created something. I can guarantee that the engineer will not completely remember why they did something 1, 2, 10 years later, let alone someone else trying to understand. If someone else finds something that doesn't match the as-builts and doesn't understand it, they'll just assume that you drew it wrong. The ics file not only shows you how you created something, but adding comments can explain why you did it that way. This is documented all in one place and can be drawn automatically as a by-product, which reduces drafting errors. I was just teaching this to my staff the other day, where we had a property boundary to draw from a legal description. We held the calculated bearing between two surveyed section corners instead of the rounded bearing on the title report, explained where all of the data came from, and documented this in the ics file.

    I am all for advancing new technology and software efficiency, but that efficiency shouldn't come at the expense of good documentation.
Children
No Data