The Route Planning application provides the following methods of accessing data that can be used for routing: a via the set of topologically connected Links for an application-specified
Abbreviations
BTPD Branded Third Party Data (subset of Third Party Data – TPD)
ITRF International Terrestrial Reference Frame
PSF Physical Storage Format (the ISO entity defined by this Technical Specification)
RDS-TMC Radio Data System-Traffic Message Channel
VICS Vehicle Information and Communication System
Syntax notation used in data model diagrams
Figure 1 — Example for Data Model Notation
⎯ Entity (any logical data entity);
⎯ Binary Relationship (any relation between two entities);
⎯ Ternary Relationship (any relation between three entities);
⎯ Connector (notation component to connect entities with a relationship valence qualified by a number);
⎯ Relationship Attribute (qualifies a relationship in more detail);
⎯ Data Model Part (a conceptual sub-unit of the whole model)
In an N-to-M binary relationship, as illustrated in Figure 1, entities A and B are connected through a relationship attribute X This type of relationship signifies that A can relate to multiple instances of B, indicated by "M," while B can also relate to multiple instances of A, denoted by "N." It is important to note that the variables "N" and "M" do not imply uniform correspondence; not every A is linked to the same number of B's, nor does every B correspond to the same number of A's.
In a Logical Data Model, the relationship between two variables, N and M, highlights that there is no direct correspondence between the number of B’s per A and the number of A’s per B This N-to-M relationship does not guarantee that functions will exist to retrieve corresponding values in both directions Specifically, while a function may exist to find B’s for a given A, the 1-to-M relationship suggests that this function could return multiple B’s for a single A Conversely, the N-to-1 relationship indicates that a single B may be associated with multiple distinct A’s across different function calls.
In relationships characterized as 1-to-1, 1-to-N, or N-to-M, individual entities may not always participate fully, with some having fewer corresponding entities For instance, in a 1-to-N relationship between Links and Shape Points, one Link can have multiple Shape Points, but each Shape Point corresponds to only one Link Notably, a Link may have no Shape Points at all, despite the potential for multiple associations To simplify notation, we will not explicitly denote cases like “{0, 1}-to-{0, 1, …, N}”.
Ternary relationships involve three entities, exemplified by an M-to-1-to-N relationship among B, C, and D In this context, the valence M on B signifies that for a chosen C and D, multiple B's can correspond to them, without guaranteeing the same number of B's for different C and D pairs Similarly, the valence N on D indicates that for a selected B and C, multiple D's can correspond, again with no assurance of uniformity across different B and C selections The distinct variables N and M highlight the lack of correlation between the number of B's for a fixed C and D, and the number of D's for a fixed B and C Lastly, the valence 1 on C denotes that for a specific B and D, there can be at most one C that corresponds to them.
In ternary relationships, the presence of multiple valences does not guarantee that all functions will operate in every direction For instance, if only the function that returns D's given B and C is defined, the valences can be interpreted as follows: the "N" on D indicates that multiple D's may correspond to a specific B and C; the "M" on B suggests that for a fixed C and D, there could be several B's that yield D; and the "1" on C signifies that for a specific B and D, there is at most one C that will return D.
Binary relationships shall be drawn in solid lines, while ternary relationships shall be drawn in dashed lines
Positioning
The Positioning function identifies the location of road network entities, such as latitude and longitude, and is essential for Map Matching Map Matching involves determining the navigation system's current position within the road network by analyzing its previous location and integrating motion data from external sources.
Positioning involves determining the location and orientation of a navigation system in relation to a transportation network, utilizing map data that reflects the real world This process allows the navigation system to dynamically ascertain its current position while in motion Additionally, Map Matching operates continuously in the background, ensuring that the navigation system consistently maintains awareness of its location, even while executing other functions Note that the specifics of Map Matching algorithms are not covered in this document.
To enhance positioning within the Roads and Ferries theme, several key functions are essential: a) providing a single set of coordinates for a specified Point Feature; b) offering a collection of Edges, Nodes, and/or Intermediate Points for a designated Feature or connected Features; c) identifying topologically connected Features related to a specified Feature; d) delivering coordinates for a specified Line Feature along with a percentage of the distance; e) outlining Features, Edges, Nodes, and/or Intermediate Points within a defined rectangle; f) detailing positioning-related Attributes, Conditions, and Relationships, such as Prohibited Maneuvers and Direction of Traffic Flow; and g) determining the entry and exit angles for Transportation Elements linked to a specified Feature.
The API will enable users to specify a rectangular pre-fetch area for Positioning data retrieval and will support a single, global latitude/longitude-based coordinate reference system The International Terrestrial Reference Frame (ITRF) is selected for its international maintenance and its equivalence to WGS84, with a difference of less than 1 meter Additionally, the Tokyo datum will be permitted in datasets from Japan and Korea due to its widespread use in local navigation applications Only one coordinate system may be utilized per storage medium, and the coordinate system identification will be provided through a meta-data identifier The API will facilitate the retrieval of both the coordinate system identifier and the coordinates stored in the media.
5.1.3 Interaction of Positioning and other Application Categories
Positioning technology can supply location data to various applications, enabling them to track progress along a route and offer maneuver instructions to users at key points Additionally, it helps determine if the navigation system has deviated from the intended path.
An application utilizes the navigation system's current position to calculate routes to requested destinations, scroll through displayed maps, and select services based on geographic proximity It also shows the navigation system's position on a map and displays the surrounding area relative to its current location Additionally, positioning may incorporate planned route information from the Route Planning application for effective Map Matching.
5.1.4 Requirements for Logical Data Model
The Logical Data Model must support the data outlined in the Function Description, with specific requirements including access to only the lowest level of data and data from the Roads and Ferries theme Positioning data should be organized into non-overlapping parcels, and to reduce the number of parcels accessed, any link that crosses into a parcel must be represented within that parcel Additionally, parcels should be accessed via their bounding rectangles to facilitate fast spatial access.
Access to metadata is required in order to identify the geodetic system of the coordinate data in the database
For the requirements of this subclause, see 5.2.7.
Route Planning
The Route Planning function is used to determine routes from one user-specified location to another
Navigation applications calculate routes based on transportation network attributes, allowing users to specify criteria such as "shortest distance" or "no highways." Users indicate a departure point, which can be the current location, and select a destination along with possible waypoints to calculate a suitable route Routing capabilities extend beyond automobiles, supporting various modes of transport, including rail, water ferries, taxis, and routes accessible by bicycle or foot, with potential future inclusion of other public transportation options.
The route calculation algorithms are outside the scope of this functional description
To enhance data access speed, the Logical Data Organization categorizes transportation features into hierarchical levels, with higher levels representing more significant features such as highways and main roads These features can be aggregated, and correspondences between different levels will be accessible to the application The specified functions in the requirements enable selection based on these levels.
The Route Planning application offers various methods for accessing routing data, including: a) utilizing topologically connected Links at specified levels; b) retrieving routing-related Attributes for specific Transportation Elements, such as Node Coordinates, Measured Length, Functional Road Class, Number of Lanes, Average Speed, and access characteristics; c) accessing navigation attributes for Roads and Intersections; d) identifying corresponding Links at different levels; e) using topologically connected GDF Roads at specified levels; f) working with GDF Road Elements and GDF Junctions; g) referencing specific GDF Road Elements or Junctions; h) accessing corresponding entities for GDF Junctions or Intersections at different levels; i) considering effective time or date periods for various Conditions; and j) utilizing location references stored in the database for specified Transportation sets.
The article discusses the use of Transportation Elements linked to a specific location reference stored in a database, as well as the entry and exit angles for Links associated with a designated Intersection.
Junction; m) via historic and forecast traffic conditions, incidents, and events information for a specified Transportation
The transportation system must include a Data Access Layer (DAL) that offers transparent access to both static and dynamic traffic information, without mandating the integration of external dynamic traffic data Additionally, it should provide an API that enables users to specify a pre-fetch area of interest, defined by feature ID or a rectangular boundary, for retrieving Route Planning data at a level determined by the application.
5.2.3 Interaction of Route Planning and other application categories
The Route Planning application seamlessly integrates with other application categories by accepting data from the Positioning application to calculate routes from the current location to the desired destination Additionally, it communicates the planned route back to the Positioning application to assess if the navigation system has deviated from the intended path.
The Route Planning application plays a crucial role in navigation by supplying the Route Guidance application with details about the planned route for generating driving instructions Additionally, it collaborates with the Services and POI Information Access application to identify services located near the route When determining end-points or way-points, the Route Planning application also accepts input from the Services and POI Information Access and Address Location applications Furthermore, it provides the Map Display Application with route information to visually represent the planned course on a graphical map.
5.2.4 Requirements for Logical Data Model
The logical data model must support the data outlined in the function description, focusing solely on the Roads and Ferries theme It requires that enclosed traffic areas be represented by links and nodes, with parcel shapes at a given level contained within a single higher-level parcel, ensuring no overlap among same-level parcels For effective route planning, references to parcels at the same and adjacent levels are necessary, and parcels may vary in coverage sizes for optimal filling Route planning data should not include intermediate points for link representation but must detail turn angles, link lengths, and costs Additionally, there is no need for extra nodes at parcel boundaries, and links crossing these boundaries should be stored within the parcels they connect to Fast access to parcels will be facilitated through their bounding rectangles, while a separate computation will identify nodes or links corresponding to origin, intermediate, and destination points, which is beyond the scope of this Technical Specification.
The logical data model entities used in Route Planning are described below Entities of these types are stored in parcels and uniquely identified with database IDs
The logical data model entities used in Route Planning are described below in alphabetical order
The Complex Intersection entity stores data about generalized road crossings, incorporating Links and Nodes related to internal elements like dual-carriageway sections, slip lanes, and roundabouts This entity also includes navigation attributes and aligns with the concept of GDF Intersections.
The Complex Road entity is used to store information about a (generalized) topological connection between Complex Intersections, including navigation attributes It corresponds to the concept of GDF Roads
The Condition entity stores information about restrictions or attributes related to a maneuver, including a condition type that defines the record's content and modifier fields for additional details Conditions can apply to a single link or a series of connected links, known as a maneuver For instance, a toll cost condition pertains to a single link, while a prohibited driving maneuver condition involves two or more connected links.
The Condition entity includes scope information detailing which lanes of the link are impacted and the types of vehicles affected by the condition Additionally, it may encompass further relevant details.
Validity Period which defines the time during which the condition is in effect
The Link entity stores information about Road Elements and Transportation Elements, which include Roads, Ferries, and Ferry Connections It contains identifiers for the link's end nodes and a set of navigation attributes These attributes are essential for applications to calculate a weighting factor for the link during route planning.
There are two types of link entities: Regular Links and SuperLinks
⎯ Regular Links are the fundamental units of the navigable road network They contain two (and only two) nodes, one at each end;
At route calculation levels above level 0, certain Links can be combined into SuperLinks, which serve to simplify the road network representation and enhance the speed of route calculations A SuperLink consists of a group of linearly connected links that share similar characteristics.
The Node entity serves as a crucial connection point within the transportation network, acting as a topological junction where two or more links converge or where a link terminates It also retains the coordinate values of the associated junction.
The API will allow the retrieval of the number of Route Planning functional levels for a dataset, and provide information as to which roads are contained in each level
The Extended Parcel Exposing Functions include two key operations: first, for a specified level, rectangle, and entity type (such as a link), it retrieves a list of parcel IDs that contain elements of the specified type and are located either entirely or partially within the rectangle Second, for a given parcel ID, it provides detailed parcel information, including the level, bounding box, data size, cache availability, a list of overlapping parcels at the next lower level, and a list of overlapping or abutting parcels at the same level.
Route Guidance
The Route Guidance function is used to generate instructions for following a route
The Route Guidance feature provides detailed, step-by-step navigation instructions, incorporating compass headings, distances, road names, signage, landmarks, and visual aids It also offers specific maneuver details, including turn angles, merges, and changes in road names Users can receive Route Guidance through text, voice, or graphical representations.
Route Guidance offers various methods to access data essential for route navigation, including guidance-relevant features and relationships linked to specific Transportation Elements These elements may encompass intersecting Road Elements and Signpost Information.
The Transportation Element encompasses various conditions and landmarks, including attributes like road names, lengths, traffic flow directions, and forms of way It specifies whether a junction is part of an intersection and categorizes links as regular, superlinks, or components of superlinks Additionally, it identifies connected transportation elements for both specified junctions and intersections, including road elements linked to roundabouts.
Roundabouts are composed of various elements and junctions, including data on the transition from a specified link to a series of connected links, such as tollbooths or gates Additionally, node and intermediate point positions for line features are essential for displaying maneuver arrows that aid in route guidance Cartographic data for line features is also crucial for creating intersection schematics, while entry and exit angles for transportation elements connected to a specified application further enhance the functionality of roundabouts.
The application utilizes phonetic strings in a specified language to provide pronunciation for named entities and commonly used guidance words It also incorporates digitized pronunciation data for these guidance words Additionally, an API is available to retrieve Route Guidance data within a user-defined rectangular area of interest, and optional picture guidance is offered through image data.
5.3.3 Route Guidance and Positioning Interaction
The Route Guidance application can enhance navigation by receiving input from other applications, enabling it to offer real-time guidance based on a calculated route and map matching It effectively tracks the user's progress along the route and delivers maneuver instructions at key points, ensuring a smooth navigation experience.
5.3.4 Map Display and Route Guidance Interaction
The application may highlight the point on a displayed map of a particular routing manoeuvre (from a calculated route)
5.3.5 Requirements for Logical Data Model
The Logical Data Model must accommodate the data specified in the function description, with additional requirements including the organization of Route Guidance data into Parcels To ensure quick access, these Parcels should be retrievable by their bounding rectangles Furthermore, to achieve optimal Parcel filling, varying coverage area sizes may be utilized.
The Logical Data Model entities used in Route Guidance are described below
The logical data model entities for Route Guidance are described below in alphabetical order
The Landmark entity serves to connect a Link or Node with various Point, Line, or Area features, enhancing the clarity of directions generated for route descriptions It encompasses essential features that aid in navigation.
The article discusses the identification of Point, Line, or Area Features associated with a Link or Node, detailing their specific locations in relation to these elements It is important to note that landmarks are not considered features within the Services.
Administrative Areas or Public Transportation Feature themes However, a facility in which a service is located may be a landmark
The Signpost entity establishes a logical connection between two Links and the relevant signpost information The first link, a mandatory component, denotes the Road Element where the signpost is situated, including its position and the direction it faces The second link, an optional component, corresponds to the destination indicated on the signpost, representing the initial Road Element that leads directly to that destination, such as a city Additionally, the Signpost entity features the Signpost Content attribute.
This attribute describes the content of signposts, including geographic names, road numbers, directional arrows, and pictograms like the airport symbol It represents a specific combination of two links: one for the signpost's location and another for the information the signpost directs to.
A physical signpost may contain multiple instances of the signpost content attribute for different directions and different languages
The API offers access to essential Metadata information, including the character set for data representation, the phoneme set for phonetic data, the binary format for digitized sounds, the supported languages in the database, the traffic side in specific regions, and the file formats used for still and motion image data.
For the requirements of this subclause, refer to 5.2.7.
Map Display
The Map Display function enables the visualization of a specific geographic area, allowing applications to present maps to users Additionally, it supports user interactions, such as input from point-and-click devices, to enhance the map display experience.
An application can showcase various geographic elements such as Points Features, Lines Features, Areas Features, Cartographic Text, and Symbols within a designated area This includes representations of roads, physical landmarks, administrative boundaries, and their corresponding names Additionally, text and symbols can be strategically placed on the map to provide clear annotations.
The Map Display function offers cartographic data for visualizing maps within any application-defined rectangle from the database This data includes essential entities such as Cartographic Features, Cartographic Text, and Symbols, enabling diverse map drawing styles.
The application enables users to zoom in and out on the map, displaying varying levels of detail based on the zoom level It also allows for map rotation and scrolling, automatically zooming out when detailed data is unavailable Users can access additional information by selecting objects on the display, and the application supports multiple windows However, generating map images and managing displays are not included in this functionality.
This application enhances data access speed by organizing cartographic data into hierarchical levels, where higher levels feature only the most significant cartographic elements Users can also select cartographic data based on these levels.
Map Display offers various methods for accessing data, including: a) retrieving Cartographic Features, Text, and Symbols within a specified rectangle, level, and feature type; b) using coordinates for specific Cartographic Features; c) accessing attributes like feature type, name, and functional classification; d) obtaining complete or partial Cartographic Features linked to specified Transportation Elements; e) querying based on the area size of a specified Area Feature; f) retrieving additional information for Point, Line, and Area Features associated with selected Cartographic Features; g) accessing Cartographic Text related to a Cartographic Feature; h) obtaining Symbols linked to a Cartographic Feature; i) returning Cartographic Features and Text in draw-order; and j) distinguishing between "off the map" and "no data at this location at this level" when no map data is available Additionally, k) the API allows for specifying a pre-fetch area of interest defined by a rectangle and application-specified level for retrieving Map Display data.
5.4.3 Interaction between Map Display and other Application Categories
There are interactions in both directions between Map Display and other application categories
5.4.3.1 Other inputs used for Map Display
An application can enhance user experience by displaying a map at the navigation system's current location and marking it with a location indicator As the navigation system moves, the map automatically scrolls to keep the marker in view Users can also select any location on the map, whether by entering an address, choosing an intersection, or using the cursor The application provides detailed information, including latitude, longitude, and street addresses for points selected on the display Additionally, it highlights routes and specific points related to routing maneuvers, ensuring users have clear navigation guidance.
5.4.3.2 Services provided by Map Display for other Application Categories
This function offers various methods for accessing data applicable to different categories of applications Firstly, it provides cartographic data for selected line features, enabling applications like Route Guidance to emphasize specific routes and line features The cartographic data encompasses display class, speed limit, number of lanes, line feature attributes, and intermediate points Secondly, it allows for the retrieval of information on features selected from a displayed map, which can be utilized by other applications, such as selecting a destination for Route Planning.
5.4.4 Requirements for Logical Data Model
The logical data model must support the data outlined in the function description, with specific requirements including multiple levels of cartographic data for varying map scales, where higher levels feature generalized details for line and area features It is essential to provide access to all GDF Feature Themes, along with their attributes and conditions Additionally, map display data should be organized into rectangular Parcels for easy identification, and any links that cross Parcel boundaries must be cut at those boundaries To reduce the number of Parcels accessed, any link entering a Parcel, regardless of whether it has a node or intermediate point within, should be represented within that Parcel.
The following are the requirements for logical data model entities for the Map Display application category
The Cartographic Feature entity consists of three types – the Display Point, Polyline, and Polygon entities
The Display Point type is utilized to depict Services, Signposts, and various point features, including toll booths Depending on the degree of generalization, a Display Point can also represent additional features.
⎯ The Polyline type is used to represent Line Features such as Road Elements and Railway Elements
A cartographic polyline does not necessarily correspond to a single Road Element or Line Feature
A Polyline can represent an Area Feature based on the level of generalization In Map Display data, topological connectivity is not significant, allowing a single cartographic Polyline to correspond to multiple Line Features, as illustrated in Figure 2.
The Polygon type is utilized to represent area features like parks and lakes To facilitate polygon filling, the coordinates for the outer boundary of the polygon are returned in a fixed order.
Figure 2 — Example of polyline representation
An Area Feature may be represented as multiple Polygons A Line Feature may be represented as multiple
Polylines If a feature is split, new points are created and, for polygons, new boundary lines are added to close it (see cartographic feature polygon example in Figure 3)
2 lake a Lake is split and closed
Figure 3 — Representation of a split area feature
Each virtual entity possesses unique attributes that define its specific characteristics, such as position, line width, color, fill pattern, and icon These attributes equip the application with essential information to determine how the entity is displayed.
The Cartographic Text entity stores the name text linked to cartographic features, including details such as suggested location, orientation, language code, priority, scale ranges, and a bounding box for positioning on the map These entities are language-dependent, allowing multiple Cartographic Text entities to be associated with the same feature for different languages.
There is a many-to-many relationship between Cartographic Text entities and Cartographic Features
A symbol is a graphic associated with a cartographic feature
Metadata serves several essential functions, including specifying the number of cartographic levels in a dataset, indicating the appropriate scale factor range for each level, and detailing the contents associated with each level.
For the requirements of this subclause, refer to 5.2.7.
Address Location
This function is used to access data that are used to determine positions, both on the earth and in the map data representation of the earth
Address location involves identifying a specific place using descriptive information or names associated with that location Applications can ascertain locations through various data types, such as addresses or nearby cross-streets There are two primary methods for determining address locations.
⎯ Geocoding: determining a link or a node, or a polygon or representative point by its address description
⎯ Reverse geocoding: determining an address description of a link or node or representative point or area
End users or applications often lack full knowledge of a location's specifications, such as the complete address or administrative area Additionally, they may be uncertain about the classification of a street, whether it is designated as a "street" or another type.
“avenue” They may need to search the database based on the information they do know, and examine a set of locations matching their criteria
Address locations can accommodate various entry orders through suitable data structures Generally, a hierarchical top-down entry order is employed, but alternative arrangements, such as prioritizing street names, are also supported.
When no matches are found, the Address Location feature can enhance search criteria by allowing users to expand their search area, including nearby locations or accommodating variations in spelling for names that sound or look similar.
For any search that queries names (street/place/intersection/junction), return the language code and the name-type attributes (official or alternative name) for the name
Language codes may be specified when retrieving names
The PSF and the API shall support access to full names as well as official abbreviations of names
This function offers various methods for accessing places, including retrieving all child places for a specified place and child place classes, with options for spatial restrictions and name matching It also allows for obtaining parent places based on specified parent place classes and name qualifications Users can find unique successor characters for partially spelled place names within a parent place, as well as obtain latitude/longitude boundaries for specific places Additionally, the function can return child places associated with a navigable feature name, external location references, and attributes of specified places It supports querying all places within a defined class in the address tree without needing to join separate tables, as defined by metadata Furthermore, users can retrieve polygonal cartographic features and representative points for specified places within a defined rectangle.
Support for methods k) and l) is optional based on place class and geographic region as determined by the data supplier Nevertheless, both the API and the PSF are required to support these methods, and a DAL must accommodate the data if it is available.
To retrieve street names from a specified list of places, one can utilize various search criteria This includes filtering by a defined rectangle, phonetic representations, or partial/full spelling matches of street names For instance, searching for "Kennedy" can yield "John F Kennedy Street." Additionally, users can obtain house number ranges and road elements for specific street names within the selected places Crossroads involving the specified street can also be identified, with options to sort them alphabetically or sequentially based on driving order For partially spelled street names, unique immediate successor characters can be returned, and all street names within a specified rectangle can be listed Furthermore, users can obtain street names in alphabetical order that match a given partially spelled name, as well as those preceding and including the matches.
5.5.4.3 Intersection and junction name searches
Retrieve a list of intersections or junctions for designated locations, applying specific search criteria These criteria include: a) spatial qualification within a defined rectangle; b) phonetic representation of intersection or junction names; c) street name of a road element, such as Exit 50 of Interstate 4; and d) matching the beginning of intersection or junction names or individual words within those names.
“John D Rockefeller Plaza” can also be found when searching by “Rockefeller”;
For a partially spelled intersection or junction name, along with an optional specified place, the system will return a set of unique immediate successor characters that match the given name Additionally, when a specific junction or street name is provided, it will deliver a combined view of street and junction names that include the specified name, eliminating the need for the application to merge separate lists.
This function offers several methods for accessing postal codes: it can return a list of road elements, navigable feature names, and places associated with a specified postal code Additionally, it provides valid postal codes for a specified place, navigable feature name, or road element.
This function offers several methods to locate specific points: a) it can identify a location by matching a street name and house number within a designated area, returning all matching locations if the combination is not unique; b) it can determine intersections of road elements by using a pair of street names in a specified area, providing data for all intersections if the streets cross at multiple points; c) it can locate a specific named intersection or junction within a given place.
When a specified name and location are not unique, all corresponding intersections or junctions are returned This can be done through a set of line features for a specific location, such as a block (banchi) in Japan, or by utilizing both line and point features within a defined bounding rectangle.
5.5.4.6 Partly overlapping features at different levels
The PSF and API will facilitate the representation and access of address location features, including both place and street features, which may be situated across multiple locations within a higher level of the address hierarchy.
The PSF and API will enable the identification of the specific segment of the address location feature that corresponds to the next higher level in the address hierarchy, particularly in cases where it holds significance for the address.
The following two cases are distinguished: a) one of the above-mentioned Address Location features partly covering multiple places;
EXAMPLE El Camino Real, San Francisco Bay Area b) multiple Address Location features, all having the same name, each located in a different place
The PSF will accommodate the specified cases, with the understanding that data content availability is optional The data supplier is responsible for defining the criteria that constitute a single Address Location feature.
The API shall offer access to the information and it has to be able to handle the optional availability of the information
Service and POI Information Access
The Service and Points-of-Interest (POI) Information Access function offers essential data for travelers, identifying common origins and destinations for routes This includes traveler-related commercial services like hotels, restaurants, and gas stations, as well as notable locations such as national parks and tourist attractions Services are categorized by type, such as airports or city centers, and may include various attributes like ratings, cuisine types, and accepted payment methods.
Third Party Data (TPD) is valuable traveler information provided by organizations like tourist or motoring groups, offering insights that may interest users The extent of this service information can vary, encompassing comprehensive data related to locations and connections to the road network However, some TPD may come from sources with proprietary restrictions, known as Branded Third Party Data (BTPD), which imposes additional usage requirements.
An application can deliver Service data to end-users and facilitate various functionalities such as Address Location, Route Planning, and Map Display It may also provide details about Services, including Third Party Data (TPD) Users can select Services based on types, geographic areas (like within a rectangle or a certain distance from a point), and specific places (such as Administrative Areas, Districts, or Postal Areas) Additionally, Services can be linked to Road Elements or other components of the Transportation Network, offering a precise location on a road element that grants access to a Service.
Searches for Services can be refined by matching either a partial or full spelling of the Service type, attribute, or name, including any individual word within these categories.
Services can be interconnected, with a primary Service referred to as a parent This parent Service can have multiple secondary Services known as child Services, and conversely, a child Service may also be linked to several parent Services For instance, an Airport Service can encompass various Parking Lots, illustrating this relationship.
In this case, the Airport is designated as the parent Service and the Parking Lots are designated as children of that parent
A service can be linked to several locations For instance, the Dallas/Fort Worth Airport is situated in Arlington and Grapevine, while also being logically connected to the cities of Dallas and Fort Worth.
Service and POI Information Access will utilize various data structures to accommodate different entry orders While a hierarchical top-down entry order is commonly employed, alternative arrangements, such as prioritizing the POI brand name, will also be supported.
Service and POI Information Access will enhance search capabilities by allowing users to expand their search criteria when no matches are found Users can request a broader search area, including nearby locations, or apply spelling tolerance for names that are similarly pronounced or written.
Service data can be accessed through various methods, including: a) retrieving application-specific Service attribute data such as name, address, phone number, chain, facility type, and operating hours; b) using the coordinates of a specified Service; c) identifying related Road Elements and their positions for accessing a specified Service; d) exploring related Services of a specified Road Element; e) examining Services within a defined set of places; f) analyzing Services within a specified set of rectangles; g) finding Services that match the beginning of the Service name based on partial or full spelling; and h) obtaining Services that satisfy any combination of specified criteria.
⎯ an application-specified string which matches the full, partial, or phonetic spelling of the Service name The application specifies whether a partial, phonetic or complete match is required,
Application-specified values of a service attribute can serve as selection criteria defined by metadata Multiple criteria of this nature can be combined using the AND operator.
⎯ any of a set of application-specified Service types,
⎯ the union of an application-specified set of places,
⎯ the union of an application-specified set of rectangles;
⎯ via the set of Services that are within an application-specified distance of an application-specified place;
⎯ via the selection of Services by relationships to other Services (parent-child relationships);
⎯ via the set of Service types for all Services which exist in an application-specified place;
⎯ for an application-specified place level, chosen from a set of place levels specified in metadata, via the set
⎯ via the set of attribute data values which exist for an application-specified attribute, for Services which meet application-specified criteria, based on availability specified in metadata;
⎯ via a Service given an application-specified external location reference;
⎯ for a given place, service type, and partially spelled service name, via retrieval of the next successor characters;
The application should display Service data in a consistent format with that of the Service data vendor, ensuring that all attributes and their corresponding values are accurately represented.
⎯ support the representation and retrieval of icons;
⎯ support the representation and retrieval of images, sound tracks, hyper-links, and other multi-media;
⎯ for a specified postal code, return the list of Services that have this postal code;
⎯ for a specified Service, return the list of postal codes that are valid for this Service
For any search that queries names, the Service shall return the language code and the name-type attributes (official or alternative name) for the name
Language codes may be specified when retrieving names
Third Party Data is considered a special type of service information All the functional requirements for Services apply to the special TPD type of services
For a specific real-world service, it is essential that multiple TPD entities from different vendors can be interconnected This capability relies on the availability of relevant data to establish these relationships.
An application can offer TPD (Transportation Product Data) to end users through various methods These include accessing TPD from a specified vendor that meets certain criteria, supporting multiple vendors simultaneously within the same database, and retrieving TPD from different vendors, which may vary in attributes and geographic coverage Additionally, users can identify the vendor for specific TPD items and access related transportation entities or TPD from a specified vendor for those entities.
The integration of TPD with the base map necessitates establishing a connection between TPD and transportation entities, which can be achieved through either direct relationships, such as IDs, or indirect relationships, like positional data Additionally, it involves identifying vendors that provide TPD services and recognizing a specified service entity, including TPD entities, that correspond to the same real-world object Furthermore, it allows for the identification of multiple TPD entities that represent the same real-world entity.
The BTPD will feature an API that enables access from multiple vendors on a single medium, contingent upon authorization or licensing It will include a function call that formats data to meet specific vendor requirements for symbology and presentation, such as HTML formatting Vendor-specific presentations will remain transparent to both the application and the Data Access Layer (DAL), allowing BTPD vendors to manage their presentations without needing to engage in DAL development This design enables DAL developers to create systems independent of various BTPD vendor presentations, with specifications for vendor-specific information stored on the media, typically provided by the TPD supplier Additionally, applications can query the BTPD for a defined set of attributes specified by the vendor, ensuring that these attributes remain transparent to both the DAL and the application, thus allowing for independent system development The semantic descriptions and formats of the queryable attributes will also be stored on the media.
Conceptually, the BTPD consists of three components (see Figure 7):
⎯ fielded BTPD records for the set of attributes to be queried on;
⎯ some form of metadata for each service type which describes the field contents, format, and range of values for the attributes which can be queried;
⎯ presentation data at least including the attributes not used for queries and formatting information
Figure 7 — Structure of BTPD 5.6.5 Requirements for the Logical Data Model
The Logical Data Model used for this application category is required to support at least the data identified in the functional description Other requirements are defined below
The Logical Data Model entity for Services and POI Information Access is described below