GeoMedia SQL Server Spatial User Guide_06.01.00

GeoMedia SQL Server Spatial User Guide

6.1.0

May 2012

Copyright

Copyright 2012 Intergraph Corporation. All Rights Reserved.

Including software, file formats, and audiovisual displays; may be used pursuant to applicable software license agreement; contains

confidential and proprietary information of Intergraph and/or third parties which is protected by copyright law, trade secret law, and

international treaty, and may not be provided or otherwise made available without proper authorization from Intergraph Corporation.

U.S. Government Restricted Rights Legend

Use, duplication, or disclosure by the government is subject to restrictions as set forth below. For civilian agencies: This was developed at

private expense and is "restricted computer software" submitted with restricted rights in accordance with subparagraphs (a) through (d) of

the Commercial Computer Software - Restricted Rights clause at 52.227-19 of the Federal Acquisition Regulations ("FAR") and its successors,

and is unpublished and all rights are reserved under the copyright laws of the United States. For units of the Department of Defense

("DoD"): This is "commercial computer software" as defined at DFARS 252.227-7014 and the rights of the Government are as specified at

DFARS 227.7202-3.

Unpublished - rights reserved under the copyright laws of the United States.

Intergraph Corporation

P.O. Box 240000

Huntsville, AL 35813

Terms of Use

Use of this software product is subject to the End User License Agreement ("EULA") delivered with this software product unless the licensee

has a valid signed license for this software product with Intergraph Corporation. If the licensee has a valid signed license for this software

product with Intergraph Corporation, the valid signed license shall take precedence and govern the use of this software product. Subject to

the terms contained within the applicable license agreement, Intergraph Corporation gives licensee permission to print a reasonable

number of copies of the documentation as defined in the applicable license agreement and delivered with the software product for

licensee's internal, non-commercial use. The documentation may not be printed for resale or redistribution.

Warranties and Liabilities

All warranties given by Intergraph Corporation about equipment or software are set forth in the EULA provided with the software or

applicable license for the software product signed by Intergraph Corporation, and nothing stated in, or implied by, this document or its

contents shall be considered or deemed a modification or amendment of such warranties. Intergraph believes the information in this

publication is accurate as of its publication date.

The information and the software discussed in this document are subject to change without notice and are subject to applicable technical

product descriptions. Intergraph Corporation is not responsible for any error that may appear in this document.

The software discussed in this document is furnished under a license and may be used or copied only in accordance with the terms of this

license. No responsibility is assumed by Intergraph for the use or reliability of software on equipment that is not supplied by Intergraph or

its affiliated companies. THE USER OF THE SOFTWARE IS EXPECTED TO MAKE THE FINAL EVALUATION AS TO THE USEFULNESS OF THE

SOFTWARE IN HIS OWN ENVIRONMENT.

Intergraph is not responsible for the accuracy of delivered data including, but not limited to, catalog, reference and symbol data. Users

should verify for themselves that the data is accurate and suitable for their project work.

Trademarks

Intergraph, the Intergraph logo, and GeoMedia are registered trademarks of Intergraph Corporation. Microsoft and Windows are registered

trademarks of Microsoft Corporation. Bing is a trademark of Microsoft Corporation. Google Maps is a trademark of Google Incorporated.

Pictometry Intelligent Images is a registered trademark of Pictometry International Corporation.

Other brands and product names are trademarks of their respective owners.

GeoMedia SQL Server Spatial User Guide 3

Contents Introduction .................................................................................................................................................. 5

Delivery and Connection ............................................................................................................................ 5

Prerequisites ........................................................................................................................................... 5 Connections ............................................................................................................................................ 5 Password Persistence ............................................................................................................................ 6 Permissions ............................................................................................................................................. 6 SQL Server Warehouse Requirements .................................................................................................. 7

Data Storage and Type Matching ............................................................................................................... 9

Geometry Storage ................................................................................................................................... 9 GeoMedia's Binary Geometry to Native Geometry Type Matching ...................................................... 11 SQL Server to GeoMedia Data Type Matching .................................................................................... 14 GeoMedia to SQL Server Data Type Matching .................................................................................... 15

GeoMedia Metadata Requirements .......................................................................................................... 16

Scalar Functions ................................................................................................................................... 17 AttributeProperties Table ...................................................................................................................... 18 FieldLookup Table ................................................................................................................................ 19 GAliasTable ........................................................................................................................................... 19 GCoordSystem Table ........................................................................................................................... 20 GeometryProperties Table .................................................................................................................... 21 GFeatures Table ................................................................................................................................... 22 GFieldMapping Table ............................................................................................................................ 23 GIndexColumns Table .......................................................................................................................... 24 GParameters Table ............................................................................................................................... 25 GPickLists Table ................................................................................................................................... 27 GQueue Table....................................................................................................................................... 29 ModifiedTables ...................................................................................................................................... 29 ModificationLog Table ........................................................................................................................... 29 Data Server Required Triggers in SQL Server Spatial ......................................................................... 34 SQL Server Spatial Indexing ................................................................................................................. 35

Working with SQL Server Spatial ............................................................................................................ 37

Using Existing Native Spatial Data ....................................................................................................... 38 Importing Spatial Data .......................................................................................................................... 39 Existing Standard SQL Server Data ..................................................................................................... 40 Feature Class Definition ........................................................................................................................ 40 Undo/Redo ............................................................................................................................................ 41 Default Values ....................................................................................................................................... 41 Spatial Filtering ..................................................................................................................................... 41 Views and Join Views ........................................................................................................................... 42

Contents

4 GeoMedia SQL Server Spatial User Guide

Database Utilities ....................................................................................................................................... 43

Exporting to SQL Server ........................................................................................................................... 45

Technical Support and Information ......................................................................................................... 49

Self-Help Support Tools ........................................................................................................................ 49 Phone Numbers .................................................................................................................................... 49 Other Links ............................................................................................................................................ 51

Index ........................................................................................................................................................... 53


S E C T I O N 1

The SQL Server Spatial data server is an add-on component for GeoMedia Professional that

makes it easier to connect to Microsofts Sequel Server (SQL Server 2008 or later) databases

that use native spatial geometry storage. This allows GeoMedia applications to use native

SQL Server Spatial databases as geospatial warehouses. Once installed, the data server is

accessed through GeoMedia Professional's Warehouse > New Connection command.

Prerequisites SQL Server connections do not require client software. The SQL Server Spatial data server will

be installed whether SQL Server is present or not. Connections can be made to SQL Server

installations that are configured as case-sensitive or case-insensitive. Both Windows

authentication and SQL Server authentication are supported for user accounts. A SQL Server

database must already exist and must have the required metadata tables before a SQL Server

connection can be made. The data server has full read-write capability, but the ability to

access and edit database objects is controlled by the privileges on the login account used for

the database connection.

Connections GeoMedia applications require specific metadata tables to exist in the SQL Server database

before a connection can be made. This metadata is created using GeoMedia Professional's

Database Utilities or during the bulk import of data from GeoMedia Professionals Export to

SQL Server command. The metadata used by the SQL Server spatial data server is different

from the metadata used by the standard SQL Server data server, and they cannot be used

interchangeably.

See the GeoMedia Metadata Requirements section of this document for a list of the required

tables.

To make a connection to SQL Server, provide a valid server name, and then a valid username

and password. Any databases the specified user has privilege to see will appear in the

Introduction

Delivery and Connection



drop-down database list. SQL Server has two modes for validating users: Windows domain

authentication and SQL Server authentication.

If the SQL Server connection is set to use Windows authentication (the default), your domain

login account will need to be added to SQL Server by a database administrator and appropriate

privileges will need to be granted on the databases you want to access. On connection, you

will only need to supply the server name and the database name.

If you are using SQL Server authentication, you will need to have a valid SQL Server user

account and password as well as the appropriate privileges on the database you want to

connect to.

Password Persistence When using SQL Server authentication, GeoMedia stores the SQL Server connection password

in the GeoWorkspace. This is meant as a convenience and allows users to open existing

GeoWorkspaces containing SQL Server connections without having to re-enter connection

passwords. However, this is a drawback to those users wanting higher levels of security. If

you do not want the passwords to be persisted in the GeoWorkspace, you must use domain

authentication. Domain authenticated connections do not store any user or password

information in the GeoWorkspace and have the added benefit of not prompting you to

re-enter passwords.

Permissions In SQL Server warehouses, access to database objects is controlled by the objects owner

through the use of permissions. GeoMedia requires all objects in your SQL Server database to

be in the DBO schema. Objects that are not owned by DBO will not be accessible or visible in

GeoMedia except by the user who created them.

When creating database objects using GeoMedia Professionals Feature Class Definition

command, the user account must be assigned the db_owner role. For database objects

created outside of GeoMedia Professional, only a user account with the role db_owner will

ensure that the resulting objects are in the DBO schema.

SQL server users who need to be restricted to read-only access should be assigned the

db_datareader role, and users who need read-write access should be assigned the

db_datawriter role. All other specific SQL Server privileges are honored as long as the DBO

ownership criterion is met when creating database objects.



There are also four scalar functions that are required for any access to native spatial data

through GeoMedia. Execute privileges are required on these four functions for any user who

does not have the db_owner role. See the Scalar Functions section for more information.

SQL Server Warehouse Requirements Connections to SQL Server spatial warehouses have several restrictions and requirements that

must be adhered to. Violation of any of these requirements may lead to a connection failure

or the inability to load data from the connection. These connection requirements and

restrictions are listed below:

All geometries are stored in 3 dimensions; 2 dimensional geometries are not supported.

All non-system SQL Server database objects must be owned by DBO. Users who create

objects in the database must have the db_owner role.

Names of tables, views, indexes, and fields are always expressed in their defined cases.

The server will preserve the case of identifiers but will be case-insensitive on comparisons.

Comparisons on data values will be case-sensitive, so caution is advised when

identifier names are stored in the database.

A local SQL Server client is not required; however, client-side administrative tools are

required when importing data generated by the Export to SQL Server command. The

server drop-down list on the New Connection dialog box is only populated when SQL

Server agents are active.

Do not use SQL Servers TIMESTAMP data type. This data type is not related to date/time

functions and is not supported. A list of supported data types is presented in the SQL

Server to GeoMedia Data Type Matching section. Data types that do not appear in this

list are not supported and are generally ignored by the data server.

All DML operations (inserts, updates, and deletes) will require a clustered primary key.

Both multi-column and character-based primary keys are allowed but are not

recommended for insert operations as the user will need to manually enter the appropriate

key value. For the best results and the best performance, use an integer-based

auto-increment (identity) primary key column.

Views are editable as long as they are key preserved and have the appropriate metadata

entries in the GIndexColumns table. Any column in the view that is both unique and not

null can act as the pseudo primary key. Even when key preserved, DML operations on

join-views will require the use of instead of triggers.



GeoMedia metadata must be present before making a connection to the database. The

required metadata can be created using GeoMedia Professional's Database Utilities or

using the metadata script created by the Export to SQL Server command.

Metadata entries must exist for all tables and views for them to be visible in the GeoMedia

environment. Database Utilities can be used to make the metadata assignments.

Data Storage and Type Matching


Geometry Storage The SQL Server Spatial data server uses two storage columns: one column is used to store the

SQL Server's native spatial data types (GEOMETRY or GEOGRAPHY); the second one is a binary

column (varbinary(max)) storing the GDO (GeoMedia Data Object - GeoMedia's native binary

storage format) geometry blob used for unsupported geometries (for example, arcs, oriented

points, text, and raster).

The default native storage data type is GEOMETRY because most data is assumed to be

projected. The GEOGRAPHY data type is fully supported as well but will require the use of an

EPSG spatial reference system identifier (SRID). For geographic data, each feature must fit

inside a single hemisphere. Objects larger than a single hemisphere are not supported and

may throw an argument exception. Geographic spatial filter areas must also fit inside a single

hemisphere.

The default geometry type used by GeoMedia Professional's Feature Class Definition command

(or any other GeoMedia command that creates a table) is determined by the

TypeForNativeGeometryStorage parameter in the GParameters metadata.

The default spatial reference system identifier (SRID) is 0 because that is what SQL Server

expects for GEOMETRY data types. SQL Server does not store the EPSG SRID's for projected

data, and a NULL SRID is not allowed. For GEOGRAPHY data types, a valid SRID is required,

and it must be one of the EPSG SRIDs currently stored in SQL Server's

sys.spatial_reference_systems table. The default SRID used by GeoMedia Professional's

Feature Class Definition command (or any other GeoMedia command that creates a table) is

determined by the DefaultNativeGeometrySrid parameter in the GParameters metadata table.

Every native spatial geometry column must have a corresponding GeoMedia binary column.

If the table is created using Feature Class Definition, the following columns are present in the

base table for the feature:




Name Data Type Description

varbinary(MAX) The binary GDO geometry

column.



manually inserted for each table using Database Utilities before GeoMedia recognizes these as

feature classes.

The use of _SPA is just a naming convention used by GeoMedia applications; you do

not need to use this naming convention if you are creating or modifying tables outside of

GeoMedia applications, as long as the metadata reflects the association between the GDO

geometry and the native geometry column.

GeoMedia's Binary Geometry to Native Geometry Type Matching

To write geometric data to SQL Server, GeoMedias SQL Server Spatial data server converts

GeoMedia native GDO geometry format to SQL Server native spatial format using the

following:

GeoMedia Geometry Type SQL Server Geometry Type

GDO column content

Native column content

PointGeometry POINT (x y z) Exact point

OrientedPointGeometry POINT (x y z) Full GDO Exact point, no

orientation

TextPointGeometry POINT (x y z) Full GDO Point origin

LineGeometry LINESTRING(

x1 y1 z1,

x2 y2 z2)

Full GDO Two-point linestring

PolylineGeometry LINESTRING(

x1 y1 z1,

,

xN yN zN)

N-point linestring

ArcGeometry LINESTRING(

x1 y1 z1,

,

xN yN zN)

Full GDO Stroked N-point

linestring




GDO column content


CompositePolylineGeometry MULTILINESTRING(

(

x11 y11 z11,

,

xN1 yN1 zN1

),

,

(x1M y1M z1M,

,

xNM yNM zNM

))

Full GDO, even

when no member

is approximated,

in order to

recreate

composite.

Composite

members need to

be approximated

(like arcs) in a

multiline string;

otherwise, exact

multiline string.

PolygonGeometry POLYGON(

(

x1 y1 z1,

,

xN yN zN

))

Exact polygon

CompositePolygonGeometry MULTILINESTRING(

(

x11 y11 z11,

,

xN1 yN1 zN1

),

,

(x1M y1M z1M,

,

xNM yNM zNM

))

Full GDO, even

when no member

is approximated,

in order to

recreate

composite.

Composite

members need to

be approximated

(like arcs) in a closed

multiline string;

otherwise. exact

closed multiline

string.




GDO column content


BoundaryGeometry POLYGON(

(

x1_int y1_int z1_int,

,

xN_int yN_int zN_int

),

(

x11_ext y11_ext

z11_ext,

,

xN1_ext yN1_ext

zN1_ext)

),

,

(

x11M_ext y11M_ext

z11M_ext,

,

xN1M_ext yN1M_ext

zN1M_ext)

))

Full GDO if any of

the members

(exterior, interior)

cannot be

represented fully

by native type;

otherwise, this

column will be

null.

Composite

members need to

be approximated

(like arcs) in a

polygon string;

otherwise, exact

polygon string.

RasterGeometry POLYGON (

x1 y1 z1,

x2 y2 z2,

x3 y3 z3,

x4 y4 z4,

x1 y1 z1)

Full GDO Exact polygon of the

raster footprint.

GeometryCollection MULTPOINT for point Full GDO if any of

the members

A collection of exact

representations or




GDO column content


geometries,

MULTILINESTRING for

line geometries,

MULTIPOLYGON for

area geometries,

GEOMETRYCOLLECTIO

N when mixed

(exterior, interior)

cannot be

represented fully

by native type;

otherwise, this

column will be

NULL.

approximations,

according to the

rules established

above, for each GDO

collection member.

SQL Server to GeoMedia Data Type Matching To use data from SQL Server, GeoMedias SQL Server Spatial data server converts SQL Server

data types to GeoMedia data types. The following table shows how the SQL Server data

types are mapped to the GeoMedia types. Any SQL Server data types missing from this list

are considered unsupported and are ignored.

SQL Server Data Type GeoMedia Data Type

binary

varbinary

LongBinary

bit Boolean

char(size)

varchar(size)

nchar(size)

nvarchar(size)

ntext*

Text if size = 6 and p < 11

Double for all other cases.

float Double



SQL Server Data Type GeoMedia Data Type

binary

varbinary

LongBinary

int Long

money Currency

real Single

smallint Integer

tinyint Byte

uniqueidentifier GUID

GeoMedia to SQL Server Data Type Matching The following table identifies the mapping used when converting from GeoMedia data types to

SQL Server data types and whether specific metadata is required for the mapping:

GeoMedia Data Type SQL Server Data Type Metadata Required?

Boolean bit No

Byte tinyint No

Integer smallint Yes for autonumber

Long int No

Single real No

Double float No

Currency money No

Date datetime No

Text nvarchar No

LongBinary varbinary No

Memo ntext No

GUID uniqueidentifier No

GeoMedia Metadata Requirements


GeoMedia applications require specific metadata objects, and these must exist in the SQL

Server database before a connection can occur. GeoMedia's metadata tables contain

information about both the attribute and geometry tables stored in the database. The

metadata functions control the follow of geometry data to and from GeoMedia applications.

The following table lists the required metadata and its object type.

GeoMedia Metadata Objects Type

AttributeProperties Table

FieldLookup Table

GAliasTable Table

GCoordSystem Table

GeometryProperties Table

GFeatures Table

GFieldMapping Table

GIndexColumns Table

GParameters Table

GPickLists Table

GQueue Table

GTileIndexes Table

ModifiedTables View

ModificationLog Table

Binary2SqlGeography Function

Binary2SqlGeometry Function

SqlGeography2Binary Function

SqlGeometry2Binary Function




To create GeoMedia's required metadata objects, you must use one of the following methods:

Database Utilities Use Database Utilities from the GeoMedia Professional program

group. Enter the server name and login as the database owner (or administrator).

When connected, select the Create Metadata Tables command. This is the preferred

method and is also the method to use when updating the metadata objects as new releases

become available.

Export to SQL Server You can also create the required metadata tables during bulk

loading when using the import.bat command file created by the Export to SQL Server

command in GeoMedia Professional by setting the sixth parameter to Y. The

metadata.sql file generated by Export to SQL Server can also be run directly in SQL Server's

Management Console.

Scalar Functions Internally, GeoMedia utilizes binary format for WKB data so it converts SQL Server's

GEOMETRY/GEOGRAPHY data type to/from binary when reading/writing native geometry

records. It uses the following four scalar functions to do the conversion:

Binary2SqlGeography Converts GeoMedia's binary data type to the native GEOGRAPHY

data type when writing WKB geographic data.

Binary2SqlGeometry Converts GeoMedia's binary data type to the native GEOMETRY data

type when writing WKB geometry data.

SqlGeography2Binary Converts native GEOGRAPHY data type to GeoMedia's binary data

type when reading WKB data.

SqlGeometry2Binary Converts native GEOMETRY data type to GeoMedia's binary data

type when reading WKB data.

Execute privileges are required on these four functions for any login to a SQL Server database

that does not have the db_owner role. These functions only convert the data type used to

store the data; they do not convert data between WKB and GDO formats.



AttributeProperties Table The AttributeProperties metadata table describes the attribute types for the columns listed in

the FieldLookup table. The common link between this table and FieldLookup is the IndexID

column. The AttributeProperties table is defined, as follows:

IndexID Uniquely identifies the column being described. The IndexID value comes from

the FieldLookup table.

IsKeyField Determines whether a column is a primary key field. The default value is 0 for

FALSE. Use -1 (TRUE) if the column is a primary key.

IsFieldDisplayable Determines whether a column is displayed in GeoMedia Professional.

The default value is -1 for TRUE. Use 0 (FALSE) to hide the column.

FieldType Determines how GeoMedia interprets the data type used in the column

definition. These are based on the conversion from SQL Server to GeoMedia data types.

The field type values correspond to the following:

1 Boolean 8 Date

2 Byte 10 Text

3 Integer 11 Binary

4 Long 12 Memo

5 Currency 15 GUID

6 Single 32 Spatial geometry

7 Double 33 Graphic geometry

FieldPrecision Represents the number of decimal places displayed in GeoMedia

Professional. For numeric data types, the default is 6. Usually, this is the same as the

scale defined for the number field.



FieldFormat Determines the general format of the data being displayed. Format types

include General Number, Date/Time, and Currency.

FieldDescription A user-provided description of the column.

FieldLookup Table The FieldLookup metadata table provides a unique identifier (IndexID) for every column in

every table/view in the database. The table definition is, as follows:

IndexID This key column contains a unique identifier for every column in every table in

the database. It is populated using an identity increment.

FeatureName The table name.

FieldName Stores each column name for the associated feature name.

The IndexID is used as a reference by other metadata tables like AttributeProperties and

GeometryProperties, which are used to describe the columns and their contents.

GAliasTable The GAliasTable metadata table determines the names of the other metadata tables used by

GeoMedia Professional. The GAliasTable is the only metadata table whose name is hard

coded. This table must exist and cannot be modified or altered in any way. The table

definition is, as follows:

TableType This key column contains an internal reference name used by GeoMedia

applications.

TableName This is the table name used by the associated table type. A table or view is

required for each table type.



GCoordSystem Table The GCoordSystem metadata table stores GeoMedia's coordinate system definitions. If this

table is not present, no coordinate system transformation will occur, and the GeoWorkspace

coordinate system will be used. This table is not user editable and is not listed due to the

large number of columns and types of parameters required to define a coordinate system. This

table should never be populated manually. There are three columns worth noting:

Name The name the user has assigned to this coordinate system. This is an optional

parameter, but it should be used because it makes the coordinate system easier to identify,

particularly if multiple coordinate systems are used in the database.

Description A user-provided description of the coordinate system. This is optional, but

like the name, it can also be useful.

CSGUID The CSGUID is a special value used to uniquely identify the coordinate system

parameters. The CSGUID is used to associate a geometry object to a GeoMedia

coordinate system. The CSGUID is also referenced in GeometryProperties and in

GFieldMapping.

Coordinate systems should be created using GeoMedia Professional's Define Coordinate

System command. When a defined coordinate system is assigned to a feature class, the

parameters that make up the coordinate system are inserted into the database table. Any

feature class that uses the coordinate system is assigned the CSGUID for that coordinate

system.

Coordinate systems are defined on a per-feature-class basis. Each feature class can have its

own coordinate system. If the database has a default coordinate system defined using the

DefaultCoordinateSystem parameter in the GParameters table, feature classes created using

the Feature Class Definition, Output to Feature Classes, or Export to SQL Server commands

will automatically use the default. Outside of GeoMedia Professional, you will need to use

the Database Utilities command, which is available in the GeoMedia Professional program

group. If you have incorrectly assigned a coordinate system to a feature class, you can also

use the Database Utilities to correct the assigned coordinate system.

If you plan to use multiple coordinate systems in your SQL Server database, you need to assign

one coordinate system to use as a default. Default coordinate systems can be assigned using

Database Utilities or Feature Class Definition. Only one default coordinate system is allowed

per database. The CSGUID of the default coordinate system is stored in the

DefaultCoordinateSystem parameter in the GParameters metadata table.



When digitizing in GeoMedia Professional, you should ensure that the GeoWorkspace

coordinate system matches the coordinate system of the feature class into which you are

digitizing. This is not always required, but depending on the coordinate transformation used,

conversion errors can occur when the coordinates are written to the database. GeoMedia

Professional will compare the GeoWorkspace coordinate system to the coordinate system of

the feature you select for editing and will warn you if there is a mismatch. It will be up to the

user to rectify or ignore the mismatch. One example where a difference is required is when

editing geographic data in the polar regions; in this case, your workspace should be set to

either north or south polar stereographic.

GeometryProperties Table The GeometryProperties metadata table stores the geometry type, primary geometry flag, and

the coordinate system ID for geometry columns contained by feature classes. The common

link between this table and FieldLookup is the IndexID column. The table definition is, as

follows:

IndexID This key field links the information to the actual column defined in the

FieldLookUp table.

PrimaryGeometryFlag A feature class can contain multiple geometry fields, but only one

field is allowed to be primary. The primary geometry field is the field that allows for

editing. A value of -1 means the geometry column is the primary geometry. All other

geometry columns in the feature class should be assigned 0. Only one primary geometry

field is allowed.

GeometryType This field determines how the data server maps the geometry:

1 Line 2 Area

3 AnySpatial 4 Coverage

5 GraphicsText 10 Point

GCoordSystemGUID This field contains the CSGUID from the GCoordSystem table. It tells

the data server what coordinate system is assigned to the geometry.



FieldDescription A user-provided description of the column.

GFeatures Table The GFeatures metadata table stores the table names of all user tables (feature classes). By

manipulating the tables listed here, you can make feature classes visible or invisible in

GeoMedia. The table definition is, as follows:

FeatureName This key column contains the name of the table that will be exposed as a

feature class in GeoMedia applications. This table is used by every command in

GeoMedia Professional that lists the available feature classes, for example, Add Legend

Entries.

GeometryType This field determines how the data server maps the geometry.

1 Line 2 Area



-1 Attribute only (no geometry field)

PrimaryGeometryFieldName The name of the primary geometry column.

FeatureDescription A user-provided description of the column.



GFieldMapping Table The GFieldMapping metadata table is used to override various aspects of column definitions.

Information stored here typically consists of the primary key column and the primary geometry

with their associated GeoMedia data types, the coordinate system ID, and any assigned

autonumber types. This table also defines the relationship between the native geometry

storage column and the GeoMedia binary geometry column. The table definition is, as

follows:

TABLE_NAME The name of the table.

COLUMN_NAME The column in the table that this information apples to.

The TABLE_NAME/COLUMN_NAME combination makes up the primary key.

DATA_TYPE Determines how GeoMedia interprets the data type used in the column

definition. Field type values include the following types (these are derived from the SQL

Server to GeoMedia data type matching table):

1 Boolean 8 Date

2 Byte 10 Text

3 Integer 11 Binary

4 Long 12 Memo

5 Currency 15 GUID

6 Single 32 Spatial geometry

7 Double 33 Graphic geometry

DATA_SUBTYPE Used when the DATA_TYPE is 32 or 33; the subtype determines the

graphic type:



1 Line 2 Area



CSGUID The coordinate system assigned to the primary geometry field.

AUTOINCREMENT A Boolean field indicating that the field is set to auto-increment. Use

-1 for True; otherwise, the value is NULL.

NATIVE_GEOMETRY This column is used to match the native geometry column with its

associated GeoMedia binary geometry column.

NATIVE_SRID This column contains the SRID of the native geometry field. Typically it

will be 0 for GEOMETRY type fields. For GEOGRAPHY types, it should reflect an SRID value

that is defined in SQL Server's sys.spatial_reference_systems table.

GIndexColumns Table The GIndexColumns metadata table is used to specify the column or columns in a view that can

act as primary or unique key fields. This table is populated using Database Utilities. The

table definition is, as follows:

The primary key is a combination of the OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME,

and COLUMN_NAME fields.

OBJECT_SCHEMA The owner of the view (the default is 'dbo').

OBJECT_NAME The name of the view.

INDEX_NAME The primary key index name from the base table.

COLUMN_NAME The name of a column in the view that will use the index in

INDEX_NAME.



INDEX_TYPE The type of the index: P for primary, U for unique. The default value is

P. If this field is missing, the first index will be assumed to be the primary index. If a

view does not have a key defined in the GIndexColumns, it will be read-only, and no DML

operations will be allowed.

COLUMN_POSITION This field is the order of the column within the index. The default

value is 1.

BASE_OBJECT_SCHEMA This field is the owner of the table (view) on which the view is

based. If this field contains NULL (empty string), notification will not be supported. Only

triggers can support notification in this case.

BASE_OBJECT_NAME This field is the name of the table (view) on which the view is based.

If this field is missing or contains NULL (empty string), notification will not be supported.

Only triggers can support notification in this case.

BASE_COLUMN_NAME This field is the name of the corresponding field of the base

table/view. This field is used for name aliasing. If this field contains NULL (empty

string), column name aliasing will not be supported.

GParameters Table The GParameters metadata table contains the default values for the parameters needed to

create new tables using GeoMedia Professional as well as other miscellaneous information,

such as the default warehouse coordinate system.



This table contains two fields, GPARAMETER and GVALUE. Currently, the following values are

used by default:

Never modify the values in the GPARAMETER column. The values used in the GVALUE column

are user editable and these control how GeoMedia Professional creates tables in the database.

These values mainly affect Feature Class Definition, but any GeoMedia Professional command

that creates a table in the database will use these as defaults. Typically, you would edit the

following:

TypeForNativeGeometryStorage This controls whether tables will be created using the

GEOMETRY or the GEOGRAPHY data type. If you are using projected data, use

GEOMETRY. If your data is GPS or longitude/latitude based, use GEOGRAPHY.

DefaultNativeStorageSrid This assigns the default SRID to use. If the

TypeForNativeGeometryStorage is set to GEOMETRY, this value must be set to 0. If

TypeForNativeGeometryStorage is set to GEOGRAPHY, this value must be set to an SRID

that is currently supported by SQL Server. Use the following query for a list of the SRIDs

currently supported by SQL Server:

SELECT * FROM SYS.spatial_reference_systems

DefaultCoordinateSystem This parameter contains the CSGUID from the GCoordSystem

table that corresponds to a GeoMedia coordinate system that is to be used as the default

for all feature classes created through the GeoMedia Professional environment. If the

TypeForNativeGeometryStorage is set to GEOGRAPHY, this value should correspond to the

CSGUID of a coordinate system in the GCoordSystem table that matches the coordinate

system for the SRID used for the DefaultNativeStorageSrid.



XUpperBound, YUpperBound, XLowerBound, YLowerBound These parameters control the

MBR or bounding box range used by GeoMedia Professional when creating spatial indexes

on geometry data types. Spatial indexes will perform better when the range used here

more closely matches the range of the data indexed. Data that falls outside the range will

not be indexed but will still be included in the results of the second pass filter, if applicable.

Optimizing the spatial indexes for each feature class will improve performance and should

be done at the database level. GeoMedia Professional will only create a default spatial

index, and it may or may not be optimal.

If you need to modify any of the other GPARAMETER/GVALUE pairs, you should first consult

GeoMedia customer support.

GPickLists Table The GPickLists metadata table contains the Picklist assignments used by both the Properties

dialog box and the data window in GeoMedia Professional. Also known as domain lists,

Picklists allow for a predefined list of values to be used when updating attribute fields.

GPickLists is defined, as follows:

The primary key is a combination of the FeatureName and FieldName columns. These

columns refer to the feature class and the specific attribute field for which the Picklist is to

be used.

PickListTableName Specifies a table in the schema containing the PickList values.

ValueFieldName and DescriptionFieldName Refers to the name of the columns in the

table containing the Picklist values.

ValueFieldName Specifies the field in the Picklist table that contains the values to be

stored in the database. The data type of the field in the Picklist table specified here must

match the data type of the attribute assigned in the FieldName.

DescriptionFieldName Specifies the field that contains Picklist descriptions to be displayed

in the pop-up menu on the Properties dialog box.



The values stored in ValueFieldName and DescriptionFieldName could be the same when

the displayed values are the same as the stored values.

FilterClause Is optional and may contain a SQL where clause that will be used to filter the

records in the Picklist. The filter allows a single Picklist table to be used when creating

multiple Picklists.

Picklist tables can be any tables that contain the required information, including existing

feature classes. You can implement a Picklist as a code list (using separate value and

description entries) or as a domain list (when value and description entries are the same).

Ranges are not supported.

The Picklist metadata table can either be populated manually or by using the Picklist Manager

utility. This utility is available from Intergraph Customer Support. For more information, visit

the SG&I Support page (http://support.intergraph.com/).

The following is an example of tables, columns, and values that could be defined for Picklists:

GPickLists

FEATURENAME FIELDNAME PICKLIST TABLENAME

VALUE FIELDNAME

DESCRIPTION FIELDNAME

FILTERCLAUSE

BUILDINGS NAME PL_BUILDING CODE_VALUE VAL_DESCRIPTION BLD_TYPE = 'NAME'

BUILDINGS STATE PL_STATE STATE_NAME DESC

BUILDINGS TYPE PL_BUILDING CODE_VALUE VAL_DESCRIPTION BLD_TYPE = 'TYPE'

PL_Building

CodeValue ValDescription Bld_Type

0 MOTEL TYPE

1 MARRIOT NAME

2 HOLIDAY INN NAME

3 BED AND BREAKFAST TYPE

4 DAYS INN NAME

PL_State

StateName Desc

Alabama ALABAMA

Arkansas ARKANSAS



StateName Desc

Colorado COLORADO

Texas TEXAS

Florida FLORIDA

Queue Table The GQueue metadata table is used to store the static queues for the Queued Edit command.

The columns in GQueue are populated through commands in GeoMedia Professional and are

used solely by the Queued Edit command. This table is not user editable and should not be

modified in any way.

ModifiedTables ModifiedTables is a join view that provides the object ID for each table/view. The view uses

an inner join between the sysobjects table and the sysindexes table in conjunction with a union

on GIndexColumns. The ModifiedTableID in this view provides the values for the

ModifiedTableID used in the ModificationLog table. This value is used to identify the edited

table in the ModificationLog table. This view is not user editable and should not be modified

in any way.

ModificationLog Table The ModificationLog metadata table tracks modifications made from the GeoMedia

environment for all feature classes in the connected schema. Specifically, it is used to track

all inserts, updates, and changes made to tables/views listed in ModifiedTables. The

ModifiedTableID is the common link between ModificationLog and ModifiedTables. The

definition of the ModificationLog table is, as follows:



ModificationNumber The auto-increment key filed for the table.

Type The type of edit that has occurred: 1 for insert, 2 for update, and 3 for delete.

ModifiedTableID The column identifier from ModifiedTables.

KeyValue1 to KeyValue10 These fields store the primary key column values for the edited

row. If there is only one primary key column, only KeyValue1 is used. For multi-column

primary keys, the values from each field that makes up the key are stored here. A primary

key can be made up of a maximum of 10 columns.

SESSIONID Identifies the SQL Server session making the edit. This field is populated

automatically from a function-based default value.

ModifiedDate Identifies the date and time of the edit. This field is populated

automatically from a function-based default value.

The ModificationLog table is part of the GeoMedia notification system. All edits made to

feature classes within the connected SQL Server database are tracked in the ModificationLog

table. Over time, this table can grow very large very quickly. Because the size of the

ModificationLog table can negatively affect editing performance in GeoMedia applications, the

table should be periodically truncated. However, do not clear this table while there are open

GeoMedia sessions. The Clear Modification Log command in Database Utilities will truncate

this table. You can also use the following SQL to clear this table:

Truncate Table dbo.ModificationLog



You could also set up a SQL Server job to do this automatically; just make sure it runs when

there are no active GeoMedia sessions.

The ModificationLog table is currently only configured to track modifications made through the

GeoMedia environment. Modifications to the data made outside of GeoMedia do not update

the ModificationLog table; thus, GeoMedia sessions are not notified of those changes.

To solve this issue, you can create triggers that will automatically provide modification logging.

To prevent insert events from happening twice, the triggers must have names that are

recognized by the SQL Server data server:

The trigger for insert must have a name that corresponds to the feature class name

appended by GMTI.

The trigger for update must have a name that corresponds to the feature class name

appended by GMTU.

The trigger for delete must have a name that corresponds to the feature class name

appended by GMTD.

For example, if the feature class is States, the triggers must have the name StatesGMTI,

StatesGMTU, and StatesGMTD. This rule holds true regardless of whether the feature class is

a table or a view. When the triggers are detected, GeoMedia will offload all the modification

logging for the specific feature class to the trigger.

Each trigger fires on the specific editing event and writes an entry into the ModificationLog

table:

Type is populated with the following constants: 1 - Insert, 2 Update, or 3 Delete.

ModifiedTableID is populated with the object ID of the object for which the entry is

created. This field comes from the ModifiedTables view.

KeyValue1 to KeyValue10 are populated by converting the primary key value to

nvarchar(255). For a single column primary key, only KeyValue1 is populated. If the

primary key consists of multiple columns, the additional columns can be added to

KeyValue2 through KeyValue10. Primary keys consisting of more than 10 columns are not

supported.

If the primary key is user editable (non-composite or does not contain an identity field), all

modifications must create two entries, one for the old key value and one for the new key

value.

The following are examples of the insert, update, and delete triggers for a feature class (table)

called States, whose primary key column is ID:



CREATE TRIGGER dbo.StatesGMTI ON dbo.States FOR INSERT AS

DECLARE @TableID INT

IF object_id('tempdb..#DisableModificationLog') IS null

SELECT @TableID=ModifiedTableID FROM ModifiedTables

WHERE TableName='States'

INSERT INTO ModificationLog(Type,ModifiedTableID,KeyValue1)

SELECT 1, CONVERT(nvarchar(20),@TableID),CONVERT(nvarchar(255),

inserted.ID) FROM inserted

GO

--

CREATE TRIGGER dbo.StatesGMTU ON dbo.States FOR UPDATE AS





BEGIN

IF update(ID)


SELECT 2, CONVERT(nvarchar(20),@TableID),

CONVERT(nvarchar(255),deleted.ID) FROM deleted

INSERT INTO ModificationLog([Type],ModifiedTableID,KeyValue1)


CONVERT(nvarchar(255),inserted.ID) FROM inserted

END

GO

--

CREATE TRIGGER dbo.StatesGMTD ON dbo.States FOR DELETE AS







CONVERT(nvarchar(255), deleted.ID) FROM deleted

GO



--

To make this work with views, you need to add an entry to the base table trigger that handles

the modification to the view. For example, if you have a simple view on States called

STATES_VIEW, you could use the following trigger to handle notification for inserts:

CREATE TRIGGER dbo.StatesGMTI ON dbo.States FOR INSERT AS


DECLARE @ViewID INT

if object_id('tempdb..#DisableModificationLog') is null




SELECT 1, convert(nvarchar(20),@TableID),

convert(nvarchar(255), inserted.ID) FROM inserted


WHERE TableName='States_View'

INSERT INTO ModificationLog(Type, ModifiedTableID,KeyValue1)

SELECT 1, convert(nvarchar(20),@ViewID),

convert(nvarchar(255), inserted.ID) FROM inserted

GO

The trigger in the above example will handle edit notification for both the table and the view,

but GeoMedia will still attempt to write another notification for the view itself. To stop this

second notification event, another trigger needs to be created on the view using the view

name:

CREATE TRIGGER dbo.States_View_GMTI ON dbo.States FOR INSERT AS


if object_id('tempdb..#DisableModificationLog') is null


WHERE TableName='States_View'

GO

The trigger itself is still on the base table States; it is only the name of the trigger that

refers to the view. This is essentially a dummy trigger; it does not do anything other than

telling GeoMedia not to write directly to the ModificationLog table.



When you edit through a view, it is the underlying base table that is actually edited, and in that

case, a modification log trigger is required. This becomes more complicated as more views

are added on the same base table. Every update to the base table should also update the

ModificationLog table for every view that is dependent on the base table. For join views, you

will need to take into account all the base tables and associated views. In the case of join

views, most editing would be handled through instead of triggers. In this case, you could

embed the insert into the ModificationLog table directly using the instead of trigger as long as

the trigger name adheres to the rules listed above.

Data Server Required Triggers in SQL Server Spatial To maintain the relationship between the native geometry and GeoMedia's binary GDO

geometry, an after-insert and an after-update trigger are required for every table. When a

native geometry column is inserted/updated outside of GeoMedia, this trigger sets GeoMedia's

binary GDO geometry to NULL. The next time the data is read by the data server, the binary

GDO column value will be reconstructed from the native value. These triggers are

automatically created for every feature class created by GeoMedia Professional. If you create

your tables outside of the GeoMedia Professional environment, you will need to manually add

these triggers. The general format for each of these triggers is shown below:

CREATE TRIGGER __INS ON AFTER INSERT AS BEGIN

SET NOCOUNT ON;

IF EXISTS (SELECT NULL FROM INSERTED WHERE INSERTED. IS

NULL AND INSERTED. IS NOT NULL) BEGIN RAISERROR (N'Unsupported. Cannot specify value for GDO column only, native column value must also be provided.', 0, 1) ROLLBACK TRANSACTION END; END; GO

CREATE TRIGGER __UPG

AFTER UPDATE AS BEGIN SET NOCOUNT ON;



IF UPDATE() BEGIN

IF NOT UPDATE() BEGIN UPDATE SET = NULL WHERE EXISTS (SELECT NULL FROM INSERTED WHERE INSERTED. = .

END

END ELSE IF UPDATE() BEGIN RAISERROR ('Unsupported. Cannot specify value for GDO column only, native column value must also be provided.', 0, 1) ROLLBACK TRANSACTION

END

END;

GO

The use of these triggers can mean data loss is possible for some types of geometries. For

example, if an OrientedPointGeometry is stored in SQL Server, GeoMedia's binary GDO

geometry field contains the actual oriented point geometry, while the native geometry field

stores only the point location. When a non-GeoMedia client updates the native POINT (x y z)

geometry, the orientation vector is lost. A more complicated scenario occurs when arcs are

stored in the binary GDOgeometry and corresponding stroked polylines are stored in the native

geometry. In this case, information referencing the geometry as an arc will be lost, and its

stroked PolylineGeometry will remain.

SQL Server Spatial Indexing Spatial filtering in GeoMedia will use standard SQL Server spatial filtering operations. These

rely on spatial indexes on the native geometry fields. For tables created using GeoMedia

Professional, the spatial indexes are created automatically using the syntax below.

For native geometries using the GEOGRAPHY data type, the spatial index is created using the

following syntax:

CREATE SPATIAL INDEX __sindx ON

();

For native geometries using the GEOMETRY data type, the spatial index is created using the

following syntax:



CREATE SPATIAL INDEX __sindx ON

()

WITH (BOUNDING_BOX = (, , ,

))

where , , , are taken

from the GParameters table.

For existing tables that contain native geometries, the database administrator should ensure

that the spatial indexes exist and are up to date. Spatial indexes can only be created on

tables that have a clustered primary key. The maximum number of key columns allowed on

any given table is 15, and the maximum size of the index key records is 895 bytes. The

primary key definition cannot be changed while the spatial index exists. For best

performance, use a single integer-based primary key populated by an identity increment.

The parameters used to create a spatial index, particularly for projected data, can have a large

effect on overall query performance. Refer to SQL Server Books Online for more information

on creating and optimizing spatial indexes.

A default spatial index is automatically created whenever a table is created via

GeoMedia, but there is no guarantee that this index will be optimal. For best performance,

you should optimize every spatial index for the specific geometry stored and periodically

rebuild the index as new data is entered.

Working with SQL Server Spatial


GeoMedia Professional's SQL Server native spatial data server utilizes two distinct columns in a

SQL Server table to store the binary representation of spatial vector data. Its stores SQL

Server's native spatial format (WKB well known binary) in a column using the native

GEOMETRY/GEOGRAPHY data type and stores GeoMedia's GDO format in a column using the

VARBINARY(max) data type (for those geometries that are not directly supported by native

spatial). For every native spatial column in a table, there must be a corresponding GDO

column, and the association must be stored in GeoMedia's GFieldMapping metadata table.

For existing native spatial data, the GDO column will have to be added and the association

made via Database Utilities. Initially, the GDO column will only contain NULL rows. During

GeoMedia INSERT and UPDATE operations, the data server will automatically populate records

in both columns using GDO format for the varbinary column and WKB for the native geometry.

This ensures that geometry types that are currently not supported by SQL Server can still be

retrieved from the GDO column while a close approximation is stored in the native geometry

column (see the section GeoMedia's Binary Geometry to Native Geometry Type Matching for

more information).

During an INSERT operation, a trigger fires to verify that if a new geometry record is inserted

into the GDO column, the same (or a close approximation) geometry is also inserted into the

corresponding row of the native geometry column. Every geometry record in the GDO column

must always have a corresponding geometry record in the native geometry column (the native

geometry record cannot be NULL if there is a GDO record). However, a new geometry record

can be inserted into the native geometry column without a corresponding record being

inserted into the GDO column (the GDO record can be NULL).

During an UPDATE operation, a trigger fires to verify that if only the row in the native geometry

column is being updated, the corresponding row in the GDO column is set to NULL. This

situation would only happen if the native geometry record was edited outside of the GeoMedia

environment. If GeoMedia detects a NULL row in the GDO column, it will read the

corresponding row from the native geometry column. The next time an update on this same

row occurs in GeoMedia, the corresponding row in the GDO column will again be populated.

While this ensures that the geometry records remain in sync, it can lead to loss of data in some

cases. For example, if you have a rotated point that is used for symbology and the native

geometry for that point is edited outside of GeoMedia, the rotation value will revert to zero

because the corresponding row in the GDO column will be set to NULL and GeoMedia will only




read the native geometry the next time the point is displayed. You would have to reset the

point's rotation using GeoMedia which would replace the NULL record in the GDO column with

the current native geometry and the updated point rotation.

Using Existing Native Spatial Data If you have existing native spatial data, it must be 3D; 2D geometries are not supported. You

will also need to add a varbinary(max) column to support GeoMedia's binary GDO geometry

format used for unsupported geometries (for example, arcs, oriented points, text, and raster).

This column can be named anything, but it is best to make it similar to the column name of the

native geometry. This will make associating the two columns a lot easier when metadata is

assigned using Database Utilities. For example, if the table ROADS contains a native

geometry column called CENTERLINE and an identity-based primary key called ID, you need to

add a new column called CENTERLINE_GDO:

ALTER TABLE ROADS ADD COLUMN CENTERLINE_GDO VARBINARY(MAX) GO

Each table also requires two maintenance triggers for the additional GDO column: an after

insert and an after update trigger. See the Data Server Required Triggers in SQL Server Spatial

section for more information. For the example ROADS table listed above, the triggers would

look like the following:

CREATE TRIGGER [dbo].[ROADS_GEOMETRY_INS] ON [dbo].[ROADS]

AFTER INSERT AS

BEGIN

SET NOCOUNT ON;

IF EXISTS (SELECT NULL FROM INSERTED WHERE INSERTED.[CENTERLINE] IS NULL

AND INSERTED.[CENTERLINE_GDO] IS NOT NULL)

BEGIN

RAISERROR(N'Unsupported. Cannot specify value for GDO column only,

native column value must also be provided.', 0, 1)

ROLLBACK TRANSACTION

END

END;

GO

CREATE TRIGGER [ROADS_GEOMETRY_UPG] ON [dbo].[ROADS]

AFTER UPDATE AS

BEGIN

SET NOCOUNT ON;

IF UPDATE([CENTERLINE])

BEGIN



IF NOT UPDATE([CENTERLINE_GDO])

BEGIN

UPDATE [ROADS] SET [CENTERLINE_GDO] = NULL

WHERE EXISTS (SELECT NULL FROM INSERTED

WHERE INSERTED.[ID] = [ROADS].[ID])

END

END

ELSE IF UPDATE([CENTERLINE_GDO])

BEGIN

RAISERROR('Unsupported. Cannot specify value for GDO column only,

native column value must also be provided.', 0, 1)

ROLLBACK TRANSACTION

END

END;

GO

Once the binary column and the triggers have been added, you will need to add the metadata

tables required by GeoMedia applications and then add the metadata entries for each table

you want to use as a feature class. You can use Database Utilities for both of these

operations.

Importing Spatial Data The easiest way to get started using the SQL Server Spatial data server is by bulk importing data

from another data source. GeoMedia Professional has two commands that will move data to

SQL Server warehouses, Export to SQL Server and Output to Feature Classes.

Export to SQL Server creates a set of files and an import.bat script that will load a SQL Server

database from any data source that GeoMedia Professional is connected to. The process will

use the coordinate system of the GeoWorkspace for the output. The resulting export files use

SQL Servers CMDSQL and BCP to load the data. For this reason, imports can only be run on a

SQL Server Administrative Client or on the system where SQL Server is installed. This method

is very fast and is ideal for bulk loading large amounts of data (>1000000 rows per table). This

method also allows you to optionally create the required metadata tables.

Output to Feature Classes requires that metadata tables already exist in the target SQL Server

database. To manually create the metadata, use GeoMedia Professionals Database Utilities,

connect to the new database using an account with the db_owner role, and then click Create

Metadata Tables. Once the metadata is created, you will be able to connect to the

warehouse through GeoMedia Professional and then use Output to Feature Classes to create

feature classes. This command is very flexible and allows you to make modifications to the



table/column definitions, key definitions, and coordinate system assignments. The drawback

is in performance; this command is considerably slower than Export to SQL Server and is best

used for smaller datasets (



Undo/Redo If you use the Undo/Redo commands while editing the geometry or attributes associated with

tables that contain an identity column, be aware that the numeric sequence is not preserved.

Auto-increment identity columns are usually assigned as primary key columns, and they should

not be used as part of a foreign key. Failure to heed this warning could invalidate view-join

definitions.

For example, a row of your data consists of an identity field called ID that contains the value

10, and there are 300 total records in this table such that max(ID)=300. If you accidentally

delete this row and use the Undo command to get it back, ID will now be assigned the next

available number in the auto-increment sequence, in this case 301.

The original ID=10 is not recoverable. In all cases, the next available autonumber value will

be obtained on an undo/redo operation; the previous autonumber value will not be preserved.

This is actually by design; it is how Microsoft intends the auto-increment field to be used.

Default Values Default values can simplify data entry and supply values for columns that are either required or

just need to have a specific entry. Default values are honored by GeoMedia but not directly.

When inserting a new record with the option to display the Attribute Properties dialog box

turned on, the default values are not shown in the dialog box even though they are available at

the database level. They will only be used when the insert occurs. If the fields are required,

you will not see an error; instead, the insert will pick up the default values. However, if the

option Copy attribute values from previous feature is enabled (Placement and Editing tab,

Tools > Options dialog box), you will no longer be able to use the default value. Instead, the

value used in the previous insert will be used. If you delete the previous value used in a

required field, the default value will still not be used, and you will get an error message.

For best results with defaults, either turn off the Copy attribute values from previous feature

option, or do not make the fields required. Functional-based defaults will work, but again,

you must turn off the Copy attribute values from previous feature option. This same

problem will occur if you are using triggers to populate required fields.

Spatial Filtering Spatial filtering will use the spatial index created on the tables' native geometry columns. The

performance of spatial indexes can vary widely, so if performance is an issue, consider



re-creating the spatial indexes using different parameters. GeoMedia applications have four

different spatial filter options:

Coarse Overlap This method uses SQL Server's Filter method to return the results. This

is generally the fastest performing filter because it only uses the spatial index; however, it

will always pick up extraneous values.

Overlap This method uses SQL Server's two pass STIntersects method.

Entirely Inside - This method uses SQL Server's STWithin method and then processes the

final results on the client.

Inside - This method uses SQL Server's STWithin method.

Simple rectangular polygons will return the quickest results; the more complicated the filter

area, the slower the process. For geographic data, SQL Server only supports Filter and

STIntersects. For these cases, GeoMedia will perform the final filtering on the client.

Views and Join Views GeoMedia Professional makes no distinction between views and tables; it treats a view just like

any other feature class. The SQL Server Spatial data server handles read-write access to most

types of views as long as the views are key preserved. This means that the status of the

primary key in the base table is preserved in the view. One way to ensure this is true is to

include and preserve the primary key in the view definition. In a join-view, the primary key

can come from either the left or the right side as long as it retains its key status. It cannot

come from both sides of the join and still be updatable. In addition, only the side of the join

containing the key will be updatable. For full editing capability on a join view, an instead of

trigger is required.

For a view to be treated as a spatial feature class, the view definition must include both the

native geometry column and GeoMedia's binary GDO column. Metadata is also required to

see the view in GeoMedia applications, and Database Utilities can be used to insert the

required metadata. For views to be updatable in GeoMedia Professional, there must also be

an entry for the key column in the GindexColumns metadata table. This is required for both

spatial and non-spatial feature classes that are view based.

Database Utilities


Database Utilities consist of several utilities for managing and updating Access, Oracle, and

SQL Server databases for use with GeoMedia products. These utilities are delivered with

GeoMedia Professional and are accessible from the Start menu.

See the Database Utilities online Help for complete information.

Database Utilities includes seven separate database tools, but only six of these are available

for SQL Server. Here are the six basic tools:

You can connect to a SQL Server spatial databases using either Windows domain

authentication or SQL Server authentication. For best results, all Database Utilities

operations should be performed by a database administrator login or by any user who has

been assigned the db_owner role.

For new databases, select the Create Metadata Tables command before attempting any

other GeoMedia operation. Subsequent use of this command will update existing

metadata with the changes for the given release (if any).

For tables or views created in SQL Server, use the Insert Feature Class Metadata command

to add the metadata required to see these as feature classes in GeoMedia. The primary

difference between the SQL Server spatial data server and the standard SQL Server data

server is the assignment of the native geometry field and the native SRID value:

To alter metadata already entered for existing feature classes, use the Edit Feature Class

Metadata command.

Database Utilities

Database Utilities


To delete the metadata for an existing feature class, use the Delete Feature Class

Metadata command. If significant DDL modifications are going to be made to a table or

view, the metadata should first be deleted and then re-inserted after the modifications

have been made.

To assign a default coordinate system to a new database or to re-assign coordinate systems

for existing feature classes, use the Assign Coordinate System command. For existing

feature classes, this command changes the coordinate system assignment without

changing the data. Use discretion here; assigning an incorrect coordinate system can

cause problems when editing. Make sure the correct coordinate system is assigned.

Exporting to SQL Server


Use the Export to SQL Server command to export data from a legacy data store to a SQL Server

2008 or later database for use with the GeoMedia product suite. This command is intended

for bulk loading large amounts of data into a database by generating ASCII files that can be

used by SQL Servers Bulk Loader application. This command is not intended to be used as an

update tool. Before using this command, you must verify that the GeoWorkspace coordinate

system is the appropriate target coordinate system for the data you want to export.

To use this command, you first select the data to be exported from a treeview of all feature

classes/queries, including categories and reference features. You can select any mixture of

feature classes, queries, categories, and reference features, across any number of connections.

This command offers the following two modes:

SQL Server non-Spatial for SQL Server 2005 or later. Geometry storage uses

varbinary(max).

SQL Server Spatial SQL Server 2008 or later. Geometry storage uses native spatial

GEOMETRY/GEOGRAPHY combined with varbinary(max) for unsupported geometry types.

SQL Server 2000 was de-supported starting from GeoMedia 6.1.11. Only SQL Server

2005 and later version are supported starting from GeoMedia 6.1.11. Native spatial storage

is only available in SQL Server 2008 or later.

You can write the command output in SQL Server native spatial format for either a projected or

non-projected target coordinate system. For a non-projected target coordinate system, you

select the appropriate spatial reference system from all the supported spatial reference

systems.

The export process takes the source data as is with no modification. Source data

that is not from another database may have problems once it is imported into the SQL Server

spatial environment. Column names may be illegal, primary key columns may not exist, and

there may be data issues. After import, verify that the data model conforms to the

requirements of SQL Server spatial, and make any necessary corrections before using the data

in the GeoMedia environment. You should also make sure that spatial indexes are created on

the spatial geometry columns after any import operation.

In the Exporting options on the Export to SQL Server dialog box, the Export native spatial

format check box is enabled whether the active target coordinate system is projected or

non-projected. When this check box is checked and a non-projected target coordinate




system is active, the Spatial reference system identifier drop-down list is enabled and

populated with all supported spatial reference systems, from which you choose the

appropriate one. Export to SQL Server creates the following files based on the coordinate

system of the GeoWorkspace:

Metadata.sqlCreates GeoMedia's required metadata objects.

FeatureClassName_pre.sql (one for each feature class or query exported)Creates the

table using defaults. You can also create the table or edit the delivered script file for more

control.

FeatureClassName.bcp (one for each feature class or query exported)Data file for loading

data.

FeatureClassName_post.sql (one for each feature class or query exported)Populates the

SQL Server metadata table and all GeoMedia metadata tables.

FeatureClassName.datContains the attribute and geometry data for use with the bulk

load processor.

Import.batScript file with all of the above files, which uses common defaults and can be

edited for handling specific options.

export.logLog file that contains either the cause of failure if error conditions arise or the

number of features successfully exported per selected feature class during the export

process.

By default, the data is exported to the \Warehouses folder. You can change this location on

the dialog box, and this location is then remembered as a session preference.

Error conditions are not reported to you while the Export to SQL Server command is

being run. This is to improve performance and to ensure uninterrupted exports of large sets

of data. You should review the export.log file at the completion of the export to determine if

any errors occurred during the export process.

To export data to SQL Server:

1. Connect to the existing warehouse from which you want to export data.

2. Verify that the GeoWorkspace coordinate system is the appropriate target coordinate

system for the data that is to be exported.



3. Select Warehouse > Export to > SQL Server to open the Export to SQL Server dialog box.

4. Select the appropriate items from the Features to export treeview.

Holding the cursor over an entry displays a tooltip with the geometry type of the

entry.

5. Optional: Check the Export to native spatial format check box.

6. With the check box in the previous step checked, and using an active non-projected target

coordinate system, select the appropriate reference system from the Spatial reference

system identifier drop-down list,

When you select a spatial reference system identifier for the first time with an

active non-projected coordinate system, the following warning message is displayed:

Verify that the GeoWorkspace coordinate system is identical to the selected spatial

system before proceeding.

This warning is also displayed when the default selection is restored from session

preferences and you have not changed it.

7. Select the appropriate Export folder.

8. Click Apply to export the data.



The following error message is displayed when there is no selected spatial reference

system identifier for a non-projected active coordinate system, and you click Apply:

Select a spatial reference system identifier that matches the GeoWorkspace

coordinate system before proceeding.

9. Examine the output ASCII files, and modify them if necessary.

10. Run the output script file.

11. Use Bulk Loader to create SQL Server tables and to load the geometry and attributes to the

SQL Server database.


Intergraph provides several ways to access information and to contact support, including

self-help tools and phone support.

Self-Help Support Tools Intergraph provides several electronic self-help support tools to answer your support questions

24 hours a day, 7 days a week.

1. Go to the SG&I Support page (http://support.intergraph.com/).

The first time you select this link, it displays the Intergraph Support page, and you

need to select Security, Government & Infrastructure Division to display the SG&I Support

page. When you select this link the next time, it will go directly to the SG&I Support page.

If you later want to change the division, just click (Change Support Division) in the list at

the upper left of the SG&I Support page.

2. Under Product Support, select the appropriate Intergraph product from the Products

drop-down list; then click Go.

3. On the Customer Log In page, enter your user ID and password; then click Log In. If you

do not have a user login, click the link to request one.

4. On the product page, do one of the following:

Click Knowledge Base.

Scroll to the Product Versions table and click the download icon for the document you

want to read.

To read about new or enhanc

GeoMedia SQL Server Spatial User Guide_06.01.00

Documents

Transcript of GeoMedia SQL Server Spatial User Guide_06.01.00