What are the capabilities of COGO points for Open Roads?

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

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.

In Power InRoads V8i we manage 100s of Boring location with COGO point for plan views. With these Borings setup as COGO points, we can manage different types of boring with different Style symbology existing, proposed, and other boring can have their own cell associated, level, color, and a description for the COGO point.

 

Then you can use Geometry>View Geometry>Horizontal Annotation to show in the dgn files with the different boring types all on their own levels symbology, cell symbols and their description label.

Also, you can pull elevation from the different tin files to verify Geotech boring against tins being used with reports. Plus, the engineer wants to see the Clearance Report showing:

Offset Point	Description	Baseline Station	Offset	- - - - - - Offset Point - - - - - -					Radial Direction
				Northing	Easting	Elevation	Latitude	Longitude

And placed in an excel spreadsheet for their use in their reports to the clients.

Do you have another way to do this in OpenRoads Designer Connect Edition?

Please share with me on how we can continue to do this.