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.
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.
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.
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
SECTION 1
Introduction
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.
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
drop-down database list. SQL Server has two modes for validating users:
authentication and SQL Server authentication.
Windows domain
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.
All geometries are stored in 3 dimensions; 2 dimensional geometries are not supported.
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.
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.
Name
Data Type
Description
<geometry_column_name>
varbinary(MAX)
<geometry_column_name
SPA
GEOMETRY/GEOGRAPHY
The native geometry column in SQL Server (<GDO geometry name>_SPA) stores the exact
representation for geometries that are currently supported by SQL Server. For unsupported
GeoMedia geometry types, an approximation of the GeoMedia geometry type is stored in the
native geometry column while the actual geometry is stored in the varbinary column. The
approximation is, as follows:
Any and all items required for GeoMedia's CompositePolylineGeometry, even if all the items
are fully supported by the underlying data source, since there is no way to convert it back
to GeoMedia's CompositePolylineGeometry from native format.
Any and all items required for GeoMedia's CompositePolygonGeometry, even if all the
items are fully supported by the underlying data source, because there is no way to convert
it back to GeoMedia's CompositePolygonGeometry from native format.
Any and all items required for GeoMedia's GeometryCollection. The varbinary column is
used only if any of the items are not fully supported by SQL Server's geometry.
For tables created outside Feature Class Definition, the varbinary column Used by GeoMedia
must be added manually, and GeoMedia's metadata must indicate the relationship between
the native geometry column and the varbinary column. GeoMedia's metadata must be
10
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.
SQL Server
Geometry Type
GDO column
content
Native column
content
PointGeometry
POINT (x y z)
OrientedPointGeometry
POINT (x y z)
Full GDO
Exact point, no
orientation
TextPointGeometry
POINT (x y z)
Full GDO
Point origin
LineGeometry
LINESTRING(
Full GDO
Two-point linestring
Exact point
x1 y1 z1,
x2 y2 z2)
PolylineGeometry
LINESTRING(
N-point linestring
x1 y1 z1,
,
xN yN zN)
ArcGeometry
LINESTRING(
x1 y1 z1,
Full GDO
Stroked N-point
linestring
,
xN yN zN)
11
SQL Server
Geometry Type
CompositePolylineGeometry MULTILINESTRING(
(
x11 y11 z11,
,
xN1 yN1 zN1
GDO column
content
Native column
content
Composite
members need to
be approximated
(like arcs) in a
multiline string;
otherwise, exact
multiline string.
),
,
(x1M y1M z1M,
,
xNM yNM zNM
))
PolygonGeometry
POLYGON(
Exact polygon
(
x1 y1 z1,
,
xN yN zN
))
CompositePolygonGeometry MULTILINESTRING(
(
x11 y11 z11,
,
xN1 yN1 zN1
),
,
Composite
members need to
be approximated
(like arcs) in a closed
multiline string;
otherwise. exact
closed multiline
string.
12
SQL Server
Geometry Type
GDO column
content
Native column
content
BoundaryGeometry
POLYGON(
Composite
members need to
be approximated
(like arcs) in a
polygon string;
otherwise, exact
polygon string.
Full GDO
A collection of exact
representations or
(
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)
))
RasterGeometry
POLYGON (
x1 y1 z1,
x2 y2 z2,
x3 y3 z3,
x4 y4 z4,
x1 y1 z1)
GeometryCollection
13
SQL Server
Geometry Type
GDO column
content
geometries,
(exterior, interior)
MULTILINESTRING for cannot be
represented fully
line geometries,
by native type;
MULTIPOLYGON for
otherwise, this
area geometries,
column will be
GEOMETRYCOLLECTIO
NULL.
N when mixed
Native column
content
approximations,
according to the
rules established
above, for each GDO
collection member.
14
binary
varbinary
LongBinary
bit
Boolean
char(size)
varchar(size)
nchar(size)
nvarchar(size)
ntext*
datetime
smalldatetime
Date
decimal(p,s) or
numeric(p,s)
p is precision
s is scale
float
Double
*Memo only
binary
varbinary
LongBinary
int
Long
money
Currency
real
Single
smallint
Integer
tinyint
Byte
uniqueidentifier
GUID
Metadata Required?
Boolean
bit
No
Byte
tinyint
No
Integer
smallint
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
15
16
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:
Binary2SqlGeometry Converts GeoMedia's binary data type to the native GEOMETRY data
type when writing WKB geometry 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.
17
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:
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
18
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
Format types
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.
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.
required for each table type.
A table or view is
19
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.
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.
20
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.
the data server what coordinate system is assigned to the geometry.
It tells
21
GFeatures Table
The GFeatures metadata table stores the table names of all user tables (feature classes).
manipulating the tables listed here, you can make feature classes visible or invisible in
GeoMedia. The table definition is, as follows:
By
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
3 AnySpatial
4 Coverage
33 GraphicsText
10 Point
22
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:
COLUMN_NAME The column in the table that this information apples to.
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:
23
1 Line
2 Area
3 AnySpatial
4 Coverage
5 GraphicsText
10 Point
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.
Use
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:
24
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.
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.
The default
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.
25
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:
26
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.
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.
27
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
MOTEL
TYPE
MARRIOT
NAME
HOLIDAY INN
NAME
TYPE
DAYS INN
NAME
PL_State
28
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:
29
Type The type of edit that has occurred: 1 for insert, 2 for update, and 3 for delete.
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.
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
30
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:
ModifiedTableID is populated with the object ID of the object for which the entry is
created. This field comes from the ModifiedTables view.
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:
31
32
--
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 @TableID INT
DECLARE @ViewID 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
SELECT @TableID=ModifiedTableID FROM ModifiedTables
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
DECLARE @TableID INT
if object_id('tempdb..#DisableModificationLog') is null
SELECT @TableID=ModifiedTableID FROM ModifiedTables
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.
33
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.
34
IF UPDATE(<native_geom_col>)
BEGIN
IF NOT UPDATE(<gdo_geom_col>)
BEGIN
UPDATE <tablename> SET <gdo_geom_col> = NULL
WHERE EXISTS (SELECT NULL FROM INSERTED
WHERE INSERTED.<primaryKeyColumn> = <tablename>.<primaryKeyColumn>
END
END
ELSE IF UPDATE(<gdo_geom_col>)
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.
For native geometries using the GEOMETRY data type, the spatial index is created using the
following syntax:
35
36
37
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.
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
38
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.
39
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 (<1000000 rows per table).
40
Never change the primary key column of a table after the table has been created. This
could make the table inaccessible by GeoMedia Professional. If you need to do this, use
Database Utilities to drop the metadata before altering the table using SQL Servers own
tools. You can re-add the metadata after making the table change. If the table has a
spatial index, you will need to drop it before modifying the primary key.
Do not change data types on existing columns using Feature Class Definition. If you need
to do this, drop the metadata first, make the data type change using SQL Server's
Management Studio, and then re-insert the metadata using Database Utilities.
Renaming a table can take a long time if the table contains data, and by default, SQL Server
will disallow this operation. The rename process creates a copy of the existing table,
deletes the original, re-creates the table with a new name, and then populates the data
back to the newly named table. If you need this capability, you may need to activate the
capability using SQL Server's Management Studio.
Copying an existing table will not work due to the way the metadata for the GDO to native
geometry relationship is handled. If you need to copy a table, use SQL Server's
Management Console.
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.
performance of spatial indexes can vary widely, so if performance is an issue, consider
The
41
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.
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.
42
Database Utilities
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.
43
Database Utilities
44
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.
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
45
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:
FeatureClassName.bcp (one for each feature class or query exported)Data file for loading
data.
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.
46
3. Select Warehouse > Export to > SQL Server to open the Export to SQL Server dialog 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.
47
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.
48
If you
Scroll to the Product Versions table and click the download icon for the document you
want to read.
To read about defects that have been fixed, click Issues Resolved.
Release Notes and Issues Resolved may not be available for the initial release of a
product because an initial release has all new features and no updated features. Some minor
releases may not provide Release Notes or Issues Resolved.
Phone Numbers
For general Intergraph information, please call 1.800.791.3357 (U.S.) or 001.256.730.2000
(international). For worldwide support, please contact your local Intergraph office
(http://www.Intergraph.com/worldwide.aspx). For North American Phone Support, please call
the appropriate number in the following table:
49
Product Family
Phone Numbers
Additional Information
1.877.463.1217
Monday Friday
7:00 a.m. 7:00 p.m., CST
FRAMME
G/Technology
InService
Government/Transportation
Camera Systems
GeoMedia
GIS Imaging
GIPS/GIES
ImageStation
IntelliWhere
MGE
TerraShare
Public Safety
50
Business Intelligence
I/CAD
Mobile Products
Security
Video Analyst
Monday Friday
7:00 a.m. 7:00 p.m., CST
1.877.822.8921
Monday Friday
7:00 a.m. 7:00 p.m., CST
24/7 support for P1 Critical System
Down problems
1.800.633.7248
Hardware
1.800.414.8991
Per-call support and spare parts (7:45 a.m. - 4:00 p.m.). Per-call
support requires PO or credit card
number.
Other Links
To submit sales inquiries, general questions, and comments, please visit our Contact Us Web
page (http://www.intergraph.com/contact/default.aspx).
51
Index
D
Data Storage and Type Matching 7
Database Utilities 32
Delivery and Connection 5
E
Exporting to SQL Server 33
G
GeoMedia Metadata Requirements 12
I
Introduction 5
T
Technical Support and Information 37
W
Working with SQL Server Spatial 27
53