Location logic working_with_content

532 views

Published on

Published in: Business, Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
532
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Location logic working_with_content

  1. 1. Developer’s Guide:Working with Content
  2. 2. Copyright © 2001-2004 Autodesk, Inc. All Rights ReservedThis 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 Mortens 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 123456789
  3. 3. ContentsAbout This Guide . . . . . . . . . . . . . . . . . . . . . . . ix Audience and Purpose . . . . . . . . . . . . . . . . . . . x Assumptions and Necessary Skills . . . . . . . . . . . . . . . . x How This Guide Is Organized . . . . . . . . . . . . . . . . . x Conventions Used in This Guide . . . . . . . . . . . . . . . . xi Text Conventions . . . . . . . . . . . . . . . . . . . xi Code and Syntax Conventions . . . . . . . . . . . . . . xiiChapter 1 Introduction . . . . . . . . . . . . . . . . . . . 1 About the LocationLogic Database . . . . . . . . . . . . . . . 2 Types of Content . . . . . . . . . . . . . . . . . . . . . 3 LocationLogic Features and Metadata. . . . . . . . . . . . . . . 4 LocationLogic Features . . . . . . . . . . . . . . . . . 5 Feature Metadata . . . . . . . . . . . . . . . . . . . 5 Optimizing the LocationLogic Database Performance. . . . . . . . . . 7 Optimizing Database Content . . . . . . . . . . . . . . . 7 Saving to the Database . . . . . . . . . . . . . . . . . 7 Creating Efficient SQL Queries . . . . . . . . . . . . . . 8 System Requirements . . . . . . . . . . . . . . . . . . . 10Chapter 2 Points of Interest (POI) Content . . . . . . . . . . . . .11 Overview. . . . . . . . . . . . . . . . . . . . . . . 12 POI Schema . . . . . . . . . . . . . . . . . . . . . . 13 <SS_GA>_POI Parent Table Data Set . . . . . . . . . . . 16 <SS_GA>_POI_NAME Child Table Data Set . . . . . . . . . 18 <SS_GA>_POI_ATTRIBUTE Child Table Data Set . . . . . . . 19 <SS_GA>_DATA_PROVIDER Table Data Set . . . . . . . . 20 Adding Content to the POI Schema . . . . . . . . . . . . . . 20 Accessing POI Content . . . . . . . . . . . . . . . . . . 21 POI Names . . . . . . . . . . . . . . . . . . . . . . 21 Extended Attributes . . . . . . . . . . . . . . . . . . . 22 Adding Extended Attributes to POIs . . . . . . . . . . . . . . 23 Task 1: Inserting Extended Attributes into the Database . . . . . . 23 Task 2: Mapping Extended Attributes to Feature Types . . . . . . 24 Selecting POIs Based on Provider . . . . . . . . . . . . . . . 28 Migration Notes . . . . . . . . . . . . . . . . . . . . 28 iii
  4. 4. Chapter 3 Dynamic Content . . . . . . . . . . . . . . . . . .29 Overview . . . . . . . . . . . . . . . . . . . . . . . 30 Accessing Dynamic Content . . . . . . . . . . . . . . . . . 31 Using Subscriptions to Access Dynamic Content . . . . . . . . 31 Using the Feature APIs to Access Dynamic Content . . . . . . . 32 Setting Up LocationLogic for Dynamic Content . . . . . . . . . . 32 Process Overview . . . . . . . . . . . . . . . . . . 33 Task 1: Modifying or Creating Dynamic Content Tables . . . . . . 34 Task 2: Configuring a Content Topic . . . . . . . . . . . . 35 Task 3: Adding Dynamic Content Metadata . . . . . . . . . . 37 Task 4: Configuring a Dispatch Handler . . . . . . . . . . . 39 Task 5: Creating Filtered Feature Categories . . . . . . . . . 41 Task 6: Creating Oracle Views to Support Filtered Feature Categories . 45 Task 7: Configuring a Dynamic Content Adapter . . . . . . . . 51 Task 8: Configuring Content Vendor Authentication . . . . . . . 51 Using Subscriptions . . . . . . . . . . . . . . . . . . . 53 How Subscriptions Are Triggered . . . . . . . . . . . . . 54 Handling Subscription Notifications . . . . . . . . . . . . 56Chapter 4 Road Network Content . . . . . . . . . . . . . . . .67 Overview . . . . . . . . . . . . . . . . . . . . . . . 68 About Routing . . . . . . . . . . . . . . . . . . . . . 69 Routes, Legs, and Steps . . . . . . . . . . . . . . . . 69 Calculating and Retrieving Routes . . . . . . . . . . . . . 70 About Travel Directions . . . . . . . . . . . . . . . . . . 71 Generating Travel Directions . . . . . . . . . . . . . . 71 Generating Locale-Specific Travel Directions . . . . . . . . . 72 Creating Custom Presentation Views . . . . . . . . . . . . 73 About Mapping . . . . . . . . . . . . . . . . . . . . . 73Chapter 5 Geocoding . . . . . . . . . . . . . . . . . . . .75 Overview . . . . . . . . . . . . . . . . . . . . . . . 76 The Autodesk LocationLogic Geocoder . . . . . . . . . . . . . 77 Geocoding Constraints . . . . . . . . . . . . . . . . . . 77 Position of Civic Number . . . . . . . . . . . . . . . 77 Support for Street Types in Street Name Field . . . . . . . . . 78 Support for Alternative Characters . . . . . . . . . . . . . 78 Support for Stripped Character Sets . . . . . . . . . . . . 79 Accessing Forward Geocoding . . . . . . . . . . . . . . . . 79 Accessing Reverse Geocoding . . . . . . . . . . . . . . . . 80 Geocoding Results . . . . . . . . . . . . . . . . . . . . 81 Standardized Address . . . . . . . . . . . . . . . . . 81 Match Confidence Level . . . . . . . . . . . . . . . . 81iv | Contents
  5. 5. Match Level . . . . . . . . . . . . . . . . . . . . 81 Geometric Point . . . . . . . . . . . . . . . . . . . 82 Street Network Link Feature ID . . . . . . . . . . . . . . 82Chapter 6 Accessing External Data from LocationLogic . . . . . . . . 83 Overview . . . . . . . . . . . . . . . . . . . . . . . 84 External Content Requirements . . . . . . . . . . . . . . . . 84 Setting Up LocationLogic for External Content . . . . . . . . . . . 85 Process Overview . . . . . . . . . . . . . . . . . . 85 Task 1: Defining External Content Sources . . . . . . . . . . 85 Task 2: Linking External Content to the LocationLogic Database . . . 87 Task 3: Creating Data Bridge Features . . . . . . . . . . . . 87 Accessing External Content . . . . . . . . . . . . . . . . . 89Appendix A Designing and Configuring Maps . . . . . . . . . . . . 91 Overview . . . . . . . . . . . . . . . . . . . . . . . 92 Types of Maps . . . . . . . . . . . . . . . . . . . 92 Map Formats . . . . . . . . . . . . . . . . . . . . 93 Map Creation and Configuration Overview . . . . . . . . . . . . 94 Task 1: Authoring Maps . . . . . . . . . . . . . . . . . . 95 Overview . . . . . . . . . . . . . . . . . . . . . 95 Representing a User’s Location . . . . . . . . . . . . . . 96 Representing a Route . . . . . . . . . . . . . . . . . 96 Representing Features . . . . . . . . . . . . . . . . . 97 Designing Maps for Performance . . . . . . . . . . . . . 97 Task 2: Creating Copyright or Branding Overlays . . . . . . . . . . 99 Creating GMX Files. . . . . . . . . . . . . . . . . . 99 Task 3: Configuring Map Manager . . . . . . . . . . . . . . .101 Adjusting the Bounding Box Expansion Factor . . . . . . . . .102 Creating and Using Custom Highlight Styles . . . . . . . . . .102 Task 4: Configuring Geomap . . . . . . . . . . . . . . . . .103 Enabling Anti-Aliasing . . . . . . . . . . . . . . . . .104 Configuring the Color Overrides Property . . . . . . . . . . .104Appendix B Content Organization . . . . . . . . . . . . . . . .107 Overview . . . . . . . . . . . . . . . . . . . . . . .108 LocationLogic Features . . . . . . . . . . . . . . . . . . .108 Feature Metadata . . . . . . . . . . . . . . . . . . . . .109 Accessing Feature Metadata . . . . . . . . . . . . . . .110 Feature Table Associations. . . . . . . . . . . . . . . . . .110 LocationLogic Feature Types . . . . . . . . . . . . . . . . .111 Feature Type Properties . . . . . . . . . . . . . . . .111 The Feature Type Table . . . . . . . . . . . . . . . .112 Contents | v
  6. 6. Associating Features and Feature Types . . . . . . . . . . . . . 113 LocationLogic Feature Categories . . . . . . . . . . . . . . . 114 The Feature Category Table . . . . . . . . . . . . . . . 115 Associating the Content Hierarchy and Feature Category Data . . . . 116 Restricting Access to Feature Categories . . . . . . . . . . . 116 Structuring Feature Categories . . . . . . . . . . . . . . 117 Associating Feature Categories and Feature Types . . . . . . . . . . 119 Accessing Extended LocationLogic Content . . . . . . . . . . . . 120 Adding a New Feature Category . . . . . . . . . . . . . . . 121 Accessing Additional Feature Tables . . . . . . . . . . . . . . 124 Defining Feature Category and Feature Type Associations . . . . . . . 128 Single Feature Type . . . . . . . . . . . . . . . . . 128 Multiple Feature Types . . . . . . . . . . . . . . . . 129 Optimizing Content Searches . . . . . . . . . . . . . . . . 129 Definition . . . . . . . . . . . . . . . . . . . . 129 Content Searches and Content Strategy . . . . . . . . . . . 129 Searching Only Leaf Nodes . . . . . . . . . . . . . . . 130 Searching All Hierarchy Levels. . . . . . . . . . . . . . 132 Streamlining Feature Filters . . . . . . . . . . . . . . . . . 135Appendix C Using the Content Management Console . . . . . . . . . 137 Overview . . . . . . . . . . . . . . . . . . . . . . . 138 The Content Management Console Interface . . . . . . . . . . . . 139 Rules and Guidelines . . . . . . . . . . . . . . . . . . . 141 Starting the Content Management Console . . . . . . . . . . . . 142 Database Login Elements . . . . . . . . . . . . . . . 142 Login Error Messages. . . . . . . . . . . . . . . . . 145 Managing Feature Categories . . . . . . . . . . . . . . . . 146 Overview. . . . . . . . . . . . . . . . . . . . . 146 Feature Category Elements . . . . . . . . . . . . . . . 146 Viewing Feature Categories . . . . . . . . . . . . . . . 148 Creating Feature Categories . . . . . . . . . . . . . . . 149 Modifying Feature Categories . . . . . . . . . . . . . . 152 Duplicating Feature Categories . . . . . . . . . . . . . . 153 Moving Feature Categories . . . . . . . . . . . . . . . 154 Deleting Feature Categories . . . . . . . . . . . . . . . 154 Managing Feature Types . . . . . . . . . . . . . . . . . . 155 Overview. . . . . . . . . . . . . . . . . . . . . 155 Feature Type Elements . . . . . . . . . . . . . . . . 156 Viewing Feature Types . . . . . . . . . . . . . . . . 157 Creating Feature Types . . . . . . . . . . . . . . . . 158 Modifying Feature Types. . . . . . . . . . . . . . . . 160 Deleting Feature Types . . . . . . . . . . . . . . . . 160 Managing Feature Type Properties . . . . . . . . . . . . . . . 161vi | Contents
  7. 7. Feature Type Property Elements . . . . . . . . . . . . . .162 Viewing Feature Type Properties . . . . . . . . . . . . .163 Creating Feature Type Properties . . . . . . . . . . . . .164 Modifying Feature Type Properties . . . . . . . . . . . . .166 Deleting Feature Type Properties . . . . . . . . . . . . .167Changing Databases . . . . . . . . . . . . . . . . . . . .168Logging Out of the Content Management Console . . . . . . . . . .169 Contents | vii
  8. 8. viii
  9. 9. About This GuideThe Autodesk® LocationLogic platform provides you with the In this chaptertools you need to build location-based services (LBS) applications. ■ Audience and purpose ■ Assumptions and necessary skillsThis guide contains information about the different types of ■ How this guide is organized ■ Conventions used in this guidecontent associated with LocationLogic, and how applications caneffectively use it.This chapter explains what’s in the guide and how it’s organized. ix
  10. 10. Audience and Purpose This guide is intended for Autodesk® LocationLogic platform and database administrators, to help them plan and maintain LocationLogic content and its organization, and application developers, to help them effectively use the LocationLogic content in their applications.Assumptions and Necessary Skills No particular administrative, database, or programming skills are necessary to understand the conceptual information presented in this guide. However, specific procedures may assume any of the following: ■ You are familiar with the Solaris 8 operating system and have root privileges on the machines on which you will be executing database SQL commands. ■ You are familiar with third-party software, such as Oracle9i™ Enterprise Edition 9.2.0.4 and BEA WebLogic Server™. ■ You are familiar with creating and running SQL scripts. ■ You are familiar with LocationLogic, and at least one of the LocationLogic APIs used for creating LocationLogic applications. For installation and configuration of the Oracle database on Intel® Itanium® architecture on HP Integrity Linux systems, it is assumed that you are familiar with Red Hat Linux Advanced Server and have root privileges on the machines on which you will be executing database SQL commands.How This Guide Is Organized This guide is organized as follows: ■ Chapter 1, “Introduction,” introduces you to the LocationLogic database and the types of content used by LocationLogic. ■ Chapter 2, “Points of Interest (POI) Content,” describes LocationLogic POI (Point of Interest) content, related administration functions (such as adding POI-related information to the database), and how LocationLogic applications use POI content. ■ Chapter 3, “Dynamic Content,” describes what dynamic content is, why it is used, how LocationLogic applications can access it, and how to set up LocationLogic to incorporate dynamic content.x | About This Guide
  11. 11. ■ Chapter 4, “Road Network Content,” describes road network content, how it is used by LocationLogic to generate maps and travel directions, and how LocationLogic applications can access those functions. ■ Chapter 5, “Geocoding,” describes what geocoding is, the LocationLogic geocoding components, and how applications can use geocoding. ■ Chapter 6, “Accessing External Data from LocationLogic,” describes how applications can access content that is in external databases, and how to set up LocationLogic to enable such access. ■ Appendix A, “Designing and Configuring Maps,” describes the map files used by Autodesk® LocationLogic, how to author maps for application use, and how to configure the necessary LocationLogic components to obtain the desired map appearance when the maps are retrieved by applications. ■ Appendix B, “Content Organization,” describes how different types of LocationLogic features, including points of interest, bookmarked information, and so forth, are organized in the LocationLogic database. ■ Appendix C, “Using the Content Management Console,” explains how to use the Content Management Console to manage LocationLogic content metadata (feature categories and feature types). Refer to the Autodesk LocationLogic Glossary for a listing of terms and definitions relating to LocationLogic and to the GIS (Geographic Information Systems) and wireless industries in general.Conventions Used in This Guide This section describes the following conventions used in this guide: ■ Text conventions ■ Code and syntax conventions Text Conventions This guide uses the following text conventions: ■ Italic is used to introduce new terms. Italic is also used for database column names, file and folder names, and book titles. ■ Bold is used for any text you must enter, such as at a command line prompt or in a dialog box. ■ A monospace font is used for all code elements (variable names, data values, method names, and so forth), command lines, scripts, and source code listings. Conventions Used in This Guide | xi
  12. 12. ■ Bold italic monospace is used for replaceable elements and placeholders within code listings. Code and Syntax Conventions This guide uses the following code and syntax conventions: ■ Indentation and line breaks have been added to make examples more legible. However, if you are copying the example code for your own use, do not use line breaks in an actual command: ■ Although line breaks are valid if the preceding line ends in a backslash, there should not be leading spaces in an actual command. The following table describes conventions used in this manual: These Indicate this... symbols... | The vertical-bar or pipe symbol separates alternative items that may be optional or required. You may choose exactly one of the given items. Do not type the vertical bar. For example, the text: A | B | C indicates that you should choose only one item—A or B or C. [] Square brackets enclose one or more optional items. Do not type the brackets. For example, the text: [A | B | C] indicates that you can choose no items or a single item—A or B or C. While the text: [D] indicates that you can choose no items or item D. {} Braces enclose one or more required items. Do not type the braces. For example, the text: {A | B | C} indicates that you must choose a single item—A or B or C. ... Ellipses mean that the preceding item(s) may be repeated any number of times.xii | About This Guide
  13. 13. Conventions Used in This Guide | xiii
  14. 14. xiv
  15. 15. 1IntroductionThis chapter introduces you to the Autodesk® LocationLogic In this chapterdatabase and the types of content used by LocationLogic. ■ About the LocationLogic database ■ Types of content ■ LocationLogic features and metadata ■ Optimizing the LocationLogic database performance ■ System requirements 1
  16. 16. About the LocationLogic Database The LocationLogic database is the repository of content used by LocationLogic software components and application code. All content is included in the database, except certain geographic content that is contained in files so as to optimize LocationLogic performance. LocationLogic applications access content in the LocationLogic database to provide users with a rich variety of location-based services, such as, for example: ■ Information about current local weather and traffic conditions ■ Routing services, with maps and turn-by-turn navigation instructions ■ Assistance in finding nearby places of business and entertainment ■ Real-time tracking of friends, mobile objects, service personnel, and fleet equipment ■ Real-time user handset notification of spatial events, including traffic incidents along a frequently traveled route The LocationLogic database consists of a standard set of LocationLogic content tables, as well as tables that contain organizational metadata describing how LocationLogic content items are related to each other in a hierarchical fashion. These tables are installed during deployment, as described in the Autodesk LocationLogic Installation Guide. The following sections describe the LocationLogic database in more detail, explaining the types of content included, how to optimize database performance, and the database system requirements.2 | Chapter 1 Introduction
  17. 17. Types of Content To provide users with a rich variety of location-based services, LocationLogic uses many types of content: ■ Point of Interest (POI) content—Data describing places of business and entertainment, as well as medical facilities, government buildings, museums, and so forth. Standard POI content is provided by vendors such as NAVTEQ and Tele Atlas, but POI content can also include custom data that you supply (see “Extended Attributes” on page 22). POI content is stored in the LocationLogic database, and is static—it remains unchanged in the database until you replace it with an updated content data set. LocationLogic applications use POI content to answer user questions such as, “Which Chinese restaurants are within 5 miles of my hotel?” and “Are there any libraries on my way home from work?” For more information about administering and using POI content, see Chapter 2, “Points of Interest (POI) Content”. ■ Dynamic content—Data that frequently changes, such as traffic incidents along specific routes, current weather conditions, or mobile objects such as LocationLogic users. This data is stored in the LocationLogic database. LocationLogic applications use dynamic content to answer user requests such as, “Are there any accidents on my way home?” and “Send me a message when Stephanie gets within a mile of where I am,” and to provide services such as fleet tracking. For more information about administering and using dynamic content, see Chapter 3, “Dynamic Content”. ■ Road network content—Navigation information about a set of roads, such as how they are connected, their posted speed limits, accessibility (for example, carpool only or bike route), and so forth. This information is obtained from vendors such as NAVTEQ and Tele Atlas, and is stored in the LocationLogic database. LocationLogic uses road network content to generate maps and travel directions as requested by LocationLogic applications. For more information about the road network content, see Chapter 4, “Road Network Content”. ■ Geocoding content—Static geographic data representing road coordinates, address ranges, POIs, and so forth, derived from road network and POI content received from content vendors. Geocoding content is stored as files on the LocationLogic server. Types of Content | 3
  18. 18. LocationLogic uses geocoding content to perform forward geocoding (translating a street address to a geographic coordinate, or point) and reverse geocoding (translating a geographic coordinate, or point, to a street address). For more information about the geocoding content, see Chapter 5, “Geocoding”. ■ External content—Data that is stored external to the LocationLogic database. There is no limit as to what this data can represent. It can be user profile data that a carrier wishes to keep private, custom features that are not in the standard NAVTEQ or Tele Atlas content data sets, and so on. LocationLogic applications can retrieve and query external content any time, and use it for any purpose. Applications send requests for external content to LocationLogic, which accesses the external content using a LocationLogic data bridge—the mechanism that links external content to the LocationLogic database. For more information about configuring and using external content, see Chapter 6, “Accessing External Data from LocationLogic”. ■ Mapping content—Geographic basemap data that represents spatial information such as roads, cities, and countries. It is derived from road network content, and stored as Autodesk MapGuide® SDF files (which contain spatial information, such as roads, cities, and countries) and MWF files (which contain pointers to groups of SDF files that, when combined, form a cohesive map). LocationLogic uses mapping content as the basis for creating maps for display on various devices, as requested by LocationLogic applications. For more information, see Appendix A, “Designing and Configuring Maps”.LocationLogic Features and Metadata From an API point of view, the content items stored in the LocationLogic database are known as “features,” and the metadata describing the relationships between the features is known as “feature metadata.” LocationLogic applications access content items in the LocationLogic database using feature-related calls. For example, the Java API method to retrieve all features that are within a specified distance of a given location is findFeaturesWithinDistance. This call is used to access any type of content in the database. This section explains more about what these terms mean in the context of the LocationLogic database.4 | Chapter 1 Introduction
  19. 19. LocationLogic FeaturesLocationLogic feature is the term used to identify any content item in the LocationLogicdatabase that can be accessed and queried by LocationLogic applications. LocationLogicfeatures 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 informationEvery LocationLogic application organizes the LocationLogic features into a contenthierarchy of logical groupings. For example, one application may use a broad category ofAsian restaurants, while another application might divide them into Japanese restaurants,Chinese restaurants, and so forth. This logical grouping of LocationLogic features in thecontent hierarchy is independent of the underlying database content and schema. That is,LocationLogic features can be grouped together in the content hierarchy regardless ofwhether or not they are in the same database table, or even whether or not their databaserecords 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 datafields, 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 methodsto search through any feature table, and to identify any LocationLogic feature’sproperties.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
  20. 20. By using feature metadata, LocationLogic applications can efficiently access LocationLogic features. In addition, you use feature metadata to enable certain kinds of content use, such as incorporating dynamic content into the LocationLogic database. There are three types of metadata, which together describe a LocationLogic feature: ■ Feature category—A logical grouping of LocationLogic features (POIs, mobile objects, and so forth), as defined for a particular application. Feature categories correspond to an application’s content hierarchy (see “LocationLogic Features” on page 5), and enable applications to efficiently access and navigate the database to find the feature a user is looking for. Typical feature categories are POIs, RESTAURANTS, and BANKS. ■ Feature type—An identifier for a group of LocationLogic features that share common characteristics, such as their source content vendor (for example, NAVTEQ), or common characteristics that might be used to query them (for example, foodtype for restaurants). Depending on the quantity and sort of LocationLogic features in your deployment, your feature types may be very broad, such as NT_POI to refer to all NAVTEQ- provided POIs, or more granular, such as NT_RESTAURANTS and NT_BANKS, which describe the characteristics of two separate sets of data: NAVTEQ-provided restaurants and banks, respectively. ■ Feature type properties—The set of characteristics that, when taken together, fully describe a feature type; for example, the feature type’s data source, as well as characteristics of the feature type, such as FOODTYPE and NAME in the case of a RESTAURANT feature type. Every feature type is described by the following feature type properties: ❏ FDATASRC. Identifies the data source of the feature table where the corresponding features are stored; for example, jdbc/Oracle. ❏ FTABLE. Identifies the name of the table where the corresponding features are stored; for example, NT_NA_RESTAURANTS. ❏ Multiple properties that identify every field of a LocationLogic feature’s database record which LocationLogic applications can access; for example, FOODTYPE, NAME, and FACILITYTYPE. Related Topic ■ See Appendix B, “Content Organization,” for more detailed information about how LocationLogic feature metadata is used; for example, to optimize content searches.6 | Chapter 1 Introduction
  21. 21. Optimizing the LocationLogic DatabasePerformance This section offers tips for improving LocationLogic database performance. The following topics are covered: ■ Optimizing database tables ■ Saving changes to the database ■ Creating efficient SQL queries Optimizing Database Content If you notice poor performance when reading or writing to the LocationLogic database, work with your database administrator to confirm that the database is optimized to work with your application. This is especially important if you have extended the database with additional custom tables or columns. How you optimize the database will depend on your data and the manner in which your application accesses it. For example, you might need to create context indexes for POI tables, or spatial indexes for table columns containing location geometry information. Saving to the Database Writing to the LocationLogic database is a time-consuming operation, so such operations should be used sparingly. Usually, the best strategy is to commit several changes at once. For example, if you create and add three new features, it is faster save those features with a single call (for example, LbsFeatureManager.saveChanges in the Java API), rather than calling the method three times. Note The exception to this rule is an application that updates many records at once. For example, a notification application might create thousands of subscriptions for users who have granted permission to do so. In this case, it is better to save five or ten subscriptions at a time, rather than waiting to commit thousands of changes at once. Besides reducing the chance of lost data, saving in smaller batches also releases system resources, resulting in better performance. Optimizing the LocationLogic Database Performance | 7
  22. 22. Another option is to save data infrequently, perhaps only when the user exits a screen or logs out of the application. This is appropriate only in cases where data loss is not a major concern. Or you might give users the option of deciding when to write the data, via a ‘Save’ button or some other interface element. A user who has caused an action may be more tolerant of the associated performance hit. Creating Efficient SQL Queries Many feature- and subscription-related API calls (for example, LbsFeatureCategory.findFeatures in the Java API) take as an argument a string representing the contents of a SQL WHERE clause. By optimizing the SQL queries passed to these methods, you can make your application considerably faster. General Guidelines When creating a SQL query, constrain your search to return the smallest result set possible. Minimize the use of wildcards and, if possible, make sure your WHERE clauses make use of indexed columns. Avoid the use of SQL functions (for example, UPPER or INIT) in WHERE clauses. Use of the GEOM Property By setting feature properties, you control which fields should be populated in features returned by the feature category query methods. Setting the GEOM property causes returned features to contain associated Oracle spatial data. Retrieving spatial data is time-consuming, so you should set this property only if your application requires it. For more information, refer to the descriptions of LbsFeature and LbsFeatureCategory in the Autodesk LocationLogic Java API Reference.8 | Chapter 1 Introduction
  23. 23. Using Wildcards for Pattern Matching in Large TablesFor large tables, use of the LIKE operator in a SQL WHERE clause can result in slowquery performance.The LIKE operator is used to compare a value to a pattern containing special wildcardcharacters, such as percent (%) and underscore (_). For example, the following querysearches 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 beable to use the normal Btree index on the column referenced in the LIKE predicate. Underthese conditions, a full database table scan is performed.To avoid this performance hit, do the following:■ Set up a context index for the POINAME table. By default, the POINAME table does not have a context index set up. To set up a context index, you need the Oracle CTX indexing package installed. This package is installed by default when you create a database with the Database Configuration Assistant. For more information, see your Oracle documentation.■ Modify the query, by replacing the LIKE clause with a CONTAINS clause that takes advantage of the context index. For example, replace: LIKE %RESTAURANTS% with CONTAINS(POINAME, %RESTAURANTS%) > 0Warning A table’s context index is not updated automatically when you perform DMLoperations (Insert, Update, and Delete). Refer to the Oracle documentation to learn aboutthe maintenance of context indexes before implementation. Optimizing the LocationLogic Database Performance | 9
  24. 24. System Requirements The hard disk requirements for the LocationLogic database vary depending on many factors, including the following: ■ The version of vendor content you are using—Different versions have different numbers of records. ■ The number of countries for which you have POI and road network data—The more countries you include, the more records the database needs. ■ Which countries you are including—Smaller countries have fewer POIs and roads than larger countries. ■ The types of maps you are generating—Higher resolution maps require bigger mapping files than lower resolution maps. For specific requirements, refer to either the NAVTEQ or Tele Atlas Content Release Notes for your geographic area (if applicable) and LocationLogic version.10 | Chapter 1 Introduction
  25. 25. 2Points of Interest (POI) ContentLocationLogic applications use POI (Point of Interest) content to In this chapteranswer user questions, such as, “Which Chinese restaurants are ■ Overview ■ POI schemawithin 5 miles of my hotel?” and “Are there any libraries on my ■ Adding content to the POI schemaway home from work?” ■ Accessing POI contentThis chapter describes LocationLogic POI content, related ■ POI names ■ Extended attributesadministration functions (such as adding POI-related information ■ Adding extended attributes to POIsto the database), and how LocationLogic applications use POI ■ Selecting POIs based on providercontent. ■ Migration notes 11
  26. 26. Overview POI (Point of Interest) content is vendor-supplied content describing places of business and entertainment, as well as medical facilities, government buildings, museums, or any place that has a location (address). In addition to the vendor-supplied content, LocationLogic includes the following POI- related content (which is always associated with a specific POI): ■ Alternate names of POIs (see “POI Names” on page 21) ■ Custom data that you supply (see “Extended Attributes” on page 22) ■ Identification of the source of all POI and POI-related content (see “Selecting POIs Based on Provider” on page 28) LocationLogic applications use this additional POI-related content to provide both a richer set of information to users, and better matches (differentiation between POIs) for user requests. POIs and POI-related content are stored in the LocationLogic database, in a set of POI tables. LocationLogic applications query the POI tables to answer user questions, such as “What Chinese restaurants are near me?” The content in the POI tables is used to identify and differentiate one POI from another, based on its properties, such as SIC (Standard Industrial Classification), facility type, and so forth. POIs are stored in the LocationLogic database in a hierarchical structure as LocationLogic features, and are described and identified by metadata elements such as the feature category and feature types. (For more information, see “LocationLogic Features and Metadata” on page 4.) Applications can access POIs by using the feature-related methods in the LocationLogic APIs (see “Accessing POI Content” on page 21.) POIs have associated properties—fields of information (columns in their database tables), such as name, location, phone number, and so forth. Applications use POI properties to access and query POI records based on the values of specific fields within the records. Note POI properties are not the same as feature type properties (see “Feature Metadata” on page 5). Feature type properties describe characteristics of feature types, such as database names. POI properties describe fields within POI data records.12 | Chapter 2 Points of Interest (POI) Content
  27. 27. The following sections provide details about POI records in the LocationLogic database, how LocationLogic applications can use the POI information, and how to administer and maintain POI information in the LocationLogic database: ■ “POI Schema” on page 13 ■ “Adding Content to the POI Schema” on page 20 ■ “Accessing POI Content” on page 21 ■ “POI Names” on page 21 ■ “Extended Attributes” on page 22 ■ “Adding Extended Attributes to POIs” on page 23 ■ “Selecting POIs Based on Provider” on page 28 ■ “Migration Notes” on page 28POI Schema The POI schema identifies every field in the POI tables, the field’s data type and size, and the primary and foreign keys. You need this information in order to add entries to the database tables (for example, adding extended attributes, as described in “Adding Extended Attributes to POIs” on page 23), and so that your LocationLogic applications can correctly retrieve the desired information from the POI and POI-related tables. The POI schema consists of four related tables. Each POI table name begins with the same prefix, <SS_GA>_, where SS indicates the data source, such as NT for NAVTEQ; and GA indicates the geographic area, such as IT for Italy. There are four POI tables: ■ <SS_GA>_POI—The POI parent table; contains basic information for every POI that is supplied by a data provider (content vendor), such as its name, address, and data provider id. For information about using POI content, see “Accessing POI Content,” on page 21. The <SS_GA>_POI table’s primary key, poi_id, is used as a foreign key link by the <SS_GA>_POI_NAME and <SS_GA>_POI_ATTRIBUTE child tables. LocationLogic uses this link to enable applications to access the POI content in the child tables, as described in “POI Names” on page 21, and “Extended Attributes” on page 22. POI Schema | 13
  28. 28. ■ <SS_GA>_POI_NAME—A POI child table; contains POI names that can be used in addition to a POI’s main name that is included in the POI parent table. For information about using multiple names, see “POI Names,” on page 21. ■ <SS_GA>_POI_ATTRIBUTE—A POI child table; contains extended attribute information (custom data) that you have added to POIs. For information about using extended attributes, see “Extended Attributes,” on page 22. For information about adding extended attributes, see “Adding Extended Attributes to POIs,” on page 23. ■ <SS_GA>_DATA_PROVIDER—A reference lookup table; maps a POI’s data provider id to the provider’s name. For information about using the data provider information, see “Selecting POIs Based on Provider,” on page 28. The <SS_GA>_DATA_PROVIDER lookup table’s primary key, data_provider_id, is used as a foreign key link by the other POI tables, which enables applications to determine the name of the data provider that was the source of any POI’s information (see “Selecting POIs Based on Provider” on page 28.) The following sections describe the properties of each POI table: ■ “<SS_GA>_POI Parent Table Data Set” on page 16 ■ “<SS_GA>_POI_ATTRIBUTE Child Table Data Set” on page 19 ■ “<SS_GA>_POI_NAME Child Table Data Set” on page 18 ■ “<SS_GA>_DATA_PROVIDER Table Data Set” on page 2014 | Chapter 2 Points of Interest (POI) Content
  29. 29. The following entity relationship diagram (ERD) illustrates the schema for each POItable, and the relationships between the tables: SS_GA_poi SS_GA_poi_attribute PK poi_id* NUMBER(19) PK poi_attribute_id* NUMBER(19) FK link_id NUMBER(19) FK poi_id* NUMBER(19) FK facility_type_id* NUMBER(19) attribute_name* VARCHAR2(50) chain_id NUMBER(5) attribute_value* VARCHAR2(255) FK food_type_id NUMBER(10) insert_date* DATE poi_name VARCHAR2(100) update_date* DATE phone_num VARCHAR2(25) FK data_provider_id* NUMBER(19) street_side CHAR(1) address VARCHAR2(100) lang_code VARCHAR2(2) city VARCHAR2(70) SS_GA_data_provider state VARCHAR2(2) country VARCHAR2(3) PK data_provider_id* NUMBER(19) postal_code VARCHAR2(10) data_provider_name* VARCHAR2(50) lon NUMBER(15,8) lat NUMBER(15,8) insert_date* DATE update_date* DATE FK data_provider_id* NUMBER(19) SS_GA_poi_name geom* VARCHAR2(0) PK poi_nam e_id* NUMBER(19) FK poi_id* NUMBER(19) name_type VARCHAR2(2) name* VARCHAR2(100) Legend lang_code VARCHAR2(2) PK primary key insert_date* DATE FK foreign key update_date* DATE * not null FK data_provider_id* NUMBER(19)POI Entity Relationship Diagram (ERD) POI Schema | 15
  30. 30. <SS_GA>_POI Parent Table Data Set The <SS_GA>_POI parent table contains basic information for every POI that is supplied by a data provider (content vendor), such as its name, address, and data provider id. (For information about using POI content, see “Accessing POI Content,” on page 21.) The following table describes the <SS_GA>_POI parent table’s data set: <SS_GA>_POI Parent Table Data Set (1 of 2) Physical Column Name Description Column Notes POI_ID Unique ID of this POI primary key LINK_ID The link ID of the road network segment foreign key (transportation link) on which this POI is located FACILITY_TYPE_ID The ID of this POI’s facility type foreign key CHAIN_ID Indicates whether this POI belongs to a chain; for example, McDonald’s. FOOD_TYPE_ID The ID of this POI’s food type (used with foreign key restaurant facilities only) POI_NAME Name of this POI PHONE_NUM Phone number of this POI STREET_SIDE Side of street that this POI is on: • L—Left • R—Right • NULL—unknown or no data ADDRESS Address of this POI LANG_CODE Language code associated with this POI’s name (POI_NAME) CITY City where this POI is located STATE State (or country subdivision, such as Région in France or Kanton in Switzerland) where this POI is located16 | Chapter 2 Points of Interest (POI) Content
  31. 31. <SS_GA>_POI Parent Table Data Set (2 of 2) Physical Column Name Description Column Notes COUNTRY Country where this POI is located POSTAL_CODE Postal code of this POI LON Longitudinal representation of the location of this POI LAT Latitudinal representation of the location of this POI INSERT_DATE The date this record was first added to the database UPDATE_DATE The date of the most recent update to this record DATA_PROVIDER_ID Unique identifier of the data provider (content vendor), such as 1 for NAVTEQ, or 100 for a custom data record provider, such as yourCompanyName GEOM Location of this POI, in lat/lon format POI Schema | 17
  32. 32. <SS_GA>_POI_NAME Child Table Data Set The <SS_GA>_POI_NAME child table contains alternate names (such as synonyms and exonyms) for POIs. (For more information about using alternate names, see “POI Names” on page 21.) The following table describes the <SS_GA>_POI_NAME table’s data set: <SS_GA>_POI_NAME Child Table Data Set Physical Column Name Description Column Notes POI_NAME_ID Unique ID of this alternate POI name primary key POI_ID ID of the POI to which this alternate name foreign key applies NAME_TYPE Data provider (content vendor) specific code indicating the type of alternate name. For NAVTEQ POIs, values are: • B—Base name • E—Exonym • S—Synonym • U—Unnamed For Tele Atlas POIs, values are: • ON—Official name • AN—Alternate name NAME The alternate POI name LANG_CODE ISO 639 two-letter language code associated with this alternate POI name INSERT_DATE The date this record was first added to the database UPDATE_DATE The date of the most recent update to this record DATA_PROVIDER_ID Unique identifier of the data provider, such foreign key as 1 for NAVTEQ, or 100 for a custom data record provider, such as yourCompanyName18 | Chapter 2 Points of Interest (POI) Content
  33. 33. <SS_GA>_POI_ATTRIBUTE Child Table Data SetThe <SS_GA>_POI_ATTRIBUTE child table contains all the extended attributes thathave been added to the POIs. It provides for an unlimited number of extended attributesfor any POI. (For information about using extended attributes, see “Extended Attributes,”on page 22. For information about adding extended attributes, see “Adding ExtendedAttributes to POIs,” on page 23.) The following table describes the<SS_GA>_POI_ATTRIBUTE table’s data set:<SS_GA>_POI_ATTRIBUTE Child Table Data Set Physical Column Name Description Column Notes POI_ATTRIBUTE_ID Unique ID of this extended attribute primary key POI_ID ID of the POI to which this extended foreign key attribute belongs ATTRIBUTE_NAME Unique name used to identify this extended attribute when requesting LocationLogic POI information ATTRIBUTE_VALUE The value of the extended attribute. Note that the value is stored as VARCHAR2(50), regardless of the actual data type. The feature type mapping must explicitly perform any required data conversion. (See “Task 2: Mapping Extended Attributes to Feature Types” on page 24.) INSERT_DATE The date this record was first added to the database UPDATE_DATE The date of the most recent update to this record DATA_PROVIDER_ID Unique identifier of the data provider foreign key (content vendor), such as 1 for NAVTEQ, or 100 for a custom data record provider, such as yourCompanyName POI Schema | 19
  34. 34. <SS_GA>_DATA_PROVIDER Table Data Set The <SS_GA>_DATA_PROVIDER table is a reference lookup table that maps a POI’s data provider (content vendor) id to the provider’s (vendor’s) name. (For information about using the data provider content, see “Selecting POIs Based on Provider,” on page 28.) The following table describes the <SS_GA>_DATA_PROVIDER table’s data set: <SS_GA>_DATA_PROVIDER Child Table Data Set Physical Column Name Description Column Notes DATA_PROVIDER_ID Unique ID used to identify a data record’s primary key source: • 1—NAVTEQ • 2—Tele Atlas • 100 and higher—Custom data DATA_PROVIDER_NAME The data provider’s nameAdding Content to the POI Schema If your application requires POI content beyond what can be accommodated in the LocationLogic POI schema, you can use any of the following techniques to extend the schema: ■ Add additional columns to the <SS_GA>_POI parent table, and expose the new content to LocationLogic by adding feature type properties (described in “Feature Metadata” on page 5.) For more information, see “Accessing Extended LocationLogic Content” on page 120. ■ Create new LocationLogic feature tables in which to store the new information, and expose it to LocationLogic by using a database view that joins the <SS_GA>_POI table to the new tables, or by adding feature types (described in “Feature Metadata” on page 5.) For more information, see “Accessing Additional Feature Tables” on page 124. ■ Insert the new information into the <SS_GA>_POI_ATTRIBUTE extended attribute table. For more information, see “Extended Attributes,” on page 22, and “Adding Extended Attributes to POIs,” on page 23. Determining the best technique to use to add POI content depends on many factors, such as the source of the information, the frequency with which it is updated, the number of attributes, and each attribute’s type. It is recommended that you contact your Autodesk Professional Services representative before choosing a particular method.20 | Chapter 2 Points of Interest (POI) Content
  35. 35. Accessing POI Content Because POIs are a type of LocationLogic feature (see “LocationLogic Features” on page 5), LocationLogic applications access them by using the LocationLogic feature methods. Each type of LocationLogic API and deployment environment provides methods for applications to specify and retrieve content items, in this case, POIs. The following list describes the different techniques that you can use to access content items (features) in the LocationLogic database: ■ Applications built using the LocationLogic Java API—Use the LbsFeature, LbsFeatureCategory, and LbsFeatureManager classes and interfaces. For more information, refer to the Autodesk LocationLogic Developer’s Guide and the Autodesk LocationLogic Java API Reference. ■ Applications built using LocationLogic XML Web Services—Use the DirectoryRequest element, and associated child elements. For more information, refer to the Autodesk LocationLogic XML Web Services Developer’s Guide. ■ Remote J2ME applications—Use the LbsmeDirectoryRequest, LbsmePOI, and LbsmePOIProperty objects and methods. For more information, refer to the Autodesk LocationLogic J2ME Developer’s Guide.POI Names POIs can have alternate names, such as synonyms and exonyms (names in a language other than the national language; for example, Munich is an exonym for München.) This gives LocationLogic applications the ability to display POI names in a variety of languages. Your application can choose which name to display based on any criterion; for example, a user’s profile configuration that includes their preferred language. In addition to displaying alternate POI names, LocationLogic applications can query POIs based on user input, regardless of which language a user chooses. Applications can make a single query, and receive matches for all records for the POI, no matter whether the name requested is the “main” name or an alternate name. Notes ■ When querying POIs (see “Accessing POI Content” on page 21), you must take care not to confuse similarly named columns: ❏ In the <SS_GA>_POI parent table, the POI_NAME column’s value is the “main” name for the POI, as received from the data provider (content vendor.) Accessing POI Content | 21
  36. 36. ❏ In the <SS_GA>_POI_NAME child table, the NAME column’s value is the “alternate” name of the POI (whether exonym, synonym, or so forth.) ■ To retrieve a POI’s multiple alternate names when accessing POIs (as described in “Accessing POI Content” on page 21), you include the alternate name properties (NAME_TYPE, NAME, LANGCODE) when you specify the POI properties to be returned.Extended Attributes You have the flexibility to add an unlimited amount of custom content to any POI, without the need for any schema changes or LocationLogic coding updates. For example, you could add a data field called SMOKING to indicate whether an establishment allows smoking within its premises. Extended attributes is the term used to describe any POI information that is not included in the standard <SS_GA>_POI parent table’s data set: ■ Custom content that you supply (see “Adding Extended Attributes to POIs” on page 23.) ■ Information from content vendors who supply POI-related content for which there is no field in the <SS_GA>_POI parent table. (This information is included in the LocationLogic database during content deployment.) Adding extended attributes is especially useful when you want to add information about a POI that is only meaningful to a particular type of POI. For example, population is something that is meaningful to places such as countries and cities, while an indication of whether smoking is allowed is typically applicable to restaurants. The extended attribute content is stored in the extended attribute table—the <SS_GA>_POI_ATTRIBUTE POI child table. The custom content that you can store in the extended attribute table must comply with the following rules: ■ Each individual extended attribute must be single-valued—that is, it can contain only a single value, such as YES, but not a list of values, such as “Saturday, Sunday”. ■ Extended attribute values are stored as text, with a maximum of 255 characters. To add a custom field with a non-text value, for example an indication of the number of Michelin stars a restaurant has received, you must explicitly perform the data conversion (using an appropriate Oracle function, such as to_number), when you add the extended attribute, as described in “Task 2: Mapping Extended Attributes to Feature Types” on page 24.22 | Chapter 2 Points of Interest (POI) Content
  37. 37. Note If you choose to include extended attribute information in your LocationLogic database, you must be sure to consider how you will carry it forward when you update your content vendor-provided POI content. Extended attributes are linked to POIs through the vendor-provided ID, which may change from release to release. Therefore, it is important that you determine additional ways to link an extended attribute and its parent POI; for example, using additional attributes such as a POI’s name, address, and so forth, that can later be used to determine the intended POI for any extended attribute. For additional content update considerations, see “Migration Notes” on page 28.Adding Extended Attributes to POIs The following table describes the steps required to add extended attributes to POIs: Process Overview: Adding Extended Attributes to POIs Task Description Refer to 1 Insert extended attribute records into the POI child “Task 1: Inserting Extended table, POI_ATTRIBUTE, by executing a series of Attributes into the Database” SQL statements. on page 23 2 Associate extended attributes with feature types to “Task 2: Mapping Extended enable access to the new POI field data. Attributes to Feature Types” on page 24 Task 1: Inserting Extended Attributes into the Database You can add one or more extended attributes to any POI(s) in the database by executing a series of SQL statements. You can execute them at the command line, but it’s recommended that your create a script that contains all the commands for all the extended attributes you want to add. To insert a new extended attribute into the POI_ATTRIBUTE table Note In this procedure, <SS_GA> indicates the table prefix name, which consists of the data source abbreviation (such as NT for NAVTEQ) and geographic area (such as NA for North America). In your commands, be sure to replace the <SS_GA> with your actual table prefix designation. 1 Using SQL*Plus, connect to the database using the Oracle user ID created to contain and manage the content tables. Adding Extended Attributes to POIs | 23
  38. 38. This user ID must have insert, update, and delete privileges for your deployment’s content tables. Refer to the Content Release Notes for your deployment’s content vendor, geographic area, and LocationLogic version, for the appropriate user id, which will be something like, NT_NA_03Q4. 2 Determine the POI_ID of the POI to which the new extended attribute will belong; for example, after executing the following statement, a list is displayed of the POI_ID and POI_NAME values for all records where the POI_NAME begins with “MACDONALD”: SELECT POI_ID POI_NAME FROM <SS_GA>_POI WHERE POI_NAME LIKE MACDONALD% 3 Determine a unique sequence number, newSeqId, by querying to find the last used POI_ATTRIBUTE_ID, and incrementing by 1. To determine the last used POI_ATTRIBUTE_ID, execute the following statement: SELECT max(POI_ATTRIBUTE_ID) FROM <SS_GA>_POI_ATTRIBUTE; Next, increment the displayed value, and use that new value for newSeqId. 4 Determine your custom provider id, newProviderId. To query for existing provider ids, execute the following statement: SELECT * FROM <SS_GA>_DATA_PROVIDER; ■ If a record is displayed with an appropriate DATA_PROVIDER_NAME value, use the corresponding DATA_PROVIDER_ID as your newProviderId value. ■ If no appropriate entry exists, then you must create a unique data provider id to identify the source of the new extended attribute. Using any value of 100 or higher, that has not already been used, create your newProviderId by executing the following statement: INSERT INTO <SS_GA>_DATA_PROVIDER values(newProviderId, yourProviderName); 5 Insert the new extended attribute into the <SS_GA>_POI_ATTRIBUTE child table; for example, the following statement adds an extended attribute, newAtt, called SMOKING, with a value, newAttValue, of NO: INSERT INTO <SS_GA>_POI_ATTRIBUTE (newSeqId,POI_ID,SMOKING,NO,sysdate,sysdate,newProviderId); COMMIT; Task 2: Mapping Extended Attributes to Feature Types In order for LocationLogic and its applications to be able to access and query an extended attribute, it must be associated with a unique LocationLogic feature type. You make this association by creating a feature type property for the desired feature type, by using either of the following methods:24 | Chapter 2 Points of Interest (POI) Content
  39. 39. ■ “Using the Content Management Console to Add a Feature Type Property,” on page 25■ “Using Direct Database Access to Add a Feature Type Property,” on page 26Related 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 FeatureType PropertyYou can use the Content Management Console to create feature type properties, and addthem into the LocationLogic feature type metadata tables.To add a feature type property using the Content Management Console■ Follow the procedure described in “Creating Feature Type Properties,” on page 164. Adding Extended Attributes to POIs | 25
  40. 40. Using Direct Database Access to Add a Feature Type Property If you are adding many feature type properties, it may be quicker to use direct database access, executing a series of SQL statements within a script, instead of manually entering a feature type property for each extended attribute at the Content Management Console. To add a feature type property using direct database access 1 Using SQL*Plus, connect to the database using the Oracle user ID created to contain and manage the platform tables (for example, ll_owner). 2 Confirm that the extended attribute you are mapping (and previously added in “Task 1: Inserting Extended Attributes into the Database,” on page 23) was correctly added to the LocationLogic database: SELECT <SS_GA>_GET_POI_ATTRIBUTE (POI_ID,<SS_GA>_POI_ATTRIBUTE,newAtt) FROM DUAL; Where ■ POI_ID is the ID of the POI to which you added the extended attribute (see step 2 in Task 2). ■ newAtt is the name of the extended attribute; for example, SMOKING. The response is one of the following: ■ The display shows a single row returned—The attribute was correctly added. ■ The display is “no rows selected”—The extended attribute was not correctly added, and you must repeat the procedure. ■ A syntax error is returned—The function is not installed correctly, and you must rerun the function creation script, create_table_syns.sql. (This script is installed in the <SS_GA> folder during content installation.)26 | Chapter 2 Points of Interest (POI) Content
  41. 41. 3 Create a new feature type property that maps the extended attribute to a feature type, and insert the new feature type property into the feature type metadata table. Use one of the following commands, depending on whether the extended attribute’s value is text (such as “YES”), numeric (such as 4), or any other type: ■ To create a feature type property for an extended attribute that contains a text string value, enter the following: INSERT INTO fm_feature_typ(FEATURETYPE,PROPERTY,TYPE,VALUE) VALUES(<SS_GA>_POI,newAtt,3,<SS_GA>_get_poi_attribute (POI_ID,<SS_GA>_POI_ATTRIBUTE,newAtt)); Where ■ POI_ID is the ID of the POI to which you added the extended attribute (see step 2 in Task 3). ■ newAtt is the name of the extended attribute; for example, SMOKING. ■ To create a feature type property for an extended attribute that contains a numeric value, enter the following: INSERT INTO fm_feature_typ(FEATURETYPE,PROPERTY,TYPE,VALUE) VALUES(<SS_GA>_POI,newAtt,3, to_number(<SS_GA>_get_poi_attribute(POI_ID, <SS_GA>_POI_ATTRIBUTE,newAtt))); COMMIT; Where ■ POI_ID is the ID of the POI to which you added the extended attribute (see step 2 in Task 3). ■ newAtt is the name of the extended attribute; for example, SMOKING. Note If you receive a syntax error, check to be certain that the value you passed to the Oracle to_number function is numeric; the to_number function cannot convert a non-numeric value. ■ To create a feature type property for an extended attribute that contains data of any type other than text or numeric, replace the to_number function in the above example with the appropriate Oracle conversion function, such as to_date. Adding Extended Attributes to POIs | 27
  42. 42. Selecting POIs Based on Provider POI content can come from different data providers (content vendors), and you can incorporate POIs from multiple content vendors into the same POI tables. This means that your applications can selectively provide access to subsets of information to users; for example, based on a level of service such as Bronze, Silver, and Gold, which provide progressively greater amounts of information. To enable such selective access, the LocationLogic database includes a data provider audit trail in POI records. For every POI parent table and child table record, you can determine the data provider (content vendor) and record creation and update information from the following table columns: INSERT_DATA, UPDATE_DATE, and DATA_PROVIDER_ID.Migration Notes Periodically you may want to update your POI content; for example, when your data provider (content vendor) issues a new release of content. Before you update your POIs, you should be aware of the following: ■ It is recommended that you consider the quantity of extended attribute content you need to migrate as a factor in your decision whether to update your POI content from your data provider. LocationLogic does not automatically migrate the extended attribute content you have added, and you will need to develop your own strategy and scripts for migrating your extended attributes. ■ When you migrate to a new version of POI content provided from your content vendor, it is possible that the POI_ID values will change. Therefore, you may not be able to retain your existing POI child tables because their POI_ID foreign key values will be incorrect. You should take this into account when you develop your extended attributes migration strategy. If you need assistance with developing a content migration strategy, contact your Autodesk Professional Services representative.28 | Chapter 2 Points of Interest (POI) Content
  43. 43. 3Dynamic ContentThis chapter describes what dynamic content is, why it is used, In this chapterhow LocationLogic applications can access it, and how to set up ■ Overview ■ Accessing dynamic contentLocationLogic to incorporate dynamic content. ■ Setting up LocationLogic for dynamic content ■ Using subscriptions 29
  44. 44. Overview Dynamic content is data that frequently changes, such as traffic incidents or weather. It is provided from a content vendor, such as Tele Atlas, and is updated in real-time as conditions change. LocationLogic applications can use dynamic content in a variety of ways, including ■ Notifying individual users about traffic incidents along a route ■ Notifying individual users about weather conditions in their area ■ Maintaining websites to inform groups of users about interests they have in common, such as city-wide traffic information ■ Tracking mobile objects, such as LocationLogic users, service personnel, and fleet equipment LocationLogic uses a dynamic content adapter to translate the dynamic content from the content vendor’s format to the internal LocationLogic format. LocationLogic maintains that data in the LocationLogic database, inserting, updating, and deleting the data in response to real-time data changes received from the content vendor. LocationLogic uses dynamic content subscriptions to manage user requests for notifications about dynamic content, such as traffic, weather, and so forth, that occur along a predetermined route (such as “My work-to-home”) or at a predetermined location (such as “San Francisco” or “Home”). To set up LocationLogic (and the LocationLogic database) to manage dynamic content, you configure a content topic—a pointer to the LocationLogic database where the dynamic content from a particular vendor, or for a particular subscription, is stored. In general, a content topic maps to a specific feature category in the LocationLogic database. The following sections provide details about adding and using dynamic content in your LocationLogic application: ■ “Accessing Dynamic Content” on page 31 ■ “Setting Up LocationLogic for Dynamic Content” on page 32 ■ “Using Subscriptions” on page 5330 | Chapter 3 Dynamic Content

×