IMAGINE Enterprise Editor

IMAGINE Enterprise Editor User s Guide August 5, 2006

Copyright 2006 Leica Geosystems Geospatial Imaging, LLC All rights reserved. Printed in the United States of America. The information contained in this document is the exclusive property of Leica Geosystems Geospatial Imaging, LLC. This work is protected under United States copyright law and other international copyright treaties and conventions. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, or by any information storage or retrieval system, except as expressly permitted in writing by Leica Geosystems Geospatial Imaging, LLC. All requests should be sent to the attention of: Manager, Technical Documentation Leica Geosystems Geospatial Imaging, LLC. 505 Peachtree Corners Circle Suite 00 Norcross, GA 30092-2500 USA. The information contained in this document is subject to change without notice. Government Reserved Rights. MrSID technology incorporated in the Software was developed in part through a project at the Los Alamos National Laboratory, funded by the U.S. Government, managed under contract by the University of California (University), and is under exclusive commercial license to LizardTech, Inc. It is used under license from LizardTech. MrSID is protected by U.S. Patent No. 5,70,835. Foreign patents pending. The U.S. Government and the University have reserved rights in MrSID technology, including without limitation: (a) The U.S. Government has a non-exclusive, nontransferable, irrevocable, paid-up license to practice or have practiced throughout the world, for or on behalf of the United States, inventions covered by U.S. Patent No. 5,70,835 and has other rights under 35 U.S.C. 200-22 and applicable implementing regulations; (b) If LizardTech's rights in the MrSID Technology terminate during the term of this Agreement, you may continue to use the Software. Any provisions of this license which could reasonably be deemed to do so would then protect the University and/or the U.S. Government; and (c) The University has no obligation to furnish any know-how, technical assistance, or technical data to users of MrSID software and makes no warranty or representation as to the validity of U.S. Patent 5,70,835 nor that the MrSID Software will not infringe any patent or other proprietary right. For further information about these provisions, contact LizardTech, 008 Western Ave., Suite 200, Seattle, WA 9804. ERDAS IMAGINE is a registered trademark of Leica Geosystems Geospatial Imaging, LLC. ORACLE is a registered trademark of Oracle Corporation. Other companies and products mentioned herein are trademarks or registered trademarks of their respective owners.

Table of Contents Table of Contents.............................. iii Preface...................................... v About This Manual........................... v Sample Data................................ v Documentation.............................. v Conventions Used in This Book.................. v Introduction................................... Introduction................................ Overview of IEE................................ Oracle Spatial Concepts....................... Spatial Data Modeling............................ Spatial Data Model Oracle Spatial Example............ 2 Supported Geometric Types....................... 2 Elements.................................... 4 Geometries................................... 5 Layers...................................... 5 Metadata, Tolerance, and Coordinate Systems.......... 7 Data Loading................................. 9 Data Validation............................... 9 Indexing Spatial Data........................... 20 Application Considerations........................ 2 Topological Data Model....................... 22 Topology elements............................. 22 Topology related tables.......................... 23 Display Metadata........................... 23 Styles...................................... 23 Themes..................................... 25 Styling Rules in Predefined Themes................. 25 Maps...................................... 26 Metadata Views............................ 28 Tutorial..................................... 29 Getting Connected.......................... 29 IEE Startup.................................. 29 Connection Dialog............................. 30 Password................................... 30 Map Selection................................ 3 Discover Options.............................. 3 Search and Locate............................. 32 IEE Interface.............................. 34 Transaction Management Commands............. 35 Understanding IEE Settings....................... 35 Snapping................................... 35 Table of Contents / iii

Data Locking................................. 35 Release Locks on Exit........................... 35 Grid........................................ 36 Draw Handles................................. 36 IEE Tolerance................................. 36 IEE Settings Dialog......................... 36 Locking & Grid Settings.......................... 36 Snapping Settings.............................. 37 Topology and Display Settings..................... 39 IEE Locks................................ 40 Understanding IEE Digitizing Locks.................. 40 Dissolve Polygon Lock........................... 40 Segmentation Lock............................. 40 Dangle Lock (Start)............................. 4 Dangle Lock (End).............................. 4 Rubber Band Lock.............................. 4 Theme Lock.................................. 4 Axis Lock.................................... 4 Grid Lock.................................... 4 Linear Snap Lock............................... 4 Theme Control............................ 42 Display Themes............................... 42 Edit Themes.................................. 42 Digitizing with IEE......................... 43 Place Point Geometry............................ 43 Place Line Geometry............................ 43 Place Polygon Geometry.......................... 43 Place Circle Polygon Geometry..................... 44 Place Circle Polygon Geometry by Center.............. 44 Place Rectangle Polygon Geometry.................. 45 Place Circular Arc Geometry....................... 45 Place Isolated Node Primitive...................... 46 Place Edge Primitive............................ 46 Place Point Feature............................. 47 Place Line Feature.............................. 47 Place Polygon Feature........................... 48 Place Polygon Interact Feature..................... 48 Saving Data to Database..................... 49 Exporting Spatial Data to Oracle............... 50 Index...................................... 5 Table of Contents / iv

Preface About This Manual The IMAGINE Enterprise Editor (IEE) User s Guide is both a theoretical and a practical guide that will help you learn how to use IMAGINE Enterprise Editor software. The IMAGINE Enterprise Editor Guide manual serves primarily as a tutorial. It also includes a comprehensive index so that you can reference particular information while using IMAGINE Enterprise Editor for your own projects. Introduction is designed to give you an overview of the concepts and technology involved with creating and maintaining data with IEE. Tutorial is designed to provide more detailed information about the components of IEE and how to use them. This user guide is not intended to tell you everything there is to know about any one topic, but to show you how to use some of the basic tools you will need to get started. Sample Data Sample data sets are provided with the software. The sample data are installed in the <IMAGINE_HOME>/examples directory. <IMAGINE_HOME> is the variable name of the directory where IMAGINE resides. When accessing data files, you need to replace <IMAGINE_HOME> with the name of the directory where ERDAS IMAGINE is loaded. Documentation This manual is part of a suite of on-line documentation that you receive with ERDAS IMAGINE software. There are two basic types of documents, digital hardcopy documents which are delivered as PDF files suitable for printing or on-line viewing, and On-Line Help Documentation, delivered as HTML files. The PDF documents are found in <IMAGINE_HOME>\help\hardcopy. Many of these documents are available from the Leica Geosystems Start menu. The on-line help system is accessed by clicking on the Help button in a dialog or by selecting an item from a Help menu. Conventions Used in This Book In ERDAS IMAGINE, the names of menus, menu options, buttons, and other components of the interface are shown in bold type. For example: In the Select Layer To Add dialog, click the Fit to Frame option. When asked to use the mouse, you are directed to click, double-click, Shift-click, middle-click, right-click, hold, drag, etc. Conventions Used in This Book / v

click click once with the left mouse button. double-click click twice with the left mouse button. Shift-click hold down the Shift key on your keyboard and simultaneously click the left mouse button. middle-click click once with the middle mouse button. right-click click once with the right mouse button. hold press and hold the left (or right, as noted) mouse button. drag drag the mouse while holding the left mouse button. The following paragraphs are used throughout the ERDAS IMAGINE documentation: These paragraphs contain strong warnings or important tips. These paragraphs give you software-specific information. These paragraphs provide information about Leica Geosystems products. These paragraphs lead you to other areas of this book or other manuals for additional information. NOTE: Notes give additional instruction. Blue Box These boxes contain supplemental technical information. Blue text indicates a link that will take you to related information when you click it. Conventions Used in This Book / vi

Introduction Introduction Overview of IEE The purpose of the IMAGINE Enterprise Editor (IEE) User s Guide is to provide background information on the technology used to implement a database-centric enterprise geographic information system (GIS) and how the IEE software can be used to manipulate and maintain the data stored within the enterprise environment. Chapter 2 covers the actual functionality provided with IEE. This guide is aimed at a diverse audience: from those who are new to databases to those savvy users who have been in this industry for years. The IMAGINE Enterprise Editor provides a seamless interface between ERDAS IMAGINE 9.0 and Oracle 0g Spatial. IEE enables simultaneous access to Oracle Spatial, Oracle Topology and Oracle Georaster formatted data within the IMAGINE Viewer. Oracle Spatial Concepts Spatial Data Modeling IMAGINE Enterprise Editor provides a seamless interface between ERDAS IMAGINE 9.0 and Oracle 0g Spatial. IEE enables simultaneous access to Oracle Spatial, Oracle Topology and Oracle Georaster formatted data within the IMAGINE Viewer. Traditional RDBMS data model concepts apply when dealing with spatial data. Oracle supports many traditional data types, including VARCHAR2 for characters, DATE type for dates, NUMBER type for numbers, and now an SDO_GEOMETRY data type for storing the coordinates of spatial features. There is no spatial table in Oracle, just ordinary Oracle tables with one or more SDO_GEOMETY columns. When normalized tables are created, Oracle recommends including SDO_GEOMETRY columns in tables where all the other columns in the table have a one-to-one relationship with the SDO_GEOMETRY column. Consider the following example of modeling road and river spatial features. Road information might include number of lanes, a street address range, and more. River information might include salinity, maximum depth, and more. Even though they are both linear features, since the information for roads is not relevant to rivers, and river information is not relevant to roads, it is not recommended to store their coordinates in the same SDO_GEOMETRY column of a table. A normalized data model would store the road spatial features in a Roads table, along with other columns that have a one to one relationship with the coordinates of a road. A similar normalized data model is recommended for a Rivers table. An additional benefit of storing roads apart from rivers becomes more apparent at query time. When you are only searching for roads, there is no need to sift through a table that contains entries for both roads and rivers. Oracle Spatial Concepts /

Figure : Spatial Data Model Comparison File / Directory Based 2 to 8 files for each layer Layers are added to edit environment individually Oracle Spatial All data for a layer is stored in a single table Layers are grouped together as a map Users only lock areas of data so many users can Spatial Data Model Oracle Spatial Example Table : Road Table Example ROAD ROAD ROAD NUM SURFACE GEOM NAME ID TYPE LANES HWY-25 32456 Primary 4 Concrete sdo_geometry I-70 32456 Primary 4 Concrete sdo_geometry Main St 34562 City 2 Asphalt sdo_geometry CR-34 23400 County Dirt sdo_geometry Table 2: sdo_geometry Structure MDSYS.SDO_GEOMETRY object Name Type Description SDO_GTYPE NUMBER Defines the kind of geometry SDO_SRID NUMBER Used to identify a coordinate system SDO_POINT SDO_POINT_TYPE Optimized storage for point data SDO_ELEM_INFO SDO_ELEM_INFO_ARRAY Defines how to interpret the ordinate array SDO_ORDINATES SDO_ORDINATE_ARRAY Storage for ordinates of geometry Supported Geometric Types Oracle Spatial supports three multi-dimensional geometric primitive types and geometries composed of collections of these types. The three primitive types are: Points (X, Y) Oracle Spatial Concepts / 2

Line strings (X, Y, Xn, Yn) Polygons (X, Y,... Xn, Yn) Geometric Primitive Types Line string Arc line string Compound line string Self-crossing line strings Valid n Polygon with hole Compound polygon Optimized polygons Self-crossing polygons Not valid Points are elements composed of between two and four ordinates, if only X and Y - often correspond to longitude and latitude. Line strings are composed of two or more pairs of points that define line segments. Self-crossing lines are supported. Lines that cross to form a ring have no implied interior. Coordinates may be stored in clockwise or counterclockwise order. Polygons are composed of line strings that form a closed ring, and the interior of the polygon is implied. Polygons may also contain holes that are constructed by defining inner polygons. Holes represent polygon voids (doughnuts). Self-crossing polygons are not supported although self-crossing line strings are. If a line string crosses itself, it does not become a polygon. A self-crossing line string does not have any implied interior. Polygon can be exterior polygons or interior polygons (also called holes). An exterior polygon has to be followed by its interior polygons. Exterior polygons must be stored in counter clockwise rotation. Interior polygons must be stored in clockwise rotation. Oracle Spatial Concepts / 3

Elements An element is the basic building block of a geometric feature for Oracle Spatial. The supported spatial element types are point, line string, and polygon. Elements are constructed using ordinates - if 2D they are pairs, called coordinates, and depending on the element type, the element may contain many coordinates. In a GIS example, elements might model historic markers (points), roads (line strings), or political or administrative boundaries (polygons). Each coordinate in an element is stored as an X, Y pair. Elements Basic building blocks of a geometry Same as geometric primitive types Element types Point Line Polygon Compound Linestring Compound Polygon Constructed using ordinates Element 7 Element 6 Element 5 Element 4 Element 2 Element 3 Hawaii, USA Element Point data consists of one or more coordinates (or more than 2 values for > 2D) and resides in one row of the spatial table. Line data consists of two or more sets of ordinate values representing line segments of the geometry. Line strings consisting of many ordinates within the spatial object. Polygon data also consists of coordinate pair values, one vertex pair for each line segment of the polygon. The first coordinate pair represents the first line segment, with coordinates defined in either a clockwise or counterclockwise order around the polygon. You must close the polygon by repeating the first vertex as the last. An example of a geometry that consists of multiple elements is the State of Hawaii. Hawaii consists of seven islands, and when modeled using Oracle Spatial it will consist of seven elements, one for each island. Oracle Spatial Concepts / 4

Geometries Geometries are the representation of spatial features, modeled as an ordered set of primitive elements. Represents a spatial feature Consists of an ordered set of elements Geometry Geometry California Geometry 3 Florida Geometry 2 Texas Geometry 4 Hawaii A complex geometric feature such as a polygon with holes would be stored as a sequence of polygon elements. In a multiple-element polygonal geometry, all sub-elements are wholly contained within the outermost element, thus building a more complex geometry from simpler pieces. A geometry might describe the available land in a town. This could be represented as a polygon with holes where water or zoning prevents construction. Layers The graphic below illustrates geometries stored in a polygonal layer representing political boundaries in the United States. Oracle Spatial Concepts / 5

Layers Consist of geometries that share a common set of attributes Layer is a geometry column in a table States layer Table 3: Oracle Spatial Gtypes SDO_GTYPES GTYPE - Gtype with Dimensionality 2D 3D 4D 0 Unknown Geometry 2000 3000 4000 Point 200 300 400 2 Linestring 2002 3002 4002 3 Polygon 2003 3003 4003 4 Collection 2004 3004 4004 5 MultiPoint 2005 3005 4005 6 MultiLinestring 2006 3006 4006 7 MultiPolygon 2007 3007 4007 The main reason for discussing earlier version of Oracle Spatial is because of issues that users will have with migrating data from other data sources or models. Oracle Spatial Concepts / 6

As an example we can look at the requirement for polygons to be counter clockwise to describe positive area and clockwise to define negative areas or voids. In 8..5 Oracle Spatial did not have this constraint and therefore all polygons had to be pre-processed during indexing and querying to determine the true relationship between positive and negative polygons. This processing could be a big issue to a large data set and was eventually mitigated by applying additional business rules to the Oracle Spatial object model. There are many spatial formats in the world and quite a few of them do not require polygons to have a certain direction. Oracle Spatial now has a function that will re-direct and re-order any polygons that do not follow its current structural rules. This allows a user to migrate spatial data into the 8..5 format and then bring the data into compliance with the current release of Oracle Spatial. Element Types Number Element Type Interpretation 0 UNKNOWN_ELEMENT User defined POINT # of points in collection 2 LINESTRING - Straight lines 2 - Circular arcs 3 POLYGON - Straight lines 003 (Outer) 2 - Circular arcs 2003 (Inner) 3 - Optimized rectangle 4 - Circle 4 COMPOUND LINESTRING # of type 2 sub-elements that make up the linestring 5 COMPOUND POLYGON # of type 2 sub-elements that make up the polygon 005 (Outer) 2005 (Inner) Oracle Spatial Concepts / 7

Element Example: Line String Ordinate offset Element type 2 Interpretation (x2,y2) (x,y) (x3,y3) (x4,y4) Each line segment is defined by two points Last point from one is the first point of next segment Line segments that close to form a ring have no implied interior Line segments must be contiguous Line segments can cross Element Example: Polygon Ordinate offset Element type 003 Interpretation (x5,y5) (x6,y6) (x,y) (x4,y4) (x2,y2) (x3,y3) Interpretation - All line segments are straight lines Area is implied Line segments cannot cross each other Oracle Spatial Concepts / 8

Element Example: Arc Polygon Ordinate offset Element type 003 Interpretation 2 (x6,y6) (x7,y7) (x5,y5) (x8,y8) (x4,y4) (x9,y9) (x,y) (x2,y2) (x3,y3) Interpretation 2 - All line segments are circular arcs Area is implied Arcs can not cross each other Element Example: Arc String Ordinate offset Element type 2 Interpretation 2 (x2,y2) (x4,y4) (x,y) (x3,y3) (x5,y5) (x6,y6) (x7,y7) Each arc is defined by three points on the circumference of a circle Last point from one arc is the first point of next arc Arcs that close to form a ring have no implied interior Arcs must be contiguous Arcs can cross Oracle Spatial Concepts / 9

Element Example: Rectangle Ordinate offset Element type 003 Interpretation 3 (x2,y2) (x,y) Optimal storage - Defined by lower left point, upper right point Area is implied Element Example: Circle Ordinate Offset Element Type 003 Interpretation 4 (x2,y2) (x,y) (x3,y3) Defined by any three distinct points on the circumference Area is implied Oracle Spatial Concepts / 0

Element Example: Compound Line String Ordinate Offset Element Type Interpretation 5 3 (x4,y4) 4 2 2 2 3 2 (x3,y3) (x2,y2) (x6,y6) (x5,y5) (x7,y7) (x,y) (x8,y8) (x9,y9) First triplet (header) defines the number of sub-elements Sub-elements must be contiguous Arcs and line segments of sub-elements can cross Element type 4 can ONLY contain sub-elements of type 2 Element Example: Compound Polygon Ordinate Offset 5 (x6,y6) (x7,y7) (x,y) Element Type 005 2 2 (x5,y5) (x4,y4) Interpretation (x3,y3) 2 2 (x2,y2) First triplet (header) defines the number of sub-elements Sub-elements must be contiguous Arcs and line segments of sub-elements cannot cross Element type 5 can ONLY contain sub-elements of type 2 Area is implied Oracle Spatial Concepts /

Etype 0 - to support interoperability Ordinate Offset 27 Element Type 2 0 Interpretation 200 (x5,y5) (x,y) (x3,y3) MDSYS.SDO_ELEM_INFO_ARRAY (,2,,27,0,200) MDSYS.SDO_ORDINATE_ARRAY ( x,y,...,x3,y3,x,y,x5,y5,x3,y3) Element Example: Unknown geometry Ordinate Offset 7 Element Type 0 Interpretation 324 2 Element type 0 is ignored by Oracle Spatial Element type 0 is for modeling unsupported element types (i.e. curves, splines etc ) A geometry with an element type 0 must contain at least one element of type,2,3,4 or 5. The non 0 element is an approximation of the unsupported geometry. The approximation is indexed by Oracle Spatial Oracle Spatial Concepts / 2

Collection Example: Point cluster Ordinate Offset Element type Interpretation 5 (x,y) (x2,y2) (x4,y4) (x3,y3) (x5,y5) Interpretation is the number of points in the cluster Collection Example: Multi Line String Ordinate offset 7 Element type 2 2 Interpretation 2 (x2,y2) (x5,y5) (x,y) (x3,y3) (x4,y4) (x6,y6) Elements can be line strings, arc strings or compound line strings Oracle Spatial Concepts / 3

Collection Example: Multi Polygon Ordinate offset 3 Element type 003 003 Interpretation 4 (x5,y5) (x6,y6) (x,y) (x4,y4) (x8,y8) (x7,y7) (x9,y9) (x2,y2) (x3,y3) Elements can be polygons, arc polygons, or compound polygons Collection Example: Multi Polygon Ordinate offset 3 Element type 003 Interpretation (x5,y5) (x6,y6) (x,y) (x7,y7) (x4,y4) (x2,y2) (x3,y3) Elements can be polygons, arc polygons, or compound polygons Oracle Spatial Concepts / 4

Element example: Polygon with void Ordinate offset 3 Element type 003 2003 (x5,y5) Interpretation 3 (x6,y6) (x,y) (x7,y7) (x8,y8) (x4,y4) (x2,y2) (x3,y3) A void can be modeled with any combination of type 3 and type 5 elements Voids can contain islands and islands can contain voids Area is implied as the difference between the outer and inner polygons Element example: Compound polygon with void Ordinate Offset 7 7 (x7,y7) Element Type 005 2 2 2003 (x5,y5) Interpretation 2 2 3 (x8,y8) (x,y) (x6,y6) (x0,y0) (x4,y4) (x2,y2) (x9,y9) (x3,y3) A void can be modeled with any combination of type 3 and type 5 elements Voids can contain islands and islands can contain voids Area is implied as the difference between the outer and inner polygons Oracle Spatial Concepts / 5

Constructing geometries SQL> INSERT INTO LINES VALUES ( 2> attribute_,..., attribute_n, 3> MDSYS.SDO_GEOMETRY ( 4> 2002, null, null, 5> MDSYS.SDO_ELEM_INFO_ARRAY (,2,), 6> MDSYS.SDO_ORDINATE_ARRAY ( 7> 0,0, 20,25, 30,0, 40,0)) 8> ); (20,25) (0,0) (30,0) (40,0) Constructing geometries SQL> INSERT INTO PARKS VALUES( 2> attribute_,..., attribute_n, 3> MDSYS.SDO_GEOMETRY( 4> 2003, null, null, 5> MDSYS.SDO_ELEM_INFO_ARRAY 6> (,005,2,,2,, 7,2,2, 7,2003,3), 7> MDSYS.SDO_ORDINATE_ARRAY 8> (0,50,0,30,50,30,50,50,40,60, 9> 30,50,20,60,0,50,25,35,35,40 ) 0> ); (20,60) (0,50) (0,50) (40,60) (30,50) (35,40) (50,50) (0,30) (25,35) (50,30) Oracle Spatial Concepts / 6

Ring ordering In 8..6+: External ring must appear before internal ring Outer and inner rings identified by element type must be constructed as 003 2003 + must be constructed as 003 2003 003 + + Metadata, Tolerance, and Coordinate Systems Every SDO_GEOMETRY column in a table requires an entry in Oracle spatial metadata dictionary, SDO_GEOM_METADATA_TABLE. For each user schema that has spatial data, the metadata is accessed through the view USER_SDO_GEOM_METADATA. The metadata entries includes the following information: Name of the table that contains the column of type SDO_GEOMETRY Name of the column defined with the SDO_GEOMETRY data type Number of axes (dimensions) for the SDO_GEOMETRY column Lower and upper bounds for each axis Tolerance value for each axis, generally the same value for all axes Spatial reference identifier (SRID) The lower and upper bound of each axis is not necessarily the minimum bounding rectangle (MBR) of the data in the SDO_GEOMETRY column. Oracle Spatial Concepts / 7

USER_SDO_GEOM_METADATA SQL> DESCRIBE USER_SDO_GEOM_METADATA Name Null? Type -------------- ---------- ------------------ TABLE_NAME NOT NULL VARCHAR2(32) COLUMN_NAME NOT NULL VARCHAR2(32) DIMINFO MDSYS.SDO_DIM_ARRAY SRID NUMBER MDSYS.SDO_DIM_ARRAY VARRAY(4) OF SDO_DIM_ELEMENT MDSYS.SDO_DIM_ELEMENT object SDO_DIMNAME VARCHAR2(64) SDO_LB NUMBER SDO_UB NUMBER SDO_TOLERANCE NUMBER The axes bounds should be values that contain all current and future geometries. The first axis defined must always be x, and the second axis y. Optional z and measure axes can also be defined. When dealing with geodetic data (data that is longitude/latitude), the first axis must be defined within a (-80, 80) range, and the second axis within (-90,90). Tolerance is generally the same for all axes. Tolerance is the distance two coordinates must be apart to be considered unique. Oracle s geometry validation routines, spatial operators, and spatial functions all use tolerance. It is very important to define a tolerance that reflects the true resolution at which your data was collected. When storing data that is not longitude/latitude, the tolerance unit is the same as the coordinate system unit associated with the spatial data. When storing longitude/latitude (geodetic) data, the tolerance unit is meters. All coordinate systems supported by Oracle Spatial and Oracle Locator are defined in a dictionary table called MDSYS.CS_SRS. Custom coordinate systems can also be added to the MDSYS.CS_SRS dictionary, and the process is described in the Oracle Spatial Users Guide and Reference. In the MDSYS.CS_SRS dictionary, a numeric primary key called the SRID identifies each supported coordinate system. The dictionary table also contains the definition of each coordinate system in the well_known_text (WKT) grammar defined by the Open GIS Consortium (OGC). Associating spatial data with a coordinate system is as simple as associating the spatial data with an SRID value. Oracle Spatial Concepts / 8

Associating spatial data with an SRID is recommended, especially if your data is geographic, that is, related to the Earth. Geographic data can be divided into two categories, geodetic (longitude/latitude data), and projected (non-longitude/latitude data). Oracle considers Great Circle distances between consecutive coordinates of geometries defined with a geodetic SRID. When associating an SRID with an SDO_GEOMETRY column, it must be specified in the USER_SDO_GEOM_METADATA entry, and also in the SDO_SRID attribute of each SDO_GEOMETRY object loaded. Data Loading Data Validation Bulk loads can be accomplished with traditional Oracle utilities, such as SQL*Loader and Import. Bulk unloading can be accomplished with Oracle s Export utility. These utilities require no spatial specific syntax. As recommended with non-spatial data, if you are performing a large bulk load, it is recommended to drop indexes (including spatial indexes if they exist), perform the load, and recreate indexes after the load completes. If indexes are not dropped prior to a bulk load, they are maintained as the load occurs. This can slow the load process considerably. SQL*Loader can load spatial data, but it does not understand Geographic Information System (GIS) vendor exchange formats, such as ESRI shapefiles, MapInfo Tab files, Autodesk DWG files, or Microstation DGN files. Each major GIS vendor has their own tool to export their exchange formats into Oracle s SDO_GEOMETRY format. See Exporting Spatial Data to Oracle on page 50. Spatial data must be valid to ensure correct results when you perform spatial analysis. If an SDO_GEOMETRY column is spatially indexed, Oracle will perform some validity checks when spatial data is inserted into the column. But complete validation only occurs by running either the SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT or SDO_GEOM.VALIDATE_LAYER_WITH_CONTEXT procedure. If data is guaranteed to be valid prior to data load, validation is not necessary. Otherwise, validation is highly recommended. Invalid geometries should either be corrected or deleted. SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT and SDO_GEOM.VALIDATE_LAYER_WITH_CONTEXT validate geometries in accordance with rules defined by the Open GIS Consortium (OGC) via the Simple Feature Specification for SQL. When invalid geometries are reported (for example, a self-intersecting polygon), additional context information, such as which edges intersected, is also reported. The additional context information is very useful in correcting invalid geometries. Some of the most common validation errors reported include: Oracle Spatial Concepts / 9

ORA 3356 Adjacent repeated points in geometry are redundant. Tolerance may be set too coarsely. Making tolerance finer may fix the error.points may truly be repeated. Remove duplicate vertices. ORA 3349 Polygon boundary crosses itself. Tolerance may be set too coarsely. Making the tolerance finer may fix the error. Polygon truly self intersects. Fix the polygon by ensuring that no edges intersect. ORA 3367 Wrong rotation for interior/exterior rings. Correct the rotation of the polygon ring. Outer rings should be counterclockwise, inner rings clockwise. The additional context information reported by the validation routines can be supplied to the following routines to help fix invalid geometries: SDO_UTIL.REMOVE_DUPLICATE_VERTICIES SDO_UTIL.EXTRACT Indexing Spatial Data R-Tree spatial indexes, introduced in Oracle 8..7, require no tuning, and are recommended in almost all scenarios. Oracle9i introduced a geodetic R-tree index, which takes into account Great Circle distances, and also geometries that span the poles and the 80 meridian. Oracle9i Release 2 introduced some parallelization when creating R-tree spatial indexes, and also performance enhancements. Oracle Database 0g includes more R-tree performance enhancements, concurrent DML enhancements, and more parallelization. Specifying the LAYER_GTYPE parameter in the CREATE INDEX statement will: Help maintain spatial integrity, by only allowing a certain class of spatial features to be inserted in to the SDO_GEOMETRY column. For example, specifying LAYER_GTYPE=POINT at index creation will allow only point data to be inserted into the column. Help query performance. Spatial queries optimizations will be invoked if the class of spatial data for the column is specified at index creation. Oracle Spatial Concepts / 20

R-tree Indexing Concept R-tree Index MBR Geometry Leaf nodes of R-tree store <MBR, geometry pointer> Application Considerations If visualization is a key component of your application, this section may be very relevant. When the display is zoomed out very far, it is not good practice to turn on very detailed layers. For example, if the display is zoomed out to show the entire United States, turning on detailed streets does not add value to the display. Detailed streets at that zoom level would appear as a solid blob on the screen. It is much more realistic to turn on detailed streets when the display is zoomed in to a one kilometer area east to west. Consider a layer with very detailed polygon regions (about 3000 vertices in each polygon). When zoomed out very far, it does not make sense to display these very detailed polygons. The detail of the polygons is lost because the many coordinates in these polygons are being forced to render onto just a few pixels. A more realistic scenario would be to use zoom control to only turn on the detailed polygons when you are reasonably zoomed in. Another realistic approach is to create a generalized layer (generalized version of the detailed polygons). The generalized layer is displayed when zoomed out very far, and the detailed layer is displayed when you are zoomed closer in. Zoom control and the use of generalized layers are very well known concepts for display applications. Correct usage of zoom control and generalized layers will provide much better performance. Unnecessary fetches of detailed geometries from the server can be avoided, especially since most of the coordinates of the detailed geometries will render on just a few pixels. Oracle Spatial Concepts / 2

Topological Data Model Topology elements The basic topology elements in an Oracle topology are its nodes, edges and faces. These elements are all two-dimensional. A node is represented by a point and can be used to model an isolated point feature or to bound edges. Every node has a coordinate pair associated with it to describe the spatial location of the node. An edge is bounded by a start and end node and has a coordinate string associated that describes the spatial representation. Each edge can consist of multiple vertices, represented by linear as well as circular arc strings. As each edge is directed, it is possible to determine which faces are located at the left and right hand side of the edge. A face is represented by a polygon (that can be reconstructed from the several edge strings) and has references to a directed edge on its outer and (if any) inner boundaries. Each topology has a universal face that contains all other nodes, edges and faces in the topology. Nodes, edges and faces are the building blocks by which every real world object can be constructed. These real world objects are modeled as features or topo_geometries. Each topo_geometry is stored as a set of topological elements, e.g. a parcel can consist of several faces. Oracle distinguishes five different topo_geometry types: points, line strings, (multi) polygons and (combining the four previous topology geometry types) a heterogeneous collection. Each topo_geometry has a reference to its topo_geometry layer. These layers consist of collections of topo_geometries of a specific type, for instance 'parcels' or 'roads'. Oracle automatically assigns unique IDs to topo_geometries and topo_geometry layers. It is possible to define a hierarchy in topology geometry layers. This hierarchy indicates that a topo_geometry of the type of the topmost hierarchy level consists of topo_geometries at the next level down and so on. On a cadastral data set this could be used to model the relationship between a cadastral municipality, cadastral sections, cadastral sheets and parcel numbers. Figure above shows relationship between topology geometries and nodes, edges and faces. Topological Data Model / 22

Topology related tables In order to be able to work with the collection of tables, the DBMS creates some extra tables. The relationship table is already mentioned as it stores the relationship between topology geometries at the one side and the nodes, edges en faces on the other side. Another automatically generated table is the history table, which holds track of all changes to the topology over time. The metadata tables store the properties of the tables, as well as references to all indexes. The initialize metadata procedure creates these indexes on the topology tables. Display Metadata Styles IEE applies specific styles (such as colors and patterns) to specific themes (that is, collections of spatial features, such as cities, rivers, and highways) to render a map (such as a GIF image for display on a Web page). For example, the application might display a map in which state parks appear in green and restaurants are marked by red stars. A map typically has several themes representing political or physical entities, or both. For example, a map might show national and state boundaries, cities, mountain ranges, rivers, and historic sites. When the map is rendered, each theme represents a layer in the complete image. The Oracle Map Definition Tool lets you define styles, themes, and base maps, including the rules for applying one or more styles to each theme. These styles, themes, base maps, and associated rules are stored in the database in map definition tables under the MDSYS schema, and they are visible to you through metadata views. Access to styles belonging to other users is determined by the database privileges granted. The mapping metadata (the set of styles, themes, and base maps) that a user can access is stored in metadata views that are automatically defined when a user is created. These views are described in Metadata Views on page 28 (for example, USER_SDO_STYLES, USER_SDO_THEMES, and USER_SDO_MAPS). The set of map definition objects that a given user can access is sometimes called that user s mapping profile. You can manage styles, themes, and base maps with the Oracle Map Definition Tool (described in the Oracle Map Definition Tool User's Guide). A style is a visual attribute that can be used to represent a spatial feature. The basic map symbols and labels for representing point, line, and area features are defined and stored as individual styles. Each style has a unique name and defines one or more graphical elements using XML syntax. Each style is of one of the following types: Color: a color for the fill or the stroke (border), or both. Display Metadata / 23

Marker: a shape with a specified fill and stroke color, or an image. Markers are often icons for representing point features, such as airports, ski resorts, and historical attractions. When a marker style is specified for a line feature, the rendering engine selects a suitable point on the line and applies the marker style (for example, a shield marker for a U.S. interstate highway) to that point. Line: a line style (width, color, end style, join style) and optionally a centerline, edges, and hash mark. Lines are often used for linear features such as highways, rivers, pipelines, and electrical transmission lines. Area: a color or texture, and optionally a stroke color. Areas are often used for polygonal features such as counties and census tracts. Text: a font specification (size and family) and optionally highlighting (bold, italic) and a foreground color. Text is often used for annotation and labeling (such as names of cities and rivers). The primary advanced style is BucketStyle, which defines the relationship between a set of simple styles and a set of buckets. For each feature to be plotted, a designated value from that feature is used to determine which bucket it falls into, and then the style associated with that bucket is used to plot the feature. The AdvancedStyle class is extended by BucketStyle, which is in turn extended by ColorSchemeStyle and VariableMarkerStyle. (Additional advanced styles, such as for charts, are planned for a future release.) Table 4 below lists the Java class for creating style of each type. Table 4: Style Type Java Classes Style Type Java Class Geometry Types Color oracle.sdovis.style.stylecolor (any type) Marker oracle.sdovis.style.stylemarker point, line Line oracle.sdovis.style.styleline line Area oracle.sdovis.style.stylearea polygon Text oracle.sdovis.style.styletext (any type) Advanced oracle.sdovis.stylex.advanced and extension (any type) All styles for a database user are stored in that user s USER_SDO_STYLES view, which is described in Metadata Views on page 28. Display Metadata / 24

Themes Styling Rules in Predefined Themes A theme is a visual representation of a particular data layer. Each theme (except for image themes) is associated with a specific spatial geometry layer, that is, with a column of type MDSYS.SDO_GEOMETRY in a table or view. For example, a theme named US_States might be associated with the STATE_SHAPE spatial geometry column in a STATES table. A theme can have its definition, including styling rules, stored permanently in the database (a predefined theme), or a theme can be dynamically defined with a map request (a JDBC theme). All predefined themes for a database user are stored in that user s USER_SDO_THEMES view, which is described in Metadata Views on page 28. Each predefined theme is associated with one or more styling rules. The styling rules for each predefined theme are expressed using XML, such as in Example for an Airport theme. The following naming conventions are used for "prefixes" in style names in the examples in this chapter: v. indicates variable (advanced style), m. indicates marker, c. indicates color, l. indicates line, and t. indicates text. In the content (character data) of an XML document, < and > must be used to represent < and >, respectively. Otherwise, < or >, such as in WHERE CATEGORY > B, will be interpreted by the XML parser as part of an XML tag. Example : Example of XML Definition of Styling Rules for an Airport Theme <?xml version=".0" standalone="yes"?> <styling_rules> <rule> <features style="c.black gray"> runway_number > </features> <label column="name" style="t.airport name"> </label> </rule> <rule> <features style="m.airplane"> runway_number = </features> </rule> </styling_rules> Each styling rule has a required <features> element and an optional <label> element. The <features> element specifies which rows (features) in the table or view will be selected based on its attribute value and the style to be used for those selected features. The <label> element specifies whether or not to annotate the selected feature, and if so, which column in the table or view to use for text labels. In the Styling Rules example, there are two styling rules associated with the Airport theme. Display Metadata / 25

The first rule specifies that only those rows that satisfy the condition runway_number > (that is, runway number greater than ) will be selected, and these will be rendered using the style named c.black gray. Any valid SQL WHERE clause conditions can be used as the value of a <features> element. If no value is supplied, no WHERE clause condition is applied. For example, assume that the definition had been the following (that is, omitting the runway_number > condition): <?xml version=".0" standalone="yes"?> <styling_rules> <rule> <features style="c.black gray"/> <label column="name" style="t.airport name"> </label> </rule> </styling_rules> In this case, all airport features would be selected and would be rendered using the color style named c.black gray. The first rule also has a <label> element, which specifies that the NAME column in the table or view will be used to annotate each airport, using the text style t.airport name. The value of the <label> element, which can be any SQL expression, is used to determine whether or not a feature will be annotated. If the value is greater than zero, the feature will be annotated. In this case, because the value is the constant, all features specified by the <features> element will be annotated, using the values in the NAME column. If the value is less than or equal to zero for a feature, that feature will not be annotated. The second rule, which applies to those airports with only one runway, does not have a <label> element, thus, preventing all such airports from being annotated. In addition, the features that satisfy the second rule will be rendered using a different style (m.airplane), as specified in its <features> element. If two or more rules are specified, a UNION ALL operation is performed on the SQL queries for the rules (from first to last) to fetch the qualified features from the table or view. If an advanced style is specified in a rule, the SELECT list of the query to fetch qualified features contains the spatial column, the attribute column or columns, the name of the feature style, the label information, the WHERE clause, and the feature query. Based on the value of the attribute column or columns and the definition of the specified feature style, each feature is associated with a style. Maps A map can consist of a combination of elements and attributes, such as the following: Background image Title Legend Display Metadata / 26

Query window Footnote (such as for a copyright notice) Base map Themes (in addition to any in the base map) JDBC queries JDBC image queries These elements and attributes, when specified in a map request, define the content and appearance of the generated map. A map can have a base map and a stack of themes rendered on top of each other in a window. A map has an associated coordinate system that all themes in the map must share. For example, if the map coordinate system is 8307 (for Longitude / Latitude [WGS 84], the most common system used for GPS devices), all themes in the map must have geometries defined using that coordinate system. You can add themes to a map by specifying a base map name or by using the programming interface to add themes. The order in which the themes are added determines the order in which they are rendered, with the last specified theme on top, so be sure you know which themes you want in the background and foreground. All base map names and definitions for a database user are stored in that user s USER_SDO_MAPS view, which is described in Metadata Views on page 28. The DEFINITION column in the USER_SDO_MAPS view contains an XML description of a base map. Example of XML Definition of a Base Map <?xml version=".0"?> <map_definition> <theme name="theme_us_states" min_scale="0" max_scale="0" /> <theme name="theme_us_parks" min_scale="5" max_scale="0" /> <theme name="theme_us_highways" min_scale="5" max_scale="0" /> <theme name="theme_us_streets" min_scale="0.05" max_scale="0" /> </map_definition> Each theme in a base map can be associated with a visible scale range within which it is displayed. In the example above, the theme named theme_us_streets is not displayed unless the map request is for a map scale of 0.05 or less and greater than 0 (in this case, a scale showing a great deal of detail). If the min_scale and max_scale attributes are not specified, the theme is displayed whenever the base map is displayed. The display order of themes in a base map is the same as their order in the base map definition. In the previous example the theme_us_states theme is rendered first, then theme_us_parks, then theme_us_highways, and finally (if the map scale is within all specified ranges) theme_us_streets. Display Metadata / 27

Metadata Views The mapping metadata describing base maps, themes, and styles is stored in the global tables SDO_MAPS_TABLE, SDO_THEMES_TABLE, and SDO_STYLES_TABLE, which are owned by MDSYS. However, you should never directly update these tables. Each user has the following views available in the schema associated with that user: USER_SDO_MAPS and ALL_SDO_MAPS contain information about base maps. USER_SDO_THEMES and ALL_SDO_THEMES contain information about themes. USER_SDO_STYLES and ALL_SDO_STYLES contain information about styles. You are encouraged to use the Oracle Map Definition Tool (described in the Oracle Map Definition Tool User's Guide) to manage the mapping metadata. Only advanced users should consider using SQL statements to update the metadata views. The USER_SDO_xxx views contain metadata information about mapping elements (styles, themes, base maps) owned by the user (schema), and the ALL_SDO_xxx views contain metadata information about mapping elements on which the user has SELECT permission. The ALL_SDO_xxx views include an OWNER column that identifies the schema of the owner of the object. The USER_SDO_xxx views do not include an OWNER column. All styles defined in the database can be referenced by any user to define that user s themes, markers with a text style, or advanced styles. However, themes and base maps are not shared among users; so, for example, you cannot reference another user s themes in a base map that you create. The following rules apply for accessing the mapping metadata: If you need to add, delete, or modify any metadata, you must perform the operations using the USER_SDO_xxx views. The ALL_SDO_xxx views are automatically updated to reflect any changes that you make to USER_SDO_xxx views. If you need only read access to the metadata for all styles, you should use the ALL_SDO_STYLES view. Both the OWNER and NAME columns make up the primary key; therefore, when you specify a style, be sure to include both the OWNER and NAME. Metadata Views / 28

Tutorial Getting Connected IEE Startup To initiate an IMAGINE Enterprise Editor session, follow the steps below. Select File -> New from the Viewer Menu. Then choose the IEE Layer option. Figure 2: IEE Startup The Enterprise Editor connection selector dialog opens. Figure 3: Connection Selector Select Connect to Oracle to open the Connect to Oracle Database dialog. Getting Connected / 29

Connection Dialog Connection information must then be given to allow a connection to an Oracle instance to be established. Figure 4: Connection Dialog The following information must be supplied during the connect process: Server The name of the Oracle Database Server that you whish to connect to. SID The System Identifier. A unique name for an Oracle instance (ex. ORCL) Port The number used by the Oracle Listener (default 52) Username The name of the Oracle Schema that has the spatial data. Password The final piece of connection information is the password for the Username (Schema) that was entered. Figure 5: Password Panel Getting Connected / 30

Map Selection This dialog lists all maps defined for the current data source. You must select from the list of maps to continue the connection process. Figure 6: Map Selection Panel To modify or add to the list of available maps use the Oracle Map Definition Tool. Discover Options The Discover Options Panel provides a navigation work flow to help in the location and investigation of spatial data within the current database connection. Figure 7: Discover Options Panel Getting Connected / 3

Choose a Theme from the <Theme List>. The values that are then displayed represent the center X and Y position and size of the MBR for the entire theme. To use these values press the Next> button or: - Press the Calc. Extent button to calculate the MBR (minimum bounding rectangle) for the currently selected theme and populate the XPos, YPos and Map Size with the resulting values. - Press the Search button to open the Search and Locate panel and enter search criteria to locate specific objects in the currently selected theme. - Type in values to the Xpos, Ypos and Map Size fields. - Press Prev. XYS to set the values for XPos, YPos and Map Size to the last values used. - Press View to set the Xpos, YPos and Map Size to the current view window. After the appropriate choice has been made press the Next> button to initiates the extraction of data from the database using the XPos, YPos and Map Size values. It it important that the metadata that defines each layer of data be as close as possible to the MBR representing the limits of the data and not set to the entire world for example (-80,80,90,90). Search and Locate The Search and Locate panel provides a means to search for and locate a feature based on search criteria. The search criteria can comprise any combination of columns in the underlying table of the active theme. The active theme is indicated in the title bar. The search criteria can use any one of a number of operators and any value to search against. Each search criteria row is separated by a Boolean AND or OR operator. Getting Connected / 32

Figure 8: Search and Locate Panel Press the Add button to add a search record to the Search Criteria list and then: - Double-click on the Column field and select the column name from the list of available values. - Double-click on the Operator field and select the type of operator to apply. - Double-click on the Value field and then type in the value to apply. - Click the Next field and choose AND or OR if you are going to add an additional search record. - Press the Search button to query the database and return the results. - Choose a record from the populated Results list by clicking on the record. - Press the Locate button to compute the MBR of the selected geometry and pass the results to the XPos, YPos and Map Size fields on the Discover Options panel. Getting Connected / 33

Once the Locate button is pressed the Discovery process is complete and the IEE layer will display the vector data in the IEE Layer of the IMAGINE Viewer. IEE Interface The IEE Menu provides access to administrative functions as well as for all menus that control digitizing and interface settings. Figure 9: IEE Menu Please see the IMAGINE Enterprise Editor on-line help for more information about the user interface. IEE Interface / 34

Transaction Management Commands Understanding IEE Settings Snapping Data Locking Release Locks on Exit Some of the commands in the IEE menu provide functionality that impacts the list of transactions that are sent to the database. These commands are Undo - IEE will undo a performed operation each time this button is clicked. It can undo all operations that were performed after the last successful commit, or since the user started using the application. Undo All - Pressing this command will undo all operations hat were performed after the last successful commit, or since the user started using the application. Redo - Pressing this command will redo a previously undone operation each time this button is clicked. It can redo all operations that were performed after the last successful commit, or since the user started using the application. Save Settings - Pressing this command will save the current IEE environment settings locally. These settings will be used very time the user starts IEE until the settings are saved again. To take full advantage of the functionality provided by IEE and to ensure that all edits made using the IEE environment, users should familiarize themselves with the following concepts before making changes in the IEE Settings Dialog. When digitizing IEE will automatically snap to nodes or vertices. The IEE Snapping Engine allows this. The snapping engine is always activated. Therefore, new linear features will always be snapped to a node or a vertex within the snapping tolerance. The Snapping Settings section in the IEE Settings dialog gives control over whether to display nodes or vertices to which IEE will snap, and what color they should appear. IEE can also set the diameter of these nodes or vertices (end points and all points). This is the display diameter of the points and also the snapping diameter. IEE can implement pessimistic or optimistic locking. The default is pessimistic locking. When pessimistic locking is enabled, any area extracted will become locked and other users will not be able to edit that area. They will however, be able to view that area. When optimistic locking is enabled any area extracted is not locked and any user can edit the data in it. When the IEE layer is started and connected to an Enterprise Server or and Oracle database, a session is created. When an area of the map is extracted, this data becomes locked if pessimistic locking is enabled. When IEE is closed, the session for that connection is destroyed. If the Release Locks on Exit option has been deselected, the data you extracted remains locked and no one else can edit that data when IEE is closed. If the Release Locks on Exit option is selected, the lock on the extracted data is released when the session ends and others can then edit the data. Transaction Management Commands / 35

It is recommended that the Release Locks on Exit option be selected if pessimistic locking is enabled. Grid Draw Handles IEE Tolerance A grid consists of evenly spaced points. This can be useful for digitizing schematic maps where accurate and consistent placement of features is necessary. Grid Settings are made up of two grid types: Grid Major and Grid Minor. The Grid Major field defines the distance in real world coordinates between points on the grid. The Grid Minor field defines the number of grid points between each Grid Major point. Draw Handles can be useful when selecting placed features. Draw handles appear as small boxes at every node of a selected feature. It helps to identify the line selected. Every table that stores simple geometry, feature, or topology primitive data requires an entry in the Oracle Spatial metadata table, USER_SDO_GEOM_METADATA. Among others, this table defines the tolerance value for each axis. The tolerance is usually the same for the x and y axes. Tolerance defines the minimum distance two coordinates must be apart to be considered unique. When using geodetic data (longitude/latitude) the tolerance unit is meters. When using data that is non-longitude/latitude, the tolerance unit is the same as the coordinate system unit associated with the spatial data. IEE Settings Dialog Locking & Grid Settings This dialog provides access to the IEE Settings. It opens when you click the IEE Settings option in IEE menu. Figure 0: Locking & Grid Settings Tab IEE Settings Dialog / 36

Lock Mechanism Settings: Use Pessimistic Locking - When this checkbox is selected, pessimistic locking is implemented in the database during data extraction. De-selecting this option implements optimistic locking. Release Locks on Exit - When this checkbox is selected, all locks held by IEE will be released when you close IEE. Process Settings: Display Progress Bar - When this checkbox is selected, a progress bar will display during the extraction of data from the database and when saving data to the database. Grid Settings: Grid Major A value greater than 0.0 entered in this field defines the distance in real world coordinates between points on the grid in the X or horizontal dimension. Default is 0.0 or no grid. Grid Minor A value greater than 0.0 entered in this field defines the distance in real world coordinates between points on the grid in the Y or vertical dimension. Default is 0.0 or no grid. Snapping Settings Figure : Snapping Settings Tab The Snapping engine is always enabled. Units: Distance - Selecting this option defines the units of the Diameter field to be measured in real world units, defined by the coordinate system currently in use. Pixels - Selecting this option defines the units of the Diameter field to be measured in on-screen pixels. IEE Settings Dialog / 37

The Distance and Pixels options are mutually exclusive, that is, only one of them can be selected at any one time. Max Visible Scale: - The value entered in this text field defines the scale below which the End Points and All Points will be displayed, if selected for display. If this value is set to zero, End Points and All Points will be displayed at all scales, if selected for display. End Points: Visible - Selecting this option displays a circle at the start and end nodes of a line.the color of the circle is determined by the value selected in the Color drop down list. The diameter of the circle is determined by the value in the Diameter field. Deselecting this option hides the circle at the start and end nodes. The Diameter field is measured in either real world distance or on-screen pixels. It is converted to real world coordinates when snapping occurs. The value in the Diameter field also determines the snapping tolerance. A color selection box shows the current color selected for end points. Click the icon to the left of the color box to choose another color. Diameter Determines the diameter of the end point circle displayed. The Diameter field is measured in either real world distance or on-screen pixels depending on the setting in the Units section. Vertex Points: Visible - Selecting this option displays a circle at all vertices of a line.the color of the circle is determined by the value selected in the Color drop down list. The diameter of the circle is determined by the value in the Diameter field. Deselecting this option hides the circle at the nodes. The Diameter field is measured in either real world distance or on-screen pixels. It is converted to real world coordinates when snapping occurs. The value in the Diameter field also determines the snapping tolerance A color selection box shows the current color selected for vertex points. Click the icon to the left of the color box to choose another color. Diameter Determines the diameter of the vertex point circle displayed. The Diameter field is measured in either real world distance or on-screen pixels depending on the setting in the Units section. IEE Settings Dialog / 38

Topology and Display Settings Figure 2: Topology and Display Tab IEE Tolerancing: Precision - Determines the precision of all edits performed using IEE. Enter the value of the new precision in the field. Topology: Allow ISO Moves - When this option is checked, IEE will allow the modification of topology edges affecting the topology face that any isolated nodes or edges fall in. When this option is not checked (default), IEE will apply normal Oracle topology rules when modifying topology edges. IEE will then return an exception if an edge is modified that changes the face in which an isolated node or isolated edge fall in. Display Settings: Hilite Color - Shows the current color selected for the Hilite Color. Draw Handles (Selection) - When this option is checked, draw handles are displayed. To hide draw handles upon a select operation de-select the Draw Handles option Display Bounding Boxes - When this option is checked, red lines will display representing each layers minimum bounding rectangle or MBR. IEE Settings Dialog / 39

IEE Locks Figure 3: IEE Locks Understanding IEE Digitizing Locks Dissolve Polygon Lock Segmentation Lock To take full advantage of the functionality provided by IEE and to ensure that all edits made using the IEE environment, you should familiarize yourself with the following concepts before making changes in the IEE Digitizing Locks Panel. Key concepts that need to be understood to use the IEE digitizing locks effectively are outlined below. When digitizing areas, one area may be digitized inside another area. When this happens, one might want to punch a hole in the outer polygon. This means the ordinates of the outer polygon will be changed to allow for the existence of an inner polygon. The ordinates of the inner polygon will be added to the ordinate list of the outer polygon, thus punching a hole in the geometry of the outer polygon. The inner polygon geometry will be created separately. For example, a lake is being digitized and the lake is to be associated with the park in which it is located. In this case, use the Dissolve Polygon lock to state the preference for associating the geometry of the lake with the geometry of the park. When digitizing one may want to activate the IEE Segmentation Engine. This engine gives you greater control when digitizing linear features, especially topological edges. When digitizing a new linear feature certain topological rules can be implemented. These include: - Create new nodes where the line intersects existing edges or faces, splitting the existing edge or face, and creating the new line. - Force the start of the edge to end at an existing node delete trailing start dangle. - Force the end of the edge to end at an existing node delete trailing end dangle. - Allow the start of the edge to end at a new node do not remove trailing start dangle. IEE Locks / 40

- Allow the end of the edge to end at a new node do not remove trailing end dangle. - Simply allow the overlapping features and do not create new nodes or split existing edges or faces. Dangle Lock (Start) Dangle Lock (End) Rubber Band Lock Theme Lock Axis Lock Grid Lock Linear Snap Lock When digitizing linear features the IEE Segmentation Engine will force the start of a new linear geometry or edge to end at an existing node and delete the trailing start dangle. When unchecked will not remove trailing start dangle. When digitizing linear features the IEE Segmentation Engine will force the end of a new linear geometry or edge to end at an existing node and delete the trailing end dangle. When unchecked will not remove trailing end dangle. This lock can be useful for maintaining topology when you are modifying linear features. When digitizing IEE may move and end node that exists on an edge. If this end node is also an end node on an attached edge, IEE will want to maintain the connection between the two edges. Rubber banding allows this. When rubber banding is selected, the attached edge is also moved when you move an end node and thus ensures that the current topology is not violated. When this lock is enabled, only objects in the theme currently being modified are affected. When this checkbox is not selected all objects that intersect or fall within edit tolerance of the object that is being modified will be affected as well. When digitizing, IEE may need to draw a line along the x (horizontal) or y (vertical) axis. The axis lock allows this. IEE can define a grid to be displayed in the map view. This grid can be particularly useful when digitizing network data as it defines a set distance between each grid point. When grid lock is enabled, each mouse click will be forced to snap to the nearest grid point. When digitizing a new linear feature and this lock is enabled, the linear feature is automatically snapped to nodes of an existing feature. In this way, can ensure that each node on your new line will snap to a node on an existing line, thus maintaining topology. IEE Locks / 4

Theme Control This panel allows the user to choose which themes/layers they wish to have display and edit control over. Figure 4: Theme Control Panel Display Themes This allows the user to switch on and off for display the themes listed by selecting or deselecting the options. Themes on the client can only be switched on/off on the fly if they are in the edit themes list. Switching on/off the display of background themes warrants a round trip to the server. Edit Themes This allows the user to switch on and off for editing the themes listed by selecting or deselecting the options. A change in the edit warrants a round trip to the server for a new extract list. If a user has a theme selected for edit and not for display, the data for that theme will still be retrieved from the database when the extract button is clicked. Theme Control / 42