Why Export to Native

Purva Lakde — Tue, 15 Mar 2016 11:06:28 GMT

Current Revision posted to OpenRoads | OpenSite Wiki by Purva Lakde on 3/15/2016 11:06:28 AM

Applies To

	Product(s):	Open Roads Technology
	Version(s):	08.11.09+
	Environment:	N/A
	Area:	General Geometry
	Subarea:	Export To Native
	Original Author:	Purva Lakde. Product Advantage Group

OVERVIEW:

“Export to Native” is a functionality within Bentley Civil V8i SELECTseries 3 that allows the user to keep a version of the native geometry database (.GPK, .ALG, .FIL) in synch with the new civil geometry stored within the design file. As a simple example, with this option enabled the user can store an alignment in the design file and that alignment will be automatically stored in the native geometry database as well. Delete that alignment from the design file, and that alignment will be deleted from the native geometry database.

“Export to Native” is not designed to work as an ‘all or nothing’ functionality. It is feature based in that the option to “export to native” must be set to “true” or “false” for each particular feature. For example, an organization may want all civil geometry stored with the feature “Centerline” to be exported to the native geometry database. But for other features (e.g. ““Edge of Pavement”, “Toe of Slope”, “Existing Drainage”, etc.) the organization may not wish to have these features exported.

DESCRIPTION:

In this topic, will explain how “Export to Native” works and how to set it up. In addition, we’ll look at the functionality in more detail so that an organization will have enough information to decide on whether to implement or not.

Note that the functionality we are going to describe, as well as its setup and Manual Export, for the most part works the same in GEOPAK, InRoads and MX. The main difference of course is how each product originally links to its own native feature files (.DDB, .XIN, .PSS). However, where there are differences in functionality between the products we’ll point that out.

We’ll look at four areas with the regard to the “Export to Native” functionality:

Why Export to Native: In Bentley Civil V8i SELECTseries 3 there are older applications (e.g. Labeling, Sheet Clipping, etc.) that will continue to rely on the native geometry databases (. GPK, .ALG, .FIL). The “Export to Native” functionality allows the native database to be created and kept in synch ‘automatically’ – forgoing the need for a user to manually export to the native database

SETUP: Once the link has been made to the native feature files, we can review each feature and its associated settings from Project Explorer. Although there are several tabs (Survey, Plan, 3D, Cross Section, Profile, etc.) that allow an organization to control how this feature will be displayed in each of these areas, only two allow the enabling of the “Export to Native” functionality via the “Auto Export” option – the Plan tab and the Profile tab.

As shown in the following image, these tabs have the options to either enable (set to True) Auto Export or disable (set to False) Auto Export.

In the particular instance of the feature “Centerline” shown in the dialog above, the Plan tab would of course tell the software to Export any horizontal geometry stored with this feature to the native database. The Profile tab would perform a similar function for any vertical geometry stored with the feature “Centerline”.

Note: By default, the Auto Export option is set to “False” for each feature. It is incumbent upon an organization to decide which features if any are to be exported and then enable the option for those particular features only.

HOW IT WORKS: Now that we’ve seen how to enable or disable the Auto Export option for any particular feature, let’s take a look at how it works in practice.

New Geometry: Whenever new civil geometry is stored in a DGN file using a feature that has the Auto Export option enabled, a ‘copy’ of that geometry is automatically exported to (or stored in) the native geometry database. This is probably the simplest case of the Export to Native functionality and the easiest way to explain how it works.

Modified Geometry: Let’s say that you have some existing civil geometry in a DGN file that has been previously Exported to the native database. Now you make changes to that geometry. For example, you could change a radius or rename it. Whenever these changes are made, the corresponding change is made to the geometry in the native database in order to stay in synch.

Deleted Geometry: Similar to the case of the modified geometry, let’s say that you have some existing civil geometry in a DGN file that has been previously Exported to the native database. Now you delete that geometry. When you do that, the corresponding deletion is made to the geometry in the native database in order to stay in synch.

One-Way Only: Keep in mind that this synchronization is a one-way street only. What that means is that while changes to civil geometry in the DGN file are Exported to the native geometry database, the functionality does not operate in reverse. In other words, any changes made to the native geometry database are NOT automatically carried back to the civil geometry in the DGN file.

Manual Export: If an organization chooses NOT to implement the Auto Export functionality, then we still has the ability to Export or “export” the civil geometry manually at any time. This can be done with the Export Geometry tool.

Tags: Export to Native