Feature Definitions not Showing Up

What you have described above is caused by the fact that there are really two different types of feature definitions, there are:

1.) Line/Point/Surface feature definitions that link directly to a DDB (GEOPAK) or XIN (InRoads)

and

2.) Survey feature definitions that are imported from XML/XIN.

The reason you cannot see Line/Point/Surface feature definitions from an XIN in GEOPAK is because GEOPAK commands can only link to a DDB for these feature definitions, and the InRoads commands can only link to an XIN. This is because the program maintains an active link back to these files to pull the current symbology settings.  Therefore, any command that uses a feature definition with a Native Style defined is actually looking back to the DDB or XIN for the symbology for the elements it will create.

Survey feature definitions act a little differently.  Instead of an ‘active link’ back to the XIN/XML, Survey does more of an ‘import’ of the feature definitions for use by the survey commands.  This import allows Survey to use XML(SMD) or XIN in either GEOPAK or InRoads.  Therefore, any Survey command that needs to place an element will look at the imported feature definition for its symbology.

I guess I am confused as to why I can use the XIN within SS2 to create my templates. Are you saying that in SS3 I would now have to point to a DDB instead?

To do Geometry features, yes. Since you have the GEOPAK flavor of SS3 installed.

Thanks for the reply, Nico. I suppose I possibly misunderstood the OpenRoads concept. I was thinking that the idea was that Geopak could use an InRoads XIN and Inroads could use a Geopak DDB and SMD file with little issue. Is this not the goal of OpenRoads? Or is it the ultimate goal, but this is just the first part of the process?

The questions I have stem from the fact that our small firm is a Geopak shop with limited licenses. Our main client recently started using InRoads and publishing their XIN file they use (among other files). Our goal would be to use whatever we can that comes directly from them, with no edits. I would like to avoid having to setup a new DDB or SMD based off what their XIN looks like, and then constantly try to keep our files in sync with theirs after any changes are made. The other option would be to try and switch over to using InRoads, but that comes with the issues of training, keeping Geopak license(s) for "old" projects, etc.  

If anyone has any insight on these topics, it would be much appreciated.

Thanks!

the idea is to transition to OpenRoads, if you come from InRoads or GEOPAK, you will be able to move to it.  In your case, creating the ddb is a lot of work, you may benefit from using the InRoads flavor of OpenRoads.  In terms of licensing, you can always talk to your account rep and switch a couple of seats.

We were in a similar situation a few years ago - we had 2 seats of PowerCivil which was a GEOPAK based product, but all of our civil work was being done in InRoads. When Bentley released PowerCivil for North America, we exchanged those and never looked back. But recently we were tasked to do some survey that only a SMD file was available. I extracted what I could from it and edited an XIN to work with it.

The XIN is actually HTML/ASCII so you can read its contents if needed and GEOPAK can import and export from its DDB, so you might be able to use one to edit the other.

We were in a similar situation a few years ago - we had 2 seats of PowerCivil which was a GEOPAK based product, but all of our civil work was being done in InRoads. When Bentley released PowerCivil for North America, we exchanged those and never looked back. But recently we were tasked to do some survey that only a SMD file was available. I extracted what I could from it and edited an XIN to work with it.

The XIN is actually HTML/ASCII so you can read its contents if needed and GEOPAK can import and export from its DDB, so you might be able to use one to edit the other.