framme_feadefover

11
Graphic Technologies, Inc. Page 1 FRAMME FEATURE DEFINITIONS OVERVIEW TAKEN FROM INTERGRAPHS FRAMME DATA STRUCTURES’ REFERENCE GUIDE AND ON-LINE HELP 2729 Deford Mill Road Owens Crossroads, Al, 35763 Tel: (205) 533-3466 Fax: (205) 533-3422 email: [email protected]

Upload: jose

Post on 17-Oct-2014

37 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: FRAMME_FeaDefOver

Graphic Technologies, Inc.

Page 1

FRAMME FEATURE DEFINITIONS

OVERVIEW

TAKEN FROM INTERGRAPH’S

FRAMME DATA STRUCTURES’ REFERENCE GUIDE AND ON-LINE HELP

2729 Deford Mill Road

Owens Crossroads, Al, 35763 Tel: (205) 533-3466 Fax: (205) 533-3422

email: [email protected]

Page 2: FRAMME_FeaDefOver

Graphic Technologies, Inc.

Page 2

SECTION I. FRAMME DATA MODEL REQUIREMENTS

he FRAMME AM/FM/GIS system provides functionality for continuos mapping, Work Order Processing, Transaction Processing, feature level editing and locking, automatic connectivity maintenance and tracing, and etc. To provide these and other functions, the FRAMME system

uses a sophisticated data model and rulebase which must be adhered to during the data conversion process. A good working knowledge of FRAMME data structures must be acquired before embarking upon a FRAMME data conversion project.

This section will provide an overview on the FRAMME Data Structures and will point out major requirements which must be noted during data conversion activities.

Data Delivery

Master File Delivery - FRAMME data can be delivered in Master File Format, ready for installation on the master data server.

• Pro’s

• Transaction records are NOT needed.

• Data posting is not required, therefore delivery is quicker.

• Con’s

• Reference Records ARE needed.

• Linear elements must be broken at map sheet boundaries.

• No posting of facilities to check the data integrity, therefore other QA/QC methods and/or processing are necessary.

Workset Delivery - FRAMME data can be delivered in Workset Format, ready for posting to the master data server.

• Pro’s

• Reference Records are NOT needed.

• Linear elements need NOT be broken at map sheet boundaries.

• No other QA/QC methods and/or processing are necessary.

• Con’s

• Transaction records are needed!

• Data posting is required, therefore delivery is slower.

T

Page 3: FRAMME_FeaDefOver

Graphic Technologies, Inc.

Page 3

FRAMME Feature Definition

Example Facilities

In the following example, the facility, a pole, consists of three components:

• A graphic symbol

• A graphic text (attribute) record

• A nongraphic record in the database which describes the pole.

4. POLE __ __ .11 IPID .12 ACCT CODE __ __ .23 TYPE __ __ .31 HEIGHT .32 CLASS __ __

Non-graphic Database Record

P-772 30/5

Graphic Annotation

Graphic Symbol

Page 4: FRAMME_FeaDefOver

Graphic Technologies, Inc.

Page 4

In the next example, the facility, a cable, consists of six components:

• A linear graphic element

• Two non-graphic records in the database which describe the cable

• A repeating graphic symbol

• Two graphic text records.

Linear Graphic Element

Repeating Graphic Symbol

Repeating Graphic Symbol

300 mcm XLPE

Graphic Text Record

Graphic Text Record

Circuit 4D11

5. REF_CABLE

6. CABLE

Non-graphic Database Record

Page 5: FRAMME_FeaDefOver

Graphic Technologies, Inc.

Page 5

FRAMME Feature Tags (Non-graphic and Graphic)

Non-graphic Feature Tag

FRAMME places a feature tag on each facility component in the non-graphic database. The FSC component option specifies that the database table contains a set of attributes referred to as the FRAMME tag, which is to be automatically maintained by FRAMME. This option is for non-graphic components only, and is recommended for all non-graphic components.

The FSC option causes FRAMME to use the database component table to maintain information on the facility. This information is required only for those components which are accessed from the non-graphic side of the model. For example, if you would like to search the RDBMS for a particular value, and then read the facility associated with that row, the table (component) must have the /FSC qualifier specified. The RB_FSC attribute requires 8 bytes. It must be defined in the *.rdl file using the following format:

.n RB_FSC F=I(32767) ; Feature Number

.n+1 RB_STATE F=I(32767) ; State Number

.n+2 RB_COMPONENT F=I(127) ; Component Number

.n+3 RB_VERSION F=I(127) ; Version Number

.n+4 RB_OCCURRENCE F=I(32767) ; Occurrence Number

The attribute names and data formats cannot be changed.

In addition, the following attributes are generally used as a part of each non-graphic component main record:

6. CABLE .100 RB_PRMRY F=I(2147483647) ; Graphic (*.dgn) Identifier (GID) .101 RB_SCNDRY F=I(2147483647) ; Unique Feature Identifier (UFID) .102 MSLINK F=I(2147483647) ; Microstation Link (not used by FRAMME) .103 RB_LOCK F=I(32767) ; Edit Lock Bit .104 RB_FSC F=I(32767) ; Feature Number .105 RB_STATE F=I(32767) ; State Number .106 RB_COMPONENT F=I(127) ; Component Number .107 RB_VERSION F=I(127) ; Version Number .108 RB_OCCURRENCE F=I(32767) ; Occurrence Number

Additional components used for a non-graphic component reference record: (See splitable linear) 5. REF_CABLE .100 RB_PRMRY F=I(2147483647) ; Graphic (*.dgn) Identifier (GID) .101 RB_SCNDRY F=I(2147483647) ; Unique Feature Identifier (UFID) .102 MSLINK F=I(2147483647) ; Microstation Link (not used by FRAMME) .103 RB_LOCK F=I(32767) ; Edit Lock Bit .104 RB_FSC F=I(32767) ; Feature Number .105 RB_STATE F=I(32767) ; State Number .106 RB_COMPONENT F=I(127) ; Component Number .107 RB_VERSION F=I(127) ; Version Number .108 RB_OCCURRENCE F=I(32767) ; Occurrence Number .109 RB_REFPRMRY F=I(2147483647) ; Reference Graphic (*.dgn) Identifier (GID) .110 RB_REFSCNDRY F=I(2147483647) ; Reference Unique Feature Identifier (UFID)

Page 6: FRAMME_FeaDefOver

Graphic Technologies, Inc.

Page 6

Graphic Feature Tag

FRAMME places a feature tag on each facility component in the graphics database. The following figure shows the format for the graphic feature tag. The graphic feature tag uniquely describes each occurrence of a facility in a design file, and includes a unique feature identifier (UFI or UFID) number. This number is maintained by FRAMME.

FRAMME maintains the link between the graphic and the non-graphic data through two columns in the relational database tables:

• The RB_PRMRY column (attribute), which identifies the design file by its graphic identifier (GID).

• The RB_SCNDRY column, which provides the unique feature identifier (UFID).

The following illustration shows formats for graphic feature tags.

Graphic Feature Tag

U(USER) (BYTE) 7 (BYTE)

(ID) 32 (WORD)

UNIQUE FEATURE IDENTIFIER (2 WORDS)

FEATURE NUMBER (WORD)

STATE NUMBER (WORD)

RULEBASE VERSION NUMBER

(BYTE)

COMPONENT NUMBER

(BYTE)

COMPONENT COUNT (WORD)

Page 7: FRAMME_FeaDefOver

Graphic Technologies, Inc.

Page 7

Graphic Feature Tag Example

The following is an example MicroStation EDG display used to review the tag on a FRAMME element.

$ edg workorder.dgn

EDG> set disp/full

EDG> 172 172 (7) TEXT NODE Level = 20 Words to follow = 44 Block=59 Word=103 byte=29900 IGDS format wtf = 41 Range: low = -8670, -8651, -2147483647 high = -7627, -5882, 2147483647 Graphic group: 0 Properties: nohole snappable planar noview_ind attributes nolocked nonew_element modified Class = Primary Symbology: color: 45, weight: 1, style: 0 words in description = 63 number of elements = 1 Node number = 22 font = 0, justification = LT Length and Height multipliers: 28000, 28000 rotation = 105.000 Origin: -7871, -8630 User Data Linkage 1007 20 F 0 1A 1 2 0

EDG> exit

Page 8: FRAMME_FeaDefOver

Graphic Technologies, Inc.

Page 8

In the above example, a text node in one facility is under review. The MicroStation EDG display is divided as shown below: User Data Linkage 1007 20 F 0 1A 1 2 0

For the displayed output, the MicroStation information is 1007. The rulebase identifier is 0x20 (32 decimal). The RB_SCNDRY value is 0x0F (15 decimal).

The feature number is 0x1A (26 decimal), the state is 1, the component number is 2, and the occurrence is 0.

2 bytes Microstation info

2 bytes Rulebase Identifier rulebase creation: -identifier=n

2 bytes Low end of RB_SCNDRY

2 bytes High end of RB_SCNDRY

2 bytes Feature number

2 bytes State number

2 bytes Component number

2 bytes Component occurrence

Page 9: FRAMME_FeaDefOver

Graphic Technologies, Inc.

Page 9

The Index (or Geoindex)

The index is a design file which contains a set of polygons or shapes. Each shape is defined and created by a feature definition and function in the rulebase. There must be at least one non-graphic component associated with the shape and there can be text as well. There is only one index per segment in the model.

Each shape represents a geographic (or detail) area in the model. Each shape is also associated with a particular class of data. Two design files (shapes) can represent the same physical area, but they will contain different types of data. This is accomplished through FRAMME class definitions (a class is a categorization of similar or related facilities in the FRAMME model).

Each shape then implicitly represents an actual master design file. In these design files, FRAMME stores and manages the actual facility data.

Only basic placement and edit of local data can be tested in a FRAMME environment without an index. If we remember that we cannot create or review any master data until we have an index (because it tells us which files are available for review), this limitation is completely logical.

Index Creation

1. The application developer must first create a feature definition which contains at least a graphic shape component and a database record. The record MUST use the design file table as specified during the rulebase creation.

2. Next, the developer must create a placement function for the facility. He must also create a function for posting the new facilities. This function can be used later for regular facility data.

3. The functions must be executed to create the shapes and then the post operation performed. FRS, during the posting process, will create the master design files associated with each index shape. The developer, during FRS installation, must create the appropriate seed design files for the successful creation of the master graphic files.

4. The index is now prepared for placing and posting regular facility data.

Note: We have not considered sizes of the index shapes, layout, position in the design plane, etc. All these items should be considered prior to creating the shapes. These considerations are too numerous to discuss here, but one basic item should be addressed: - No two shapes of the same class can overlap.

Index and Virtual Display

Virtual Display uses the index to know which master design files to attach based on the current view or screen display. The shapes which are found in the index in the current view range are queried to find their associated design files. Those files are subsequently displayed to the user.

Page 10: FRAMME_FeaDefOver

Graphic Technologies, Inc.

Page 10

Index Shapes

Facilities

Land

F-24-D-15 F-24-D-16 F-24-D-17

L-24-D-15 L-24-D-16 L-24-D-17

Page 11: FRAMME_FeaDefOver

Graphic Technologies, Inc.

Page 11

Splittable Linear Features

RB_PRMRY = 1 RB_SCNDRY = 1

Main Database Record

Reference Record

RB_PRMRY = 2 RB_SCNDRY = 1 RB_REFPRMRY = 1 RB_REFSCNDRY = 1

Reference Record

Reference Record

RB_PRMRY = 3 RB_SCNDRY = 1 RB_REFPRMRY = 1 RB_REFSCNDRY = 1

RB_PRMRY = 1 RB_SCNDRY = 1 RB_REFPRMRY = 1 RB_REFSCNDRY = 1

MAP A MAP C MAP B

Table: 6. CABLE

Table: 5. REF_CABLE

300 mcm XLPE

Circuit 4D11