This document provides a developer's guide for working with content in Autodesk LocationLogic, including: - Points of interest (POI) content can be added to and accessed from the LocationLogic database using a defined schema and tables. Extended attributes can be added and mapped to POI types. - Dynamic content is accessed through subscriptions or feature APIs. It requires configuring topics, handlers, filters, views, and authentication. - Road network content supports routing, travel directions, and mapping. Geocoding allows forward and reverse address lookups using constraints. - External data can be accessed by defining sources, linking them to the database, and creating data bridge features. - Maps can be

1. Developer’s Guide:
Working with Content

2. Copyright © 2001-2004 Autodesk, Inc.
All Rights Reserved
This publication, or parts thereof, may not be reproduced in any form, by any method, for any purpose.
AUTODESK, INC. MAKES NO WARRANTY, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE, REGARDING THESE MATERIALS AND MAKES SUCH MATERIALS AVAILABLE SOLELY ON AN
"AS-IS" BASIS.
IN NO EVENT SHALL AUTODESK, INC. BE LIABLE TO ANYONE FOR SPECIAL, COLLATERAL, INCIDENTAL,
OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH OR ARISING OUT OF PURCHASE OR USE OF
THESE MATERIALS. THE SOLE AND EXCLUSIVE LIABILITY TO AUTODESK, INC., REGARDLESS OF THE
FORM OF ACTION, SHALL NOT EXCEED THE PURCHASE PRICE OF THE MATERIALS DESCRIBED HEREIN.
Autodesk, Inc. reserves the right to revise and improve its products as it sees fit. This publication describes the state of this product
at the time of its publication, and may not reflect the product at all times in the future.
Autodesk Trademarks
The following are registered trademarks of Autodesk, Inc., in the USA and/or other countries: Autodesk, Autodesk (logo),
Autodesk MapGuide.
Third Party Trademarks
Ascential GeoLocator is a trademark of Ascential Corporation in the United States and/or other countries.
BEA WebLogic and BEA WebLogic Server are registered trademarks of BEA Systems, Inc. in the United States and/or other
countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United
States and other countries.
Microsoft is a registered trademark of Microsoft Corporation in the United States and/or other countries.
NAVTEQ is a registered trademark of NAVTEQ Corporation in the United States and/or other counties.
Netscape and Netscape Navigator are registered trademarks of Netscape Communications Corporation in the United States and
other countries.
Oracle8i, Oracle9i, and Oracle Spatial are trademarks of Oracle Corporation in the United States and/or other countries.
Red Hat is a registered trademark of Red Hat Corporation in the United States and/or other countries.
True Time Maps is a registered trademark of Tele Atlas, Inc.
All other brand names, product names, or trademarks belong to their respective holders.
Third Party Software Program Credits
This product includes software developed by the Apache Software Foundation (http://www.apache.org/). Copyright © 1999-2004
The Apache Software Foundation.
This product includes the DELI Delivery Context Library. Copyright © Hewlett-Packard Company 2004. All rights reserved.
This product includes the edtFTPj Java FTP Client Library. Copyright © 1999-2004, Enterprise Distributed Technologies Ltd.
This product includes the J-GUID software from ActiveScript. Copyright © 1999-2004 ActiveScript. All rights reserved.
This product includes software from NAVTEQ, Inc. Copyright © 2004 NAVTEQ, Inc. All rights reserved.
This product contains software from Tele Atlas, Inc. Copyright © 2004 Tele Atlas, Inc. All rights reserved.
This product includes the kXML library. Copyright © 2002-2004 Stefan Haustein, Oberhausen, Rhld., Germany.
This product includes Morten's JavaScript Tree Menu. Copyright © 2001-2004, Morten Wang & contributors. All rights reserved.
GOVERNMENT USE
Use, duplication, or disclosure by the U. S. Government is subject to restrictions as set forth in FAR 12.212 (Commercial Computer
Software-Restricted Rights) and DFAR 267.7202 (Rights in Technical Data and Computer Software), as applicable.
Autodesk LocationLogic 5 with Service Pack 1 (5.0.1)
Document Last Revised: June 30, 2004
123456789

3. Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . ix
Audience and Purpose . . . . . . . . . . . . . . . . . . . x
Assumptions and Necessary Skills . . . . . . . . . . . . . . . . x
How This Guide Is Organized . . . . . . . . . . . . . . . . . x
Conventions Used in This Guide . . . . . . . . . . . . . . . . xi
Text Conventions . . . . . . . . . . . . . . . . . . . xi
Code and Syntax Conventions . . . . . . . . . . . . . . xii
Chapter 1 Introduction . . . . . . . . . . . . . . . . . . . 1
About the LocationLogic Database . . . . . . . . . . . . . . . 2
Types of Content . . . . . . . . . . . . . . . . . . . . . 3
LocationLogic Features and Metadata. . . . . . . . . . . . . . . 4
LocationLogic Features . . . . . . . . . . . . . . . . . 5
Feature Metadata . . . . . . . . . . . . . . . . . . . 5
Optimizing the LocationLogic Database Performance. . . . . . . . . . 7
Optimizing Database Content . . . . . . . . . . . . . . . 7
Saving to the Database . . . . . . . . . . . . . . . . . 7
Creating Efficient SQL Queries . . . . . . . . . . . . . . 8
System Requirements . . . . . . . . . . . . . . . . . . . 10
Chapter 2 Points of Interest (POI) Content . . . . . . . . . . . . .11
Overview. . . . . . . . . . . . . . . . . . . . . . . 12
POI Schema . . . . . . . . . . . . . . . . . . . . . . 13
<SS_GA>_POI Parent Table Data Set . . . . . . . . . . . 16
<SS_GA>_POI_NAME Child Table Data Set . . . . . . . . . 18
<SS_GA>_POI_ATTRIBUTE Child Table Data Set . . . . . . . 19
<SS_GA>_DATA_PROVIDER Table Data Set . . . . . . . . 20
Adding Content to the POI Schema . . . . . . . . . . . . . . 20
Accessing POI Content . . . . . . . . . . . . . . . . . . 21
POI Names . . . . . . . . . . . . . . . . . . . . . . 21
Extended Attributes . . . . . . . . . . . . . . . . . . . 22
Adding Extended Attributes to POIs . . . . . . . . . . . . . . 23
Task 1: Inserting Extended Attributes into the Database . . . . . . 23
Task 2: Mapping Extended Attributes to Feature Types . . . . . . 24
Selecting POIs Based on Provider . . . . . . . . . . . . . . . 28
Migration Notes . . . . . . . . . . . . . . . . . . . . 28
iii

4. Chapter 3 Dynamic Content . . . . . . . . . . . . . . . . . .29
Overview . . . . . . . . . . . . . . . . . . . . . . . 30
Accessing Dynamic Content . . . . . . . . . . . . . . . . . 31
Using Subscriptions to Access Dynamic Content . . . . . . . . 31
Using the Feature APIs to Access Dynamic Content . . . . . . . 32
Setting Up LocationLogic for Dynamic Content . . . . . . . . . . 32
Process Overview . . . . . . . . . . . . . . . . . . 33
Task 1: Modifying or Creating Dynamic Content Tables . . . . . . 34
Task 2: Configuring a Content Topic . . . . . . . . . . . . 35
Task 3: Adding Dynamic Content Metadata . . . . . . . . . . 37
Task 4: Configuring a Dispatch Handler . . . . . . . . . . . 39
Task 5: Creating Filtered Feature Categories . . . . . . . . . 41
Task 6: Creating Oracle Views to Support Filtered Feature Categories . 45
Task 7: Configuring a Dynamic Content Adapter . . . . . . . . 51
Task 8: Configuring Content Vendor Authentication . . . . . . . 51
Using Subscriptions . . . . . . . . . . . . . . . . . . . 53
How Subscriptions Are Triggered . . . . . . . . . . . . . 54
Handling Subscription Notifications . . . . . . . . . . . . 56
Chapter 4 Road Network Content . . . . . . . . . . . . . . . .67
Overview . . . . . . . . . . . . . . . . . . . . . . . 68
About Routing . . . . . . . . . . . . . . . . . . . . . 69
Routes, Legs, and Steps . . . . . . . . . . . . . . . . 69
Calculating and Retrieving Routes . . . . . . . . . . . . . 70
About Travel Directions . . . . . . . . . . . . . . . . . . 71
Generating Travel Directions . . . . . . . . . . . . . . 71
Generating Locale-Specific Travel Directions . . . . . . . . . 72
Creating Custom Presentation Views . . . . . . . . . . . . 73
About Mapping . . . . . . . . . . . . . . . . . . . . . 73
Chapter 5 Geocoding . . . . . . . . . . . . . . . . . . . .75
Overview . . . . . . . . . . . . . . . . . . . . . . . 76
The Autodesk LocationLogic Geocoder . . . . . . . . . . . . . 77
Geocoding Constraints . . . . . . . . . . . . . . . . . . 77
Position of Civic Number . . . . . . . . . . . . . . . 77
Support for Street Types in Street Name Field . . . . . . . . . 78
Support for Alternative Characters . . . . . . . . . . . . . 78
Support for Stripped Character Sets . . . . . . . . . . . . 79
Accessing Forward Geocoding . . . . . . . . . . . . . . . . 79
Accessing Reverse Geocoding . . . . . . . . . . . . . . . . 80
Geocoding Results . . . . . . . . . . . . . . . . . . . . 81
Standardized Address . . . . . . . . . . . . . . . . . 81
Match Confidence Level . . . . . . . . . . . . . . . . 81
iv | Contents

5. Match Level . . . . . . . . . . . . . . . . . . . . 81
Geometric Point . . . . . . . . . . . . . . . . . . . 82
Street Network Link Feature ID . . . . . . . . . . . . . . 82
Chapter 6 Accessing External Data from LocationLogic . . . . . . . . 83
Overview . . . . . . . . . . . . . . . . . . . . . . . 84
External Content Requirements . . . . . . . . . . . . . . . . 84
Setting Up LocationLogic for External Content . . . . . . . . . . . 85
Process Overview . . . . . . . . . . . . . . . . . . 85
Task 1: Defining External Content Sources . . . . . . . . . . 85
Task 2: Linking External Content to the LocationLogic Database . . . 87
Task 3: Creating Data Bridge Features . . . . . . . . . . . . 87
Accessing External Content . . . . . . . . . . . . . . . . . 89
Appendix A Designing and Configuring Maps . . . . . . . . . . . . 91
Overview . . . . . . . . . . . . . . . . . . . . . . . 92
Types of Maps . . . . . . . . . . . . . . . . . . . 92
Map Formats . . . . . . . . . . . . . . . . . . . . 93
Map Creation and Configuration Overview . . . . . . . . . . . . 94
Task 1: Authoring Maps . . . . . . . . . . . . . . . . . . 95
Overview . . . . . . . . . . . . . . . . . . . . . 95
Representing a User’s Location . . . . . . . . . . . . . . 96
Representing a Route . . . . . . . . . . . . . . . . . 96
Representing Features . . . . . . . . . . . . . . . . . 97
Designing Maps for Performance . . . . . . . . . . . . . 97
Task 2: Creating Copyright or Branding Overlays . . . . . . . . . . 99
Creating GMX Files. . . . . . . . . . . . . . . . . . 99
Task 3: Configuring Map Manager . . . . . . . . . . . . . . .101
Adjusting the Bounding Box Expansion Factor . . . . . . . . .102
Creating and Using Custom Highlight Styles . . . . . . . . . .102
Task 4: Configuring Geomap . . . . . . . . . . . . . . . . .103
Enabling Anti-Aliasing . . . . . . . . . . . . . . . . .104
Configuring the Color Overrides Property . . . . . . . . . . .104
Appendix B Content Organization . . . . . . . . . . . . . . . .107
Overview . . . . . . . . . . . . . . . . . . . . . . .108
LocationLogic Features . . . . . . . . . . . . . . . . . . .108
Feature Metadata . . . . . . . . . . . . . . . . . . . . .109
Accessing Feature Metadata . . . . . . . . . . . . . . .110
Feature Table Associations. . . . . . . . . . . . . . . . . .110
LocationLogic Feature Types . . . . . . . . . . . . . . . . .111
Feature Type Properties . . . . . . . . . . . . . . . .111
The Feature Type Table . . . . . . . . . . . . . . . .112
Contents | v

6. Associating Features and Feature Types . . . . . . . . . . . . . 113
LocationLogic Feature Categories . . . . . . . . . . . . . . . 114
The Feature Category Table . . . . . . . . . . . . . . . 115
Associating the Content Hierarchy and Feature Category Data . . . . 116
Restricting Access to Feature Categories . . . . . . . . . . . 116
Structuring Feature Categories . . . . . . . . . . . . . . 117
Associating Feature Categories and Feature Types . . . . . . . . . . 119
Accessing Extended LocationLogic Content . . . . . . . . . . . . 120
Adding a New Feature Category . . . . . . . . . . . . . . . 121
Accessing Additional Feature Tables . . . . . . . . . . . . . . 124
Defining Feature Category and Feature Type Associations . . . . . . . 128
Single Feature Type . . . . . . . . . . . . . . . . . 128
Multiple Feature Types . . . . . . . . . . . . . . . . 129
Optimizing Content Searches . . . . . . . . . . . . . . . . 129
Definition . . . . . . . . . . . . . . . . . . . . 129
Content Searches and Content Strategy . . . . . . . . . . . 129
Searching Only Leaf Nodes . . . . . . . . . . . . . . . 130
Searching All Hierarchy Levels. . . . . . . . . . . . . . 132
Streamlining Feature Filters . . . . . . . . . . . . . . . . . 135
Appendix C Using the Content Management Console . . . . . . . . . 137
Overview . . . . . . . . . . . . . . . . . . . . . . . 138
The Content Management Console Interface . . . . . . . . . . . . 139
Rules and Guidelines . . . . . . . . . . . . . . . . . . . 141
Starting the Content Management Console . . . . . . . . . . . . 142
Database Login Elements . . . . . . . . . . . . . . . 142
Login Error Messages. . . . . . . . . . . . . . . . . 145
Managing Feature Categories . . . . . . . . . . . . . . . . 146
Overview. . . . . . . . . . . . . . . . . . . . . 146
Feature Category Elements . . . . . . . . . . . . . . . 146
Viewing Feature Categories . . . . . . . . . . . . . . . 148
Creating Feature Categories . . . . . . . . . . . . . . . 149
Modifying Feature Categories . . . . . . . . . . . . . . 152
Duplicating Feature Categories . . . . . . . . . . . . . . 153
Moving Feature Categories . . . . . . . . . . . . . . . 154
Deleting Feature Categories . . . . . . . . . . . . . . . 154
Managing Feature Types . . . . . . . . . . . . . . . . . . 155
Overview. . . . . . . . . . . . . . . . . . . . . 155
Feature Type Elements . . . . . . . . . . . . . . . . 156
Viewing Feature Types . . . . . . . . . . . . . . . . 157
Creating Feature Types . . . . . . . . . . . . . . . . 158
Modifying Feature Types. . . . . . . . . . . . . . . . 160
Deleting Feature Types . . . . . . . . . . . . . . . . 160
Managing Feature Type Properties . . . . . . . . . . . . . . . 161
vi | Contents

7. Feature Type Property Elements . . . . . . . . . . . . . .162
Viewing Feature Type Properties . . . . . . . . . . . . .163
Creating Feature Type Properties . . . . . . . . . . . . .164
Modifying Feature Type Properties . . . . . . . . . . . . .166
Deleting Feature Type Properties . . . . . . . . . . . . .167
Changing Databases . . . . . . . . . . . . . . . . . . . .168
Logging Out of the Content Management Console . . . . . . . . . .169
Contents | vii

8. viii

9. About This Guide
The Autodesk® LocationLogic platform provides you with the In this chapter
tools you need to build location-based services (LBS) applications. ■ Audience and purpose
■ Assumptions and necessary skills
This guide contains information about the different types of ■ How this guide is organized
■ Conventions used in this guide
content associated with LocationLogic, and how applications can
effectively use it.
This chapter explains what’s in the guide and how it’s organized.
ix

10. Audience and Purpose
This guide is intended for Autodesk® LocationLogic platform and database
administrators, to help them plan and maintain LocationLogic content and its
organization, and application developers, to help them effectively use the LocationLogic
content in their applications.
Assumptions and Necessary Skills
No particular administrative, database, or programming skills are necessary to understand
the conceptual information presented in this guide. However, specific procedures may
assume any of the following:
■ You are familiar with the Solaris 8 operating system and have root privileges on the
machines on which you will be executing database SQL commands.
■ You are familiar with third-party software, such as Oracle9i™ Enterprise Edition
9.2.0.4 and BEA WebLogic Server™.
■ You are familiar with creating and running SQL scripts.
■ You are familiar with LocationLogic, and at least one of the LocationLogic APIs used
for creating LocationLogic applications.
For installation and configuration of the Oracle database on Intel® Itanium® architecture
on HP Integrity Linux systems, it is assumed that you are familiar with Red Hat Linux
Advanced Server and have root privileges on the machines on which you will be
executing database SQL commands.
How This Guide Is Organized
This guide is organized as follows:
■ Chapter 1, “Introduction,” introduces you to the LocationLogic database and the types
of content used by LocationLogic.
■ Chapter 2, “Points of Interest (POI) Content,” describes LocationLogic POI (Point of
Interest) content, related administration functions (such as adding POI-related
information to the database), and how LocationLogic applications use POI content.
■ Chapter 3, “Dynamic Content,” describes what dynamic content is, why it is used, how
LocationLogic applications can access it, and how to set up LocationLogic to
incorporate dynamic content.
x | About This Guide

11. ■ Chapter 4, “Road Network Content,” describes road network content, how it is used
by LocationLogic to generate maps and travel directions, and how LocationLogic
applications can access those functions.
■ Chapter 5, “Geocoding,” describes what geocoding is, the LocationLogic geocoding
components, and how applications can use geocoding.
■ Chapter 6, “Accessing External Data from LocationLogic,” describes how
applications can access content that is in external databases, and how to set up
LocationLogic to enable such access.
■ Appendix A, “Designing and Configuring Maps,” describes the map files used by
Autodesk® LocationLogic, how to author maps for application use, and how to
configure the necessary LocationLogic components to obtain the desired map
appearance when the maps are retrieved by applications.
■ Appendix B, “Content Organization,” describes how different types of LocationLogic
features, including points of interest, bookmarked information, and so forth, are
organized in the LocationLogic database.
■ Appendix C, “Using the Content Management Console,” explains how to use the
Content Management Console to manage LocationLogic content metadata (feature
categories and feature types).
Refer to the Autodesk LocationLogic Glossary for a listing of terms and definitions
relating to LocationLogic and to the GIS (Geographic Information Systems) and wireless
industries in general.
Conventions Used in This Guide
This section describes the following conventions used in this guide:
■ Text conventions
■ Code and syntax conventions
Text Conventions
This guide uses the following text conventions:
■ Italic is used to introduce new terms. Italic is also used for database column names,
file and folder names, and book titles.
■ Bold is used for any text you must enter, such as at a command line prompt or in a
dialog box.
■ A monospace font is used for all code elements (variable names, data values,
method names, and so forth), command lines, scripts, and source code listings.
Conventions Used in This Guide | xi

12. ■ Bold italic monospace is used for replaceable elements and placeholders within
code listings.
Code and Syntax Conventions
This guide uses the following code and syntax conventions:
■ Indentation and line breaks have been added to make examples more legible.
However, if you are copying the example code for your own use, do not use line breaks
in an actual command:
■ Although line breaks are valid if the preceding line ends in a backslash, there should
not be leading spaces in an actual command.
The following table describes conventions used in this manual:
These Indicate this...
symbols...
| The vertical-bar or pipe symbol separates alternative items that may be
optional or required. You may choose exactly one of the given items. Do not
type the vertical bar. For example, the text:
A | B | C
indicates that you should choose only one item—A or B or C.
[] Square brackets enclose one or more optional items. Do not type the brackets.
For example, the text:
[A | B | C]
indicates that you can choose no items or a single item—A or B or C.
While the text:
[D]
indicates that you can choose no items or item D.
{} Braces enclose one or more required items. Do not type the braces. For
example, the text:
{A | B | C}
indicates that you must choose a single item—A or B or C.
... Ellipses mean that the preceding item(s) may be repeated any number of
times.
xii | About This Guide

13. Conventions Used in This Guide | xiii

14. xiv

15. 1
Introduction
This chapter introduces you to the Autodesk® LocationLogic In this chapter
database and the types of content used by LocationLogic. ■ About the LocationLogic
database
■ Types of content
■ LocationLogic features and
metadata
■ Optimizing the LocationLogic
database performance
■ System requirements
1

16. About the LocationLogic Database
The LocationLogic database is the repository of content used by LocationLogic software
components and application code. All content is included in the database, except certain
geographic content that is contained in files so as to optimize LocationLogic
performance.
LocationLogic applications access content in the LocationLogic database to provide users
with a rich variety of location-based services, such as, for example:
■ Information about current local weather and traffic conditions
■ Routing services, with maps and turn-by-turn navigation instructions
■ Assistance in finding nearby places of business and entertainment
■ Real-time tracking of friends, mobile objects, service personnel, and fleet equipment
■ Real-time user handset notification of spatial events, including traffic incidents along
a frequently traveled route
The LocationLogic database consists of a standard set of LocationLogic content tables, as
well as tables that contain organizational metadata describing how LocationLogic content
items are related to each other in a hierarchical fashion. These tables are installed during
deployment, as described in the Autodesk LocationLogic Installation Guide.
The following sections describe the LocationLogic database in more detail, explaining the
types of content included, how to optimize database performance, and the database
system requirements.
2 | Chapter 1 Introduction

17. Types of Content
To provide users with a rich variety of location-based services, LocationLogic uses many
types of content:
■ Point of Interest (POI) content—Data describing places of business and
entertainment, as well as medical facilities, government buildings, museums, and so
forth. Standard POI content is provided by vendors such as NAVTEQ and Tele Atlas,
but POI content can also include custom data that you supply (see “Extended
Attributes” on page 22). POI content is stored in the LocationLogic database, and is
static—it remains unchanged in the database until you replace it with an updated
content data set.
LocationLogic applications use POI content to answer user questions such as, “Which
Chinese restaurants are within 5 miles of my hotel?” and “Are there any libraries on
my way home from work?”
For more information about administering and using POI content, see Chapter 2,
“Points of Interest (POI) Content”.
■ Dynamic content—Data that frequently changes, such as traffic incidents along
specific routes, current weather conditions, or mobile objects such as LocationLogic
users. This data is stored in the LocationLogic database.
LocationLogic applications use dynamic content to answer user requests such as, “Are
there any accidents on my way home?” and “Send me a message when Stephanie gets
within a mile of where I am,” and to provide services such as fleet tracking. For more
information about administering and using dynamic content, see Chapter 3, “Dynamic
Content”.
■ Road network content—Navigation information about a set of roads, such as how
they are connected, their posted speed limits, accessibility (for example, carpool only
or bike route), and so forth. This information is obtained from vendors such as
NAVTEQ and Tele Atlas, and is stored in the LocationLogic database.
LocationLogic uses road network content to generate maps and travel directions as
requested by LocationLogic applications. For more information about the road
network content, see Chapter 4, “Road Network Content”.
■ Geocoding content—Static geographic data representing road coordinates, address
ranges, POIs, and so forth, derived from road network and POI content received from
content vendors. Geocoding content is stored as files on the LocationLogic server.
Types of Content | 3

18. LocationLogic uses geocoding content to perform forward geocoding (translating a
street address to a geographic coordinate, or point) and reverse geocoding (translating
a geographic coordinate, or point, to a street address). For more information about the
geocoding content, see Chapter 5, “Geocoding”.
■ External content—Data that is stored external to the LocationLogic database. There
is no limit as to what this data can represent. It can be user profile data that a carrier
wishes to keep private, custom features that are not in the standard NAVTEQ or Tele
Atlas content data sets, and so on.
LocationLogic applications can retrieve and query external content any time, and use
it for any purpose. Applications send requests for external content to LocationLogic,
which accesses the external content using a LocationLogic data bridge—the
mechanism that links external content to the LocationLogic database. For more
information about configuring and using external content, see Chapter 6, “Accessing
External Data from LocationLogic”.
■ Mapping content—Geographic basemap data that represents spatial information
such as roads, cities, and countries. It is derived from road network content, and stored
as Autodesk MapGuide® SDF files (which contain spatial information, such as roads,
cities, and countries) and MWF files (which contain pointers to groups of SDF files
that, when combined, form a cohesive map).
LocationLogic uses mapping content as the basis for creating maps for display on
various devices, as requested by LocationLogic applications. For more information,
see Appendix A, “Designing and Configuring Maps”.
LocationLogic Features and Metadata
From an API point of view, the content items stored in the LocationLogic database are
known as “features,” and the metadata describing the relationships between the features
is known as “feature metadata.”
LocationLogic applications access content items in the LocationLogic database using
feature-related calls. For example, the Java API method to retrieve all features that are
within a specified distance of a given location is findFeaturesWithinDistance.
This call is used to access any type of content in the database.
This section explains more about what these terms mean in the context of the
LocationLogic database.
4 | Chapter 1 Introduction

19. LocationLogic Features
LocationLogic feature is the term used to identify any content item in the LocationLogic
database that can be accessed and queried by LocationLogic applications. LocationLogic
features include, but are not limited to
■ Places, such as points of interest (POIs), businesses, and facilities
■ Mobile objects, such as LocationLogic users
■ Dynamic content, such as current traffic conditions
■ User information, such as history, bookmarked routes and locations, or personal
information
Every LocationLogic application organizes the LocationLogic features into a content
hierarchy of logical groupings. For example, one application may use a broad category of
Asian restaurants, while another application might divide them into Japanese restaurants,
Chinese restaurants, and so forth. This logical grouping of LocationLogic features in the
content hierarchy is independent of the underlying database content and schema. That is,
LocationLogic features can be grouped together in the content hierarchy regardless of
whether or not they are in the same database table, or even whether or not their database
records contain the same data fields (columns).
Any LocationLogic database table that contains features is referred to as a feature table.
Although different types of LocationLogic features have different properties (the data
fields, or columns, that contain a feature’s identifying characteristics, such as name,
address, and so forth) in their feature tables, your applications will use the same methods
to search through any feature table, and to identify any LocationLogic feature’s
properties.
Related Topic
■ See Appendix B, “Content Organization,” for more detailed information about
LocationLogic features and feature tables.
Feature Metadata
Feature metadata is the term used for information that describes
■ The hierarchical relationships (content hierarchy) between LocationLogic features
■ The location of a feature’s database record (where it exists within the LocationLogic
database or an external database)
LocationLogic Features and Metadata | 5

20. By using feature metadata, LocationLogic applications can efficiently access
LocationLogic features. In addition, you use feature metadata to enable certain kinds of
content use, such as incorporating dynamic content into the LocationLogic database.
There are three types of metadata, which together describe a LocationLogic feature:
■ Feature category—A logical grouping of LocationLogic features (POIs, mobile
objects, and so forth), as defined for a particular application. Feature categories
correspond to an application’s content hierarchy (see “LocationLogic Features” on
page 5), and enable applications to efficiently access and navigate the database to find
the feature a user is looking for. Typical feature categories are POIs,
RESTAURANTS, and BANKS.
■ Feature type—An identifier for a group of LocationLogic features that share
common characteristics, such as their source content vendor (for example, NAVTEQ),
or common characteristics that might be used to query them (for example, foodtype
for restaurants).
Depending on the quantity and sort of LocationLogic features in your deployment,
your feature types may be very broad, such as NT_POI to refer to all NAVTEQ-
provided POIs, or more granular, such as NT_RESTAURANTS and NT_BANKS,
which describe the characteristics of two separate sets of data: NAVTEQ-provided
restaurants and banks, respectively.
■ Feature type properties—The set of characteristics that, when taken together, fully
describe a feature type; for example, the feature type’s data source, as well as
characteristics of the feature type, such as FOODTYPE and NAME in the case of a
RESTAURANT feature type. Every feature type is described by the following feature
type properties:
❏ FDATASRC. Identifies the data source of the feature table where the corresponding
features are stored; for example, jdbc/Oracle.
❏ FTABLE. Identifies the name of the table where the corresponding features are
stored; for example, NT_NA_RESTAURANTS.
❏ Multiple properties that identify every field of a LocationLogic feature’s database
record which LocationLogic applications can access; for example, FOODTYPE,
NAME, and FACILITYTYPE.
Related Topic
■ See Appendix B, “Content Organization,” for more detailed information about how
LocationLogic feature metadata is used; for example, to optimize content searches.
6 | Chapter 1 Introduction

21. Optimizing the LocationLogic Database
Performance
This section offers tips for improving LocationLogic database performance. The
following topics are covered:
■ Optimizing database tables
■ Saving changes to the database
■ Creating efficient SQL queries
Optimizing Database Content
If you notice poor performance when reading or writing to the LocationLogic database,
work with your database administrator to confirm that the database is optimized to work
with your application. This is especially important if you have extended the database with
additional custom tables or columns.
How you optimize the database will depend on your data and the manner in which your
application accesses it. For example, you might need to create context indexes for POI
tables, or spatial indexes for table columns containing location geometry information.
Saving to the Database
Writing to the LocationLogic database is a time-consuming operation, so such operations
should be used sparingly.
Usually, the best strategy is to commit several changes at once. For example, if you create
and add three new features, it is faster save those features with a single call (for example,
LbsFeatureManager.saveChanges in the Java API), rather than calling the
method three times.
Note The exception to this rule is an application that updates many records at once. For
example, a notification application might create thousands of subscriptions for users who
have granted permission to do so. In this case, it is better to save five or ten subscriptions
at a time, rather than waiting to commit thousands of changes at once. Besides reducing
the chance of lost data, saving in smaller batches also releases system resources, resulting
in better performance.
Optimizing the LocationLogic Database Performance | 7

22. Another option is to save data infrequently, perhaps only when the user exits a screen or
logs out of the application. This is appropriate only in cases where data loss is not a major
concern. Or you might give users the option of deciding when to write the data, via a
‘Save’ button or some other interface element. A user who has caused an action may be
more tolerant of the associated performance hit.
Creating Efficient SQL Queries
Many feature- and subscription-related API calls (for example,
LbsFeatureCategory.findFeatures in the Java API) take as an argument a
string representing the contents of a SQL WHERE clause. By optimizing the SQL queries
passed to these methods, you can make your application considerably faster.
General Guidelines
When creating a SQL query, constrain your search to return the smallest result set
possible. Minimize the use of wildcards and, if possible, make sure your WHERE clauses
make use of indexed columns. Avoid the use of SQL functions (for example, UPPER or
INIT) in WHERE clauses.
Use of the GEOM Property
By setting feature properties, you control which fields should be populated in features
returned by the feature category query methods.
Setting the GEOM property causes returned features to contain associated Oracle spatial
data. Retrieving spatial data is time-consuming, so you should set this property only if
your application requires it.
For more information, refer to the descriptions of LbsFeature and
LbsFeatureCategory in the Autodesk LocationLogic Java API Reference.
8 | Chapter 1 Introduction

23. Using Wildcards for Pattern Matching in Large Tables
For large tables, use of the LIKE operator in a SQL WHERE clause can result in slow
query performance.
The LIKE operator is used to compare a value to a pattern containing special wildcard
characters, such as percent (%) and underscore (_). For example, the following query
searches the POINAME table for a value that includes the substring “RESTAURANTS”:
poiname LIKE '%RESTAURANT%'
If the comparison pattern starts with either of these special characters, Oracle will not be
able to use the normal Btree index on the column referenced in the LIKE predicate. Under
these conditions, a full database table scan is performed.
To avoid this performance hit, do the following:
■ Set up a context index for the POINAME table.
By default, the POINAME table does not have a context index set up. To set up a
context index, you need the Oracle CTX indexing package installed. This package is
installed by default when you create a database with the Database Configuration
Assistant. For more information, see your Oracle documentation.
■ Modify the query, by replacing the LIKE clause with a CONTAINS clause that takes
advantage of the context index.
For example, replace:
LIKE '%RESTAURANTS%'
with
CONTAINS(POINAME, '%RESTAURANTS%') > 0
Warning A table’s context index is not updated automatically when you perform DML
operations (Insert, Update, and Delete). Refer to the Oracle documentation to learn about
the maintenance of context indexes before implementation.
Optimizing the LocationLogic Database Performance | 9

24. System Requirements
The hard disk requirements for the LocationLogic database vary depending on many
factors, including the following:
■ The version of vendor content you are using—Different versions have different
numbers of records.
■ The number of countries for which you have POI and road network data—The more
countries you include, the more records the database needs.
■ Which countries you are including—Smaller countries have fewer POIs and roads
than larger countries.
■ The types of maps you are generating—Higher resolution maps require bigger
mapping files than lower resolution maps.
For specific requirements, refer to either the NAVTEQ or Tele Atlas Content Release
Notes for your geographic area (if applicable) and LocationLogic version.
10 | Chapter 1 Introduction

25. 2
Points of Interest (POI) Content
LocationLogic applications use POI (Point of Interest) content to In this chapter
answer user questions, such as, “Which Chinese restaurants are ■ Overview
■ POI schema
within 5 miles of my hotel?” and “Are there any libraries on my
■ Adding content to the POI
schema
way home from work?”
■ Accessing POI content
This chapter describes LocationLogic POI content, related ■ POI names
■ Extended attributes
administration functions (such as adding POI-related information
■ Adding extended attributes to
POIs
to the database), and how LocationLogic applications use POI
■ Selecting POIs based on provider
content. ■ Migration notes
11

26. Overview
POI (Point of Interest) content is vendor-supplied content describing places of business
and entertainment, as well as medical facilities, government buildings, museums, or any
place that has a location (address).
In addition to the vendor-supplied content, LocationLogic includes the following POI-
related content (which is always associated with a specific POI):
■ Alternate names of POIs (see “POI Names” on page 21)
■ Custom data that you supply (see “Extended Attributes” on page 22)
■ Identification of the source of all POI and POI-related content (see “Selecting POIs
Based on Provider” on page 28)
LocationLogic applications use this additional POI-related content to provide both a
richer set of information to users, and better matches (differentiation between POIs) for
user requests.
POIs and POI-related content are stored in the LocationLogic database, in a set of POI
tables. LocationLogic applications query the POI tables to answer user questions, such as
“What Chinese restaurants are near me?” The content in the POI tables is used to identify
and differentiate one POI from another, based on its properties, such as SIC (Standard
Industrial Classification), facility type, and so forth.
POIs are stored in the LocationLogic database in a hierarchical structure as
LocationLogic features, and are described and identified by metadata elements such as the
feature category and feature types. (For more information, see “LocationLogic Features
and Metadata” on page 4.) Applications can access POIs by using the feature-related
methods in the LocationLogic APIs (see “Accessing POI Content” on page 21.)
POIs have associated properties—fields of information (columns in their database
tables), such as name, location, phone number, and so forth. Applications use POI
properties to access and query POI records based on the values of specific fields within
the records.
Note POI properties are not the same as feature type properties (see “Feature Metadata”
on page 5). Feature type properties describe characteristics of feature types, such as
database names. POI properties describe fields within POI data records.
12 | Chapter 2 Points of Interest (POI) Content

27. The following sections provide details about POI records in the LocationLogic database,
how LocationLogic applications can use the POI information, and how to administer and
maintain POI information in the LocationLogic database:
■ “POI Schema” on page 13
■ “Adding Content to the POI Schema” on page 20
■ “Accessing POI Content” on page 21
■ “POI Names” on page 21
■ “Extended Attributes” on page 22
■ “Adding Extended Attributes to POIs” on page 23
■ “Selecting POIs Based on Provider” on page 28
■ “Migration Notes” on page 28
POI Schema
The POI schema identifies every field in the POI tables, the field’s data type and size, and
the primary and foreign keys. You need this information in order to add entries to the
database tables (for example, adding extended attributes, as described in “Adding
Extended Attributes to POIs” on page 23), and so that your LocationLogic applications
can correctly retrieve the desired information from the POI and POI-related tables.
The POI schema consists of four related tables. Each POI table name begins with the same
prefix, <SS_GA>_, where SS indicates the data source, such as NT for NAVTEQ; and
GA indicates the geographic area, such as IT for Italy. There are four POI tables:
■ <SS_GA>_POI—The POI parent table; contains basic information for every POI that
is supplied by a data provider (content vendor), such as its name, address, and data
provider id. For information about using POI content, see “Accessing POI Content,”
on page 21.
The <SS_GA>_POI table’s primary key, poi_id, is used as a foreign key link by
the <SS_GA>_POI_NAME and <SS_GA>_POI_ATTRIBUTE child tables.
LocationLogic uses this link to enable applications to access the POI content in the
child tables, as described in “POI Names” on page 21, and “Extended Attributes” on
page 22.
POI Schema | 13

28. ■ <SS_GA>_POI_NAME—A POI child table; contains POI names that can be used in
addition to a POI’s main name that is included in the POI parent table. For information
about using multiple names, see “POI Names,” on page 21.
■ <SS_GA>_POI_ATTRIBUTE—A POI child table; contains extended attribute
information (custom data) that you have added to POIs. For information about using
extended attributes, see “Extended Attributes,” on page 22. For information about
adding extended attributes, see “Adding Extended Attributes to POIs,” on page 23.
■ <SS_GA>_DATA_PROVIDER—A reference lookup table; maps a POI’s data
provider id to the provider’s name. For information about using the data provider
information, see “Selecting POIs Based on Provider,” on page 28.
The <SS_GA>_DATA_PROVIDER lookup table’s primary key,
data_provider_id, is used as a foreign key link by the other POI tables, which
enables applications to determine the name of the data provider that was the source of
any POI’s information (see “Selecting POIs Based on Provider” on page 28.)
The following sections describe the properties of each POI table:
■ “<SS_GA>_POI Parent Table Data Set” on page 16
■ “<SS_GA>_POI_ATTRIBUTE Child Table Data Set” on page 19
■ “<SS_GA>_POI_NAME Child Table Data Set” on page 18
■ “<SS_GA>_DATA_PROVIDER Table Data Set” on page 20
14 | Chapter 2 Points of Interest (POI) Content

29. The following entity relationship diagram (ERD) illustrates the schema for each POI
table, and the relationships between the tables:
SS_GA_poi SS_GA_poi_attribute
PK poi_id* NUMBER(19) PK poi_attribute_id* NUMBER(19)
FK link_id NUMBER(19) FK poi_id* NUMBER(19)
FK facility_type_id* NUMBER(19) attribute_name* VARCHAR2(50)
chain_id NUMBER(5) attribute_value* VARCHAR2(255)
FK food_type_id NUMBER(10) insert_date* DATE
poi_name VARCHAR2(100) update_date* DATE
phone_num VARCHAR2(25) FK data_provider_id* NUMBER(19)
street_side CHAR(1)
address VARCHAR2(100)
lang_code VARCHAR2(2)
city VARCHAR2(70) SS_GA_data_provider
state VARCHAR2(2)
country VARCHAR2(3) PK data_provider_id* NUMBER(19)
postal_code VARCHAR2(10) data_provider_name* VARCHAR2(50)
lon NUMBER(15,8)
lat NUMBER(15,8)
insert_date* DATE
update_date* DATE
FK data_provider_id* NUMBER(19) SS_GA_poi_name
geom* VARCHAR2(0) PK poi_nam e_id* NUMBER(19)
FK poi_id* NUMBER(19)
name_type VARCHAR2(2)
name* VARCHAR2(100)
Legend lang_code VARCHAR2(2)
PK primary key
insert_date* DATE
FK foreign key
update_date* DATE
* not null
FK data_provider_id* NUMBER(19)
POI Entity Relationship Diagram (ERD)
POI Schema | 15

30. <SS_GA>_POI Parent Table Data Set
The <SS_GA>_POI parent table contains basic information for every POI that is
supplied by a data provider (content vendor), such as its name, address, and data provider
id. (For information about using POI content, see “Accessing POI Content,” on page 21.)
The following table describes the <SS_GA>_POI parent table’s data set:
<SS_GA>_POI Parent Table Data Set (1 of 2)
Physical Column Name Description Column Notes
POI_ID Unique ID of this POI primary key
LINK_ID The link ID of the road network segment foreign key
(transportation link) on which this POI is
located
FACILITY_TYPE_ID The ID of this POI’s facility type foreign key
CHAIN_ID Indicates whether this POI belongs to a
chain; for example, McDonald’s.
FOOD_TYPE_ID The ID of this POI’s food type (used with foreign key
restaurant facilities only)
POI_NAME Name of this POI
PHONE_NUM Phone number of this POI
STREET_SIDE Side of street that this POI is on:
• L—Left
• R—Right
• NULL—unknown or no data
ADDRESS Address of this POI
LANG_CODE Language code associated with this POI’s
name (POI_NAME)
CITY City where this POI is located
STATE State (or country subdivision, such as
Région in France or Kanton in
Switzerland) where this POI is located
16 | Chapter 2 Points of Interest (POI) Content

31. <SS_GA>_POI Parent Table Data Set (2 of 2)
Physical Column Name Description Column Notes
COUNTRY Country where this POI is located
POSTAL_CODE Postal code of this POI
LON Longitudinal representation of the location
of this POI
LAT Latitudinal representation of the location
of this POI
INSERT_DATE The date this record was first added to the
database
UPDATE_DATE The date of the most recent update to this
record
DATA_PROVIDER_ID Unique identifier of the data provider
(content vendor), such as 1 for NAVTEQ,
or 100 for a custom data record provider,
such as yourCompanyName
GEOM Location of this POI, in lat/lon format
POI Schema | 17

32. <SS_GA>_POI_NAME Child Table Data Set
The <SS_GA>_POI_NAME child table contains alternate names (such as synonyms and
exonyms) for POIs. (For more information about using alternate names, see “POI Names”
on page 21.) The following table describes the <SS_GA>_POI_NAME table’s data set:
<SS_GA>_POI_NAME Child Table Data Set
Physical Column Name Description Column Notes
POI_NAME_ID Unique ID of this alternate POI name primary key
POI_ID ID of the POI to which this alternate name foreign key
applies
NAME_TYPE Data provider (content vendor) specific
code indicating the type of alternate name.
For NAVTEQ POIs, values are:
• B—Base name
• E—Exonym
• S—Synonym
• U—Unnamed
For Tele Atlas POIs, values are:
• ON—Official name
• AN—Alternate name
NAME The alternate POI name
LANG_CODE ISO 639 two-letter language code
associated with this alternate POI name
INSERT_DATE The date this record was first added to the
database
UPDATE_DATE The date of the most recent update to this
record
DATA_PROVIDER_ID Unique identifier of the data provider, such foreign key
as 1 for NAVTEQ, or 100 for a custom
data record provider, such as
yourCompanyName
18 | Chapter 2 Points of Interest (POI) Content

33. <SS_GA>_POI_ATTRIBUTE Child Table Data Set
The <SS_GA>_POI_ATTRIBUTE child table contains all the extended attributes that
have been added to the POIs. It provides for an unlimited number of extended attributes
for any POI. (For information about using extended attributes, see “Extended Attributes,”
on page 22. For information about adding extended attributes, see “Adding Extended
Attributes to POIs,” on page 23.) The following table describes the
<SS_GA>_POI_ATTRIBUTE table’s data set:
<SS_GA>_POI_ATTRIBUTE Child Table Data Set
Physical Column Name Description Column Notes
POI_ATTRIBUTE_ID Unique ID of this extended attribute primary key
POI_ID ID of the POI to which this extended foreign key
attribute belongs
ATTRIBUTE_NAME Unique name used to identify this
extended attribute when requesting
LocationLogic POI information
ATTRIBUTE_VALUE The value of the extended attribute. Note
that the value is stored as
VARCHAR2(50), regardless of the actual
data type. The feature type mapping must
explicitly perform any required data
conversion. (See “Task 2: Mapping
Extended Attributes to Feature Types” on
page 24.)
INSERT_DATE The date this record was first added to the
database
UPDATE_DATE The date of the most recent update to this
record
DATA_PROVIDER_ID Unique identifier of the data provider foreign key
(content vendor), such as 1 for NAVTEQ,
or 100 for a custom data record provider,
such as yourCompanyName
POI Schema | 19

34. <SS_GA>_DATA_PROVIDER Table Data Set
The <SS_GA>_DATA_PROVIDER table is a reference lookup table that maps a POI’s
data provider (content vendor) id to the provider’s (vendor’s) name. (For information
about using the data provider content, see “Selecting POIs Based on Provider,” on page
28.) The following table describes the <SS_GA>_DATA_PROVIDER table’s data set:
<SS_GA>_DATA_PROVIDER Child Table Data Set
Physical Column Name Description Column Notes
DATA_PROVIDER_ID Unique ID used to identify a data record’s primary key
source:
• 1—NAVTEQ
• 2—Tele Atlas
• 100 and higher—Custom data
DATA_PROVIDER_NAME The data provider’s name
Adding Content to the POI Schema
If your application requires POI content beyond what can be accommodated in the
LocationLogic POI schema, you can use any of the following techniques to extend the
schema:
■ Add additional columns to the <SS_GA>_POI parent table, and expose the new
content to LocationLogic by adding feature type properties (described in “Feature
Metadata” on page 5.) For more information, see “Accessing Extended LocationLogic
Content” on page 120.
■ Create new LocationLogic feature tables in which to store the new information, and
expose it to LocationLogic by using a database view that joins the <SS_GA>_POI
table to the new tables, or by adding feature types (described in “Feature Metadata”
on page 5.) For more information, see “Accessing Additional Feature Tables” on
page 124.
■ Insert the new information into the <SS_GA>_POI_ATTRIBUTE extended attribute
table. For more information, see “Extended Attributes,” on page 22, and “Adding
Extended Attributes to POIs,” on page 23.
Determining the best technique to use to add POI content depends on many factors, such
as the source of the information, the frequency with which it is updated, the number of
attributes, and each attribute’s type. It is recommended that you contact your Autodesk
Professional Services representative before choosing a particular method.
20 | Chapter 2 Points of Interest (POI) Content

35. Accessing POI Content
Because POIs are a type of LocationLogic feature (see “LocationLogic Features” on
page 5), LocationLogic applications access them by using the LocationLogic feature
methods.
Each type of LocationLogic API and deployment environment provides methods for
applications to specify and retrieve content items, in this case, POIs. The following list
describes the different techniques that you can use to access content items (features) in
the LocationLogic database:
■ Applications built using the LocationLogic Java API—Use the LbsFeature,
LbsFeatureCategory, and LbsFeatureManager classes and interfaces. For
more information, refer to the Autodesk LocationLogic Developer’s Guide and the
Autodesk LocationLogic Java API Reference.
■ Applications built using LocationLogic XML Web Services—Use the
DirectoryRequest element, and associated child elements. For more
information, refer to the Autodesk LocationLogic XML Web Services Developer’s
Guide.
■ Remote J2ME applications—Use the LbsmeDirectoryRequest, LbsmePOI,
and LbsmePOIProperty objects and methods. For more information, refer to the
Autodesk LocationLogic J2ME Developer’s Guide.
POI Names
POIs can have alternate names, such as synonyms and exonyms (names in a language
other than the national language; for example, Munich is an exonym for München.) This
gives LocationLogic applications the ability to display POI names in a variety of
languages. Your application can choose which name to display based on any criterion; for
example, a user’s profile configuration that includes their preferred language.
In addition to displaying alternate POI names, LocationLogic applications can query POIs
based on user input, regardless of which language a user chooses. Applications can make
a single query, and receive matches for all records for the POI, no matter whether the
name requested is the “main” name or an alternate name.
Notes
■ When querying POIs (see “Accessing POI Content” on page 21), you must take care
not to confuse similarly named columns:
❏ In the <SS_GA>_POI parent table, the POI_NAME column’s value is the “main”
name for the POI, as received from the data provider (content vendor.)
Accessing POI Content | 21

36. ❏ In the <SS_GA>_POI_NAME child table, the NAME column’s value is the
“alternate” name of the POI (whether exonym, synonym, or so forth.)
■ To retrieve a POI’s multiple alternate names when accessing POIs (as described in
“Accessing POI Content” on page 21), you include the alternate name properties
(NAME_TYPE, NAME, LANGCODE) when you specify the POI properties to be
returned.
Extended Attributes
You have the flexibility to add an unlimited amount of custom content to any POI,
without the need for any schema changes or LocationLogic coding updates. For example,
you could add a data field called SMOKING to indicate whether an establishment allows
smoking within its premises.
Extended attributes is the term used to describe any POI information that is not included
in the standard <SS_GA>_POI parent table’s data set:
■ Custom content that you supply (see “Adding Extended Attributes to POIs” on
page 23.)
■ Information from content vendors who supply POI-related content for which there is
no field in the <SS_GA>_POI parent table. (This information is included in the
LocationLogic database during content deployment.)
Adding extended attributes is especially useful when you want to add information about
a POI that is only meaningful to a particular type of POI. For example, population is
something that is meaningful to places such as countries and cities, while an indication of
whether smoking is allowed is typically applicable to restaurants.
The extended attribute content is stored in the extended attribute table—the
<SS_GA>_POI_ATTRIBUTE POI child table.
The custom content that you can store in the extended attribute table must comply with
the following rules:
■ Each individual extended attribute must be single-valued—that is, it can contain only
a single value, such as YES, but not a list of values, such as “Saturday, Sunday”.
■ Extended attribute values are stored as text, with a maximum of 255 characters. To add
a custom field with a non-text value, for example an indication of the number of
Michelin stars a restaurant has received, you must explicitly perform the data
conversion (using an appropriate Oracle function, such as to_number), when you
add the extended attribute, as described in “Task 2: Mapping Extended Attributes to
Feature Types” on page 24.
22 | Chapter 2 Points of Interest (POI) Content

37. Note If you choose to include extended attribute information in your LocationLogic
database, you must be sure to consider how you will carry it forward when you update
your content vendor-provided POI content. Extended attributes are linked to POIs
through the vendor-provided ID, which may change from release to release. Therefore, it
is important that you determine additional ways to link an extended attribute and its parent
POI; for example, using additional attributes such as a POI’s name, address, and so forth,
that can later be used to determine the intended POI for any extended attribute. For
additional content update considerations, see “Migration Notes” on page 28.
Adding Extended Attributes to POIs
The following table describes the steps required to add extended attributes to POIs:
Process Overview: Adding Extended Attributes to POIs
Task Description Refer to
1 Insert extended attribute records into the POI child “Task 1: Inserting Extended
table, POI_ATTRIBUTE, by executing a series of Attributes into the Database”
SQL statements. on page 23
2 Associate extended attributes with feature types to “Task 2: Mapping Extended
enable access to the new POI field data. Attributes to Feature Types”
on page 24
Task 1: Inserting Extended Attributes into the
Database
You can add one or more extended attributes to any POI(s) in the database by executing
a series of SQL statements. You can execute them at the command line, but it’s
recommended that your create a script that contains all the commands for all the extended
attributes you want to add.
To insert a new extended attribute into the POI_ATTRIBUTE table
Note In this procedure, <SS_GA> indicates the table prefix name, which consists of the
data source abbreviation (such as NT for NAVTEQ) and geographic area (such as NA for
North America). In your commands, be sure to replace the <SS_GA> with your actual
table prefix designation.
1 Using SQL*Plus, connect to the database using the Oracle user ID created to contain
and manage the content tables.
Adding Extended Attributes to POIs | 23

38. This user ID must have insert, update, and delete privileges for your deployment’s
content tables. Refer to the Content Release Notes for your deployment’s content
vendor, geographic area, and LocationLogic version, for the appropriate user id,
which will be something like, NT_NA_03Q4.
2 Determine the POI_ID of the POI to which the new extended attribute will belong;
for example, after executing the following statement, a list is displayed of the POI_ID
and POI_NAME values for all records where the POI_NAME begins with
“MACDONALD”:
SELECT POI_ID POI_NAME FROM <SS_GA>_POI WHERE POI_NAME LIKE
'MACDONALD%'
3 Determine a unique sequence number, newSeqId, by querying to find the last used
POI_ATTRIBUTE_ID, and incrementing by 1. To determine the last used
POI_ATTRIBUTE_ID, execute the following statement:
SELECT max(POI_ATTRIBUTE_ID) FROM <SS_GA>_POI_ATTRIBUTE;
Next, increment the displayed value, and use that new value for newSeqId.
4 Determine your custom provider id, newProviderId.
To query for existing provider ids, execute the following statement:
SELECT * FROM <SS_GA>_DATA_PROVIDER;
■ If a record is displayed with an appropriate DATA_PROVIDER_NAME value, use
the corresponding DATA_PROVIDER_ID as your newProviderId value.
■ If no appropriate entry exists, then you must create a unique data provider id to
identify the source of the new extended attribute. Using any value of 100 or higher,
that has not already been used, create your newProviderId by executing the
following statement:
INSERT INTO <SS_GA>_DATA_PROVIDER values(newProviderId,
'yourProviderName');
5 Insert the new extended attribute into the <SS_GA>_POI_ATTRIBUTE child table;
for example, the following statement adds an extended attribute, newAtt, called
SMOKING, with a value, newAttValue, of NO:
INSERT INTO <SS_GA>_POI_ATTRIBUTE
(newSeqId,POI_ID,'SMOKING','NO',sysdate,sysdate,newProviderId);
COMMIT;
Task 2: Mapping Extended Attributes to Feature
Types
In order for LocationLogic and its applications to be able to access and query an extended
attribute, it must be associated with a unique LocationLogic feature type. You make this
association by creating a feature type property for the desired feature type, by using either
of the following methods:
24 | Chapter 2 Points of Interest (POI) Content

39. ■ “Using the Content Management Console to Add a Feature Type Property,” on page
25
■ “Using Direct Database Access to Add a Feature Type Property,” on page 26
Related Topic
■ For detailed information about feature types and feature type properties, see
“LocationLogic Feature Types” on page 111.
Using the Content Management Console to Add a Feature
Type Property
You can use the Content Management Console to create feature type properties, and add
them into the LocationLogic feature type metadata tables.
To add a feature type property using the Content Management Console
■ Follow the procedure described in “Creating Feature Type Properties,” on page 164.
Adding Extended Attributes to POIs | 25

40. Using Direct Database Access to Add a Feature Type Property
If you are adding many feature type properties, it may be quicker to use direct database
access, executing a series of SQL statements within a script, instead of manually entering
a feature type property for each extended attribute at the Content Management Console.
To add a feature type property using direct database access
1 Using SQL*Plus, connect to the database using the Oracle user ID created to contain
and manage the platform tables (for example, ll_owner).
2 Confirm that the extended attribute you are mapping (and previously added in “Task
1: Inserting Extended Attributes into the Database,” on page 23) was correctly added
to the LocationLogic database:
SELECT <SS_GA>_GET_POI_ATTRIBUTE
(POI_ID,'<SS_GA>_POI_ATTRIBUTE','newAtt') FROM DUAL;
Where
■ POI_ID is the ID of the POI to which you added the extended attribute (see step 2
in Task 2).
■ newAtt is the name of the extended attribute; for example, SMOKING.
The response is one of the following:
■ The display shows a single row returned—The attribute was correctly added.
■ The display is “no rows selected”—The extended attribute was not correctly
added, and you must repeat the procedure.
■ A syntax error is returned—The function is not installed correctly, and you must
rerun the function creation script, create_table_syns.sql. (This script is installed in
the <SS_GA> folder during content installation.)
26 | Chapter 2 Points of Interest (POI) Content

41. 3 Create a new feature type property that maps the extended attribute to a feature type,
and insert the new feature type property into the feature type metadata table. Use one
of the following commands, depending on whether the extended attribute’s value is
text (such as “YES”), numeric (such as 4), or any other type:
■ To create a feature type property for an extended attribute that contains a text string
value, enter the following:
INSERT INTO fm_feature_typ(FEATURETYPE,PROPERTY,TYPE,VALUE)
VALUES('<SS_GA>_POI','newAtt',3,'<SS_GA>_get_poi_attribute
(POI_ID,''<SS_GA>_POI_ATTRIBUTE'',''newAtt'')');
Where
■ POI_ID is the ID of the POI to which you added the extended attribute (see step
2 in Task 3).
■ newAtt is the name of the extended attribute; for example, SMOKING.
■ To create a feature type property for an extended attribute that contains a numeric
value, enter the following:
INSERT INTO fm_feature_typ(FEATURETYPE,PROPERTY,TYPE,VALUE)
VALUES('<SS_GA>_POI','newAtt',3,
'to_number(<SS_GA>_get_poi_attribute(POI_ID,
''<SS_GA>_POI_ATTRIBUTE'',''newAtt''))');
COMMIT;
Where
■ POI_ID is the ID of the POI to which you added the extended attribute (see step
2 in Task 3).
■ newAtt is the name of the extended attribute; for example, SMOKING.
Note If you receive a syntax error, check to be certain that the value you passed
to the Oracle to_number function is numeric; the to_number function cannot
convert a non-numeric value.
■ To create a feature type property for an extended attribute that contains data of any
type other than text or numeric, replace the to_number function in the above
example with the appropriate Oracle conversion function, such as to_date.
Adding Extended Attributes to POIs | 27

42. Selecting POIs Based on Provider
POI content can come from different data providers (content vendors), and you can
incorporate POIs from multiple content vendors into the same POI tables. This means that
your applications can selectively provide access to subsets of information to users; for
example, based on a level of service such as Bronze, Silver, and Gold, which provide
progressively greater amounts of information.
To enable such selective access, the LocationLogic database includes a data provider
audit trail in POI records. For every POI parent table and child table record, you can
determine the data provider (content vendor) and record creation and update information
from the following table columns: INSERT_DATA, UPDATE_DATE, and
DATA_PROVIDER_ID.
Migration Notes
Periodically you may want to update your POI content; for example, when your data
provider (content vendor) issues a new release of content. Before you update your POIs,
you should be aware of the following:
■ It is recommended that you consider the quantity of extended attribute content you
need to migrate as a factor in your decision whether to update your POI content from
your data provider. LocationLogic does not automatically migrate the extended
attribute content you have added, and you will need to develop your own strategy and
scripts for migrating your extended attributes.
■ When you migrate to a new version of POI content provided from your content
vendor, it is possible that the POI_ID values will change. Therefore, you may not be
able to retain your existing POI child tables because their POI_ID foreign key values
will be incorrect. You should take this into account when you develop your extended
attributes migration strategy.
If you need assistance with developing a content migration strategy, contact your
Autodesk Professional Services representative.
28 | Chapter 2 Points of Interest (POI) Content

43. 3
Dynamic Content
This chapter describes what dynamic content is, why it is used, In this chapter
how LocationLogic applications can access it, and how to set up ■ Overview
■ Accessing dynamic content
LocationLogic to incorporate dynamic content.
■ Setting up LocationLogic for
dynamic content
■ Using subscriptions
29

44. Overview
Dynamic content is data that frequently changes, such as traffic incidents or weather. It is
provided from a content vendor, such as Tele Atlas, and is updated in real-time as
conditions change. LocationLogic applications can use dynamic content in a variety of
ways, including
■ Notifying individual users about traffic incidents along a route
■ Notifying individual users about weather conditions in their area
■ Maintaining websites to inform groups of users about interests they have in common,
such as city-wide traffic information
■ Tracking mobile objects, such as LocationLogic users, service personnel, and fleet
equipment
LocationLogic uses a dynamic content adapter to translate the dynamic content from the
content vendor’s format to the internal LocationLogic format. LocationLogic maintains
that data in the LocationLogic database, inserting, updating, and deleting the data in
response to real-time data changes received from the content vendor.
LocationLogic uses dynamic content subscriptions to manage user requests for
notifications about dynamic content, such as traffic, weather, and so forth, that occur
along a predetermined route (such as “My work-to-home”) or at a predetermined location
(such as “San Francisco” or “Home”).
To set up LocationLogic (and the LocationLogic database) to manage dynamic content,
you configure a content topic—a pointer to the LocationLogic database where the
dynamic content from a particular vendor, or for a particular subscription, is stored. In
general, a content topic maps to a specific feature category in the LocationLogic database.
The following sections provide details about adding and using dynamic content in your
LocationLogic application:
■ “Accessing Dynamic Content” on page 31
■ “Setting Up LocationLogic for Dynamic Content” on page 32
■ “Using Subscriptions” on page 53
30 | Chapter 3 Dynamic Content

45. Accessing Dynamic Content
There are two techniques that LocationLogic applications can use to access dynamic
content in the LocationLogic database. Which technique to use depends on what your
application will do with the dynamic content:
■ If your application provides individual users with requested notifications (such as
traffic incidents along their work-to-home route), or real-time reporting of changing
events (such as continually updated storm warnings), you should use LocationLogic
subscriptions to access dynamic content.
■ If your application provides a snapshot view of information (typically for a website),
instead of real-time monitoring (for example, the current weather for a given city,
instead of real-time storm warning levels), you should use the feature-related methods
and services of the LocationLogic API that your application is using. (For more
information, see “Using the Feature APIs to Access Dynamic Content” on page 32.)
Using Subscriptions to Access Dynamic Content
You can greatly simplify the process of using dynamic content by using LocationLogic
subscriptions. LocationLogic subscriptions automatically provide many aspects of
dynamic content management, so your LocationLogic applications do not need custom
code to
■ Schedule and communicate with the dynamic content vendor
■ Monitor the content for changes (new, revised, and deleted information)
■ Keep track of where in the LocationLogic database each item of dynamic content is
located
For more information about subscriptions, including implementation and data details, see
“Using Subscriptions” on page 53.
Accessing Dynamic Content | 31