Hi.
I've now tested using Database Properties for Features which seem to work fine if I want each new Feature to create a new record in the ODBC Database.
My question is, how do I get a number of Features to look at the SAME row in the Database? Something like a Duplicate Linkage I guess.
I would think this would be a pretty common requirement especially when storing WHERE certain graphical information comes from. For example you may have hundreds of individual lines, polygons etc from an individual Ground Survey of part of an overall site, and you want to record in your Model WHERE this linework etc. came from in a single database record. Also, it would be very useful to be able to 'hit' all these graphical elements in one operation to be able to make this common database linkage.
I would imagine this type of 'metadata' functionality would be a VERY common requirement as nominated a data source would be a common issue. How do people generally handle this in Map?
Thank you.
Here is some information from the Bentley Map help that may be of assistance.
Bentley Map Operation with RDBMS Bentley Map tries to maintain the concept of one data base record for each graphic record. That means when starting a project with RDBMS features or opening a file that appears to have an RDBMS connection. If a successful database connection is not made for these projects or files, Bentley Map will not edit, copy or create features that would normally have properties. This helps prevent orphan records either in the RDBMS or the DGN file. As such, Bentley Map does not use the settings for linkage generation mode.
However, some users have applications that automatically set the linkage generation mode for their own purposes. And, on some occasions, there are requirements to copy features without creating new database records. For example, fence copy part of a map into another DGN with a differing projection for printing or sharing purposes. In that case you can start Bentley Map with the following variable set:
MS_GEOXFM_DISALLOW_INFERRED_DBCONNECTION = 1
Keith Raymond
Thanks Keith.
While I can see the possible orphan records advantages of the one record per graphic element concept, the duplication of information seems to be a large overhead/disadvantage.
To be honest, while I see a number of advantages of the Map Product, I'm also striking various practical difficulties too.
Perhaps if I outline our historical situation you can comment further.
We have a Project area of approximately 640 hectares comprising both an Urban and Parklands environment.
As various Drawings, Survey Plans etc. arrive we record them in an Access Database where each of these Records also has an mslink number.
We maintain a number of Microstation 'Base' files of the Site which are strictly layered and are separated into separate files such as Detail, Street Furniture, Landscape, Electrical, Water, Sewer etc. These Base files are connected to the 'Drawing Register' Database via an ODBC linkage. New Drawings are created quickly and efficiently primarily by attaching the relevamt base files as a starting point.
If new Drawings received by the organisation require an update to the base files we update the relevant base files and use standard Microstation functionality to link the new graphics to the relevant record in the drawing register database, NB. The arrival of a new survey may mean that potentially many hundreds of graphic elements will all be pointing to the same database row.
If for example, we want to know where a particular water line came from, we simply interrogate the graphics element and all the information such as original CADD file name, current location, Drawing Numbers, Dates etc can be seen from the database. This process seems to work fine and the link to the datasource is a huge advantage.
We'd previously looked at Geographics to expand this structure further and for an individual graphics element to have multiple Feature Linkages etc made a lot of sense. ie. this piece of graphics is both an edge of path and and edge of grassed area. Previously we could also easily tag large amounts of graphics with these linkages. Under Map this concept of multiple Feature Linkages looks like it has gone out the window and we now need duplicate graphics for each separate Feature. Again, maybe this was done for comptability purposes with products such as ArcInfo but in other ways it appears to be a retrograde process for the compatabilty advantage. Perhaps that's life though? :-)
So in our situation, it appeared a likely process for most Features placed we would have a data entry Form that firstly collected/stored individual information about the graphics element/feature such as Seat Number, Type etc within the DGN file and on the lower part of the data entry form we would have a Datasource Entry area that would be linked to the existing Drawing Register Database and in this area we might be able to select an mslink/row from the existing database to show where this information came from. NB. After selecting the mslink number it may also display a few other fields from within the database in a read only format.
Based on your comments it would appear Map would prefer we create new database entries for each piece of graphics placed which would appear to be another large duplication process for minimal advanatge.
Is the process I'm suggesting really that unusual? I would have thought it would be quite common and yet it hardly seems easy to implement.
We are a relatively small organisation and don't have huge resources to advance this pilot but are certainly looking at something that is relatively easy to implement and maintain without large programming customisation.
Any suugestions Keith?
Ok.....thanks again for your reply Keith. It's good to get some feedback. I had sent this query to Bentley (and received a Ticket Number) half way through January and I still haven't received any reply.
Firstly, when is the next release of Bentley Map due that will have the Table Join Feature that you mentioned? Note: By way of feedback, as an international company it would be more useful if Bentley gave this information out in Month/Year Format rather than by 'Season'. :-)
Secondly, I think I understand how the Join might work but would it be possible for you to give an example? Again, I would think the ability to easily have 'data source' as an easily defined Feature Attribute (and not necessarily a one to one) would be a VERY useful feature.
:-)
True enough. Not everyone runs on the calendar year. We are expecting the release towards the end of June this year.
In your example below, you want to associate a series of features with a record that indicates when those features may have been collected. In XFM you could define some simple properties for each feature with an ID (because it's often a good idea but not necessary) and a property that indicates when the data was collected. These properties could be contained in the database as they are now. In a separate table, you would have a record with a unique ID and any other information describing the origin of that data. When the join tool is available, you would simply join the property from the feature to the unique ID in the data origin record. You could then easily review the source of any graphic element. There's nothing to prevent you from using the duplicate linkage mechanism as always in MicroStation. But hopefully the above method will make it straightforward to model your data easily with Bentley Map and use any related data in your database.
AlanH: As an international company it would be more useful if Bentley gave this information out in Month/Year Format rather than by 'Season'
Keith: True enough. Not everyone runs on the calendar year.
Might his comment not have more to do with out-of-phase seasons in the northern and southern hemispheres?
Regards, Jon Summers LA Solutions