USING ORACLE VIEWS IN SPATIAL FEATURE DEFINITIONS PURPOSE The purpose of this entry is to describe the design of Oracle Views for the definition of spatial features used by Bentley Geospatial products ie Bentley Map, Bentley Electric, Bentley Gas, Bentley Water, GeoWeb Publisher, and the Oracle Spatial Connector for ProjectWise) to solve a need to both separate and share business and GIS data. PROBLEM DEFINITION Classical examples of the definition of Oracle spatial tables include both the geometry and the business attributes into the same spatial table. This can, at existing installations, where business data already exists, cause problems with the setup of the spatial tables. What is needed is a way to reference the business data to the spatial data and allow the business data to be maintained, not only by the GIS user, but also by the current business data users. Some of the requirements for this solution may be: The business table is maintained by some person or group outside of the GIS department we will call this the BUSINESS department). The spatial data geometry) is maintained by the GIS department. The GIS users will benefit from at least viewing and searching on the business data. The BUSINESS department will benefit by at least viewing and searching on the spatial data. Some or all) business data can be maintained by the GIS users. Some or all) business data can be maintained by the BUSINESS department. Do not duplicate the business data into the GIS spatial data. In summarizing these requirements, there seems to be a need to separate and consolidate the business and spatial data without sacrificing good database design and data integrity. PROBLEM SOLUTION We will investigate the usage of Oracle Views as one of the solutions to solving this problem. The basic design will comprise of: 1. Creation of the spatial geometry table, including spatial indexes and metadata entries. 2. Loading of existing spatial data into the geometry table.
3. Creation of the view, as a join between the business data and the spatial data, including the creation of the metadata entries. 4. Creation of the triggers to maintain the data between the view and the actual tables. When finished we will have the business and spatial data separated, but also viewed as a consolidated dataset, that will be maintainable by either the BUSINESS or GIS departments. STEP 1 CREATION OF THE SPATIAL GEOMETRY TABLE As described in the Bentley Map help file, a spatial table must meet the 4 following requirements. The feature table must have a primary key constraint consisting of a single numeric or string/character column to represent the feature ID. This primary key is required to enable versioning using the standard versioning system of the Oracle Workspace Manager. The table must have a geometric SDO_GEOMETRY) column specifying the feature geometry, and this geometry column must be registered in the Oracle Spatial metadata table ALL_SDO_GEOM_METADATA or the related USER_SDO_GEOM_METADATA view for the user). The table fields must be of a common type, not a user defined type. Geometry must be of similar types, meaning all geometries must be of point, line, or polygon type, not a mixture of these. Along with these basic requirements, point features have the following OPTIONAL needs because point features text and cells in Microstation) have additional geometric requirements. Since there is a rotation value for both text and cells, for their graphical display, there can also be a optional rotation field defined. This can be placed in the spatial table or the business table, but I would suspect that this will be placed in the spatial table, just to keep the spatial data together. For the purpose of this exercise we will call this field ROTATION, it will be numeric field. Since there is also a X and Y scale factor for point features text and cell), we will also add these fields to a point feature spatial table. We will call these X_SCALE and Y_SCALE and make them numeric also. If these fields are not defined, for point features, then when data is retrieved from the spatial database and plotted in the drawing or displayed in some other fashion), the point feature will always plot at a angle of 0 degrees or radians) and at a scale of 1 or text height/width of 1). This is probably not desirable for most types of output. SPATIAL TABLE DEFINITIONS CREATE TABLE point_feat_geom rec_id NUMBER22), // used to link to the business table geometry MDSYS.SDO_GEOMETRY, // required Oracle geometry object rotation NUMBER, // optional point feature rotation x_scale NUMBER, // optional point feature x scale
y_scale NUMBER // optional point feature y scale ); The polyline and polygon tables will look the same as the point feature, except it will not contain the optional columns that can be used for a point feature. CREATE TABLE polyline_feat_geom rec_id NUMBER22), // used to link to the business table geometry MDSYS.SDO_GEOMETRY // required Oracle geometry object ); CREATE TABLE polygon_feat_geom rec_id NUMBER22), // used to link to the business table geometry MDSYS.SDO_GEOMETRY // required Oracle geometry object ); ENTRY INTO THE SDO_GEOM_METADATA TABLE. Now that we have the spatial table defined, we need to add entries into the SDO_GEOM_METADATA table so that Oracle can perform operations on these tables. This satisfies the second bullet item above. These entries are: INSERT INTO USER_SDO_GEOM_METADATA TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES 'point_feat_geom', 'geometry', MDSYS.SDO_DIM_ARRAY MDSYS.SDO_DIM_ELEMENT'X', 5000000, 5000000, 0.000000050), MDSYS.SDO_DIM_ELEMENT'Y', 5000000, 5000000, 0.000000050) ), NULL); INSERT INTO USER_SDO_GEOM_METADATA TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES 'polyline_feat_geom', 'geometry', MDSYS.SDO_DIM_ARRAY MDSYS.SDO_DIM_ELEMENT'X', 5000000, 5000000, 0.000000050), MDSYS.SDO_DIM_ELEMENT'Y', 5000000, 5000000, 0.000000050) ), NULL);
INSERT INTO USER_SDO_GEOM_METADATA TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES 'polygon_feat_geom', 'geometry', MDSYS.SDO_DIM_ARRAY MDSYS.SDO_DIM_ELEMENT'X', 5000000, 5000000, 0.000000050), MDSYS.SDO_DIM_ELEMENT'Y', 5000000, 5000000, 0.000000050) ), NULL); CREATION OF THE SPATIAL INDEXES Now we want to define the spatial indexes for each of these tables. The spatial index assists in the retrieval of the data for spatial operations view, fence, etc.). CREATE INDEX point_feature_sidx ON point_feat_geomgeometry) INDEXTYPE IS mdsys.spatial_index PARAMETERS 'layer_gtype=point'); CREATE INDEX polyline_feature_sidx ON polyline_feat_geomgeometry) INDEXTYPE IS mdsys.spatial_index PARAMETERS 'layer_gtype=line ); CREATE INDEX polyline_feature_sidx ON polyline_feat_geomgeometry) INDEXTYPE IS mdsys.spatial_index PARAMETERS 'layer_gtype=polygon ); Ok, we are done with the table creations. Notice that I did not create a primary key on these tables, which is a requirement for the spatial tables, as per Bentley Map. For this implementation, the primary key is assigned to the views and not to the geometry table, since we are combining multiple tables into the view. Next we want to review the business table. STEP 2 BUSINESS TABLE DEFINITION We are assuming that the business table is already created and possibly populated. The business table for this example is defined as follows: CREATE TABLE point_feat_prop unique_id NUMBER22), // Unique identifier for the business table records
StringValue VARCHAR216), // String value NumberValue NUMBER32), // Numeric value DateValue DATE // Date value ); STEP 3 VIEW DEFINITION Now that we have the business and spatial tables defined, we can define the view that links these 2 tables together. Note the same basic process can be used for the polyline and polygon tables. To link these together we are going to use the rec_id column in the spatial table with the unique_id column in the business table. CREATE VIEW point_feat_vw AS SELECT p.unique_id unique_id, p. StringValue stringvalue, p. NumberValue numbervalue, p. DateValue datevalue, g.geometry geometry, g.rotation rotation, g.x_scale x_scale, g.y_scale y_scale FROM point_feat_prop p, point_feat_geom g WHERE p.unique_id = g.rec_id; Since we have the view created, we need to now finish defining a couple of more items, so that the Geospatial Administrator and Bentley Map will recognize this as a spatial table. DEFINE THE PRIMARY KEY Remember earlier Bentley Map requires a primary key be defined on the spatial table, for the purpose of allowing Oracle to create versions of the data. But we cannot by default have a primary key active on a view. To get around this we create the primary key, but we disable it, by the following: ALTER VIEW point_feat_vw ADD PRIMARY KEYunique_id) DISABLE;
ENTRY TO THE SDO_GEOM_METADATA TABLE. Ok, the last task is to add a entry into the SDO_GEOM_METADATA table. This is done as follows 1 : INSERT INTO user_sdo_geom_metadata SELECT 'point_feat_vw', column_name, diminfo, srid FROM user_sdo_geom_metadata WHERE table_name = 'POINT_FEAT_GEOM'; STEP 4 SETTING UP THE TRIGGERS Since we are doing selects, deletes, inserts and updates into a view and not the parent tables, we need to create some triggers that properly manipulate the data. Therefore we will be creating a trigger for inserts, updates and deletes on the view. INSERT TRIGGER We redirect the insertion of the data from the view into the actual tables business and spatial) CREATE OR REPLACE TRIGGER point_feat_insert_trigger INSTEAD OF INSERT ON point_feat_vw DECLARE duplicate_info EXCEPTION; PRAGMA EXCEPTION_INIT duplicate_info, 00001); BEGIN INSERT INTO point_feat_prop unique_id, StringValue, NumberValue, DateValue ) 1 Actually you could have done this differently, via SQL, but this is one of several options.
VALUES :new.unique_id, :new.stringvalue, :new.numbervalue, :new.datevalue ); INSERT INTO point_feat_geom rec_id, geometry, rotation, x_scale, y_scale ) VALUES :new.unique_id, :new.geometry, :new.rotation, :new.x_scale, :new.y_scale ); EXCEPTION WHEN duplicate_info THEN RAISE_APPLICATION_ERROR num=> 20107, msg=> 'Duplicate ref_id'); END point_feat_insert_trigger; / UPDATE TRIGGER When the user updates the view, we want to update the underlying tables instead. CREATE OR REPLACE TRIGGER point_feat_update_trigger INSTEAD OF UPDATE ON point_feat_vw FOR EACH ROW BEGIN UPDATE point_feat_prop SET unique_id = :new.unique_id, StringValue= :new.stringvalue, NumberValue = :new.numbervalue, DateValue=:new.dateValue WHERE unique_id = :old.unique_id;
UPDATE point_feat_geom SET geometry = :new.geometry, rotation =:new.rotation, x_scale=:new.x_scale, y_scale=:new.y_scale, rec_id = :new.unique_id WHERE rec_id= :new.unique_id; END point_feat_update_trigger; / DELETE TRIGGER Lastly, we need to define the delete record trigger for the underlying records of the view 2. CREATE OR REPLACE TRIGGER point_feat_delete_trigger INSTEAD OF DELETE ON point_feat_vw BEGIN DELETE FROM point_feat_prop WHERE unique_id = :old.unique_id; DELETE FROM point_feat_geom WHERE rec_id = :old.unique_id; END point_feat_delete_trigger; OPTIONAL ADDING TEST DATA I know earlier, I said that the business or spatial data may already exist, which in most cases, it probably does. For completeness of this exercise, I will add test data. This will consist of a couple of rows of data, entered into the spatial and the business tables. This will allow us to set up the XFM Schema and test the placement, editing and removal of the spatial data. /* Delete all the current records thawe inserted as test records. DELETE from point_feat_vw where unique_id in 1, 2); commit; /* Insert a record into the view */ INSERT INTO point_feat_vw unique_id, 2 If you do not want to delete the business data, but instead delete the spatial data, then you would remove the deletion from the point_feat_prop table from this trigger. This way the GIS department would not be able to delete the records from the business table, when deleting spatial data.
stringvalue, numbervalue, datevalue, geometry, rotation, x_scale, y_scale ) values 1, 'text1', 1000, select sysdate from dual), mdsys.sdo_geometry 2001, null, mdsys.sdo_point_type1,1,null), null, null ), 1.00, 1.00, 1.00 ); commit; /* Insert another record into the view */ INSERT INTO point_feat_vw unique_id, stringvalue, numbervalue, datevalue, geometry, rotation, x_scale, y_scale ) values 2, 'text2',
20, select sysdate from dual), mdsys.sdo_geometry 2001, null, mdsys.sdo_point_type100,200,null), null, null ), 0.785, 0.50, 0.50 ); commit; OPTIONAL CREATING A SEQUENCE GENERATOR In order for the spatial interface, in the Bentley products, to post new records to a particular spatial feature, a sequence generator must be created for the spatial feature. This is optional at the time of the creation of the spatial feature schema, in the database, because it can be done in the GSA when registering the feature. It is wise though to do this in the database, to keep the schema definition in one place the database). DROP SEQUENCE "point_feature_seq"; CREATE SEQUENCE "point_feature_seq" INCREMENT BY 1 START WITH 3 ORDER; commit; REGISTERING THE SPATIAL FEATURE WITH THE GSA Now that we have the spatial feature schema defined in the database, for the example feature, we need to setup the XFM schema through the GSA. The GSA is then used to generate all the feature interfaces, including the placement, viewing and editing of the feature instances. The GSA can also be used to setup the Bentley geospatial product workspaces, as an extension of the standard MicroStation workspaces. CREATE TEMPLATE XFM SCHEMA WITH ORACLE SPATIAL CONNECTION First we want to open the GSA and create a new schema. Then we want to navigate to the Graphical Sources and create a new Oracle Spatial Connection.
Now we want to register the features found in this spatial connection.
Finally we create a workspace, save the XFM schema file and Export the XFM schema and workspace, to be used in Bentley Map. TESTING FEATURE SETUP AND CONFIGURATION Now that we have the feature schema set up in the database, and have the XFM project set up and ready to use, we will start up Bentley Map with the XFM project and perform a few operatons, namely query, update, create and post features. First, let s open a work drawing, created from the GSA when setting up the XFM schema.
Notice that the 2 entries for placement and promote are listed in the Bentley Map command manager. This tells me that I have the XFM project loaded and ready to go. Now we want to go to the file pull down menu, and select the Open Oracle Spatial option. This will bring up the interoperability form. Select the Oracle node, and right mouse click to select the Open Graphical Source: testos item from the drop down list. Once you supply the password for the connection, and to the Oracle data source, you can now select a connection and the underlying features for manipulation. Make sure your spatial option is set for all for the connection and retrieve the features from the Point Feature class. Map will indicate how many of these features were queried from the spatial database, in our case it is the 2 inserts we did in the setup scripts. Let s use one of the standard Bentley Map tools to see what the non graphical data contains. As you can see, we have 4 properties from the business table, but where are the 4 properties we had from the spatial table geometry, rotation, x_scale, y_scale)? These properties are there, but are not maintained as business attributes, but rather are considered administrative attributes and are not available for the user to manipulate, at least thru forms, etc. that would edit the attributes. Now, the user can manipulate these thru graphical means, for instance moving the point feature, spatially, would update the geometry column of the spatial table. Also scaling or rotating the point feature would update the appropriate fields in the spatial table also.
If we change one of the attributes of the feature, we can then post this feature back to the database and review it s properties. This exercises the update trigger that we implemented on the view. We can also place a new feature in the drawing. Along with the graphics, we enter the business attributes during the placement operation. This functionality, besides placing a new feature, exercises the insert trigger of the view, when the new feature is posted to the database.
Once the feature is posted, we can look at the database, thru SQL Developer, and see the new row has been entered into the view. Once a feature has been posted, we can then lock the feature and delete it graphically. Once a post operation is performed, Bentley Map will inform the spatial database that a particular record has been deleted in the drawing, and to remove this row from the database. This operation exercises the delete trigger that we implemented on the view. FURTHER EXPANSIONS As you can see the use of views is a powerful tool in the consolidation of the spatial and business data domains. I just want to propose a few ideas for future topics, expanding upon the foundation laid in this entry. The use of views to maintain separate map products for a particular set of data. Regularly, especially in utilities industry, there is a need to produce maps at different scales, and different levels of detail. The use of views along with the XFM schema setups provide by the GSA, can be used to provide this level of integration. This is also important in providing white space management in different map outputs. The inclusion of other data sets into the spatial realm. This can be tabular data from other outside sources. Creation of other spatial features, without the recreation of the base data. Since the business and spatial data already exists, we can set up different views of the data with very little effort.