location logic working_with_content

Developer’s Guide:Working with Content

1 2 3 4 5 6 7 8 9

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 NOTLIMITED TO ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULARPURPOSE, 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 OFTHESE MATERIALS. THE SOLE AND EXCLUSIVE LIABILITY TO AUTODESK, INC., REGARDLESS OF THEFORM 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 productat the time of its publication, and may not reflect the product at all times in the future.

Autodesk TrademarksThe following are registered trademarks of Autodesk, Inc., in the USA and/or other countries: Autodesk, Autodesk (logo),Autodesk MapGuide.

Third Party TrademarksAscential 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 othercountries.Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the UnitedStates 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 andother 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 CreditsThis product includes software developed by the Apache Software Foundation (http://www.apache.org/). Copyright © 1999-2004The 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 USEUse, duplication, or disclosure by the U. S. Government is subject to restrictions as set forth in FAR 12.212 (Commercial ComputerSoftware-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

Contents

About This Guide . . . . . . . . . . . . . . . . . . . . . . . ixAudience and Purpose . . . . . . . . . . . . . . . . . . . xAssumptions and Necessary Skills . . . . . . . . . . . . . . . . xHow This Guide Is Organized . . . . . . . . . . . . . . . . . xConventions Used in This Guide . . . . . . . . . . . . . . . . xi

Text Conventions . . . . . . . . . . . . . . . . . . . xiCode and Syntax Conventions . . . . . . . . . . . . . . xii

Chapter 1 Introduction . . . . . . . . . . . . . . . . . . . 1About the LocationLogic Database . . . . . . . . . . . . . . . 2Types of Content . . . . . . . . . . . . . . . . . . . . . 3LocationLogic Features and Metadata. . . . . . . . . . . . . . . 4

LocationLogic Features . . . . . . . . . . . . . . . . . 5Feature Metadata . . . . . . . . . . . . . . . . . . . 5

Optimizing the LocationLogic Database Performance. . . . . . . . . . 7Optimizing Database Content . . . . . . . . . . . . . . . 7Saving to the Database . . . . . . . . . . . . . . . . . 7Creating Efficient SQL Queries . . . . . . . . . . . . . . 8

System Requirements . . . . . . . . . . . . . . . . . . . 10

Chapter 2 Points of Interest (POI) Content . . . . . . . . . . . . .11Overview. . . . . . . . . . . . . . . . . . . . . . . 12POI 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 . . . . . . . . . . . . . . 20Accessing POI Content . . . . . . . . . . . . . . . . . . 21POI Names . . . . . . . . . . . . . . . . . . . . . . 21Extended Attributes . . . . . . . . . . . . . . . . . . . 22Adding Extended Attributes to POIs . . . . . . . . . . . . . . 23

Task 1: Inserting Extended Attributes into the Database . . . . . . 23Task 2: Mapping Extended Attributes to Feature Types . . . . . . 24

Selecting POIs Based on Provider . . . . . . . . . . . . . . . 28Migration Notes . . . . . . . . . . . . . . . . . . . . 28

iii

Chapter 3 Dynamic Content . . . . . . . . . . . . . . . . . .29Overview . . . . . . . . . . . . . . . . . . . . . . . 30Accessing Dynamic Content . . . . . . . . . . . . . . . . . 31

Using Subscriptions to Access Dynamic Content . . . . . . . . 31Using the Feature APIs to Access Dynamic Content . . . . . . . 32

Setting Up LocationLogic for Dynamic Content . . . . . . . . . . 32Process Overview . . . . . . . . . . . . . . . . . . 33Task 1: Modifying or Creating Dynamic Content Tables . . . . . . 34Task 2: Configuring a Content Topic . . . . . . . . . . . . 35Task 3: Adding Dynamic Content Metadata . . . . . . . . . . 37Task 4: Configuring a Dispatch Handler . . . . . . . . . . . 39Task 5: Creating Filtered Feature Categories . . . . . . . . . 41Task 6: Creating Oracle Views to Support Filtered Feature Categories . 45Task 7: Configuring a Dynamic Content Adapter . . . . . . . . 51Task 8: Configuring Content Vendor Authentication . . . . . . . 51

Using Subscriptions . . . . . . . . . . . . . . . . . . . 53How Subscriptions Are Triggered . . . . . . . . . . . . . 54Handling Subscription Notifications . . . . . . . . . . . . 56

Chapter 4 Road Network Content . . . . . . . . . . . . . . . .67Overview . . . . . . . . . . . . . . . . . . . . . . . 68About Routing . . . . . . . . . . . . . . . . . . . . . 69

Routes, Legs, and Steps . . . . . . . . . . . . . . . . 69Calculating and Retrieving Routes . . . . . . . . . . . . . 70

About Travel Directions . . . . . . . . . . . . . . . . . . 71Generating Travel Directions . . . . . . . . . . . . . . 71Generating Locale-Specific Travel Directions . . . . . . . . . 72Creating Custom Presentation Views . . . . . . . . . . . . 73

About Mapping . . . . . . . . . . . . . . . . . . . . . 73

Chapter 5 Geocoding . . . . . . . . . . . . . . . . . . . .75Overview . . . . . . . . . . . . . . . . . . . . . . . 76The Autodesk LocationLogic Geocoder . . . . . . . . . . . . . 77Geocoding Constraints . . . . . . . . . . . . . . . . . . 77

Position of Civic Number . . . . . . . . . . . . . . . 77Support for Street Types in Street Name Field . . . . . . . . . 78Support for Alternative Characters . . . . . . . . . . . . . 78Support for Stripped Character Sets . . . . . . . . . . . . 79

Accessing Forward Geocoding . . . . . . . . . . . . . . . . 79Accessing Reverse Geocoding . . . . . . . . . . . . . . . . 80Geocoding Results . . . . . . . . . . . . . . . . . . . . 81

Standardized Address . . . . . . . . . . . . . . . . . 81Match Confidence Level . . . . . . . . . . . . . . . . 81

iv | Contents

Match Level . . . . . . . . . . . . . . . . . . . . 81Geometric Point . . . . . . . . . . . . . . . . . . . 82Street Network Link Feature ID . . . . . . . . . . . . . . 82

Chapter 6 Accessing External Data from LocationLogic . . . . . . . . 83Overview . . . . . . . . . . . . . . . . . . . . . . . 84External Content Requirements . . . . . . . . . . . . . . . . 84Setting Up LocationLogic for External Content . . . . . . . . . . . 85

Process Overview . . . . . . . . . . . . . . . . . . 85Task 1: Defining External Content Sources . . . . . . . . . . 85Task 2: Linking External Content to the LocationLogic Database . . . 87Task 3: Creating Data Bridge Features . . . . . . . . . . . . 87

Accessing External Content . . . . . . . . . . . . . . . . . 89

Appendix A Designing and Configuring Maps . . . . . . . . . . . . 91Overview . . . . . . . . . . . . . . . . . . . . . . . 92

Types of Maps . . . . . . . . . . . . . . . . . . . 92Map Formats . . . . . . . . . . . . . . . . . . . . 93

Map Creation and Configuration Overview . . . . . . . . . . . . 94Task 1: Authoring Maps . . . . . . . . . . . . . . . . . . 95

Overview . . . . . . . . . . . . . . . . . . . . . 95Representing a User’s Location . . . . . . . . . . . . . . 96Representing a Route . . . . . . . . . . . . . . . . . 96Representing Features . . . . . . . . . . . . . . . . . 97Designing Maps for Performance . . . . . . . . . . . . . 97

Task 2: Creating Copyright or Branding Overlays . . . . . . . . . . 99Creating GMX Files. . . . . . . . . . . . . . . . . . 99

Task 3: Configuring Map Manager . . . . . . . . . . . . . . .101Adjusting the Bounding Box Expansion Factor . . . . . . . . .102Creating and Using Custom Highlight Styles . . . . . . . . . .102

Task 4: Configuring Geomap . . . . . . . . . . . . . . . . .103Enabling Anti-Aliasing . . . . . . . . . . . . . . . . .104Configuring the Color Overrides Property . . . . . . . . . . .104

Appendix B Content Organization . . . . . . . . . . . . . . . .107Overview . . . . . . . . . . . . . . . . . . . . . . .108LocationLogic Features . . . . . . . . . . . . . . . . . . .108Feature Metadata . . . . . . . . . . . . . . . . . . . . .109

Accessing Feature Metadata . . . . . . . . . . . . . . .110Feature Table Associations. . . . . . . . . . . . . . . . . .110LocationLogic Feature Types . . . . . . . . . . . . . . . . .111

Feature Type Properties . . . . . . . . . . . . . . . .111The Feature Type Table . . . . . . . . . . . . . . . .112

Contents | v

Associating Features and Feature Types . . . . . . . . . . . . . 113LocationLogic Feature Categories . . . . . . . . . . . . . . . 114

The Feature Category Table . . . . . . . . . . . . . . . 115Associating the Content Hierarchy and Feature Category Data . . . . 116Restricting Access to Feature Categories . . . . . . . . . . . 116Structuring Feature Categories . . . . . . . . . . . . . . 117

Associating Feature Categories and Feature Types . . . . . . . . . . 119Accessing Extended LocationLogic Content . . . . . . . . . . . . 120Adding a New Feature Category . . . . . . . . . . . . . . . 121Accessing Additional Feature Tables . . . . . . . . . . . . . . 124Defining Feature Category and Feature Type Associations . . . . . . . 128

Single Feature Type . . . . . . . . . . . . . . . . . 128Multiple Feature Types . . . . . . . . . . . . . . . . 129

Optimizing Content Searches . . . . . . . . . . . . . . . . 129Definition . . . . . . . . . . . . . . . . . . . . 129Content Searches and Content Strategy . . . . . . . . . . . 129Searching Only Leaf Nodes . . . . . . . . . . . . . . . 130Searching All Hierarchy Levels. . . . . . . . . . . . . . 132

Streamlining Feature Filters . . . . . . . . . . . . . . . . . 135

Appendix C Using the Content Management Console . . . . . . . . . 137Overview . . . . . . . . . . . . . . . . . . . . . . . 138The Content Management Console Interface . . . . . . . . . . . . 139Rules and Guidelines . . . . . . . . . . . . . . . . . . . 141Starting the Content Management Console . . . . . . . . . . . . 142

Database Login Elements . . . . . . . . . . . . . . . 142Login Error Messages. . . . . . . . . . . . . . . . . 145

Managing Feature Categories . . . . . . . . . . . . . . . . 146Overview. . . . . . . . . . . . . . . . . . . . . 146Feature Category Elements . . . . . . . . . . . . . . . 146Viewing Feature Categories . . . . . . . . . . . . . . . 148Creating Feature Categories . . . . . . . . . . . . . . . 149Modifying Feature Categories . . . . . . . . . . . . . . 152Duplicating Feature Categories . . . . . . . . . . . . . . 153Moving Feature Categories . . . . . . . . . . . . . . . 154Deleting Feature Categories . . . . . . . . . . . . . . . 154

Managing Feature Types . . . . . . . . . . . . . . . . . . 155Overview. . . . . . . . . . . . . . . . . . . . . 155Feature Type Elements . . . . . . . . . . . . . . . . 156Viewing Feature Types . . . . . . . . . . . . . . . . 157Creating Feature Types . . . . . . . . . . . . . . . . 158Modifying Feature Types. . . . . . . . . . . . . . . . 160Deleting Feature Types . . . . . . . . . . . . . . . . 160

Managing Feature Type Properties . . . . . . . . . . . . . . . 161

vi | Contents

Feature Type Property Elements . . . . . . . . . . . . . .162Viewing Feature Type Properties . . . . . . . . . . . . .163Creating Feature Type Properties . . . . . . . . . . . . .164Modifying Feature Type Properties . . . . . . . . . . . . .166Deleting Feature Type Properties . . . . . . . . . . . . .167

Changing Databases . . . . . . . . . . . . . . . . . . . .168Logging Out of the Content Management Console . . . . . . . . . .169

Contents | vii

I■

■

■

■

About This Guide

n this chapterAudience and purpose

Assumptions and necessary skills

How this guide is organized

Conventions used in this guide

The Autodesk® LocationLogic platform provides you with the

tools you need to build location-based services (LBS) applications.

This guide contains information about the different types of

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

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

■ 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 ConventionsThis 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

../llgl/llgl.pdf

■ Bold italic monospace is used for replaceable elements and placeholders within code listings.

Code and Syntax ConventionsThis 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 symbols...

Indicate this...

| 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

Conventions Used in This Guide | xiii

I■

■

■

■

■

1
Introduction
n this chapterAbout the LocationLogic database

Types of content

LocationLogic features and metadata

Optimizing the LocationLogic database performance

System requirements

This chapter introduces you to the Autodesk® LocationLogic

database and the types of content used by LocationLogic.

1

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

../llig/llig.pdf

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

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.


LocationLogic FeaturesLocationLogic 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 MetadataFeature 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

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.


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 ContentIf 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 DatabaseWriting 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

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 QueriesMany 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.


../lljr/com.autodesk.lbs.pdf

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%'

withCONTAINS(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

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.


I■

■

■

■

■

■

■

■

■

2
Points of Interest (POI) Content
n this chapterOverview

POI schema

Adding content to the POI schema

Accessing POI content

POI names

Extended attributes

Adding extended attributes to POIs

Selecting POIs based on provider

Migration notes

LocationLogic applications use POI (Point of Interest) 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?”

This chapter describes LocationLogic POI content, related

administration functions (such as adding POI-related information

to the database), and how LocationLogic applications use POI

content.

11

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

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

■ <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


The following entity relationship diagram (ERD) illustrates the schema for each POI table, and the relationships between the tables:

POI Entity Relationship Diagram (ERD)

SS_GA_data_provider

PK data_provider_id* NUMBER(19)data_provider_name* VARCHAR2(50)

SS_GA_poiPK poi_id* NUMBER(19)FK link_id NUMBER(19)FK facility_type_id* NUMBER(19)

chain_id NUMBER(5)FK food_type_id NUMBER(10)

poi_name VARCHAR2(100)phone_num VARCHAR2(25)street_side CHAR(1)address VARCHAR2(100)lang_code VARCHAR2(2)city VARCHAR2(70)state VARCHAR2(2)country VARCHAR2(3)postal_code VARCHAR2(10)lon NUMBER(15,8)lat NUMBER(15,8)insert_date* DATEupdate_date* DATE

FK data_provider_id* NUMBER(19)geom* VARCHAR2(0)

SS_GA_poi_attributePK poi_attribute_id* NUMBER(19)FK poi_id* NUMBER(19)

attribute_name* VARCHAR2(50)attribute_value* VARCHAR2(255)insert_date* DATEupdate_date* DATE

FK data_provider_id* NUMBER(19)

SS_GA_poi_name

PK poi_name_id* NUMBER(19)FK poi_id* NUMBER(19)

name_type VARCHAR2(2)name* VARCHAR2(100)lang_code VARCHAR2(2)insert_date* DATEupdate_date* DATE

FK data_provider_id* NUMBER(19)

LegendPK primary keyFK foreign key* not null

POI Schema | 15

<SS_GA>_POI Parent Table Data SetThe <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 (transportation link) on which this POI is located

foreign key

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 restaurant facilities only)

foreign key

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


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

<SS_GA>_POI Parent Table Data Set (2 of 2)


POI Schema | 17

<SS_GA>_POI_NAME Child Table Data SetThe <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


POI_NAME_ID Unique ID of this alternate POI name primary key

POI_ID ID of the POI to which this alternate name applies

foreign key

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—UnnamedFor 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



DATA_PROVIDER_ID Unique identifier of the data provider, such as 1 for NAVTEQ, or 100 for a custom data record provider, such as yourCompanyName

foreign key


<SS_GA>_POI_ATTRIBUTE Child Table Data SetThe <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


POI_ATTRIBUTE_ID Unique ID of this extended attribute primary key

POI_ID ID of the POI to which this extended attribute belongs

foreign key

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.)



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

foreign key

POI Schema | 19

<SS_GA>_DATA_PROVIDER Table Data SetThe <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:

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.

<SS_GA>_DATA_PROVIDER Child Table Data Set


DATA_PROVIDER_ID Unique ID used to identify a data record’s source:• 1—NAVTEQ• 2—Tele Atlas• 100 and higher—Custom data

primary key

DATA_PROVIDER_NAME The data provider’s name


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

../lljr/lljr.pdf

../lldg/lldg.pdf

../lxdg/lxdg.pdf

../lxdg/lxdg.pdf

../medg/medg.pdf

❏ 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.


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:

Task 1: Inserting Extended Attributes into the DatabaseYou 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.

Process Overview: Adding Extended Attributes to POIs

Task Description Refer to

1 Insert extended attribute records into the POI child table, POI_ATTRIBUTE, by executing a series of SQL statements.

“Task 1: Inserting Extended Attributes into the Database” on page 23

2 Associate extended attributes with feature types to enable access to the new POI field data.

“Task 2: Mapping Extended Attributes to Feature Types” on page 24

Adding Extended Attributes to POIs | 23

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 TypesIn 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:


■ “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.


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.)


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.


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.


I■

■

■

■

3
Dynamic Content

Accessing dynamic content

Setting up LocationLogic for dynamic content

Using subscriptions

This chapter 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.

29

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

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 ContentYou 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

Using the Feature APIs to Access Dynamic ContentBecause dynamic content is stored in the LocationLogic database in the same way as other LocationLogic features (see “LocationLogic Features” on page 5), applications access dynamic content 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, dynamic content. The following list describes the different techniques that you can use to access content items (dynamic content) in the LocationLogic database:




Setting Up LocationLogic for Dynamic Content

The following sections explain the process of setting up LocationLogic so that dynamic content can be added to your LocationLogic database and be used by your LocationLogic applications (either by implementing subscriptions, or by using the feature APIs.) Typically, you perform this process as part of the LocationLogic deployment. However, if your initial deployment does not include using dynamic content, you can still shut down LocationLogic at any time in order to set it up to use dynamic content.


../lldg/lldg.pdf

../lxdg/lxdg.pdf

../lxdg/lxdg.pdf

../medg/medg.pdf

../lljr/lljr.pdf

Process OverviewThe following table describes the steps required to add dynamic content to the LocationLogic database:

Process Overview: Adding Dynamic Content


1 To add dynamic content that is in a different format from existing dynamic content, design the necessary tables, and modify existing tables or create new tables, as needed.

“Task 1: Modifying or Creating Dynamic Content Tables” on page 34

2 Configure the content topic in the LocationLogic llservices.xml property file (in the propertytemplates folder.)

“Task 2: Configuring a Content Topic” on page 35

3 Add supporting metadata for dynamic content table schemas.

“Task 3: Adding Dynamic Content Metadata” on page 37

4 Optionally, configure a new dispatch handler for subscriptions to use for dynamic content event notifications. For information about when this is required, see the task description.

“Task 4: Configuring a Dispatch Handler” on page 39

5 Optionally, create filtered feature categories (sub-categories) to optimize information retrieval speed.

“Task 5: Creating Filtered Feature Categories” on page 41

6 To enable access to filtered feature categories, set up Oracle views for the filtered feature data.

“Task 6: Creating Oracle Views to Support Filtered Feature Categories” on page 45

7 Configure a dynamic content adapter to enable access to the dynamic content.

“Task 7: Configuring a Dynamic Content Adapter” on page 51

8 Connect to the content vendor. “Task 8: Configuring Content Vendor Authentication” on page 51

Setting Up LocationLogic for Dynamic Content | 33

Task 1: Modifying or Creating Dynamic Content TablesYou can design a different database schema for every content topic (pointer to information or content that a LocationLogic application is currently monitoring, such as traffic incidents). For traffic incident-related dynamic content, you must include the fields described in the “Required Traffic Incident Database Fields” table. You can add additional table columns needed to support a particular content vendor’s data. LocationLogic automatically accommodates these additional fields (assuming you add the required metadata), making them available for retrieval by LocationLogic applications.

Notes

■ Once you have designed your table, you must add it to the LocationLogic database. (It is recommended that you create a SQL script to create the table, and any required metadata, as described in “Task 3: Adding Dynamic Content Metadata” on page 37.)

■ If your table contains location geometry data, it must be spatially indexed.

The following table describes the fields that are required for traffic incident-related dynamic content (where <TYPE> should be replaced by LINK or SEGMENT to indicate that the dynamic content is either link-based or segment-based, respectively):

Required Traffic Incident Database Fields (1 of 2)

Logical Column Name Description Type

TRAFFIC_<TYPE>_ID Unique LocationLogic platform-generated key

NOT NULL NUMBER(19)

VENDOR_KEY NOT NULL VARCHAR2(255)

VENDOR Vendor ID for this traffic content vendor

NUMBER(19)

VENDOR_LINK Vendor unique link to the external traffic feed item associated with this traffic incident

VARCHAR2(255)

TRAFFIC_FLINK_ID Vendor unique link (foreign link) to the external traffic point associated with this traffic incident

NUMBER(19)


Task 2: Configuring a Content TopicIn order for LocationLogic and LocationLogic applications to access and query dynamic content (whether by using subscriptions, or by using the feature APIs), they must know

■ How the dynamic content fits in to the LocationLogic content hierarchy (that is, what its feature category is)

■ Where dynamic content is, physically, in the LocationLogic database

You set up this information by configuring content topics, which point to the LocationLogic database where the dynamic content from a particular vendor, or for a particular subscription, is stored.

To configure a content topic

1 Choose a name for the content topic; for example, sfTraffic.2 Change to the /opt/adsklbs/lbsadmin/config/lbs/propertytemplates directory.3 Using any XML or text editor, open the llservices.xml property file.4 Add the content topic to the dynamiccontentmanager.topicList:

CREATED Time and date when LocationLogic added this incident to the traffic database table

NOT NULL DATE

UPDATED Time and date of the most recent update of this incident

NOT NULL DATE

EXPIRES Time and date for the ending of applicability of this incident

DATE

LAT Latitudinal representation of the location of this traffic link or segment

NUMBER(38,17)

LON Longitudinal representation of the location of this traffic link or segment

NUMBER(38,17)

GEOM Location of feature in lat/lon format

NOT NULL MDSYS.SDO_GEOMETRY

Required Traffic Incident Database Fields (2 of 2)

Logical Column Name Description Type


■ Find the dynamiccontentmanager.topicList property instance. The property instance entry looks similar to the following:<property idref="dynamiccontentmanager.topicList"/>

■ Add the name of the content topic to the dynamiccontentmanager.topicList value; for example:<property idref="dynamiccontentmanager.topicList">sfTraffic</

property>

5 Add additional dynamiccontentmanager.<topicName>.* properties as needed.If you are using a content adapter that is provided with LocationLogic, consult the relevant documentation for configuration property requirements; for example, the Autodesk LocationLogic Tele Atlas True Time Maps Traffic Adapter Configuration Guide. Otherwise, refer to the Autodesk LocationLogic Properties Reference. If you are unsure which configuration properties you need to set, contact your Autodesk Professional Services representative.

6 Save your changes.7 Load the properties into the LocationLogic database:

/opt/adsklbs/tools/propertiesloader/propertiesloader.sh llservices.xml

After the loading is complete, you will see a message similar to the following:PropertyLoader: file llservices.xml successfully loaded.


../llta/llta.pdf

../llta/llta.pdf

../llpr/llpr.pdf

Task 3: Adding Dynamic Content MetadataYou must add feature metadata to the feature category and feature type tables so that LocationLogic can access the dynamic content.

Whether you add metadata for a single table using the Oracle Server Manager from the command line, or add metadata for a set of tables by using a SQL file containing multiple SQL command lines, the SQL commands are the same. The following procedure shows the commands as entered at the command prompt.

To add dynamic content feature metadata

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 To ensure data integrity, delete any existing feature category metadata that is associated with the content topic before adding new or changed metadata. After you have deleted the existing data, commit the changes to the database:DELETE FROM FM_FEATURE_CAT WHERE

PARENTCATPATH='DynamicContent' AND CATNAME='YourTopicName';COMMIT;

Where■ YourTopicName is the name of the content topic you are adding as the feature

category.

3 Add the new or changed feature category metadata:INSERT INTO FM_FEATURE_CAT

VALUES(CATNAME, PARENTCATPATH, FEATURETYPE, EN) VALUES('YourTopicName','DynamicContent','YourFeatureType','YourDisplayName'));

Where■ YourTopicName is the name of the content topic you are adding.■ YourFeatureType is the feature type for this dynamic content.■ YourDisplayName is the display string for this feature category.


4 To ensure data integrity, delete any existing feature type metadata that is associated with the content topic before adding new or changed feature type metadata. After you have deleted the existing data, commit the changes to the database:DELETE FROM FM_FEATURE_TYP WHERE

FEATURETYPE='YourFeatureType';COMMIT;

Where■ YourFeatureType is the feature type for this dynamic content.

5 Add the new or changed feature type metadata for the content topic:INSERT INTO FM_FEATURE_TYP

VALUES(FEATURETYPE, PROPERTY, TYPE, VALUE) VALUES('YourFeatureType','theProperty','thePropertyType','thePropertyValue'));

Where■ YourFeatureType is the feature type for this dynamic content.■ theProperty is this feature type property for this metadata (for example,

“FDATASRC”).■ thePropertyType identifies whether this property is a data source name, a table

name, or a column name.■ thePropertyValue is the actual value of the property (such as “jdbc.Oracle”).

Related Topics

■ “Feature Metadata” on page 109■ “The Feature Type Table” on page 112


Task 4: Configuring a Dispatch HandlerDepending on how your application is built, you may need to configure a dispatch handler in order to use subscriptions to access dynamic content. (If you are not using subscriptions, then you do not need to configure a dispatch handler, and you can skip this task.)

■ Applications built using the LocationLogic Java API—You must configure a separate dispatch handler for every application that receives alerts.

■ Applications built using LocationLogic XML Web Services or the J2ME API—You can use the supplied WSGSubscriptionEventQueue, or you can configure an additional dispatch handler.If you use the WSGSubscriptionEventQueue, you should be aware that as with all JMS queues, only a single application will receive the associated messages. Therefore, if there are multiple applications running against a single LocationLogic XML Web Services deployment, you must configure separate dispatch handlers for each application.

If you want to enable multiple applications to respond to a single alert, then you must configure a JMS topic to use as your dispatch handler (instead of a JMS queue.)

Additionally, you can configure dispatch handlers to support other communication protocols, such as SMS or MMS email.

To configure a dispatch handler

1 Decide what type of handler you want to configure (typically a JMS queue), and choose a name for the handler; for example, SUBSCRIPTION_EVENTSNote Use the name you choose here as the value for the notifyHandler parameter when you create subscriptions, as described in “Working with Subscriptions” in the Autodesk LocationLogic Developer’s Guide.

2 Using the WebLogic Admin console, create the resource (the JMS queue or any other J2EE resource based on type of dispatch handler).

3 Change to the /opt/adsklbs/lbsadmin/config/lbs/propertytemplates directory.4 Using any XML or text editor, open the llservices.xml property file.


../lldg/lldg.pdf

5 Create the LocationLogic event dispatcher properties for the new dispatch handler by adding the following entries (replacing SUBSCRIPTION_EVENTS with your dispatch handler’s name); for example:<property idref="eventdispatcher.-handler-.className" name="eventdispatcher.SUBSCRIPTION_EVENTS.className">com.autodesk.lbs.afx.common</property>

<property idref="eventdispatcher.handlers.JmsHandlereventdispatcher.-handler-.customParameter.destinationName" name="eventdispatcher.handlers.JmsHandlereventdispatcher.-SUBSCRIPTION_EVENTS-.customParameter.destinationName">SubscriptionEvents</property>

<property idref="eventdispatcher.-handler-.customParameter.destinationType" name="eventdispatcher.SUBSCRIPTION_EVENTS.customParameter.destinationType">Queue</property>

If you are using a customized WebLogic Server configuration, you will likely need to configure the following optional event dispatcher properties, as well:<property idref="eventdispatcher.-handler-.customParameter.connectionFactory" name="eventdispatcher.SUBSCRIPTION_EVENTS.customParameter.connectionFactory">jms.LLogicQueueConnectionFactory</property>

<property idref="eventdispatcher.-handler-.customParameter.contextFactory" name="eventdispatcher.SUBSCRIPTION_EVENTS.customParameter.contextFactory">weblogic.jndi.WLInitialContextFactory</property>

6 Add the new resource to the resource list specified by the LocationLogic resources configuration property:■ Find the cluster.llogic1.resources property instance. The property

instance entry looks similar to the following:<property idref="cluster.-clusterName-.resources"name="cluster.llogic1.resources">datasrc.jdbc/Oracle,jms.LLogicTopicConnectionFactory,jms.LLogicQueueConnectionFactory,

... <additional entries omitted for brevity> ...ejb.LLCacheManagerHome </property>

■ Add the resource, using the name you chose in step 1, to the cluster.llogic1.resources value.

7 Save your changes.


8 Load the properties into the LocationLogic database:/opt/adsklbs/tools/propertiesloader/propertiesloader.sh llservices.xml


Related Topic

■ For detailed information about setting up dispatch handlers, refer to the “Dynamic Content Manager Properties” and “Event Dispatcher Properties” in the Autodesk LocationLogic Properties Reference.

Task 5: Creating Filtered Feature CategoriesLocationLogic applications can query a base category—a dynamic content feature category specified by the featurecategorypath parameter in a method call to createFeatureCategorySubscription.

You also have the option to set up filtered feature categories, which include just a subset of a subscribed base category’s information. By querying a filtered feature category, performance improves because applications can avoid querying a broader, base category of information, and then subsequently looking at a specific column’s value to determine to which of several subcategories the base category’s record actually belongs.

For example, if a subscribed traffic incident feature category provides traffic incidents of severities 1 through 5, you can set up 5 separate filtered feature categories so that your application can query each incident severity level as a separate feature category.


../llpr/llpr.pdf

../llpr/llpr.pdf

To set up a filtered feature category

1 Create a new LocationLogic feature category by adding a metadata entry to the LocationLogic feature category table:INSERT INTO FM_FEATURE_CAT (CATNAME, PARENTCATPATH, FEATURETYPE, FEATUREFILTER, EN) VALUES ('newCat', 'subscribedFC', 'subscribedFT', 'sqlFilter', 'displayName');

Where■ newCat is the name of the new feature category; for example,

Severity4Incidents.■ subscribedFC is the base feature category used to create the subscription; for

example, DynamicContent.Traffic.Segment.■ subscribedFT is the base feature type of the subscribed feature category; for

example, TRAFFIC_SEGMENT.■ sqlFilter is the SQL WHERE clause fragment to apply to the subscribed features in

order to filter them for the relevant features for the new feature category; for example, SEVERITY=4.Note Do not include the WHERE keyword in the sqlFilter value. LocationLogic automatically adds the WHERE keyword when making the database access call.

■ displayName is the English text used whenever this feature category’s name is displayed; for example, “Severity 4 Traffic Incidents”.

Using the above examples, the INSERT command is:INSERT INTO FM_FEATURE_CAT (CATNAME, PARENTCATPATH, FEATURETYPE, FEATUREFILTER, EN) VALUES ('Severity4Incidents', 'DynamicContent.Traffic.Segment', 'TRAFFIC_SEGMENT', 'Severity=4', 'Severity 4 Traffic Incidents');

2 Change to the /opt/adsklbs/lbsadmin/config/lbs/propertytemplates directory.3 Using any XML or text editor, open the llservices.xml property file.


4 Set up a filtered feature category for the subscribed feature category by configuring the dynamiccontentmanager.<topicName>.ffc configuration property, as follows:■ If the dynamiccontentmanager.<topicName>.ffc property is set in the

file, modify its value as desired.■ If the property is not in the file, add the following entry:

<property idref="dynamiccontentmanager.-topicName-.ffc”name=dynamiccontentmanager.theTopic.ffc”>subscribedFC.newCat</property>

Where■ theTopic is the name you choose for the content topic, and include in the

dynamiccontentmanager.topicList property value; for example, gbTraffic.

■ subscribedFC is the new feature category’s parent category (which is the feature category used to create the subscription); for example, DynamicContent.Traffic.Segment.

■ newCat is the name of the new feature category; for example, Severity4Incidents.

The concatenation of the subscribedFC and newCat values represents the fully qualified feature category path for the new filtered feature category. It is also used as the replacement for the <filteredFeatureCategory> token when setting Dynamic Content Manager properties.Using the above examples, the configuration property setting is:<property idref="dynamiccontentmanager.-topicName-.ffc”name=dynamiccontentmanager.gbTraffic.ffc”>DynamicContent.Traffic. Segment.Severity4Incidents</property>

Note You can configure more than one filtered feature category for a subscribed feature category by specifying multiple subscribedFC.newCat values in a comma-separated format for the .ffc property value.


5 Identify the filtered feature category as belonging to a subscribed base category by configuring the dynamiccontentmanager.<filteredFeatureCategory>.basecategory configuration property, as follows:■ If the dynamiccontentmanager.<filteredFeatureCategory>.

basecategory property is set in the file, modify its value as desired.■ If the property is not in the file, add the following entry:

<property idref="dynamiccontentmanager.-filteredFeatureCategory-

.basecategory”name=dynamiccontentmanager.theFfc.basecategory”>subscribedBaseCat</property>

Where■ theFfc is a value specified for a .ffc configuration property; for example,

DynamicContent.Traffic.Segment.Severity4Incidents■ subscribedBaseCat is the subscribed base category (as specified by the

featurecategorypath parameter in the createFeatureCategorySubscription method call); for example, DynamicContent.Traffic.Segment.

Using the above examples, the configuration property setting is:<property idref="dynamiccontentmanager.-filteredFeatureCategory-.basecategory”name=dynamiccontentmanager.DynamicContent.Traffic.Segment.Severity4Incidents.basecategory”>DynamicContent.Traffic.Segment</property>

For more information, refer to “Working with Subscriptions” in the Autodesk LocationLogic Developer’s Guide. Also refer to dynamiccontentmanager properties in the Autodesk LocationLogic Java API Reference.





../lldg/lldg.pdf

../lldg/lldg.pdf


Task 6: Creating Oracle Views to Support Filtered Feature CategoriesIf your application uses filtered feature categories to organize its dynamic content, you must create Oracle views to the filtered feature categories. You should create a SQL script to execute a series of SQL statements to create all the necessary table views and metadata.

Note You also use this procedure to create views for any optional notification data that you choose to include in subscription notifications (see “Optional Notification Data” on page 60.)

To create the Oracle views

Note This procedure describes the required steps in general terms. See the code that follows for a specific example.

1 Determine whether the SCAN_FEATURES view already exists:set long 2000set pagesize 2000SELECT text

FROM user_viewsWHERE view_name = 'SCAN_FEATURES';

The response will be one of the following:■ If there is no SCAN_FEATURES view for the LocationLogic database, the

response will be “no rows selected”.■ If the SCAN_FEATURES view exists, the response will be similar to the following:

TEXT----------------------------------------------------(

SELECT 1 AS SCAN_ID,'DynamicContent.Traffic.NOTIFICATIONS_RF_TS_HIGH' ASFEATURE_CATEGORYFROM DUAL

UNIONSELECT 2 AS SCAN_ID,

'DynamicContent.Traffic.NOTIFICATIONS_RF_TS_MED' ASFEATURE_CATEGORYFROM DUAL

UNIONSELECT 3 AS SCAN_ID,

'DynamicContent.Traffic.NOTIFICATIONS_RF_TS_LOW' ASFEATURE_CATEGORYFROM DUAL

)


If the SCAN_FEATURES view exists, then you must determine the view for each of the filtered feature categories, in turn. For the preceding response, you would execute the following three SQL statements:

SELECT text FROM user_views WHERE view_name = 'NOTIFICATIONS_RF_TS_HIGH';SELECT text FROM user_views WHERE view_name = 'NOTIFICATIONS_RF_TS_MED';SELECT text FROM user_views WHERE view_name = 'NOTIFICATIONS_RF_TS_LOW';

Warning If the SCAN_FEATURES view already exists, you must be sure to duplicate all the existing view information in your CREATE or REPLACE statements, in the following steps. If you do not, then the previous view information will be overwritten, and applications will no longer be able to access previously configured filtered feature categories.

2 Create (or replace if it exists already) the LocationLogic database’s SCAN_FEATURES view.You must include an entry for each filtered feature category that is monitored by a subscription. The SCAN_ID values must be sequentially numbered, starting at 1. The FEATURE_CATEGORY values must be the fully qualified filtered feature category, as specified for a dynamiccontentmanager.<topicName>.ffc configuration property.

3 Create (or replace if it exists already) a view for each filtered feature category that is included in the SCAN_FEATURES view.The name for a filtered feature category view must be the same as the filtered feature category’s name. The view must include data from the dynamic content database table where the filtered feature category’s data is being stored, appropriate links to user records (such as fields from the USER_SUBSCRIPTION table’s records) to identify the user to which the subscription belongs, and appropriate filter/trigger conditions to indicate when the data is considered to be applicable.

4 Create feature category metadata for each filtered feature category that is included in the SCAN_FEATURES view.

5 Create feature type metadata for each data item that is included in an individual filtered feature category’s view.

The following SQL script creates the necessary Oracle views for three traffic severity filtered feature categories.

Note You can use the same method for other types of data (such as weather), by changing the table name from TRAFFIC_SEGMENT to the table where the dynamic content is to be stored. You can include different fields in the view for a specific filtered


feature category. And you can use different criteria to specify trigger conditions for subscription data applicability.

create_traffic_views.sql (1 of 5)

-- Step 2:-- Create the LocationLogic subscription view. ---- Feature categories should be the fully qualified filtered feature category,-- as specified for a dynamiccontentmanager.<topicName>.ffc property value--CREATE OR REPLACE VIEW SCAN_FEATURES(SCAN_ID,FEATURE_CATEGORY) AS(

SELECT 1 AS SCAN_ID, 'DynamicContent.Traffic.NOTIFICATIONS_RF_TS_HIGH' AS FEATURE_CATEGORY

FROM DUALUNIONSELECT 2 AS SCAN_ID, 'DynamicContent.Traffic.NOTIFICATIONS_RF_TS_MED' AS

FEATURE_CATEGORYFROM DUAL

UNIONSELECT 3 AS SCAN_ID, 'DynamicContent.Traffic.NOTIFICATIONS_RF_TS_LOW' AS

FEATURE_CATEGORYFROM DUAL

);

-- Step 3:-- Create the view for 1st filtered feature category in the SCAN_FEATURES view.-- The table names, included fields, and condition triggers (FEATURE_CATEGORY and-- IMPACT_TYPE should be modified to fit your situation.-- The values 1004, 1006, 1008, and 1009 correspond to the FN_FEATURE_* feature-- notification constants (see the LbsFeatureCategorySubscription interface-- description in the Autodesk LocationLogic Java API Reference.

CREATE OR REPLACE VIEW NOTIFICATIONS_RF_TS_HIGH(USER_SUBSCRIPTION_ID,CONDITION_FILTER,USERID,FEATURE_CATEGORY,NOTIFY_DESTINATION,NAME, TYPE,TRAFFIC_SEGMENT_ID) ASSELECT s.USER_SUBSCRIPTION_ID,s.CONDITION_FILTER,s.USERID,s.FEATURE_CATEGORY,s.NOTIFY_DESTINATION,s.NAME, s.TYPE,t.TRAFFIC_SEGMENT_IDFROM TRAFFIC_SEGMENT t,

USER_SUBSCRIPTION s,SUBSCRIPTION_LINK l

WHERE t.TRAFFIC_FLINK_ID=l.TRAFFIC_FLINK_IDAND l.USER_SUBSCRIPTION_ID = s.USER_SUBSCRIPTION_IDAND CONDITION_FILTER IN(1004,1006,1008,1009)AND ACTIVE_FLAG = 0AND SUSPENDED_FLAG =1AND SPATIAL_FILTER_TYPE =2AND FEATURE_CATEGORY='DynamicContent.Traffic.SegmentSeverityHigh' AND IMPACT_TYPE >=3 AND NEXT_ACTION_DATE <= (SELECT CURRENT_SCAN_DATE


../lljr/lljr.pdf

FROM SCAN_LOGWHERE TYPE='SUBSCRIPTION_SCAN')

;

-- Create the view for 2nd filtered feature category in the SCAN_FEATURES view.CREATE OR REPLACE VIEW NOTIFICATIONS_RF_TS_MED(USER_SUBSCRIPTION_ID,CONDITION_FILTER,USERID,FEATURE_CATEGORY,NOTIFY_DESTINATION,NAME, TYPE,TRAFFIC_SEGMENT_ID) ASSELECT s.USER_SUBSCRIPTION_ID,s.CONDITION_FILTER,s.USERID,s.FEATURE_CATEGORY,s.NOTIFY_DESTINATION,s.NAME, s.TYPE,t.TRAFFIC_SEGMENT_IDFROM TRAFFIC_SEGMENT t,


WHERE t.TRAFFIC_FLINK_ID=l.TRAFFIC_FLINK_IDAND l.USER_SUBSCRIPTION_ID = s.USER_SUBSCRIPTION_IDAND CONDITION_FILTER IN(1004,1006,1008,1009)AND ACTIVE_FLAG = 0AND SUSPENDED_FLAG =1AND SPATIAL_FILTER_TYPE =2AND FEATURE_CATEGORY='DynamicContent.Traffic.SegmentSeverityMedium' AND IMPACT_TYPE >=2 AND NEXT_ACTION_DATE <= (SELECT CURRENT_SCAN_DATE


;

-- Create the view for 3rd filtered feature category in the SCAN_FEATURES view.CREATE OR REPLACE VIEW NOTIFICATIONS_RF_TS_LOW(USER_SUBSCRIPTION_ID,CONDITION_FILTER,USERID,FEATURE_CATEGORY,NOTIFY_DESTINATION,NAME, TYPE,TRAFFIC_SEGMENT_ID) ASSELECT s.USER_SUBSCRIPTION_ID,s.CONDITION_FILTER,s.USERID,s.FEATURE_CATEGORY,s.NOTIFY_DESTINATION,s.NAME, s.TYPE,t.TRAFFIC_SEGMENT_IDFROM TRAFFIC_SEGMENT t,


WHERE t.TRAFFIC_FLINK_ID=l.TRAFFIC_FLINK_IDAND l.USER_SUBSCRIPTION_ID = s.USER_SUBSCRIPTION_IDAND CONDITION_FILTER IN(1004, 1006,1008,1009)AND ACTIVE_FLAG = 0AND SUSPENDED_FLAG =1AND SPATIAL_FILTER_TYPE =2AND FEATURE_CATEGORY='DynamicContent.Traffic.SegmentSeverityLow' AND IMPACT_TYPE >=0 AND NEXT_ACTION_DATE <= (SELECT CURRENT_SCAN_DATE


;



-- Step 4:-- Create the feature category metadata for the 1st filtered feature category.DELETE FROM FM_FEATURE_CAT where CATNAME='NOTIFICATIONS_RF_TS_HIGH';INSERT INTO FM_FEATURE_CAT (CATNAME, PARENTCATPATH, FEATURETYPE, EN)

VALUES ('NOTIFICATIONS_RF_TS_HIGH', 'DynamicContent.Traffic', 'NOTIFICATIONS_RF_TS_HIGH', 'Route Filter High sev SEGMENT Traffic');

-- Step 5:-- Create the feature type metadata for every data field in the 1st filtered-- feature category’s view.DELETE FROM FM_FEATURE_TYP WHERE FEATURETYPE = 'NOTIFICATIONS_RF_TS_HIGH';INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_HIGH', 'FDATASRC', 1, 'jdbc.Oracle');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_HIGH', 'FTABLE', 2, 'NOTIFICATIONS_RF_TS_HIGH');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_HIGH', 'FID', 3, 'USER_SUBSCRIPTION_ID');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_HIGH', 'CONDITION_FILTER', 3, 'CONDITION_FILTER');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_HIGH', 'USERID', 3, 'USERID');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_HIGH', 'FEATURE_CATEGORY', 3, 'FEATURE_CATEGORY');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_HIGH', 'NOTIFY_DESTINATION', 3, 'NOTIFY_DESTINATION');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_HIGH', 'NAME', 3, 'NAME');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_HIGH', 'TYPE', 3, 'TYPE');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_HIGH', 'TRAFFIC_SEGMENT_ID', 3, 'TRAFFIC_SEGMENT_ID');

-- Create the feature category metadata for the 2nd filtered feature category.DELETE FROM FM_FEATURE_CAT where CATNAME='NOTIFICATIONS_RF_TS_MED';INSERT INTO FM_FEATURE_CAT (CATNAME, PARENTCATPATH, FEATURETYPE, EN)

VALUES ('NOTIFICATIONS_RF_TS_MED', 'DynamicContent.Traffic', 'NOTIFICATIONS_RF_TS_MED', 'Route Filter Medium sev SEGMENT Traffic');

-- Create the feature type metadata for every data field in the 2nd filtered-- feature category’s view.DELETE FROM FM_FEATURE_TYP WHERE FEATURETYPE = 'NOTIFICATIONS_RF_TS_MED';INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)



VALUES ('NOTIFICATIONS_RF_TS_MED', 'FDATASRC', 1, 'jdbc.Oracle');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_MED', 'FTABLE', 2, 'NOTIFICATIONS_RF_TS_MED');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_MED', 'FID', 3, 'USER_SUBSCRIPTION_ID');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_MED', 'CONDITION_FILTER', 3, 'CONDITION_FILTER');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_MED', 'USERID', 3, 'USERID');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_MED', 'FEATURE_CATEGORY', 3, 'FEATURE_CATEGORY');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_MED', 'NOTIFY_DESTINATION', 3, 'NOTIFY_DESTINATION');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_MED', 'NAME', 3, 'NAME');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_MED', 'TYPE', 3, 'TYPE');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_MED', 'TRAFFIC_SEGMENT_ID', 3, 'TRAFFIC_SEGMENT_ID');

-- Create the feature category metadata for the 3rd filtered feature category.DELETE FROM FM_FEATURE_CAT where CATNAME='NOTIFICATIONS_RF_TS_LOW';INSERT INTO FM_FEATURE_CAT (CATNAME, PARENTCATPATH, FEATURETYPE, EN)

VALUES ('NOTIFICATIONS_RF_TS_LOW', 'DynamicContent.Traffic', 'NOTIFICATIONS_RF_TS_LOW', 'Route Filter Low sev SEGMENT Traffic');

-- Create the feature type metadata for every data field in the 3rd filtered-- feature category’s view.DELETE FROM FM_FEATURE_TYP WHERE FEATURETYPE = 'NOTIFICATIONS_RF_TS_LOW';INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_LOW', 'FDATASRC', 1, 'jdbc.Oracle');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_LOW', 'FTABLE', 2, 'NOTIFICATIONS_RF_TS_LOW');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_LOW', 'FID', 3, 'USER_SUBSCRIPTION_ID');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_LOW', 'CONDITION_FILTER', 3, 'CONDITION_FILTER');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_LOW', 'USERID', 3, 'USERID');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)



Task 7: Configuring a Dynamic Content AdapterA content adapter translates information from a content vendor's format to the internal LocationLogic format.

If you are using a content adapter that is provided with LocationLogic, consult the relevant documentation for configuration information; for example, the Autodesk LocationLogic Tele Atlas True Time Maps Traffic Adapter Configuration Guide.

If you are unsure which content adapter to use, or need additional content adapters, contact your Autodesk Professional Services representative.

Task 8: Configuring Content Vendor AuthenticationTo connect to a content vendor’s data, you must obtain authorization information (a user name and password), which you then add to the content topic configuration. If your LocationLogic deployment is behind a firewall, then you may need to add additional configuration parameters to enable proxy access.

You must perform one or both of the following procedures to connect LocationLogic to the content vendor’s database:

■ Configure user authorization—Necessary for every deployment.■ Configure access through a firewall—Necessary if LocationLogic is deployed behind

a firewall.

VALUES ('NOTIFICATIONS_RF_TS_LOW', 'FEATURE_CATEGORY', 3, 'FEATURE_CATEGORY');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_LOW', 'NOTIFY_DESTINATION', 3, 'NOTIFY_DESTINATION');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_LOW', 'NAME', 3, 'NAME');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_LOW', 'TYPE', 3, 'TYPE');INSERT INTO FM_FEATURE_TYP (FEATURETYPE, PROPERTY, TYPE, VALUE)

VALUES ('NOTIFICATIONS_RF_TS_LOW', 'TRAFFIC_SEGMENT_ID', 3, 'TRAFFIC_SEGMENT_ID');



../llta/llta.pdf

../llta/llta.pdf

To configure user authorization

1 Change to the /opt/adsklbs/lbsadmin/config/lbs/propertytemplates directory.2 Using any XML or text editor, open the llservices.xml property file.3 Do one of the following:

■ If the property is not in the file, add the following entry:<property idref="dynamiccontentmanager.-topicName-.authorization”name=dynamiccontentmanager.theTopic.authorization”>ValidUser:ValidPwd</property>

Where■ theTopic is the name of the content topic you are adding.■ ValidUser is the vendor-provided user name.■ ValidPwd is the vendor-provided password for the ValidUser.

■ If the dynamiccontentmanager.<topicName>.authorization property is set in the file, modify its value as desired.




To configure access through a firewall

1 Change to the /opt/adsklbs/lbsadmin/config/lbs/propertytemplates directory.2 Using any XML or text editor, open the llservices.xml property file.3 Find the dynamiccontentmanager.proxyHost property instance.

The property instance entry looks similar to one of the following:<property idref="dynamiccontentmanager.proxyHost”/>

<property idref="dynamiccontentmanager.proxyHost”>Server</property>

4 Add or modify the property value with the information you received from your content vendor for your account.

5 Repeat steps 3-4 for the following properties:■ dynamiccontentmanager.proxyPort

■ dynamiccontentmanager.proxyAuthorization

6 Save your changes.


7 Load the properties into the LocationLogic database:/opt/adsklbs/tools/propertiesloader/propertiesloader.sh llservices.xml


Using Subscriptions

A subscription is a request for notifications (alerts) made by a user, such as, “send me a message when Stephanie gets within a mile of where I am,” or “send me messages describing any traffic incidents along my travel route between 5:00PM and 7:00PM each weekday.”

There are two types of LocationLogic subscriptions:

■ Mobile subscriptions—Monitor whether two mobile devices, or a mobile device and a fixed location, are near each other. This type of subscription might be used as part of a friend-finder application. If your application enables users to create subscriptions that monitor other users’ mobile devices, you might also want to allow users to control who can subscribe to them (and possibly where and when). Refer to “Managing User Permissions” in the Autodesk LocationLogic Developer’s Guide.

■ Feature category subscriptions—Monitor changes to features that are near a mobile device or fixed location, or that fall along a route. This type of subscription is also known as a dynamic content subscription. It might be used as part of a traffic application that provides users with traffic incidents near their current location.

A feature category subscription is associated with a single dynamic content feature category, which can be either of the following (where <topicName> is the name you choose for the content topic, and include in the dynamiccontentmanager.topicList property value):❏ A base feature category, as specified by the

dynamiccontentmanager.<topicName>.topic configuration property; for example:dynamiccontentmanager.gbTraffic.topic=DynamicContentManager.Traffic.Segment

For more information about configuring the content topic, see “Task 2: Configuring a Content Topic” on page 35.

❏ One of the comma-separated list of filtered feature categories specified by the dynamiccontentmanager.<topicName>.ffc configuration property; for example:

Using Subscriptions | 53

../lldg/lldg.pdf

dynamiccontentmanager.gbTraffic.ffc=DynamicContent.Traffic.SegmentSeverity1,DynamicContent.Traffic.SegmentSeverity2,DynamicContent.Traffic.SegmentSeverity3,DynamicContent.Traffic.SegmentSeverity4

Each type of LocationLogic API and deployment environment provides methods to create, delete, query, update (activate or deactivate), and modify subscriptions:

■ Applications built using the LocationLogic Java API—Use the following classes and interfaces:❏ LbsFeatureCategorySubscription

❏ LbsMobileSubscription

❏ LbsSubscription

❏ LbsSubscriptionManager

For more information, refer to the Autodesk LocationLogic Developer’s Guide.

■ Applications built using LocationLogic XML Web Services—Use the SubscriptionRequest element, and associated child elements. For more information, refer to “Alert Requests” in the Autodesk LocationLogic XML Web Services Developer’s Guide.

■ Remote J2ME applications—Use the following objects and methods:❏ LbsmeCreateSubscriptionRequest

❏ LbsmeEditSubscriptionRequest

❏ LbsmeListSubscriptionsRequest

❏ LbsmeSubscription

For more information, refer to the Autodesk LocationLogic J2ME Developer’s Guide.

How Subscriptions Are TriggeredWhen creating a subscription, you supply a temporal filter, a spatial filter, and a notification condition that act together to specify criteria for when and how the subscription should be triggered. When the criteria are met, the LocationLogic platform generates a notification containing the requested data. That data can then be passed to a client application, which processes the data and sends one or more alerts to the end user. Although there are many techniques you can use to receive and process the notification, the following are typical:

■ Applications built using the LocationLogic Java API—Use an MDB (message driven bean) to receive the information from the subscription's associated event handler. The MDB could either format and send a notification message directly to the


../lldg/lldg.pdf

../lxdg/lxdg.pdf

../lxdg/lxdg.pdf

../medg/medg.pdf

user, or forward the message on to additional application routines for further processing.

■ Applications built using LocationLogic XML Web Services—Use the asynchronous message processing methods available in the application’s source code language; for example, MDBs in Java, or Remote Method Invocation (RMI) in a Windows™ C application.

■ Remote J2ME applications—Use a custom servlet consumer, similar to the one provided with the XML Web Services Gateway Sample Application. This servlet would consume the alert message, transform the data into a suitable user notification message, and forward that message to the application’s SMS or text message gateway, which would then send it to the user’s J2ME device.

Temporal and Spatial Filters

A temporal filter represents a time-based event, which can be any of the following:

■ Single instant in time (for example, 8:00AM exactly, for one day only)■ Range of time (for example, from 5:00PM to 6:30PM, for one day only)■ Recurrence (for example, 8:00AM every day, or 5:00 to 6:30 every Monday,

Wednesday, and Friday)

A spatial filter represents location-based criteria, which can be any of the following:

■ Route■ Circular buffer surrounding a mobile device■ Circular buffer surrounding a fixed location

For more information about specifying subscription filters, refer to the Autodesk LocationLogic Developer’s Guide and the Autodesk LocationLogic XML Web Services Developer’s Guide.


../lldg/lldg.pdf

../lldg/lldg.pdf

../lxdg/lxdg.pdf

../lxdg/lxdg.pdf

Notification Conditions

A notification condition works with a subscription’s temporal and spatial filters to determine how the subscription should be triggered.

You might use a notification condition to specify that a mobile subscription be triggered the first time the spatial criteria are met, or that it instead be triggered every time the criteria are met. You might specify that a feature category subscription be triggered for all matching features, or for only the features that change during the active period of the subscription.

There are a number of notification conditions, and they vary by subscription type. For more information refer to the Autodesk LocationLogic Java API Reference.

Handling Subscription NotificationsEach subscription contains a string representing the name of an event handler, which is configured through the WebLogic Admin Console, and is included in the LocationLogic properties. When a subscription is triggered, the event handler name is used to look up the associated dispatch handler (as specified in the LocationLogic properties).

The following sections describe the data returned in notifications for each type of subscription:

■ “Feature Category Subscription Notification Data” on page 56■ “Mobile Subscription Notification Data” on page 59■ “Optional Notification Data” on page 60

Feature Category Subscription Notification Data

When a feature category subscription is triggered, LocationLogic publishes a notification containing all non-null information from the applicable dynamic content database record, plus any optional notification information you have specified (see “Optional Notification Data” on page 60), and the following data:

Feature Category Subscription Notification Format (1 of 3)

Name Type Description

ct int Count of events in the message (required)

id long Subscription ID (required)

uid String Subscription user ID (required)



nf int Notification fields (required)

The following values are valid:FEATURE_SNAPSHOT = 1004FEATURE_CHANGED = 1005FEATURE_ALL = 1006FN_FEATURE_CHANGED_BATCHED = 1008FN_FEATURE_ALL_BATCHED = 1009

fc String Dynamic content feature category (required)

<n>.op int Operation code (whether the content is an insert, update or delete).

The following values are valid:FEATURE_ADDED = 1001FEATURE_DELETED = 1002FEATURE_UPDATED = 1003

<n>.ce.x double Longitude of the traffic incident location (required only for point-based traffic incidents). This is derived from the TRAFFIC_POINT table’s GEOM column value.

<n>.ce.y double Latitude of the traffic incident location (required only for point-based traffic incidents). This is derived from the TRAFFIC_POINT table’s GEOM column value.

<n>.ss.x double Start point longitude of the segment on which the traffic incident occurred (required only for segment-based traffic incidents). This is derived from the TRAFFIC_SEGMENT table’s GEOM column value.

<n>.ss.y double Start point latitude of the segment on which the traffic incident occurred (required only for segment-based traffic incidents). This is derived from the TRAFFIC_SEGMENT table’s GEOM column value.

<n>.es.x double End point longitude of the segment on which the traffic incident occurred (required only for segment-based traffic incidents). This is derived from the TRAFFIC_SEGMENT table’s GEOM column value.




In the table, <n> is an integer identifying the number of the matched event. For example, you might write an application that alerts users to traffic incidents occurring at a specified route and time. If three incidents are found during an active period of the subscription, LocationLogic publishes one message that includes all three matching events, with the respective <n> values set to 1, 2, and 3.

Also in the table, <topic-property-name> represents a column in the TRAFFIC_SEGMENT or TRAFFIC_POINT table for which data is returned for the particular subscription alert. For all columns that contain non-null values, the data is returned exactly as it is in the traffic table, except for the following columns:

■ GEOM. The GEOM column data is not returned in the subscription alert notification in a GEOM field, but in the <n>.ce.x and <n>.ce.y columns (for subscriptions using the TRAFFIC_POINT table), or the <n>.ss.x, <n>.ss.y, <n>.es.x, and <n>.es.y columns (for subscriptions using the TRAFFIC_SEGMENT table).Note Applications using the LocationLogic Java API must take care to interpret the geometry received from a feature query as an LbsPoint or LbsLineString object.

■ <*>_DATE. Create, start, update, and expire dates are returned in the subscription notification alert (in milliseconds) as Java primitive LONG values (normalized to GMT) even though they are represented in the traffic tables in Java DATE object format.Note Applications must take care to interpret the dates properly. If the information is being processed from a subscription alert notification, the dates must be processed as LONG values; if processing is by a feature query, the dates must be processed as Java DATE objects.

<n>.es.y double End point latitude of the segment on which the traffic incident occurred (required only for segment-based traffic incidents). This is derived from the TRAFFIC_SEGMENT table’s GEOM column value.

<optional information>

Fields and data for any non-null optional information you have specified for subscription alert notifications (see “Optional Notification Data” on page 60).

<n>.<topic-property-name>

<Java primitive>

<topic property value>




Mobile Subscription Notification Data

When a mobile subscription is triggered, LocationLogic publishes a notification containing any optional notification information you have specified (see “Optional Notification Data” on page 60), and the following data:

Mobile Subscription Notification Format (1 of 2)


al String Application listener (JMS only for Version 3.1)

ct int 1



nf int Subscription notification field, which will be one of the following:MN_SNAPSHOT = 1MN_SNAPSHOT_TRUE = 2MN_SNAPSHOT_FALSE = 4MN_FIRST = 8MN_FIRST_TRUE = 16MN_FIRST_FALSE = 32MN_ALL_CHANGES = 64MN_ALL_TRUE = 128MN_ALL_FALSE = 256MN_ALL_CHANGES_WITH_SNAPSHOT_TRUE = 512

fc String Empty string

op int Operation code to be sent to the application; one of the following:MN_SNAPSHOT = 1MN_SNAPSHOT_TRUE = 2MN_SNAPSHOT_FALSE = 4MN_FIRST = 8MN_FIRST_TRUE = 16MN_FIRST_FALSE = 32MN_ALL_CHANGES = 64MN_ALL_TRUE = 128MN_ALL_FALSE = 256This value will be the same as that returned for the ‘nf’ notification field.


Optional Notification Data

In addition to the fields that are automatically included in all subscription alert notifications, you can choose to include additional fields in notifications for both feature category and mobile subscriptions. You specify the optional fields by configuring the LocationLogic Subscription Manager subscriptionmanager.notification.optionalfields property. The property value is a comma-separated list of feature types representing columns in the USER_SUBSCRIPTION table:

sf.id String FID of LbsLocatable object (empty if not the device ID)

sf.lon double Longitude of LbsLocatable object

sf.lat double Latitude of LbsLocatable object

sf.dst double Distance used in spatial filtering

tg.id String FID of LbsLocatable object being monitored (empty if not the device ID)

tg.lon double Longitude of the LbsLocatable object being monitored

tg.lat double Latitude of the LbsLocatable object being monitored

ev.dst double Distance between two LbsLocatable objects

ev.pdst double Previous distance between two LbsLocatable objects. By default this distance is –1.0.

ev.dat long The time the event occurred

ev.ang double Angle in degrees between two LbsLocatable objects

<optional information>

Fields and data for any non-null optional information you have specified for subscription alert notifications (see “Optional Notification Data” on page 60).

Mobile Subscription Notification Format (2 of 2)



■ NAME■ TYPE■ FEATURE_CATEGORY■ FEATURE_SEVERITY■ CREATE_DATE■ START_DATE■ EXPIRE_DATE■ TEMPORAL_FILTER■ EXPIRES_COUNT■ NOTIFICATIONS■ CONDITION_FILTER■ SPATIAL_FILTER_TYPE

An alert notification will include fields (and data) for all the corresponding columns’ values that are not null.

Warning If you specify that additional fields from the optional notification data be included in subscription notifications, you must also include those fields in the Oracle views. See “Task 6: Creating Oracle Views to Support Filtered Feature Categories” on page 45.

Notification of Deleted Subscriptions

LocationLogic applications can delete subscriptions by using one of the following methods:

■ Applications built using the LocationLogic Java API—Use the Subscription Manager deleteSubscription method.

■ Applications built using LocationLogic XML Web Services—Use the SubscriptionRequest element’s DeleteSubscription child element.

■ Remote J2ME applications—Use the LbsmeChangeSubscriptionStatusRequest element, and set the type parameter to DELETE.

Note Deleted subscription notifications are not issued when applications explicitly delete a subscription. The notifications are issued only if LocationLogic deletes the subscription because its expiry time is reached.

You can configure LocationLogic to automatically delete subscriptions when they expire, and to generate corresponding notifications. To do so, set the subscriptionmanager.notification.deleteonexpire LocationLogic property to true in llservices.xml. (For information about editing LocationLogic


properties, see step 3 in “Task 8: Configuring Content Vendor Authentication,” on page 51.)

The notification is published with the following data:

Deleted Subscription Notification Format (1 of 2)


ct int Count of events in the message (required); value is always 1 because only a single deletion can occur per subscription.

<n>.fc String Subscription feature category path (required)

This will be “Personal.Subscriptions.Subscription” or some similar value.

<n>.op int Operation code notifying the application that the subscription has been deleted

This will be the following value: FEATURE_DELETE_ON_EXPIRE = 1007

<n>.nd String User-specified name of the JMS topic or JMS queue to be used as the application listener

<n>.USER_SUBSCRIPTION_ID

long Subscription ID (required)

<n>.USER_ID long Subscription user ID (required)

<n>.NAME String Subscription name

<n>.TYPE String User-specified subscription type

<n>.FEATURE_CATEGORY

String Dynamic content feature category

For feature category subscriptions, this will be a string representing a valid path For mobile subscriptions, this will be an empty string.

<n>.LAST_NOTIFICATION_DATE

long Date of last alert sent to user


In the table, <n> is always 1 because only a single deletion can occur per subscription.

‘No Feature Content’ Notification

You can specify that LocationLogic generate a notification if a feature category subscription is triggered, but no content matching the subscription’s feature category is found. For example, as part of a traffic application, you could send the user an alert stating that there are currently no active traffic incidents to report. The notification is controlled with the following LocationLogic Subscription Manager configuration property:

subscriptionmanager.notification.nofeaturecontent

<n>.TEMPORAL_FILTER String The subscription’s temporal filter, as an iCalendar-formatted string

<n>.NOTIFY_DESTINATION

String User-specified JMS queue or JMS topic name

<n>.CONDITION_FILTER long Notification fields (required):MN_SNAPSHOT = 1MN_SNAPSHOT_TRUE = 2MN_SNAPSHOT_FALSE = 4MN_FIRST = 8MN_FIRST_TRUE = 16MN_FIRST_FALSE = 32MN_ALL_CHANGES = 64MN_ALL_TRUE = 128MN_ALL_FALSE = 256MN_ALL_CHANGES_WITH_SNAPSHOT_TRUE=512FN_FEATURE_SNAPSHOT = 1004FN_FEATURE_CHANGED = 1005FN_FEATURE_ALL = 1006FN_CHANGED_BATCHED=1008FN__ALL_BATCHED=1009

Deleted Subscription Notification Format (2 of 2)



The notification is published with the following data:

‘No Feature Content’ Notification Format


ct int Count of events in the message (required). This value will always be 0.


nf int Notification fields (required)

This will be one of the following values:FEATURE_SNAPSHOT = 1004FEATURE_CHANGED = 1005FEATURE_ALL = 1006FN_ALL_BATCHED=1009

fc String Dynamic content feature category (required)



I■

■

■

■

4
Road Network Content

About routing

About travel directions

About mapping

This chapter describes road network content, how it is used by

LocationLogic to generate maps and travel directions, and how

LocationLogic applications can access those functions.

67

Overview

LocationLogic uses a road network, also called a street network or road system, to calculate travel directions or draw a map onscreen. A road network is an abstract representation of real-world road system data, such as:

■ Coordinates of the street center line (a polyline)■ Name or label of the center line (for example, “Baltimore Avenue”)■ Address ranges on either side of a road■ Topological connectivities—whether adjacent links are accessible■ Navigation attributes such as speed limits, turn restrictions, and one-way streets

The road network used by LocationLogic is derived from static geographic data that is obtained from vendors such as NAVTEQ and Tele Atlas. The road network is added to the LocationLogic database during content deployment. The countries included depend on which content vendor you have a license from, and for which regions your license is valid. Content vendors issue quarterly updates of their road network content; and typically, LocationLogic deployments update their road network content once a year.

The road network is used to generate the mapping content that is used by LocationLogic. This mapping content is referred to as basemap data, and includes both 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). The resulting SDF files are used for both geocoding (see Chapter 5, “Geocoding”), and mapping (see Appendix A, “Designing and Configuring Maps”).

The following sections provide details about how LocationLogic applications can use road network content:

■ “About Routing” on page 69■ “About Travel Directions” on page 71■ “About Mapping” on page 73

68 | Chapter 4 Road Network Content

About Routing

LocationLogic calculates routes that meet specific requirements for travel from one place to another. You can also compare routes, to find out if one route is shorter or has a faster travel time, which is useful if you want to compare a time-dependent route to a standard route, or if you want to compare two time-dependent routes that will be travelled at different hours of the day.

Routes, Legs, and StepsA route is a trip calculated by connecting a start location to a destination location. A route may include intermediate locations. Segments that connect locations are called legs.

Legs along a route

■ Have a start location and a destination location, with no intermediate stops.■ Do not have to be contiguous. For example, a missing leg might indicate a ferry trip.■ Do not have to traverse the entire route (LocationLogic does not fill in gaps).■ Can overlap.■ Can have different travel preferences. For example, travel along a route can be by car

in one leg and by foot in another.■ Can have different cost types. For example, travel along a route might take the

shortest-time path in one leg and the shortest-distance path in another.■ Consist of turn-by-turn instructions called steps. (Note that a route must be calculated

before the steps can be determined.)

The following example shows a trip from Wall Street (lower Manhattan) to Central Park (mid Manhattan), with a stop in Greenwich Village. Bracketed terms indicate alternate street names.

Route

■ Trip from Wall Street to Central Park, stopping in Greenwich Village

Legs

■ Wall Street to Greenwich Village■ Greenwich Village to Central Park

Steps

■ Depart on Wall Street (East)■ Turn Left (North) onto William St for 0.3 miles■ Turn Left (West) onto Fulton St for 0.2 miles

About Routing | 69

■ Turn Right (North) onto Church St for 0.6 miles■ Bear Left (North) onto 6th Ave [Ave of the Americas] for 1.0 mile■ At Greenwich Village, continue (North) on 6th Ave [Ave of the Americas] for 0.4

miles■ Turn Left (West) onto W 14th St for 0.3 miles■ Turn Right (North) onto 8th Ave for 2.2 miles■ 8th Ave becomes Central Park W■ Arrive Central Park

A step type and one or more step modifiers describe each step. A step type represents a basic instruction such as a first step, right turn, or road name change. Step modifiers remind the traveler to take special care during a step.

For example, a step modifier might indicate a slight turn, a ramp, or a turn onto the same street. In some cases, step modifiers can be combined; for example, a left turn might be a sharp turn onto the same street. The default modifier for all steps is normal, indicating no special directives are required.

Calculating and Retrieving RoutesYou can create simple routes; for example, a route with a start location, destination, and no intermediate steps. And you can create complex routes; for example, routes that consist of one or more intermediate stops, changes in the manner of travel (such as foot or automobile), and/or different street networks for different portions of the route.

Each type of LocationLogic API and deployment environment provides methods to calculate and retrieve routes:

■ Applications built using the LocationLogic Java API—Use the following classes and interfaces:❏ LbsGeoToolkitFactory

❏ LbsLeg

❏ LbsRoute

❏ LbsRouteManager

❏ LbsRoutePreferences

❏ LbsStep

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 DetermineRouteRequest element, and associated child elements. For more information, refer to “Route Requests” in the Autodesk LocationLogic XML Web Services Developer’s Guide.


../lldg/lldg.pdf

../lxdg/lxdg.pdf

../lxdg/lxdg.pdf

../lljr/lljr.pdf

■ Remote J2ME applications—Use the following objects and methods:❏ LbsmeDetermineRouteRequest

❏ LbsmeRoutePreference

For more information, refer to “Calculating a Route” in the Autodesk LocationLogic J2ME Developer’s Guide.

About Travel Directions

After creating a route, you can use LocationLogic to generate either one of the following:

■ Complete travel directions that show the locations and steps in a route in sufficient detail so that they can be easily navigated.

■ A travel direction summary that shows only the start, waypoint (if any), and end locations, along with a few major steps that dominate the route.

Generating Travel DirectionsEach type of LocationLogic API and deployment environment provides methods to generate travel directions:

■ Applications built using the LocationLogic Java API—Use the following classes and interfaces:❏ LbsRouteTextView

❏ LbsRouteTextViewPart

❏ LbsTravelDirectionsPreferences


About Travel Directions | 71

../medg/medg.pdf

../medg/medg.pdf

../lldg/lldg.pdf

../lljr/lljr.pdf

■ Applications built using LocationLogic XML Web Services—Use the DetermineRouteRequest and RouteInstructionsList elements, and associated child elements. For more information, refer to “Route Requests” in the Autodesk LocationLogic XML Web Services Developer’s Guide.

■ Remote J2ME applications—Use the following objects and methods:❏ LbsmeDetermineRouteRequest

❏ LbsmeRouteInstruction

❏ LbsmeRoutePreference


Generating Locale-Specific Travel DirectionsLocationLogic includes a resource bundle that makes it easy to generate locale-specific travel directions that use the language and unit type appropriate for a particular locale. The LocationLogic resource bundle includes property files that provide default support for the United States, Canada, Britain, Italy, France, Spain, Portugal, and the Netherlands. You can modify these property files, or create new files for additional locales, as described in the following procedure.

To add support for additional locales

1 Make a copy of the default RouteTextViewResources.properties file. Rename the file, using the following format:

RouteTextViewResources_{language code}_{country code}.propertiesFor example:

RouteTextViewResources_fr_CA.properties

2 Edit the properties file, replacing the values with localized versions as appropriate. Comments are provided in the default properties file to facilitate this process.

3 Repeat this process, creating as many property files as you need to support all new locales.

4 Use the Java JAR utility to place the new property files, along with any existing property files, in an archive called appresources.jar.


../lxdg/lxdg.pdf

../medg/medg.pdf

5 Place the appresources.jar file in the same location as the llogicclient.jar file for the application to which you are adding resources (for example, MyApp/WEB-INF/lib). Note Do not place the appresources.jar file into llogic.ear or on the system classpath.

6 Redeploy your application.

Creating Custom Presentation ViewsLocationLogic generates standard textual directions. If you need to create a custom presentation view (for example, a voice application), you will need to write your own application code to construct the natural language descriptions of the route, legs, and steps. For more information, refer to the descriptions of LbsRoute, LbsLeg, and LbsStep in the Autodesk LocationLogic Java API Reference.

About Mapping

An important aspect of LocationLogic applications is providing maps to users. The LocationLogic Geomap component uses basemap data to provide full mapping functionality for your applications.

Note You control the server locations, generated URL locations, and other map format options by setting the corresponding LocationLogic configuration properties as specified in Appendix A, “Designing and Configuring Maps,” and the Autodesk LocationLogic Properties Reference.

You have a great deal of flexibility in setting up your application’s maps. You can select from a variety of types of information to display, and from a variety of map formats.

You can generate maps that are centered around a specific location, or that display a route. When you generate maps, you can specify that the maps include any of the following:

■ Symbols—Graphics representing items such as traffic incidents or the start or end point of a route

■ Image hotspots—Points on a map that a user can select to get more information about a place, product, or service (such as the phone number)

■ Route highlights—Overlaid lines representing a previously calculated route

About Mapping | 73


../llpr/llpr.pdf

../llpr/llpr.pdf

Each type of LocationLogic API and deployment environment provides methods for applications to generate maps, with desired options (such as symbols, hotspots, and so forth):

■ Applications built using the LocationLogic Java API—Use the following classes and interfaces:❏ LbsMapManager

❏ LbsMapHotSpot

❏ LbsMapImageMap

❏ LbsMapLinestring

❏ LbsMapSymbol


■ Applications built using LocationLogic XML Web Services—Use the PortrayMapRequest element, and associated child elements. For more information, refer to “Presentation Requests” in the Autodesk LocationLogic XML Web Services Developer’s Guide.

■ Remote J2ME applications—Use the following objects and methods:❏ LbsmePortrayMapRequest

❏ LbsmeBoundingBox

❏ LbsmeBBoxContext



../lldg/lldg.pdf

../lxdg/lxdg.pdf

../lxdg/lxdg.pdf

../medg/medg.pdf

../lljr/lljr.pdf

I■

■

■

■

■

■

5
Geocoding

The Autodesk LocationLogic Geocoder

Geocoding constraints

Accessing forward geocoding

Accessing reverse geocoding

Geocoding results

This chapter describes what geocoding is, the LocationLogic

geocoding components, and how applications use geocoding.

75

Overview

Forward geocoding is the process of translating a street address to a geographic coordinate (point) so that it can be accurately placed on a map. Geocoding is an important service of a location-based application.

The opposite function of forward geocoding is reverse geocoding, which is the process of translating a geographic coordinate to a street address. The derived information, which includes address location, and directional distances from reference points, can then be used to fulfill other geo-spatial queries. For example, you can route to and from a POI (Point of Interest), or search for POIs in the vicinity of the derived point.

Taken together, forward geocoding and reverse geocoding are referred to as geocoding.

A geocoding engine provides the complete functionality required to parse an input address into its individual components, to apply rules-based match logic, and to resolve the address by returning the results of a forward or reverse geocode request.

For forward geocoding, LocationLogic uses proprietary-formatted data files from Ascential Software (formerly Vality). For reverse geocoding, LocationLogic uses SDF files, which are created from the road network and POI data, and installed during LocationLogic deployment.

The following sections provide details about the LocationLogic Geocoder, and performing geocoding in your LocationLogic application:

■ “The Autodesk LocationLogic Geocoder” on page 77■ “Geocoding Constraints” on page 77■ “Accessing Forward Geocoding” on page 79■ “Accessing Reverse Geocoding” on page 80■ “Geocoding Results” on page 81

76 | Chapter 5 Geocoding

The Autodesk LocationLogic Geocoder

The Autodesk LocationLogic Geocoder is used by the LocationLogic platform for geocoding. It is made up of two components:

■ Integrity GeoLocator from Ascential Software (formerly Vality)—A geocoding engine that performs all forward geocoding for most areas in the United States and Europe. GeoLocator converts street addresses to latitude/longitude coordinates using data sets for the appropriate geographical region.

■ Autodesk Reverse Geocoder—The LocationLogic geocoding engine that performs reverse geocoding.

Related Topic

■ The Integrity GeoLocator and the Autodesk Reverse Geocoder are installed when you install LocationLogic. For more information about configuring these components, refer to the Autodesk LocationLogic Installation Guide and “Geocode Properties” in the Autodesk LocationLogic Properties Reference.

Geocoding Constraints

The following sections summarize the guidelines with which the data sent in geocoding geocoding requests must comply:

■ “Position of Civic Number” on page 77■ “Support for Street Types in Street Name Field” on page 78■ “Support for Alternative Characters” on page 78■ “Support for Stripped Character Sets” on page 79

Position of Civic NumberStandardized addresses for the following countries will have the civic number before the street name (for example, 123 Main):

■ Canada (CA)■ Great Britain (GB)■ France (FR)■ Luxembourg (LU)■ United States (US)

Standardized addresses for the following countries will have civic number after the street name (for example, Main 123):

The Autodesk LocationLogic Geocoder | 77

../llig/llig.pdf

..//llpr/llpr.pdf

■ Austria (AT)■ Belgium (BE)■ Denmark (DK)■ Germany (DE)■ Italy (IT)■ Netherlands (NL)■ Portugal (PT)■ Spain (ES)■ Sweden (SE)■ Switzerland (CH)

Support for Street Types in Street Name FieldThe geocoder provides the following support for street types in street name fields:

■ Before street name■ After street name■ Attached to street name■ Unattached to street name■ Hyphenated (for example, Albrecht-Dürer-Straße)

Support for Alternative CharactersLocationLogic supports country-specific special characters, such as ‘ß’ in Germany. Some special characters have more than one alternate result. Examples of results and alternate city and street names are as follows:

Name Result Alternate Result

Köln Köln Koeln

München München Muenchen

Goethestraße Goethestraße Goethestrasse

Rue de Grénell rue de Grénell Rue de Grenell


Support for Stripped Character SetsLocationLogic supports the 7-bit ASCII character set, a stripped version of the 8-bit ASCII character set, for pattern-matching and lexical comparisons. Examples of the 7-bit and 8-bit ASCII character sets for city and street names are as follows:

Accessing Forward Geocoding

Applications use forward geocoding for the following:

■ Displaying tabular address data on a pushpin map■ Accurately showing locations or events on a map■ Querying to find geographic features by address

Each type of LocationLogic API and deployment environment provides methods for forward geocoding:

■ Applications built using the LocationLogic Java API—Use the following classes and interfaces:❏ LbsAddress

❏ LbsPoint

❏ LbsGeocoder

❏ LbsGeocodeMatch

❏ LbsGeoToolkitFactory


■ Applications built using LocationLogic XML Web Services—Use the GeocodeRequest element, and associated child elements. For more information, refer to “Geocoding Requests” in the Autodesk LocationLogic XML Web Services Developer’s Guide.

Name 7-bit ASCII Character Version 8-bit ASCII Character Version

Köln Koln Köln

München Munchen München

Goethestraße Goethestrabe Goethestraße

Rue de Grénell Rue de Grenell Rue de Grénell

Accessing Forward Geocoding | 79

../lljr/lljr.pdf

../lldg/lldg.pdf

../lxdg/lxdg.pdf

../lxdg/lxdg.pdf

■ Remote J2ME applications—Use the following objects and methods:❏ LbsmeAddress

❏ LbsmeGeocodeMatch

❏ LbsmeGeocodeRequest

❏ LbsmePoint

For more information, refer to “Geocoding and Reverse Geocoding Locations” in the Autodesk LocationLogic J2ME Developer’s Guide.

Accessing Reverse Geocoding

Each type of LocationLogic API and deployment environment provides methods for reverse geocoding:

■ Applications built using the LocationLogic Java API—Use the following classes and interfaces:❏ LbsGeocoder

❏ LbsReverseGeocoderPreferences

❏ LbsGeocodeMatch

❏ LbsGeoToolkitFactory


■ Applications built using LocationLogic XML Web Services—Use the ReverseGeocodeRequest element, and associated child elements. For more information, refer to “Geocoding Requests” in the Autodesk LocationLogic XML Web Services Developer’s Guide.

■ Remote J2ME applications—Use the following objects and methods:❏ LbsmeAddress

❏ LbsmeGeocodeMatch

❏ LbsmePoint

❏ LbsmeReverseGeocodeRequest

For more information, refer to “Geocoding and Reverse Geocoding Locations” in the Autodesk LocationLogic J2ME Developer’s Guide.


../lljr/lljr.pdf

../medg/medg.pdf

../lldg/lldg.pdf

../lxdg/lxdg.pdf

../lxdg/lxdg.pdf

../medg/medg.pdf

Geocoding Results

The geocoder returns the following results for forward and reverse geocode requests:

Standardized AddressA standardized address is an address format that conforms to a specific country’s postal addressing guide, which includes guidelines for capitalization, punctuation, abbreviations, symbols, and postal codes. All addresses in the geocoding data sets are in standardized address form.

Match Confidence LevelThe match confidence level represents the confidence of the match. When LocationLogic geocodes an address, it applies pattern-matching algorithms to compare an input address against records in the geocoding database. The match confidence reflects the degree of accuracy according to the pattern-matching algorithms. A higher number indicates a better match.

The match confidence is influenced by the following factors:

■ Spelling—Values that are spelled the same will have a higher match confidence than values whose spellings differ, and simple variations or common misspellings yield a higher match confidence than larger variations. For example, “Woshington” matches the following values in decreasing order of match confidence: “Woshington Ave,” “Washington Ave”, “Worthington Ave.”

■ Frequency—Common values, such as “Main Street” will have a lower match confidence than uncommon values, such as “McInnis Parkway,” because it is less probable that an uncommon value was matched in error than a common one.

Match LevelThe match level is the level of the match, based on the number of data fields that are identified in the input address. Ideally, the match will have all of the same data fields as

Forward Geocode Results Reverse Geocode Results

• Standardized Address• Match Confidence Level• Match Level• Geometric Point• Street Network Link Feature ID

• Standardized Address• Geometric Point• Street Network Link Feature ID

Geocoding Results | 81

the input address. The match level is defined by a numerical value between 0 to 5, with 4 (house number matched exactly) indicating the best match. The following table defines each match level:

Note Match levels only apply to forward geocoding matches. Reverse geocoding matches always have a match level of 0.

Geometric PointThe geometric point represents a location on the Earth’s surface defined by a coordinate pair and a spatial reference system (SRS).

Street Network Link Feature IDA street network link is a road segment on a street network. Each street network link has a street network link feature ID, which is a database link feature ID in the Oracle database. The street network link feature ID is only returned if the geocoded result has a match level of 3 or 4.

Geocoding Match Levels

Match Level Description

5 Indicates a street intersection matched exactly.

4 Indicates a house number matched exactly.

3 Indicates that the street name matched, either exactly or approximately.

2 Indicates the postal code matched exactly.

1 Indicates the municipality matched, either exactly or approximately.

0 Indicates an unknown match level.


I■

■

■

■

6
Accessing External Data from LocationLogic

External content requirements

Setting up LocationLogic for external content

Accessing external content

In addition to accessing content in the LocationLogic database,

LocationLogic applications can access content that is in external

databases. This chapter explains how to set up a link between

LocationLogic and external content.

83

Overview

In addition to accessing the LocationLogic database, your applications can access data in other, external databases. The external data can be anything that your application needs; for example, custom POI content from unsupported vendors, carrier-specific user account information, and so forth.

To make external content accessible to LocationLogic and its applications, you set up a data bridge—a mechanism that links data in an external database to the LocationLogic database.

LocationLogic uses two tables in the LocationLogic database to implement a data bridge:

■ The data link table maintains information about external data sources. For every external source, there is an entry in the data link table that fully defines the external source, including its database name and a corresponding SQL select statement that can be executed against the database in order to return individual data items.

■ The data bridge table contains a row for every external data item that LocationLogic can access, pointing the way to the actual data through the datalink_id column. From a LocationLogic point of view, external data items that are accessible through the data bridge table are a type of LocationLogic feature (see “LocationLogic Features” on page 5.) For information about accessing the external data, see “Accessing External Content” on page 89.

Note The data bridge implementation uses the same feature type (configurable through the featuremanager.databridgefeaturetype property, as described in “Structuring Feature Categories” on page 117), for all external data items that are accessible to any given LocationLogic application. This means that although the external data can represent any sort of information, only one sort of information is available to any application. For example, the external data can represent custom POI content, or user account information, but you cannot have both available to a single LocationLogic application.

External Content Requirements

In order for LocationLogic to access external data, the data must comply with the following requirements:

■ The external source must be accessible through JDBC (Java DataBase Connectivity).■ The external source’s host/port must be accessible to LocationLogic by standard

network access. (It can include communication through firewalls.)■ The external database can be any type, such as SQL+, Access, and so forth.

84 | Chapter 6 Accessing External Data from LocationLogic

■ The external database columns to be accessed must be of type string.

Setting Up LocationLogic for External Content

The following sections explain the process of setting up LocationLogic so that external content can be used (accessed and queried) by LocationLogic applications. Typically, you perform this process as part of the LocationLogic deployment. However, if your initial deployment does not include using external content, you can still shut down LocationLogic at any time in order to set it up to use external content.

Process OverviewThe following table describes the steps required to link external data to LocationLogic:

Task 1: Defining External Content SourcesBefore you can reference individual external data items, you need to define every item’s source, such as its database name and machine address. Multiple data items can come from the same source. You only need to define a given source one time, even when it is the source for multiple data items.

To define an external content data source

1 Open the WebLogic Server Console■ Open a Web browser and go to the following address:

http://localhost:7001/console■ When prompted for username and password, enter system/weblogic.

Process Overview: Linking External Content to LocationLogic


1 Define external content data sources. “Task 1: Defining External Content Sources” on page 85

2 Link external content to the LocationLogic database by adding records to the data link table.

“Task 2: Linking External Content to the LocationLogic Database” on page 87

3 Create LocationLogic data bridge records to correspond to external data items.

“Task 3: Creating Data Bridge Features” on page 87

Setting Up LocationLogic for External Content | 85

The WebLogic Server Console is displayed.

2 Modify the following block of properties to match your data source.Bold italic indicates values you need to modify:<JDBCDataSource JNDIName="datasrc.YourDataSource"

Name="datasrc.YourDataSource" PoolName="YourPool"Targets="AdminServer"/>

<JDBCConnectionPool DriverName="oracle.jdbc.driver.OracleDriver"LoginDelaySeconds="1" MaxCapacity="3" Name="YourPool"Properties="user=YourUsername;password=YourPassword;\

dll=ocijdbc8;protocol=thin"RefreshMinutes="15" SupportsLocalTransaction="true"Targets="AdminServer" TestTableName="dual"

URL="jdbc:oracle:thin:@YourServersIPAddress"/>

Where■ YourDataSource is the name of the data source. This is also the name you use

when you add the data source information to the data link table.■ YourPool is the name of the connection pool.■ YourUsername is the name of a user with read access to the database associated

with the YourPool connection pool.■ YourPassword is the password for the YourUsername user.■ YourServersIPAddress is the Internet Protocol address of the host machine for

YourDataSource. It may be numeric (for example, 10.1.23.124) or a machine name (for example, lbsdev-04.autodesk.com). You must also include the port number—the default is 1521—using the format host:port.


Task 2: Linking External Content to the LocationLogic DatabaseYou must add information to the LocationLogic data link table so that LocationLogic can access external content. Use the DataLinkGenerator tool, available from your Autodesk Professional Services representative.

Task 3: Creating Data Bridge FeaturesTo implement the link to an external data item, you must create a corresponding LocationLogic database record in the data bridge table. You can use any of the following techniques to create the data bridge records:

■ Use the DataBridgeGenerator tool, available from your Autodesk Professional Services representative.

■ Use direct database access to add rows to the LocationLogic data bridge table by using a SQL script. For information about SQL scripts, refer to your Oracle documentation.

■ Program your LocationLogic application to create data bridge records, as described in the following example.

LocationLogic Java API Example

You can use the LocationLogic feature-related APIs from within your application to create data bridge features. If your application is built using the LocationLogic Java API, use the LbsFeatureManager interface and LbsFeatureCategory interface methods, as shown in the following sample code.

UserLogicBean.java - getEmailAddress() (1 of 2)

public String getEmailAddress() throws LLAppException{String emailAddress = "";

try {LbsFeatureManager featureManager =

LbsEngineFactory.getFeatureManager(getLbsSession());PropertyReader pr =

PropertyReader.getInstance(CommonConstants.PROPERTIES_FILE);// data bridge items must use this feature category pathLbsFeatureCategory featureCategory = featureManager.

getFeatureCategory("Personal.UserProfile.DataBridge.AddressBook");// set up the whereClause filter to look for features of type "EMAIL"String whereClause = “TYPE='EMAIL'";Vector properties = new Vector();properties.add("EMAIL_ADDRESS”);

Setting Up LocationLogic for External Content | 87

List features = featureCategory.findFeatures(properties, whereClause);

// if there are features of type "EMAIL”, then the data bridge and// feature already existif (!features.isEmpty()) {

Lbsfeature feature = (LbsFeature) features.get(0);// retrieve the value that is stored as the external user profile itememailAddress = (String) feature.getProperty("EMAIL_ADDRESS");

}// else the data bridge needs to be createdelse {

// create the data bridge feature with feature type "EMAIL”LbsFeature feature =

featureManager.createDataBridgeFeature("EXTERNAL_FEATURE","EMAIL", null, getUsername());

featureCategory.addFeature(feature);featureCategory.saveChanges();

// now try again to retrieve the feature propertyfeatures = featureCategory.findFeatures(properties, whereClause);if (!features.isEmpty()) {

Lbsfeature feature2 = (LbsFeature) features.get(0);emailAddress = (String) feature2.getProperty("EMAIL_ADDRESS");

}}

}catch (LbsException e) {

e.printStackTrace();}return emailAddress;

}

UserLogicBean.java - getEmailAddress() (2 of 2)


Accessing External Content

Each type of LocationLogic API and deployment environment provides methods for applications to specify and retrieve content items, in this case, external content accessible through the data bridge. The following list describes the different techniques that you can use to access LocationLogic content items (features):




Accessing External Content | 89

../lldg/lldg.pdf

../lxdg/lxdg.pdf

../lxdg/lxdg.pdf

../medg/medg.pdf

../lljr/lljr.pdf

I■

■

■

■

■

■

A
Designing and Configuring Maps
n this appendixOverview

Map creation and configuration overview

Authoring maps

Creating copyright or branding overlays

Configuring Map Manager

Configuring Geomap

This chapter describes the map files used by Autodesk®

LocationLogic, how to integrate maps into your application, and

how to configure LocationLogic to generate maps with the desired

appearance for your application.

91

Overview

LocationLogic retrieves map files from the file system, overlays them with geographic information produced by the LocationLogic platform (such as routes), and then creates raster versions of the maps for display on various devices.

The required map files are Autodesk MapGuide® Map Window Files (MWFs), which point to layers of geographic data in SDFs (spatial data files). If you want to author custom maps for your applications, you will need Autodesk MapGuide® Author Release 6 and Autodesk MapGuide® Server Release 5 or 6 to create maps for LocationLogic. You create map files in Autodesk MapGuide Author and test them in Autodesk MapGuide Server. For detailed map authoring guidelines, refer to the Autodesk MapGuide Author documentation.

Note Neither Autodesk MapGuide® Author nor Autodesk MapGuide® Server are required to display maps in LocationLogic.

Types of MapsLocationLogic can generate maps based on parameters such as the following:

■ Center point—The map's center point and diameter, or center point and scale.■ Route—The calculated route to display. When your application calculates a route, or

requests a route handle for a cached route, you can request that a map be returned along with it. The route will be highlighted on the map, and will contain symbols for the start and end points, as well as any waypoints (intermediate locations specified in a multi-leg route).

For all maps, you can specify the coordinates of a bounding box to display only a section of the route. With some additional coding, you can use route information from a previous request to highlight individual legs, steps, and turns, or to add POIs.

92 | Appendix A Designing and Configuring Maps

Map FormatsApplications can retrieve maps in a variety of formats. You should select the format based on your user's client device. For example, if you determine that your user has a mobile device with a black-and-white screen, you would select the 1-bit uncompressed Wireless Bitmap (WBMP) format. You can generate a map in the following raster formats:

■ 1-bit BMP—Black-and-white bitmap■ 1-bit WBMP—Black-and-white wireless bitmap■ 8-bit GIF—Graphics Interchange Format (256 colors)■ 2-bit PNG—Grayscale Portable Network Graphics■ 8-bit PNG—Color Portable Network Graphics (256 colors)■ 24-bit PNG—Color Portable Network Graphics (16,777,216 colors)

Map Parameters

Applications can specify the following parameters in a map request, regardless of the map type:

■ Map name—A logical map name. If you specify null, the default map name specified in the LocationLogic configuration properties will be used.

■ Width—The desired map image width, in pixels.■ Height—The desired map image height, in pixels.■ Map format—The name of the map format.

The width and height must be between 16 and 2048 (inclusive). You should set the width and height parameters to reasonably correspond to the user's client device, just as you selected the map format. For example, a good image display size for a typical mobile phone device would be 128 for the width, and 128 for the height. If you generate a PNG format map for a Web browser, however, you could set the map size significantly larger, perhaps 640 x 480.

For all map formats, you can specify POIs, positions, and routes that are overlaid on the map as symbols or polylines. You can specify which symbols and linestyles are used.

Overview | 93

Map Creation and Configuration Overview

You must perform the following tasks to create maps and to configure them for integration with LocationLogic:

Process Overview: Map Creation and Configuration


1 Author maps with Autodesk MapGuide® Author, which includes configuring• background color• polyline layers (for example, roads and

rivers)• polygon layers (for example, regions and

lakes)• point layers (for example, POIs and

landmarks)• scale

• “Task 1: Authoring Maps” on page 95

• Autodesk MapGuide® documentation

2 Optionally, create copyright or branding overlays for your maps.

• “Task 2: Creating Copyright or Branding Overlays” on page 99

• Autodesk LocationLogic Properties Reference

3 Configure the Map Manager component of the platform, which assembles information that determines how the map will be drawn and displayed. You can configure properties such as • highlighting style• bounding box extension

• “Task 3: Configuring Map Manager” on page 101


4 Configure Geomap, which converts map files to a format suitable for mobile devices. You configure Geomap using Map Manager properties.

• “Task 4: Configuring Geomap” on page 103



../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

Task 1: Authoring Maps

When designing maps for display on mobile devices with small screens, such as PDAs and cell phones, you need to be particularly concerned about usability, appearance, and performance.

Note All guidelines assume that you will be using Autodesk MapGuide® Author Release 6.

OverviewBefore creating maps, you should consult a cartographer to ensure that your maps conform to industry standards. For example, you will want to use standard colors for certain types of geographic information, such as city blocks, and standard symbols for POIs (points of interest), such as airports.

When authoring maps, you will also need to consider the final output format. For example, if you want to send images to be displayed on a black-and-white WAP phone or PDA, it is recommended that you author your map in black-and-white. However, if you need to use a color source file, LocationLogic will prevent dithering by automatically rendering the WBMP image using a black-and-white, two-color palette.

The following sections describe typical mapping tasks and implementation guidelines:

■ “Representing a User’s Location” on page 96■ “Representing a Route” on page 96■ “Representing Features” on page 97■ “Designing Maps for Performance” on page 97

Task 1: Authoring Maps | 95

Representing a User’s LocationIn Location-Based Services (LBS) applications, users often request a map that provides context for their location (or the location of another person, place, or object) within a certain geographical area. A contextual map can answer a question such as, “Where am I, in the context of the city (state, country, world)?”

Guidelines for Representing a User’s Location

Following are guidelines for representing a user’s location on a map:

■ Show the user’s location in terms of the geographic area or context. For example, the user must be able to visualize herself and her spatial relationship to the surrounding city.

■ Apply selection principles that will display only the relevant features for a given map scale. For example, using selection, you would inherently suppress irrelevant information, such as all the stop signs in the city. Selection is a term used in cartography that implies the suppression of nonessential features.

Representing a RouteUsers often request a route to a destination. Given a starting location and a stopping point, your application needs to draw a route that will help the user successfully navigate in the real world. A route map can answer a question such as, “How do I reach the Royale Theater from where I am?”

Guidelines for Representing a Route

Following are guidelines for representing a route on a map:

■ Specify a thick line with a line color that contrasts with the map background. You might want to make the line semi-transparent so that the street network is visible underneath the route.

■ Clearly mark the start and end points of the route.


Representing FeaturesMap users might be interested in information such as the population sizes of cities along their route. A map designed to present information about features can answer a question such as, “What is the largest city along my route?”

Guidelines for Representing Features

Following are guidelines for representing features on a map:

■ Apply the principle of visual variables to emphasize the different properties of the feature. These variables include❏ Size❏ Shape❏ Graytone value❏ Texture❏ Orientation❏ Hue

For example, you can use different sizes and colors of dots to indicate the different population sizes of cities.

■ Other visual variable principles might also apply.

Designing Maps for PerformanceImproperly designed maps can take a long time to load, slowing the performance of LocationLogic applications. This section offers the following guidelines for designing quick-loading maps:

■ “Generalizing Data in SDFs” on page 97■ “Limiting Data in SDFs” on page 98

Generalizing Data in SDFs

LocationLogic applications display raster versions of Autodesk MapGuide® Map Window Files (MWFs), which point to layers of geographic data in SDFs (spatial data files).

You can increase the speed of map loading by generalizing the data in your SDFs. Generalizing reduces line detail by decreasing the number of vertices.

Note For best generalization results, use a specialized application, such as Safe Software’s Feature Manipulation Engine (FME).

Task 1: Authoring Maps | 97

Following are guidelines for generalizing data in SDFs:

■ Design your maps to use varying degrees of generalization based on the scale at which the map will be displayed. As a general rule, you need to create a separate SDF for each one-half to one order of magnitude of scale. This could result in several versions of the same SDF, each displayed over a different scale range.

■ Set the display range so that a given layer displays when zoomed out, but becomes unavailable when zoomed in to a specified point. To do this, repeat the information on the first layer, but set the display range so that the second layer becomes available when zoomed in to the point where the first layer stops.For example, you might set the first layer’s display range at 40,000,000 to 4,000,000 (one order of magnitude), which would cause the generalized data to display when the user zooms out within that range. You would then set the second layer’s display range from 4,000,000 to 400,000 (next order of magnitude), and the third, from 400,000 to 40,000.

Limiting Data in SDFs

You can further improve performance by limiting the amount and type of data used in your maps. Following are guidelines for limiting data in SDFs:

■ To decrease map loading time, include only relevant data on each layer. MWFs can incorporate complex themes and display five to ten layers simultaneously, with 100 to 500 features visible simultaneously per layer. Simplify the amount of visible data as much as possible.

■ Limit the amount of SDF data needed for any map. As a general rule, when rebuilding layers for a particular map view, make sure that you use less than 100KB of data. You can track the amount of data being used by reading the status bar in Autodesk MapGuide Author®.

■ Create a separate SDF for each layer to be included in a MWF. Each SDF should contain only the data needed for its corresponding layer.

■ Use only one type of feature, such as points or polylines, in each SDF. More than one type of feature in a single SDF will slow access to the file.

■ Minimize the number of text map layers and feature labels.


Task 2: Creating Copyright or Branding Overlays

The following table describes the steps required to create copyright or branding overlays:

Creating GMX FilesA GMX (Geomap MWF Extension) file is an XML text file that is used to extend the information in a map’s MWF file. Each GMX file corresponds to a single MWF. The GMX file points to one or more static image files (your copyright or branding logos), and supports the placement of those images on your maps.

Follow these rules when creating GMX files:

■ The filename must have the same base filename as the corresponding MWF, and the file suffix must be .gmx. For example, a GMX corresponding to sfcolor.mwf must be named sfcolor.gmx.

■ A GMX file must be located in the same directory as the corresponding MWF.■ Supported image encodings are JPEG, GIF, and PNG.

Sample GMX File

The following example results in logo.jpg being drawn in the top left corner of the map, and logo2.gif being drawn in the top right corner:

<?xml version="1.0" encoding="UTF-8"?>

Step Description Refer to

1 Create a raster graphic image (GIF, JPEG, or PNG) to use as your copyright or branding logo.

Your graphics package documentation.

2 Create a GMX file that references the raster file for every map that you want to copyright or brand.

“Creating GMX Files” on page 99

3 If you used relative path names in your GMX file, enable Geomap to find the image file by setting the mapmanager.mapspec.staticimagepath property.

Autodesk LocationLogic Properties Reference

Task 2: Creating Copyright or Branding Overlays | 99

../llpr/llpr.pdf

<GeomapMWFExtension Version="6.0"><GeneralProperties>

<StaticImage><Name>/data/LL/rasters/logo.jpg</Name>

<Position>TopLeft</Position></StaticImage><StaticImage>

<Name>/data/LL/rasters/logo2.gif</Name><Position>TopRight</Position>

</StaticImage></GeneralProperties>

</GeomapMWFExtension>

StaticImage Element

The StaticImage element contains two sub-elements:

■ Name—Specifies the filename and pathname of the static image file. You can specify the pathname as:❏ Absolute—Begin the value with the “/” character. Geomap uses the image file as

specified, without regard to the mapmanager.mapspec.staticimagepath property value.

❏ Relative—Geomap converts the pathname to an absolute pathname by appending the Name value to the directory pathname specified by the mapmanager.mapspec.staticimagepath property.

We recommend that you use relative pathnames and the mapmanager.mapspec.staticimagepath property, which offers greater flexibility with regard to file relocation and sharing.

■ Position—Specifies where the static image should be placed on the map. You can specify the following values:❏ BottomLeft

❏ TopLeft

❏ BottomRight

❏ TopRight

If you do not specify a Position element for an image, or if you specify an invalid value, then BottomLeft is assumed, and the image is drawn in the bottom left corner of the map. If you specify the same Position value for two or more images, then they are drawn on top of each other.

Note The StaticImage element does not provide a mechanism for image scaling. The static image is copied pixel-for-pixel to the map image.


Task 3: Configuring Map Manager

The LocationLogic Map Manager assembles information from the platform—such as map area, map size, location, and route—that determines how the map will be drawn and displayed.

For more information about Map Manager properties, refer to the Autodesk LocationLogic Properties Reference.

Following are the map display properties covered in this section:

Other map display attributes include symbol label size, text font, text color, background color, and background mode. For information about these properties, refer to the Autodesk LocationLogic Properties Reference.

The following guidelines can help you improve the appearance of maps displayed with LocationLogic applications.

Map Display Properties Covered in this Section

Map Display Property Description Refer to

Bounding box expansion factor

Map Manager property that creates padding around the boundaries of a map.

• “Adjusting the Bounding Box Expansion Factor” on page 102


Highlight style Map Manager properties that determine how a feature, such as a route, will be highlighted on a map. You determine the highlight styles in the mapmanager.markup.HLSn property that configures Geomap. Then, you can select a particular highlight style using the mapmanager.highlightStyle property.

• “Creating and Using Custom Highlight Styles” on page 102


Task 3: Configuring Map Manager | 101

../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

Adjusting the Bounding Box Expansion FactorThe bounding box expansion factor, expressed in a percentage, is used to provide a margin of display padding around the edges of a map. The bounding box expansion factor is applied whenever Map Manager generates a map URL.

For example, in the case of a route map, the initial bounding box is determined from the geometry of the links composing the route. The generated bounding box encloses the route exactly, so the edges of the route might touch the edge of the map. To create padding around the route, set the bounding box expansion factor to 10 or 20 percent. You might want to experiment with different values to optimize the appearance of maps for your target devices.

Creating and Using Custom Highlight StylesYou can configure LocationLogic maps to use a custom highlight style for features such as routes or regions. First, you set up a highlight style, and then you configure Map Manager to use a particular highlight style or styles for a specific purpose. You can specify a highlight style per application, per map, per output format, or as a global default.

To create a custom highlight style

■ Modify the mapmanager.markup.HLSn property value:color, thickness, linestyle, invert mode, opacity

Where:❏ n corresponds to the number of the highlight style being defined. Geomap allows

you to define up to four highlight styles.❏ color is an integer in the range of 1–256 (Autodesk MapGuide® palette).❏ thickness is an integer greater than 0 (corresponds to the values in Autodesk

MapGuide®).❏ linestyle is one of the Autodesk MapGuide® line styles, by name, such as SOLID.


❏ invert mode determines whether the color scheme will be dark over light, or light over dark. Possible values are true or false.

❏ opacity corresponds to a floating-point number of the form: 0 (transparent) ≥ n ≥ 1.0 (opaque)

Note The Java code default value of the mapmanager.markup.HLSn property is: “4,1,SOLID,FALSE,1.0”

To use a custom highlight style

■ Configure the Map Manager highlight style property for a specific purpose or as a global default.For example, the following properties would be used to specify custom highlight styles for the sf_finder application. (The values would be specified as numbers that correspond to your custom highlight styles.)mapmanager.sf_finder.usa.BMP1U.highlightStylemapmanager.sf_finder.usa.highlightStyle

Task 4: Configuring Geomap

LocationLogic Geomap converts MWFs to a format suitable for display on mobile devices. You can configure both the Map Manager and Geomap using Map Manager properties.

For more information about Geomap properties, refer to the Autodesk LocationLogic Properties Reference.

Following are the map display properties covered in this section:

Map Display Properties Covered in this Section

Map Display Property Description Refer to

Anti-aliasing Map Manager property that configures Geomap to control line smoothness in raster text and graphics.

• “Enabling Anti-Aliasing” on page 104


Color overrides Map Manager property that configures Geomap to use a custom color scheme rather than the standard Autodesk MapGuide®

colors. For more information about Autodesk MapGuide® colors, refer to the Autodesk MapGuide® documentation.

• “Configuring the Color Overrides Property” on page 104


Task 4: Configuring Geomap | 103

../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

../llpr/llpr.pdf

Enabling Anti-AliasingLocationLogic Geomap provides a built-in anti-aliasing feature to smooth the appearance of lines or text in a raster map image.

You configure anti-aliasing in the mapmanager.xml file. There are two anti-aliasing properties:

■ graphics.antialiasing■ graphics.text.antialiasing

Since black-and-white images display adequately without anti-aliasing, LocationLogic disables anti-aliasing for 1-bit image formats such as WBMP1U or BMP1U, regardless of property settings. However, anti-aliasing can improve the appearance of grayscale images such as PNG2.

Since your map must provide readable labels for roads and features, text anti-aliasing is usually more important to a map’s appearance than line anti-aliasing. If the text labels or lines on your map display with jagged edges, set the graphics.text.antialiasing property to true.

Related Topic

■ For more information about Geomap Properties, refer to the Map Manager properties section in the Autodesk LocationLogic Properties Reference.

Configuring the Color Overrides PropertyIf you want to override the Autodesk MapGuide® color palette with a custom color scheme, you can set the color overrides property. The color overrides property name takes the form:

mapmanager.Coloroverrides.<color index value>

Where:

■ <color index value> corresponds to a selected color in the drop-down lists displayed in Autodesk MapGuide® Author. Acceptable values are 1–256.


../llpr/llpr.pdf

The property value takes the form of a combined RGB hexadecimal value, expressed as an integer, which consists of the following components:

■ RR—Bits 16–23■ GG—Bits 8–15■ BB—Bits 0–7

Where:

■ RR, GG, and BB are in the range 00 to FF, inclusive.

The following table shows examples of Autodesk MapGuide® color values:

Related Topics

■ For more information about Map Manager properties, refer to the Autodesk LocationLogic Properties Reference.

■ For more information about Autodesk MapGuide® Author, refer to the Autodesk MapGuide® documentation.

■ For more information about map image formats supported by LocationLogic, see “Map Formats” on page 93.

Selected Autodesk MapGuide® Color Values

Color Autodesk MapGuide® Value(s)

Black 4

Dark gray 246 or 247

Light gray 252 or 253

White 1

Task 4: Configuring Geomap | 105

../llpr/llpr.pdf

../llpr/llpr.pdf

I■

■

■

■

■

■

■

■

■

■

■

■

■

■

B
Content Organization

LocationLogic features

Feature metadata

Feature table associations

LocationLogic feature types

Associating features and feature types

LocationLogic feature categories

Associating feature categories and feature types

Accessing extended LocationLogic content

Adding a new feature category

Accessing additional feature tables

Defining feature category and feature type associations

Optimizing content searches

Streamlining feature filters

This chapter describes how different types of Autodesk®

LocationLogic features, including points of interest, bookmarked

information, and so forth, are organized in the LocationLogic

database.

107

Overview

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.”

Features and feature metadata are the keys that enable your LocationLogic applications to provide the information your users seek.

The following sections explain more about what these terms mean in the context of the LocationLogic database:

■ “LocationLogic Features” on page 108■ “Feature Metadata” on page 109■ “Feature Table Associations” on page 110■ “LocationLogic Feature Types” on page 111■ “Associating Features and Feature Types” on page 113■ “LocationLogic Feature Categories” on page 114■ “Associating Feature Categories and Feature Types” on page 119

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 (see Chapter 2, “Points of Interest (POI) Content.”)

■ Dynamic content, such as mobile users and current traffic conditions (see Chapter 3, “Dynamic Content.”)

■ External content linked through a data bridge (see Chapter 6, “Accessing External Data from LocationLogic.”)

108 | Appendix B Content Organization

LocationLogic features are represented in the LocationLogic database as rows in a feature table. The following table of POI data is a typical feature table:

Typical LocationLogic feature table of Points of Interest (POIs)

Note Although non-POI features, such as dynamic content and external data, have different data fields (columns) in their database tables, they are stored in the database in the same way as POI features, and so your applications will use the same methods of identifying feature characteristics and searching through the feature tables.

Feature Metadata

Feature metadata is data that describes the hierarchical relationships between LocationLogic features (such as how they are nested within feature categories), as well as the location of a feature’s database record (where it exists within the LocationLogic database or an external database). LocationLogic database. There are three types of feature metadata, which together describe a LocationLogic feature:

■ Feature categories (see “LocationLogic Feature Categories” on page 114)■ Feature types (see “LocationLogic Feature Types” on page 111)■ Feature type properties (see “Feature Type Properties” on page 111)

id facilitytype poiname foodtype<remaining

feature tablecolumns>

101 5800 Tokyo House 1102 5800 Sushi Hana 2

NT_SF_POI

<additional table rows for remaining features>

103 5800 Pasta Bella 31101 3578 BofA #27451102 6000 BofA Main

Feature Metadata | 109

Accessing Feature MetadataYou can manage feature metadata by using either of the following techniques:

■ Use direct database access to the LocationLogic Oracle. This method is recommended for experienced Oracle database administrators only, and is not documented in this guide.

■ The Content Management Console, which is a Web-based application. For information about the Content Management Console, see Chapter 9, “Using the Content Management Console”.

Feature Table Associations

The best way to understand feature metadata is to start with how LocationLogic features are physically stored as LocationLogic database records. From that point there is a clear path through how the feature’s database records are accessed by a feature type’s properties, how those feature types relate to feature categories, and finally how the feature categories relate to your application’s organization (content hierarchy) of the LocationLogic features.

Feature data and metadata are stored in the following LocationLogic database tables:

■ Feature tables■ Feature type table■ Feature category table

Related Topics

■ “Associating Features and Feature Types” on page 113■ “Associating the Content Hierarchy and Feature Category Data” on page 116■ “Associating Feature Categories and Feature Types” on page 119


LocationLogic Feature Types

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), are typically stored together in the LocationLogic database. The LocationLogic term for such a group of related features is feature type.

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.

Organizing features into feature types optimizes database queries by LocationLogic for typical user requests such as “Where are all the Chinese restaurants near me?” When LocationLogic applications request features by specifying sorting criteria in their API calls, LocationLogic uses feature types to efficiently search the database. For example, to find Chinese restaurants, only feature tables that contain restaurants will be queried, and only the foodtype column will be evaluated to determine if its value is Chinese.

Feature Type PropertiesFeature type properties are 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 feature are stored; for example, jdbc/Oracle.

■ FTABLE. Identifies the name of the table where the corresponding feature is 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.

LocationLogic Feature Types | 111

The Feature Type TableThe LocationLogic feature type table contains the entire set of feature types.

The following diagram shows a portion of the feature type table entries for the NT_POI feature type:

Typical LocationLogic feature type table

For every feature type, such as NT_POI, the feature type table contains the following rows:

■ A single property type 1 row identifying the data source of the feature table where the corresponding features are stored (for example, jdbc/Oracle)

■ A single property type 2 row identifying the name of the feature table where the corresponding features are stored (for example, NT_SF_POI)

■ A property type 3 row for every feature field (physical column name) that your LocationLogic application can access through the feature type table (for example, FACILITY_TYPE_ID, POINAME, and FOOD_TYPE_ID)

■ A property type 4 row for every extended POI attribute that your LocationLogic application can access.

Related Topic

■ You can use the Content Management Console to add, modify, or delete both feature types and feature type properties. For more information, see Chapter 9, “Using the Content Management Console”.

featuretype property type valueNT_POI FDATASRC 1 jdbc/OracleNT_POI FTABLE 2 NT_SF_POI

FM_FEATURE_TYP

<additional table rows with type 3 data corresponding to NT_SF_POIphysical column names>

NT_POI FOODTYPE 3 foodtypeNT_POI NAME 3 poinameNT_POI FACILITYTYPE 3 facilitytypeNT_POI FID 3 id


Associating Features and Feature Types

The following diagram shows how the feature database records correlate with the feature type property values:

Associating feature table and feature type table data

The LocationLogic feature type table is a look-up table that allows your applications to access LocationLogic content independently of any underlying database changes. For example, your application needs to know only that there is an FTABLE property associated with the NT_POI feature type, instead of knowing the specific database table name, NT_SF_POI. So if the content database table name itself changes, that change will be carried through to the feature type table, and your application can just continue using the FTABLE property.

Similarly, your application can use the logical column names that are in the feature type table’s property fields (for example, NAME) instead of the actual physical column names that are in the value fields (for example, poiname).

Related Topic

■ For more information about using logical column names, see “Associating Feature Categories and Feature Types” on page 119.




NT_SF_POI




FM_FEATURE_TYP



Associating Features and Feature Types | 113

LocationLogic Feature Categories

A feature category is a logical grouping of LocationLogic features (POIs, mobile objects, and so forth), as defined for a particular application.

Every LocationLogic application organizes the LocationLogic features into a custom hierarchy of feature categories. 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)

The following diagram shows a small portion of a typical content hierarchy:

Typical LocationLogic application content hierarchy

Each feature category in the content hierarchy is independent of the underlying database content and schema. That is, it doesn’t matter what database table a LocationLogic feature is in, nor whether the features of related categories include the same data fields.

POIs (root) RESTAURANTS (parent, child)

Content Hierarchy

JAPANESE (child, leaf) ITALIAN (child, leaf) BANKS (parent, child) ATM (child, leaf) BRANCH (child, leaf)


The Feature Category TableThe LocationLogic feature category table contains your entire set of feature categories.

The following diagram shows the feature category table entries for the preceding content hierarchy:

Typical LocationLogic feature category table

There is a row in the feature category table for every feature category.

Related Topic

■ You can use the Content Management Console to add, modify, or delete feature categories. For more information, see Chapter 9, “Using the Content Management Console”.

catname parentcatpath featuretype featurefilter

POIs NULL NULL NULLRESTAURANTS POIs NULL NULL

FM_FEATURE_CAT

<additional feature category table rows>

JAPANESE POIs.RESTAURANTS NT_POI

FACILITYTYPE=5800AND (FOODTYPE=1 ORFOODTYPE=2)

ITALIAN POIs.RESTAURANTS NT_POI FACILITYTYPE=5800

AND (FOODTYPE=3)BANKS POIs NULL NULL

<additionalfeaturecategory datacolumns>

ATM POIs.BANKS NT_POI FACILITYTYPE=3578BRANCH POIs.BANKS NT_POI FACILITYTYPE=6000

LocationLogic Feature Categories | 115

Associating the Content Hierarchy and Feature Category DataThe following diagram shows how your application’s content hierarchy correlates with the feature category catname and parentcatpath values:

Associating content hierarchy and feature category data

As shown, every category in the content hierarchy is put into the catname field of its feature category table record. The content hierarchy’s nested organization is put into the feature category table’s parentcatpath field. For the root level category, the parentcatpath value is set to null.

Restricting Access to Feature CategoriesYou can design your content hierarchy to isolate feature categories from one another, thereby restricting feature access on an application or user basis. For example, feature categories within the Personal hierarchy branch can be accessed only by the associated user, while features within the POIs branch can be accessed by all the users of the associated application.

catname parentcatpath

POIs NULLRESTAURANTS POIs

FM_FEATURE_CAT


JAPANESE POIs.RESTAURANTS

ITALIAN POIs.RESTAURANTS

BANKS POIs


ATM POIs.BANKSBRANCH POIs.BANKS


Content Hierarchy



You can also use feature categories to organize and identify administrative areas and street networks so that these types of features can be used in queries to the Feature Manager.

One of the key differences between feature categories used to categorize POIs and those used to categorize areas and street networks is that mobile applications may often allow users to navigate through the POI feature category hierarchy, but not through the administrative area and street network feature categories.

Structuring Feature CategoriesAlthough you have a great deal of flexibility in designing your content hierarchy, particularly within the POI branch, the standard structure of the DynamicContent, Personal, and System feature categories is preconfigured by the LocationLogic properties as follows:

DynamicContentTraffic

PointSegmentForeignLinkForeignLinkLookup

PersonalBookmarks

LocationsRoutes

HistoryCustomDataBridge

user defined category 1user defined category n

SubscriptionsSubscriptionLink

MobileDevicesSystem

DataBridgeSetup

To rename any of the standard feature categories, you must change the entries in the feature category table, as well the LocationLogic property values.

LocationLogic Feature Categories | 117

The following table summarizes the feature category-related property values:

Note These property values are designated as read-only because they do not need to be changed for most LocationLogic deployments. Therefore, you cannot change them by using the System Console. Instead, you must modify the llservices.xml property file, and reload the properties, as described in “Task 2: Configuring a Content Topic,” on page 35.

Related Topic

■ For details about each LocationLogic system property, refer to the Autodesk LocationLogic Properties Reference.

Default Feature Category and Feature Type Property Values

Property Name Default Value

featuremanager.databridgefeaturetype DATA_BRIDGE

featuremanager.mobileuserfeaturetype USER_DEVICE

featuremanager.personal.customfeaturecategory Custom

featuremanager.personal.datalinkfeaturecategory System.DataBridgeSetup

featuremanager.personal.historyfeaturecategory History

featuremanager.personal.locationbookmarkfeaturecategory

Bookmarks.Locations

featuremanager.personal.mobilefeaturecategory MobileDevices

featuremanager.personal.routebookmarkfeaturecategory

Bookmarks.Routes

featuremanager.personal.subscriptionfeaturecategory

Subscriptions.Subscription

featuremanager.personal.userpropertiesfeaturecategory

System.UserProperties

featuremanager.personalcategoryname Personal

featuremanager.systemcategoryname System


../llpr/llpr.pdf

../llpr/llpr.pdf

Associating Feature Categories and Feature Types

The following diagram shows how the feature category data correlates with the feature type table’s featuretype and property values:

Associating feature category and feature type data

To enable your application to perform queries for features within a feature category, you must assign a non-null featuretype value to that feature category. This provides your application with the information about which database and table the feature category’s feature records are in (as identified by the feature type’s feature type properties).



FM_FEATURE_CAT



FACILITYTYPE=5800AND (FOODTYPE=1OR FOODTYPE=2)






FM_FEATURE_TYP



Associating Feature Categories and Feature Types | 119

Categories that have no child sub-categories must be associated with a single feature type from the feature type table. (Parent categories may have their child categories associated with multiple feature types. In the example shown, all Japanese restaurants must be associated with a single feature type, and all Italian restaurants must be associated with a single feature type. However, the Japanese and Italian restaurant feature types can be the same as or different from each other.)

The final piece of data required for a LocationLogic application to be able to search for all LocationLogic features within a particular feature category is the feature category’s featurefilter value. The featurefilter data is a text string representation of a SQL WHERE clause fragment. The WHERE clause elements are the feature table column names (logical or physical), as specified in the feature type table.

Related Topics

■ For more information about logical and physical column names, see “Associating Features and Feature Types” on page 113.

■ For more information about associating feature categories with single and multiple feature types, see “Defining Feature Category and Feature Type Associations” on page 128.

Accessing Extended LocationLogic Content

Periodically your LocationLogic database may be updated with additional content, such as expanded POI information that contains additional data fields. You can use the Content Management Console to add an entry to the feature type table so that your application can access the new data.

For example, if updated POI information includes a new hours field in each POI record, the LocationLogic database will be updated with the additional column, and you can use the Content Management Console to add a new type 3 feature property so that your applications can access the hours information.

The following diagram shows the added type 3 HOURS NT_POI feature type property.


Adding a new feature type property

Adding a New Feature Category

As your LocationLogic applications mature, you may want to add feature categories to support your users’ changing needs. For example, your users may want to be able to find sushi restaurants specifically, rather than having to look through all Japanese restaurants.

The following table describes the steps to add a new feature category:

Step Description

1 Revise your application’s content hierarchy.

2 Use the Content Management Console to modify the featurefilter value of the existing feature category, Japanese restaurants, in the feature category table.

3 Use the Content Management Console to add the new feature category, Sushi restaurants, in the feature category table.




NT_SF_POI



hours


FM_FEATURE_TYP



NT_POI HOURS 3 hours

Adding a New Feature Category | 121

The following diagrams show the changes to the content hierarchy and the feature category table:

Adding a feature category: Step 1, revise the content hierarchy


Content Hierarchy



Content Hierarchy

JAPANESE (child, leaf)

ITALIAN (child, leaf) BANKS (parent, child) ATM (child, leaf) BRANCH (child, leaf)

SUSHI (child, leaf)


Adding a feature category: Steps 2 and 3, modify the Japanese Restaurants featurefilter value and add the Sushi Restaurants feature category



FM_FEATURE_CAT










FM_FEATURE_CAT


JAPANESE POIs.RESTAURANTS NT_POI FACILITYTYPE=5800

AND FOODTYPE=1





SUSHI POIs.RESTAURANTS NT_POI FACILITYTYPE=5800

AND FOODTYPE=2

Adding a New Feature Category | 123

Accessing Additional Feature Tables

As your LocationLogic application and content change, you may need to access LocationLogic features that are in different database tables or in a separate database from your original content. When this occurs, you can use the Content Management Console to add the required feature type data and modify or add feature category data as needed.

As an example, suppose that a carrier has confidential data (such as enhanced restaurant listings for which it charges clients an extra fee) that should be accessible only to specific applications. If this data were included in the standard POI feature table (for example, NT_SF_POI), it would be accessible to all LocationLogic applications. However, if the data is instead placed in a separate table (for example, NT_SF_REST), access to it can be restricted to specific applications.

The following table describes the steps to enable your LocationLogic application to access the features in the new feature table:

Step Description

1 Create the new NT_SF_REST database table, and transfer/load the appropriate feature records.

2 Use the Content Management Console to add the new feature type property records to the feature type table.

3 Use the Content Management Console to modify the featuretype values of the affected categories in the feature category table.


The following diagram shows the result of creating the new NT_SF_REST feature table:

Accessing additional feature tables: Step 1, creating the new feature table




NT_SF_POI






NT_SF_REST

<additional table rows for remaining features>103 5800 Pasta Bella 3



NT_SF_POI


1101 3578 BofA #27451102 6000 BofA Main

Accessing Additional Feature Tables | 125

The following diagram shows the feature type table before and after adding a feature type so that your applications can access the new feature table, NT_SF_REST:

Accessing additional feature tables: Step 2, adding new feature type property records


FM_FEATURE_TYP




FM_FEATURE_TYP

<additional table rows with type 3 data corresponding to NT_SF_POI andNT_SF_REST physical column names>


NT_REST FDATASRC 1 jdbc/OracleNT_REST FTABLE 2 NT_SF_REST

NT_REST FID 3 id

NT_REST FOODTYPE 3 foodtypeNT_REST NAME 3 poinameNT_REST FACILITYTYPE 3 facilitytype


And finally, the following diagram shows the feature category table modifications for the new feature type:

Accessing additional feature tables: Step 3, modifying a feature category’s featuretype value



FM_FEATURE_CAT










FM_FEATURE_CAT


JAPANESE POIs.RESTAURANTS NT_REST


ITALIAN POIs.RESTAURANTS NT_REST FACILITYTYPE=5800




Accessing Additional Feature Tables | 127

Defining Feature Category and Feature Type Associations

You can follow either of two approaches when associating your LocationLogic application’s parent feature categories and their corresponding feature types. To decide which approach to use, you must determine what sort of searches you want your application to support:

■ Design your hierarchy so that all data within a single feature category is associated with a single underlying feature type.

■ Design your hierarchy so that data within a single feature category can be associated with multiple feature types.

Related Topic

■ “Associating Feature Categories and Feature Types” on page 119

Single Feature TypeIf you define your feature category hierarchy so that every feature within a feature category is associated with the same feature type, your application will have the following benefits:

■ Every feature category can be directly queried to return a list of features within that category.

■ Depending on how the data and filters have been constructed, the query may also return a list of features within the feature category’s sub-categories (child categories).

■ The feature search performance will be quicker.

To associate a feature category with a single feature type

1 Put every feature into a single feature table.2 Ensure that every feature of the specified feature category and each of the sub-

categories is associated with the same feature type. That is, the feature category and each of the sub-categories must have the same value in the feature category table’s featuretype column.

3 Ensure that the appropriate search criteria (SQL WHERE clauses) are used.


Multiple Feature TypesIf you define your feature category hierarchy so that features in a feature category map to multiple feature types, your application will benefit from the following:

■ Child feature categories can be in different feature tables.■ Child feature categories can be directly queried for their list of member features.

You cannot, however, directly query feature categories that contain data for multiple feature types. Instead, you must query the child feature categories individually.

To associate a feature category with multiple feature types

1 Distribute feature data in as many feature tables as you like.2 Associate every feature with any feature category.

Optimizing Content Searches

DefinitionContent searches are queries of the LocationLogic database feature tables using the search criteria you specify.

Content Searches and Content StrategyTo define an effective content strategy, it helps to understand how LocationLogic performs content searches. Simply put, you program your application to access the Feature Manager (through the LocationLogic Java API), which in turn conducts the actual search. Refer to the Autodesk LocationLogic Developer’s Guide for implementation details.

Optimizing Content Searches | 129

../lldg/lldg.pdf

../lldg/lldg.pdf

Searching Only Leaf NodesIf your application does not need to search feature categories recursively or to search categories that are aggregates of multiple sub-category types, you can define your hierarchy very simply.

To set up a feature category table for searching only leaf nodes

■ Set the feature types of all the non-leaf nodes to null.

Example

This example illustrates how to define a feature category table so only its leaf nodes can be searched. The first step is to determine the feature category hierarchy, for example:

The next step is to define the feature category data. This example assumes your data is from NAVTEQ; your application may use data from another provider, such as Tele Atlas.

Sample Hierarchy

POIsRestaurant

AmericanChineseFrenchVegetarian

BankingATMBranch

Defining a Feature Category Table to Search Only Leaf Nodes (1 of 2)

catname parentcatpath featuretype featurefilter en

POIs NULL NULL NULL Points

RESTAURANT POIs NULL NULL Restaurants

AMERICAN POIs.RESTAURANT NAVTEQ_POI FACILITY_TYPE_ID=’05800’ AND FOOD_TYPE_ID=1

American

CHINESE POIs.RESTAURANT NAVTEQ_POI FACILITY_TYPE_ID=’05800’ AND FOOD_TYPE_ID=3

Chinese


In this example, you can search for American, Chinese, French, and Vegetarian Restaurants, as well as ATMs and Bank Branches. That is, you can search all the leaf node categories.

However, this hierarchy definition means that you cannot search more generally through the non-leaf nodes, POIs, Restaurant, or Banking establishments, since they all have null entries in their featuretype columns.

FRENCH POIs.RESTAURANT NAVTEQ_POI FACILITY_TYPE_ID=’05800’ AND FOOD_TYPE_ID=5

French

VEGETARIAN POIs.RESTAURANT NAVTEQ_POI FACILITY_TYPE_ID=’05800’ AND FOOD_TYPE_ID=15

Vegetarian

BANKING POIs NULL NULL Banking

ATM POIs.BANKING NAVTEQ_POI FACILITY_TYPE_ID=’03578’

ATM

BRANCH POIs.BANKING NAVTEQ_POI FACILITY_TYPE_ID=’06000’

Branch

Defining a Feature Category Table to Search Only Leaf Nodes (2 of 2)



Searching All Hierarchy LevelsTo enable your application to search the feature category hierarchy for all node types (non-leaf nodes as well as leaf nodes), you must set up the feature category table so that all data is non-null.

To set up a feature category table for complete searches

1 Associate all non-leaf node feature categories with a feature type by assigning a non-null value to the feature category table’s featuretype column.

2 Identify an appropriate feature filter for all non-leaf node feature categories (other than the root node).

3 Apply SQL logic to simplify the feature filter’s SQL WHERE clauses.4 Identify the feature filter for the root node.

Example of Complete Searching

The following example illustrates how to define a feature category table for the sample hierarchy so that all node types can be searched:

If you assume that all the feature data to be categorized in the POIs tree resides in a single table, the step-by-step process is as follows:

1 Associate every feature category in the tree with the NAVTEQ_POI feature type.2 To identify appropriate feature filters, work from the bottom of the tree (the leaf

nodes) upwards.

Sample Hierarchy

POIsRestaurant

AmericanChineseFrenchVegetarian

BankingATMBranch


The features that should make up the domain of queries against the POIs.RESTAURANT feature category are exactly those features that appear in any of the domains, POIs.RESTAURANT.AMERICAN, POIs.RESTAURANT.CHINESE, POIs.RESTAURANT.FRENCH, or POIs.RESTAURANT.VEGETARIAN.To construct the feature filter, you could simply use the OR operator to join the component feature filters. For example, to build the query for the POIs.RESTAURANT feature category, you can combine the queries for American, Chinese, and Vegetarian restaurants:( (FACILITY_TYPE_ID=’05800’ AND FOOD_TYPE_ID=1)OR (FACILITY_TYPE_ID=’05800’ AND FOOD_TYPE_ID=3)OR (FACILITY_TYPE_ID=’05800’ AND FOOD_TYPE_ID=5) )

Once you join together the queries for even a few feature categories, the result is a long, repetitive search string for the SQL WHERE clause to execute.

3 Use SQL logic to combine all the RESTAURANT feature filters into an efficient, equivalent form:FACILITY_TYPE_ID=’05800’ AND FOOD_TYPE_ID IN (1, 3, 5, 15)

Repeating Steps 2 and 3 for the POIs.BANKING feature category, you could simply use the OR operator to join the feature filters for ATM and BRANCH, or you could simplify it as follows:

FACILITY_TYPE_ID IN (’03578’, ‘06000’)

4 To determine the feature filter for the root node (in this case the POIs feature category), use the OR operator to join the feature filters of the relevant sub-categories (POIs.RESTAURANTS and POIs.BANKING):(FACILITY_TYPE_ID=’05800’ AND FOOD_TYPE_ID IN (1, 3, 5, 15)) OR(FACILITY_TYPE_ID IN (’03578’, ‘06000’))


Revising the feature type table as shown, you could now query for features from any node in the feature category hierarchy, as well as implement recursive queries:

Defining a Feature Category Table to Search All Nodes


POIs NULL NAVTEQ_POI (FACILITY_TYPE_ID= ’05800’ AND FOOD_TYPE_ID IN (1, 3, 5, 15)) OR (FACILITY_TYPE_ID IN (‘03578’, ‘06000’))

Points

RESTAURANT POIs NAVTEQ_POI FACILITY_TYPE_ID=’05800’ AND FOOD_TYPE_ID IN (1, 3, 5, 15)

Restaurants


American


Chinese


French


Vegetarian

BANKING POIs NAVTEQ_POI FACILITY_TYPE_ID IN(‘03578’, ‘06000’)

Banking


ATM


Branch


Streamlining Feature Filters

While the strategy used in “Example of Complete Searching” on page 132 will always allow you to successfully search for a feature through the entire feature category hierarchy, using the OR operator to join a sizeable number of sub-categories’ feature filters can result in overly complex SQL query commands. However, if you know something about what your data represents, you can frequently streamline the SQL code needed to positively query for a feature contained within a feature category.

To streamline a feature category table’s feature filters

1 Beginning with the leaf nodes, move up the content hierarchy until you arrive at a parent node.

2 Evaluate the parent node’s feature filter to determine if it contains unnecessary limiting conditions. If so, then streamline the feature filter’s SQL WHERE clause as appropriate.

3 Once every parent node at the same hierarchical level has been evaluated and simplified (if possible), continue recursively evaluating and streamlining each hierarchy level’s parent nodes in turn, until you reach the root node.

4 Streamline the feature filter for the root node, if possible.

Example

To streamline the feature filters shown in “Defining a Feature Category Table to Search All Nodes” on page 134, the step-by-step process is as follows:

1 Work up from the leaf nodes to arrive at the POIs.RESTAURANT parent node.2 If you know that every restaurant included in the NAVTEQ_POI table is American,

Chinese, French, or Vegetarian, you can streamline the POIs.RESTAURANT feature filter to FACILITY_TYPE_ID=’05800’.

3 Continue on to evaluate the other parent node at the same hierarchical level as POIs.RESTAURANT, which is POIs.BANKING.Analysis shows that no streamlining is possible for POIs.BANKING.

4 If you know that every feature in the NAVTEQ_POI table belongs to either POIs.RESTAURANT or POIs.BANKING, you can set the feature filter for POIs to null.

Streamlining Feature Filters | 135

If you follow this procedure, your category type table will look like this:

Defining a Feature Category Table with Streamlined Feature Filters


POIs NULL NAVTEQ_POI NULL Points

RESTAURANT POIs NAVTEQ_POI FACILITY_TYPE_ID=’05800’

Restaurants


American


Chinese


French


Vegetarian

BANKING POIs NAVTEQ_POI FACILITY_TYPE_ID IN (‘03578’, ‘06000’)

Banking


ATM


Branch


I■

■

■

■

■

■

■

C
Using the Content Management Console

The Content Management Console interface

Rules and guidelines

Starting the Content Management Console

Managing feature categories, feature types, and feature type properties

Changing databases

Logging out of the Content Management Console

Autodesk® LocationLogic maintains metadata about feature

categories and feature types in the LocationLogic database. The

Content Management Console is a web-based application that

simplifies management of this metadata. This chapter explains how

to use the Content Management Console.

137

Overview

The Content Management Console provides an interface between you and the LocationLogic database, which simplifies the task of managing feature metadata without having to modify the data directly in the LocationLogic database.

The Content Management Console is designed to run on Microsoft® Internet Explorer® 6.

The Content Management Console makes it easy to accomplish the following tasks:

■ Access new LocationLogic content■ Add a new feature category to benefit your users■ Access LocationLogic features in a separate database

Each of these tasks is described in the following sections.

Related Topic

■ For more information about setting up the Content Management Console, refer to the Autodesk LocationLogic Installation Guide.

138 | Appendix C Using the Content Management Console

../llig/llig.pdf

The Content Management Console Interface

The Content Management Console interface components consists of a navigation bar, navigation pane, display pane, and language columns.

Navigation Bar

The navigation bar displays the following commands:

■ Change Database—Use this command to change databases without logging out. For more information, see “Changing Databases” on page 168.

■ Logout—Use this command to logout manually. For more information, see “Logging Out of the Content Management Console” on page 169.

Navigation Pane

The navigation pane contains an Explorer-like, hierarchical display of feature categories and feature types. Use the following actions to navigate the hierarchy:

■ To expand the hierarchy and show child items, click the plus sign (+) icons.■ To collapse the hierarchy and hide child items, click the minus sign (-) icons.■ To select an item, click its name.

Navigation bar

Language column

Display pane

Navigation pane

The Content Management Console Interface | 139

Display Pane

The display pane shows details about the current operation. In the previous example, the display pane shows details about the item selected in the navigation pane. When you first open the Content Management Console, or are changing databases, this pane contains entry fields for login information.

Language Columns

The LocationLogic database can include languages other than English, which are viewable in the Content Management Console. For more information about configuring the Content Management Console interface to display multiple languages, refer to the Autodesk LocationLogic Installation Guide.


../llig/llig.pdf

Rules and Guidelines

Use the Content Management Console in accordance with the following:

■ You can use the Content Management Console while the LocationLogic platform is running only if you are making changes to feature metadata that is not being used by the platform. To make changes to feature metadata being used by the platform, the platform managed servers must be shut down, and the administration server must be running.

■ If the platform managed servers are not shut down while you are making changes to feature metadata used by the platform, you risk editing the wrong data or damaging data. For example,❏ Location-based applications supported by the platform can access old information

that you may be updating at the same time.❏ The Content Management Console allows you to modify core platform metadata;

but without sufficient knowledge of how to properly modify the core platform metadata, you may cause the platform to fail. If it fails, the platform and all data may be damaged.

■ If you intend to use the Content Management Console while the platform is running, you should back up all the feature metadata before you modify it. It is good practice to test the changes you want to make in a staging environment before applying them to the production deployment.

■ Only one person at a time should use the Content Management Console to change feature metadata.

■ The Content Management Console cannot be used to change the LocationLogic schema. You can add metadata only within the context of the existing table definitions.

■ You can use the Content Management Console to manage feature metadata in any accessible LocationLogic content database, in addition to the database associated with a local deployment.

■ When using the Content Management Console, be sure to navigate by clicking hyperlinks and buttons. Navigating with your browser’s Next and Back buttons can result in errors.

Warning The Content Management Console enforces data integrity rules. Modifying the feature category or feature type tables directly in the LocationLogic database can cause data integrity problems, such as unintentionally adding, modifying, or deleting information from the wrong column in a table.

Rules and Guidelines | 141

Starting the Content Management Console

The LocationLogic Oracle database enforces security for feature metadata. To log in, you need a valid account name and password for the LocationLogic database that contains your content. If necessary, contact your database administrator to obtain an Oracle user account.

Database Login ElementsThe Content Management Console uses login elements to refer to the parameters required to access the Content Management Console. To access the Content Management Console, you will be prompted to complete the following login elements:

Notes

■ Login elements are not case-sensitive.

Database Login Elements

Element Description

Pre-configured database Names of host computers for the Oracle database that have been accessed at least once. Selecting from the Pre-configured database list will fill in the login elements required for the host computer specified, except for the password.

Database hostname Name of the host computer for the Oracle database. For example: essex.

Database SID Oracle database System ID. For example: ll.

Username User name for the Oracle database. For example: ll_owner.

Password Password for the Oracle database.

Port Number Port number for the Oracle database. For example: 1521.

Feature Category table Name of the Feature Category table to access. For example: FM_FEATURE_CAT.

Feature Type table Name of the Feature Type table to access. For example: FM_FEATURE_TYP.


■ The Content Management Console generates a cookie that remembers the login parameters for a database after it is accessed the first time. If you choose to log in to a pre-configured database, the parameters will fill in automatically, except for the password parameter. If you do not log in to a specific pre-configured database after 14 days, the cookie will expire, and you must reenter its parameters. In order for the Content Management Console to memorize login parameters, cookies must be enabled.

To start the Content Management Console

1 Access the console using either of the following methods:■ To access the Console from the WebLogic Server Administration Console, click

LL Content Management Console—the last link in the left pane.The Content Management Console is displayed in the right part of the WebLogic Server Administration Console window, and is set to the Content Management Database Login screen.

■ To start the Console in the stand-alone mode, open Microsoft® Internet Explorer®, and go to the following URL:http://<hostname>:7001/contentconsole/

Where■ <hostname> is the name of the machine on which the Content Management

Console is running.

The Content Management Console displays the Content Management Database Login screen.

Starting the Content Management Console | 143

2 Do either of the following:■ Enter the correct login parameters. For more information, see “Database Login

Elements,” on page 142.■ Select a database from the Pre-configured database list and enter the password.

3 Click Login To Database.The Content Management Console connects to the Oracle database, validates the login information and, if the login is successful, displays the Content Management Database Parameters screen.


Login Error MessagesAfter you click Login To Database, an error message will appear if there are blank or incorrect parameters. The error message will prompt you to either fill in or correct these parameters. While most error messages are easily understood, the following table describes ambiguous error messages:

Ambiguous Login Error Messages

Error Message Description

Message: Io exception: Invalid number format for portnumber Vendor specific error code: 17002SQL State: null

Invalid port number.

Message: Io exception: The Network Adapter couldnot establish the connectionVendor specific error code: 17002SQL State: null

Invalid database hostname or invalid port number.Also, database or port may not be responding.

Message: 0RA-01017: invalid username/password;logon deniedVendor specific error code: 1017SQL state: 72000

Invalid username and/or password.

Message: Io exception: Connection refused(DESCRIPTION=(TMP=)(VSNNUM=135295488)(ERR=12505)(ERROR_STACK=(ERROR=(CODE=12505)(EMFI=4))))Vendor specific error code: 17002SQL state: null

Invalid Oracle database System ID.

Starting the Content Management Console | 145

Managing Feature Categories

OverviewThis section describes how to use the Content Management Console to manage feature categories in the LocationLogic database. For more information about managing feature categories, see the following sections:

■ “Feature Category Elements” on page 146■ “Viewing Feature Categories” on page 148■ “Creating Feature Categories” on page 149■ “Modifying Feature Categories” on page 152■ “Duplicating Feature Categories” on page 153■ “Moving Feature Categories” on page 154■ “Deleting Feature Categories” on page 154

Warning Before changing any feature categories, see “Rules and Guidelines,” on page 141.

Related Topics

■ For more information about feature categories, see “LocationLogic Feature Categories” on page 114.

■ For more information about tasks that require you to manage feature categories, see “Adding a New Feature Category,” on page 121, and “Accessing Additional Feature Tables,” on page 124.

Feature Category ElementsA feature category table contains feature category hierarchy information that is application-specific, rather than general information that is available from a content vendor. The Content Management Console uses feature category elements to represent columns in a feature category table. Include the required feature category table columns


and indexes to ensure that the feature category table conforms to the content schema. Each feature category consists of the following elements:

Feature Category Elements

Element Description

Category Name Name of the feature category. Use alphanumeric characters and do not leave blank.

Parent Category Path Location of the parent category in the hierarchy. (This element is read-only.)

Feature Type Feature type name used to link to the feature type table. Select a feature type or <None> from the list. Selecting <None> will fill the featuretype column with a NULL value in the feature category table.

Feature Filter Works with the feature type data to identify features of a feature category. The feature filter consists of a SQL WHERE clause for the feature type table. Use valid SQL syntax for the WHERE clause. Leaving the Feature Filter blank will fill the featurefilter column with a NULL value in the feature category table.

Priority Number that specifies the retrieval order for this category. A smaller number specifies a higher retrieval priority. If not specified, the default is the lowest priority. Use a signed integer, zero (0), or leave blank. Leaving the Priority blank will fill the priority column with a NULL value in the feature category table.

Language columns, represented by the ISO Standard 639 two-letter language code

Columns used for every language your application supports, and named using the ISO Standard 639 two-letter language code. For more information about configuring the Content Management Console to display multiple languages, refer to the Autodesk LocationLogic Installation Guide.

Managing Feature Categories | 147

../llig/llig.pdf

../llig/llig.pdf

Viewing Feature CategoriesUse the Content Management Console to view information for a specific feature category.

To view feature categories

■ In the navigation pane of the Content Management Console, expand the Feature Category hierarchy and select the category that you want to view.

The Content Management Console displays the Feature Category screen.


Creating Feature CategoriesThe Content Management Console provides a simple way to create and add new feature category information to the feature category hierarchy accessed by your application. For more information about structuring your feature category hierarchy, see Appendix B, “Content Organization”.

To create feature categories

1 Do one of the following:■ Create a parent feature category

In the navigation pane of the Content Management Console, select Feature Categories.The Content Management Console displays the Feature Category Root screen.

■ Create and add a new child feature category to an existing parent feature category.In the navigation pane of the Content Management Console, select the parent category to which you want to add a feature category.The Content Management Console displays the Feature Category screen.

2 Click Create.


Note You click Create whether you are creating a new parent feature category (from the Feature Category Root screen) or creating and adding a new child feature category (from the Feature Category screen).The Content Management Console displays the Create Feature Category screen.

3 Enter the feature category elements. For more information, see “Feature Category Elements” on page 146.Tip Click View Features to preview the schema for the specific feature type you have selected.


4 Click Create Feature Category.The Content Management Console creates the new feature category. After creating a new feature category, the navigation pane resets to its collapsed state.

5 Verify that the new feature category was created correctly by selecting it in the navigation pane.


Modifying Feature CategoriesYou use the Content Management Console to edit or modify information for existing feature categories.

To modify a feature category

1 In the navigation pane of the Content Management Console, select the feature category that you want to modify.The Content Management Console displays the Feature Category screen.

2 Click Modify.The Content Management Console displays the Modify Feature Category screen.

3 Edit the feature category attributes. For more information, see “Feature Category Elements” on page 146.

4 Click Modify Feature Category.The Content Management Console saves your changes. After modifying feature category, the navigation pane resets to its collapsed state.

5 Verify that the modified feature category was changed by selecting it in the navigation pane.


Duplicating Feature CategoriesYou duplicate a feature category by copying the source feature category, and pasting the copy to its target location. For example, instead of adding a new feature category that is very similar to one already existing, you could duplicate the feature category and modify it.

When a copy and paste operation duplicates an existing feature category name, LocationLogic automatically appends a number to the category name. This number starts at one (1) and increments by one each time you duplicate the name. For example, the first copy of featureCat123 is named featureCat1231, the second copy is named featureCat1232, and so on.

To duplicate a feature category

1 In the navigation pane of the Content Management Console, select the category that you want to duplicate.The Content Management Console displays the Feature Category Properties screen.

2 Click Copy.LocationLogic copies the category and any child items to a memory buffer.

3 In the navigation pane, select the parent category for the target location of the feature category you want to duplicate.

4 Click Paste.The Content Management Console creates a new category and associated child items, if any, under the selected parent.Note The Paste link appears only when the memory buffer contains a category. After pasting, the Content Management Console clears the memory buffer.To paste additional copies in the same folder, repeat Steps 2 through 4. You cannot simply click Paste more than once.


Moving Feature CategoriesYou move a feature category by cutting the source feature category and pasting it to its target location. If you cut a feature category but do not paste it anywhere before you log out of the Content Management Console, the transaction fails, no data changes, and the source feature category will remain in the same location.

To move a feature category

1 In the navigation pane of the Content Management Console, select the category that you want to move.The Content Management Console displays the Feature Category screen.

2 Click Cut.LocationLogic copies the category and its child items to the memory buffer.

3 In the navigation pane, select the parent category as the target location to which you want to move the feature category.

4 Click Paste.The Content Management Console moves the feature category and associated child items, if any, under the selected parent.Note The Paste link appears only when the memory buffer contains a category. After pasting, the Content Management Console clears the memory buffer.

Deleting Feature CategoriesWhen you delete a feature category, all child items associated with the feature category are also deleted.

To delete a feature category

1 In the navigation pane of the Content Management Console, select the feature category that you want to delete.The Content Management Console displays the Feature Category screen.

2 Click Delete.The Content Management Console prompts you to confirm the deletion.

3 Click OK to delete the feature category.


Managing Feature Types

OverviewThis section describes how to use the Content Management Console to create and add, edit, and delete feature types associated with a feature category.

You use the Content Management Console to manage the feature types in the LocationLogic database. The feature type table defines the link between feature types and the actual feature data.

You define links to specific feature types within a data source table by adding feature properties to the feature type. For more information, see “Managing Feature Type Properties” on page 161.

For information about managing feature types, refer to the following sections:

■ “Feature Type Elements” on page 156■ “Viewing Feature Types” on page 157■ “Creating Feature Types” on page 158■ “Modifying Feature Types” on page 160■ “Deleting Feature Types” on page 160

Warning Before changing feature types, see “Rules and Guidelines,” on page 141.

Related Topics

■ For more information about feature types, see “LocationLogic Feature Types” on page 111.

■ For more information about tasks that require you to manage feature types, see “Accessing Extended LocationLogic Content,” on page 120, and “Accessing Additional Feature Tables,” on page 124.

Managing Feature Types | 155

Feature Type ElementsA feature type table contains database table mapping information that is application-specific, rather than general information that is available from a content vendor. The mapping information relates logical feature type properties to the data source, table, and column names. For more information about feature type properties, see “LocationLogic Feature Types” on page 111.

The Content Management Console uses feature type elements to represent columns in a feature type table. Include the required feature type table columns and indexes to ensure that the feature type table conforms to the content schema. Each feature type consists of the following elements:

Feature Type Elements

Element Description

Feature Type Name Name of the feature type. Use alphanumeric characters, do not use the same name as another feature type, and do not leave blank.

Feature Type Data Source Name

Feature type property used to access the data source that contains the feature data. Ensure that you can establish a connection to the data source. Enter the logical JNDI name of the data source. Use alphanumeric and valid JNDI characters and do not leave blank. For example: jdbc/Oracle.

Feature Type Table Name

Feature type property used to access the table containing the feature data. Ensure that the feature type table exists. Enter a name with alphanumeric characters and do not leave blank.


Viewing Feature TypesYou use the Content Management Console to view elements of a specific feature type.

To view feature types

■ In the navigation pane of the Content Management Console, expand the Feature Type hierarchy and select the feature type that you want to view.

The Content Management Console displays the Feature Type screen.


Creating Feature TypesThe Content Management Console provides a simple way to add new feature type information used to map POI (Point of Interest) information to your application’s LocationLogic database.

To create feature types

1 Display one of the following screens:■ Feature Type Root screen

Select the Feature Types folder in the navigation pane of the Content Management Console to display the Feature Type Root screen.

■ Feature Type screenIn the navigation pane of the Content Management Console, expand the Feature Type hierarchy and select any feature type to display the Feature Type screen.


2 Click Create.Note You will click Create whether you are displaying the Feature Type Root screen or the Feature Type screen.The Content Management Console displays the Create Feature Type screen.

3 Enter the feature type elements. For more information, see “Feature Type Elements” on page 156.

4 Click Create Feature Type.The Content Management Console creates the new feature type. After creating a new feature type, the navigation pane resets to its collapsed state.

5 Verify the new feature type by selecting it in the navigation pane.6 Optionally, add feature type properties for linking to column names. For more

information, see “Creating Feature Type Properties” on page 164.


Modifying Feature TypesUse the Content Management Console to edit or modify properties of an existing feature type.

To modify a feature type

1 In the navigation pane of the Content Management Console, select the feature type that you want to modify.The Content Management Console displays the Feature Type screen.

2 Click Modify to the right of the feature type element you want to edit.3 Edit the Property Value.4 Click Modify Feature Type Property to save changes.

The Content Management Console saves your changes. After modifying feature type, the Feature Type screen is displayed.

5 To verify that the feature type was added, select it in the Feature Type screen.

Deleting Feature TypesWhen you delete a feature type, all feature type properties associated with the feature type are deleted at the same time, in a single transaction.

To delete a feature type

1 In the navigation pane of the Content Management Console, select the feature type that you want to delete.The Content Management Console displays the Feature Type Properties screen.

2 Click Delete.3 One of the following will occur:

■ If there are no feature categories that contain the feature type to be deleted, then the Content Management Console prompts you to confirm the deletion. Click OK to delete the feature type.


■ If any feature categories contain the feature type to be deleted, then the Content Management Console displays all of the associated feature categories. You must eliminate all references to the feature categories listed before the feature type can be deleted. For more information, see “Modifying Feature Categories,” on page 152 and “Deleting Feature Categories,” on page 154.

Managing Feature Type Properties

This section describes how to use the Content Management Console to manage feature type properties that provide the mapping information to link a feature type to the corresponding database column of a feature type table. For information about managing feature type properties, refer to the following sections:

■ “Feature Type Property Elements” on page 162■ “Viewing Feature Type Properties” on page 163■ “Creating Feature Type Properties” on page 164■ “Modifying Feature Type Properties” on page 166■ “Deleting Feature Type Properties” on page 167

Warning Before changing any feature type properties, see “Rules and Guidelines,” on page 141.

Managing Feature Type Properties | 161

Related Topics

■ For more information about how features and feature type properties are related, see “Associating Features and Feature Types” on page 113.

■ For more information about tasks that require you to manage feature types, see “Accessing Extended LocationLogic Content,” on page 120, and “Accessing Additional Feature Tables,” on page 124.

Feature Type Property ElementsA feature type property can be used to link a logical name to a physical column name. The Content Management Console uses feature type properties to represent columns in a feature type table. Feature type properties must have the following elements:

Feature Type Property Elements

Element Description

Property name Logical name of the property. Must be distinct from the property value when case is ignored. Use alphanumeric characters and do not leave blank.

Property value Physical name of the table column that contains the property. A drop-down list is provided for required columns. In addition to the table column name, you can use standard or customized database single row character functions.


Viewing Feature Type PropertiesYou use the Content Management Console to view feature type property information.

To view feature type properties

■ In the navigation pane of the Content Management Console, expand the Feature Type hierarchy and select the feature type associated with the feature type properties you want to view.

The Content Management Console displays the Feature Type screen.


Creating Feature Type PropertiesThe Content Management Console provides a simple way to add new properties to a feature type.

To create a feature type property

1 In the navigation pane of the Content Management Console, select the feature type associated with the feature type property that you want to add.The Content Management Console displays the Feature Type screen.

2 Click Add.The Content Management Console displays the Add Feature Type Property screen.


3 Enter the feature type properties. For more information, see “Feature Type Property Elements” on page 162.For Property Value, do one of the following:■ Enter the property value.■ Choose a property value from the list. The list contains property values pertaining

to a particular feature type.

4 Click Add Feature Type Property.

The Content Management Console creates the new feature type property. After adding the feature type property, the Feature Type screen is displayed.

5 Verify that the feature type property was added by selecting it in the Feature Type screen.


Modifying Feature Type PropertiesYou can use the Content Management Console to modify existing feature type property information.

To modify a feature type property

1 In the navigation pane of the Content Management Console, expand the Feature Type hierarchy and select the feature type associated with the feature type properties that you want to modify.The Content Management Console displays the Feature Type Properties screen.

2 Click Modify next to the feature type property that you want to modify.The Content Management Console displays the Modify Feature Type Property screen.

3 Edit the property value.4 Click Modify Feature Type Property.

The Content Management Console saves your changes. After modifying the feature type property, the Feature Type screen is displayed.

5 Verify that the feature type property was modified by selecting it in the Feature Type screen.


Deleting Feature Type PropertiesYou use the Content Management Console to delete existing feature type property information that is no longer needed.

To delete a feature type property

1 In the navigation pane of the Content Management Console, expand the Feature Type hierarchy and select the feature type associated with the feature type property that you want to delete.The Content Management Console displays the Feature Type Properties screen.

2 Click Delete next to the feature type property that you want to delete.The Content Management Console prompts you to confirm the deletion.

3 Click OK to delete the feature type property.


Changing Databases

Using the Content Management Console, you can change to a different database without explicitly logging out and logging in again.

To change databases

1 On the navigation bar in the Content Management Console, click Change Database.The Content Management Console displays the Content Management Database Login screen.

2 Enter your login information. For more information see “Database Login Elements” on page 142.

3 Click Login To Database.The Content Management Console logs out of the current database, connects to the new Oracle database, validates the login information, and if the login is successful, displays the Feature Definition Database Properties screen.


Logging Out of the Content Management Console

The Content Management Console automatically logs you out after a certain period of inactivity. The default inactivity time is 30 minutes. You can change the default inactivity time period by modifying the web descriptor. For more information about changing default inactivity time, refer to the Autodesk LocationLogic Installation Guide. You can also log out manually.

To manually log out of the Content Management Console

■ On the Content Management Console navigation bar, click Logout.

The Content Management Console logs you out.

Logging Out of the Content Management Console | 169

../llig/llig.pdf

location logic working_with_content

Business

database content

autodesk locationlogic

dynamic content metadata

dynamic content tables34

content topic

types of content

autodesk mapguide

autodesk trademarksthe