ISO 19133:2005

Geographic information - Location-based services - Tracking and navigation

ISO 19133:2005 describes the data types, and operations associated with those types, for the implementation of tracking and navigation services. It is designed to specify web services that can be made available to wireless devices through web-resident proxy applications, but is not restricted to that environment.

Information géographique — Services basés sur la localisation — Suivi et navigation

L'ISO 19133:2005 décrit les types de données ainsi que les opérations associées pour l'implémentation de services de navigation et de suivi. Elle est conçue, entre autres, pour spécifier des services web pouvant être accessibles à des dispositifs sans fil par le biais d'applications web proxy.

Geografske informacije - Storitve na podlagi lokacije - Sledenje in navigacija

General Information

• Status: Published
• Publication Date: 20-Oct-2005
• ICS: 35.240.70 - IT applications in science
• Technical Committee: ISO/TC 211 - Geographic information/Geomatics
• Drafting Committee: ISO/TC 211 - Geographic information/Geomatics
• Current Stage: 9093 - International Standard confirmed
• Start Date: 21-Mar-2022
• Completion Date: 13-Dec-2025
• Ref Project: oSIST ISO 19133:2006 - Geographic information - Location-based services - Tracking and navigation

Relations

• Consolidated By: ISO 20643:2005/Amd 1:2012 - Mechanical vibration - Hand-held and hand-guided machinery - Principles for evaluation of vibration emission - Amendment 1: Accelerometer positions
• Effective Date: 06-Jun-2022

Overview

ISO 19133:2005 - Geographic information - Location-based services - Tracking and navigation defines the data types and operations needed to implement tracking and navigation services for location‑based services (LBS). The standard is targeted at web service implementations (for example, web‑resident proxy applications serving wireless devices) but is not limited to that architecture. ISO 19133 specifies models for representing positions, movement, routing, cost functions and address/network information to support interoperable tracking and navigation solutions.

Key topics and technical scope

ISO 19133 organizes the tracking and navigation domain into well‑defined packages and topics, including:

• Tracking: semantics and service models for position reports, mobile subscriber representations, tracking locations, triggers (periodic, transition), and quality‑of‑position metadata.
• Point estimates & coordinate models: representations for point estimates (circle, ellipse, sphere, ellipsoid), measured coordinates and coordinate reference systems.
• Location transformation & linear referencing: mechanisms for transforming locations and representing linear reference systems (LRS) such as offsets, reference markers and expressions.
• Navigation: route request/response models, instructions, rendering services, and cost functions (time, distance, monetary costs, transfers, tolls, counts) used by routing algorithms.
• Network & routing model: formalization of network elements (links, turns, junctions), constraints/advisories, network positions and route definitions.
• Address model: structured address and address elements (street, postal code, intersection, named place) to support geocoding and location matching.
• Implementation support: basic feature/data model packages, test suites and informative annexes on graph algorithms and RM‑ODP service views.

Practical applications and users

ISO 19133 is practical for anyone building interoperable location services:

• LBS and mobile app developers implementing tracking, geofencing, and turn‑by‑turn navigation.
• Fleet management and telematics providers for standardized position reporting and routing.
• Transport and public transit agencies for route planning, transfers and cost modeling.
• Emergency services and asset tracking where accurate quality‑of‑position metadata and triggers are critical.
• GIS integrators and standards architects who need consistent models for coordinates, linear referencing and network data to integrate multiple systems.
  Benefits include improved interoperability, clearer semantics for position accuracy and triggers, and consistent routing/cost modeling for cross‑vendor services.

Related standards

• Related to the ISO 19100 series (geographic information standards) and complements web service and geospatial data standards used in LBS ecosystems. For implementation, combine ISO 19133 models with relevant coordinate reference, feature‑model and web service standards to achieve end‑to‑end interoperability.

Keywords: ISO 19133, location-based services, tracking and navigation, LBS, tracking service, navigation service, routing, cost function, network model, address model, linear reference system.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 19133
First edition
2005-10-15
Geographic information — Location-
based services — Tracking and
navigation
Information géographique — Services basés sur la localisation — Suivi
et navigation
Reference number
©
ISO 2005
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2005
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2005 – All rights reserved

Contents Page
Foreword. viii
Introduction . ix
1 Scope . 1
2 Conformance. 1
3 Normative references . 2
4 Terms and definitions. 2
5 Abbreviated terms and UML notation. 6
5.1 Abbreviated terms . 6
5.2 UML notation. 6
6 Tracking . 7
6.1 Semantics . 7
6.2 Package: Tracking Service . 7
6.3 Package: Point Estimates . 21
6.4 Package: Location Transformation. 26
6.5 Package: Measured Coordinates . 27
6.6 Package: Linear Reference Systems. 32
7 Navigation. 39
7.1 Semantics . 39
7.2 Cost Functions and algorithms. 41
7.3 Package: Navigation Service. 42
7.4 Package: Cost Function. 55
7.5 Package: Preferences. 68
8 Address Model . 70
8.1 Semantics . 70
8.2 Package: Address. 70
8.3 Package: Address Elements. 74
9 Network. 85
9.1 Semantics . 85
9.2 Package: Network Model . 85
9.3 Package: Turn and Junction. 89
9.4 Package: Constraint and Advisory . 95
9.5 Package: Link. 108
9.6 Package: Network Position. 111
9.7 Package: Route . 112
9.8 Package: Combined Networks . 117
10 Basic implementation packages . 120
10.1 Package: Feature Data Model. 120
10.2 Package: New Basic Types. 124
Annex A (normative) Abstract test suite. 127
Annex B (informative) Directed weighted graphs and their algorithms . 134
Annex C (informative) View of Standard in terms of RM-ODP Services. 137
Bibliography . 139
Figures
Figure 1 — Tracking packages . 7
Figure 2 — Context Diagram: TK_Position . 8
Figure 3 — Context Diagram: TK_MobileSubscriber . 9
Figure 4 — Context Diagram: TK_TrackingLocation. 10
Figure 5 — Context Diagram: TK_TrackingService. 11
Figure 6 — Context Diagram: TK_PositionType . 12
Figure 7 — Context Diagram: TK_TrackingLocationSequence . 13
Figure 8 — Context Diagram: TK_Trigger . 14
Figure 9 — Context Diagram: TK_PeriodicTrigger. 15
Figure 10 — Context Diagram: TK_TransitionTrigger. 16
Figure 11 — Context Diagram: TK_TrackingLocationMetadata. 17
Figure 12 — Context Diagram: TK_Transition . 18
Figure 13 — Context Diagram: TK_QualityOfPosition . 19
Figure 14 — Context Diagram: TK_Accuracy . 20
Figure 15 — Context Diagram: TK_AccuracyStatement. 20
Figure 16 — Point Estimate classes. 21
Figure 17 — Geometric interpretations of point estimate types . 22
Figure 18 — Context Diagram: EG_PointEstimateCircle .22
Figure 19 — Context Diagram: EG_PointEstimateEllipse . 23
Figure 20 — Context Diagram: EG_PointEstimateArc . 24
Figure 21 — Context Diagram: EG_PointEstimateSphere. 25
Figure 22 — Context Diagram: EG_PointEstimateEllipsoid . 26
Figure 23 — Context Diagram: LT_LocationTransformationService. 27
Figure 24 — Measure Position. 28
Figure 25 — Measured Coordinate Systems. 29
Figure 26 — Context Diagram: MC_MeasurePosition. 30
Figure 27 — Context Diagram: MC_CoordinateSystem. 30
Figure 28 — Context Diagram: MC_CoordinateReferenceSystem . 31
Figure 29 — LRS classes . 32
Figure 30 — Context Diagram: LR_PositionExpression.33
Figure 31 — Context Diagram: LR_LinearReferenceMethod . 35
Figure 32 — Context Diagram: LR_OffsetDirection. 35
Figure 33 — Context Diagram: LR_ReferenceMarker . 36
Figure 34 — Context Diagram: LR_Feature. 37
Figure 35 — Context Diagram: LR_Element. 37
Figure 36— Context Diagram: LR_OffsetExpression. 38
Figure 37 — Navigation Packages. 39
Figure 38 — Example of route from one link position to another. 40
iv © ISO 2005 – All rights reserved

Figure 39 — Services. 42
Figure 40 — Context Diagram: NS_NavigationService. 43
Figure 41 — Context Diagram: NS_RouteRequest. 46
Figure 42 — Context Diagram: NS_Instruction. 48
Figure 43 — Context Diagram: NS_InstructionList . 49
Figure 44 — Context Diagram: NS_RouteResponse. 50
Figure 45 — Context Diagram: NS_CostedTurn. 51
Figure 46 — Context Diagram: NS_RenderingService .51
Figure 47 — Context Diagram: NS_RenderingRequest . 52
Figure 48 — Context Diagram: NS_RenderingResponse. 53
Figure 49 — Context Diagram: NS_RenderingType. 53
Figure 50 — Context Diagram: NS_CostedLink . 54
Figure 51 — Context Diagram: NS_CostFunctionCode. 54
Figure 52 — Context Diagram: NS_RouteRequestType . 55
Figure 53 — Context Diagram: NS_CostFunction. 59
Figure 54 — Context Diagram: NS_CostElements . 59
Figure 55 — Context Diagram: NS_MonetaryCost . 60
Figure 56 — Context Diagram: NS_Tolls. 61
Figure 57 — Context Diagram: NS_Fares. 61
Figure 58 — Context Diagram: NS_Time. 62
Figure 59 — Context Diagram: NS_TravelTime . 62
Figure 60 — Context Diagram: NS_WaitingTime. 63
Figure 61 — Context Diagram: NS_Counts. 64
Figure 62 — Context Diagram: NS_NumberManeuvers. 64
Figure 63 — Context Diagram: NS_NumberTurns . 65
Figure 64 — Context Diagram: NS_NumberTransfers .65
Figure 65 — Context Diagram: NS_Distance . 66
Figure 66 — Context Diagram: NS_WeightedCost. 67
Figure 67 — Context Diagram: NS_CostFunctionTerm . 68
Figure 68 — Context Diagram: NS_RoutePreferences .68
Figure 69 — Context Diagram: NS_AvoidList. 69
Figure 70 — Leaf packages of the Address Model. 70
Figure 71 — Basic Address classes . 71
Figure 72 — Context Diagram: AD_Address. 72
Figure 73 — Context Diagram: AD_AbstractAddress. 72
Figure 74 — Context Diagram: AD_USAddress . 74
Figure 75 — Context Diagram: AD_AddressElement .75
Figure 76 — Context Diagram: AD_Addressee . 76
Figure 77 — Context Diagram: AD_StreetIntersection . 76
Figure 78 — Context Diagram: AD_Street. 78
Figure 79 — Context Diagram: AD_PostalCode . 79
Figure 80 — Context Diagram: AD_StreetLocation. 79
Figure 81 — Context Diagram: AD_PhoneNumber. 80
Figure 82 — Context Diagram: AD_NamedPlace. 81
Figure 83 — Context Diagram: AD_StreetAddress. 82
Figure 84 — Context Diagram: AD_NamedPlaceClassification . 82
Figure 85 — Context Diagram: AD_Building. 83
Figure 86 — Context Diagram: AD_MuniQuadrant. 83
Figure 87 — Context Diagram: AD_RegionCode . 84
Figure 88 — Context Diagram: AD_NumberRange. 85
Figure 89 — Context Diagram: AD_ListNamedPlaces .85
Figure 90 — Context Diagram: NT_Network . 86
Figure 91 — Context Diagram: NT_WayPoint . 87
Figure 92 — Context Diagram: NT_WayPointList. 88
Figure 93 — Junction and turns . 89
Figure 94 — Context Diagram: NT_Turn. 92
Figure 95 — Context Diagram: NT_TurnDirection. 92
Figure 96 — Context Diagram: NT_Junction. 94
Figure 97 — Context Diagram: NT_JunctionType . 95
Figure 98 — Context Diagram: NT_AngularDirection . 95
Figure 99 — Context Diagram: NT_Constraint. 96
Figure 100 — Context Diagram: NT_VehicleConstraint. 98
Figure 101 — Context Diagram: NT_TemporalConstraint . 99
Figure 102 — Context Diagram: NT_LaneConstraint . 100
Figure 103 — Context Diagram: NT_Vehicle . 101
Figure 104 — Context Diagram: NT_Advisory . 102
Figure 105 — Context Diagram: NT_SpatialRelation. 103
Figure 106 — Context Diagram: NT_AdvisoryCategory . 104
Figure 107 — Context Diagram: NT_AdvisoryElement . 104
Figure 108 — Context Diagram: NT_ExitAssociation. 105
Figure 109 — Context Diagram: NT_AdvisoryDirection . 106
Figure 110 — Context Diagram: NT_AdvisoryDistance . 107
Figure 111 — Context Diagram: NT_AdvisorySpatialRelation . 107
Figure 112 — Context Diagram: NT_Link . 110
Figure 113 — Context Diagram: NT_RouteSegmentCategory . 110
Figure 114 — Context Diagram: NT_LinkPosition. 111
Figure 115 — Context Diagram: NT_NetworkPosition . 112
Figure 116 — Context Diagram: NT_Route . 114
Figure 117 — Context Diagram: NT_RouteSummary. 115
Figure 118 — Context Diagram: NT_Maneuver. 117
vi © ISO 2005 – All rights reserved

Figure 119 — Combined Networks . 117
Figure 120 — Context Diagram: NT_CombinedNetwork . 118
Figure 121 — Context Diagram: NT_TransferNode. 119
Figure 122 — Context Diagram: NT_Transfer. 119
Figure 123 — Context Diagram: NT_TransferLink . 120
Figure 124 — Feature data classes. 120
Figure 125 — Context Diagram: FD_Feature . 121
Figure 126 — Context Diagram: FD_FeatureCollection. 122
Figure 127 — Context Diagram: FD_QueryFeatureCollection . 123
Figure 128 — Context Diagram: FD_FeatureName . 124
Figure 129 — Context Diagram: VoiceStream . 125
Figure 130 — Context Diagram: BinaryData . 125
Figure 131 — Context Diagram: Map. 126
Figure 132 — Context Diagram: Image. 126
Figure C.1 — Conceptual architecture equating mobile and non-mobile services . 137

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 19133 was prepared by Technical Committee ISO/TC 211, Geographic information/Geomatics.
viii © ISO 2005 – All rights reserved

Introduction
This International Standard is a description of the data and services needed to support tracking and navigation
applications for mobile clients. The web services views of this International Standard are given in Annex C.

INTERNATIONAL STANDARD ISO 19133:2005(E)

Geographic information — Location-based services — Tracking
and navigation
1 Scope
This International Standard describes the data types, and operations associated with those types, for the
implementation of tracking and navigation services. This International Standard is designed to specify web
services that can be made available to wireless devices through web-resident proxy applications, but is not
restricted to that environment.
2 Conformance
Conformance to this International Standard takes on two meanings dependent on the type of entity declaring
conformance.
Mechanisms for the transfer of data are conformant to this International Standard if they can be considered to
consist of transfer record or type definitions that implement or extend a consistent subset of the object types
described within this International Standard.
Web servers for tracking and navigation are conformant to this International Standard if their interfaces
implement one or more of the subtypes of service defined in this International Standard and their
communications and messaging are accomplished using a conformant transfer mechanism.
Clauses 6 and 7 of this International Standard use the Unified Modeling Language (UML) to present
conceptual schemas for describing the information and services for tracking and navigation. Clause 8 further
describes a general schema for addresses to be used as location equivalents in three types of services.
Clause 9 describes network data appropriate for these services. This International Standard concerns only
externally visible interfaces and places no restriction on the underlying implementations other than what is
needed to satisfy the interface specifications in the actual situation, such as
⎯ interfaces to software services using techniques such as COM or CORBA;
⎯ interfaces to databases using techniques such as SQL;
⎯ data interchange using encoding as defined in ISO 19118.
Few applications will require the full range of capabilities described by this conceptual schema. This clause,
therefore, defines a set of conformance classes that will support applications whose requirements range from
the minimum necessary to define data structures to full object implementation. This flexibility is controlled by a
set of UML types that can be implemented in a variety of manners. Implementations that define full object
functionality shall implement all operations defined by the types of the chosen conformance class, as is
common for UML designed object implementations. Implementations that choose to depend on external “free
functions” for some or all operations, or forgo them altogether, need not support all operations, but shall
always support a data type sufficient to record the state of each of the chosen UML types as defined by its
member variables. Common names for “metaphorically identical” but technically different entities are
acceptable. The UML model in this International Standard defines abstract types, application schemas define
conceptual classes, various software systems define implementation classes or data structures, and the XML
from the encoding standard (ISO 19118) defines entity tags. All of these reference the same information
content. There is no difficulty in allowing the use of the same name to represent the same information content
even though at a deeper level there are significant technical differences in the digital entities being
implemented.
Details of the conformance classes are given in the abstract test suite in Annex A.
3 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
codes
ISO 19107, Geographic information — Spatial schema
ISO 19108, Geographic information — Temporal schema
ISO 19109, Geographic information — Rules for application schema
ISO 19111, Geographic information — Spatial referencing by coordinates
ISO 19112, Geographic information —Spatial referencing by geographic identifiers
ISO 19118, Geographic information — Encoding
4 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
4.1
candidate route
any route that satisfies all constraints of the routing request with the possible exception of optimality of the
cost function
NOTE Navigation is the process of finding the candidate route that optimizes a chosen cost function.
4.2
cost function
function that associates a measure (cost) to a route
NOTE The normal mechanism is to apply a cost to each part of a route, and to define the total route cost as the sum
of the cost of the parts. This is necessary for the operation of the most common navigation algorithms. The units of cost
functions are not limited to monetary costs and values only, but include such measures as time, distance, and possibly
others. The only requirement is that the function be additive and at least non-negative. This last criteria can be softened as
long as no zero or less cost is associated with any loop in the network, as this will prevent the existence of a “minimal
cost” route.
4.3
Dijkstra graph
positively weighted directed graph appropriately configured to execute a shortest path search
NOTE The term comes from the most commonly known algorithm for finding a shortest path in a positively weighted
graph, from E. Dijkstra’s paper [7]. Although this algorithm is not the only one in use, the requirements for the graph are
common to most. The most common relaxation of the requirement is the “positive weights”, which are not needed in the
Bellman–Ford algorithm [4], [8].
2 © ISO 2005 – All rights reserved

4.4
geocoding
translation of one form of location into another
NOTE Geocoding usually refers to the translation of “address” or “intersection” to “direct position”. Many service
providers also include a “reverse geocoding” interface to their geocoder, thus extending the definition of the service as a
general translator of location. Because routing services use internal location encodings not usually available to others, a
geocoder is an integral part of the internals of such a service.
4.5
instantiate
to represent (an abstraction) by the creation of a concrete instance or to create the ability to create an
instance
NOTE A class or data element definition instantiates a type if it creates the ability to create objects or data elements,
respectively, that can represent the concepts (instance data and/or operations) defined by that type. A class is instantiated
by an object if the class defines that object’s structure and function. A data schema is instantiated by a data element if the
data schema defines that element’s structure.
4.6
junction
single topological node in a network with its associated collection of turns, incoming and outgoing links
NOTE Junction is an alias for node.
4.7
linear referencing system
linear positioning system [ISO 19116]
positioning system that measures distance from a reference point along a route (feature)
NOTE The system includes the complete set of procedures for determining and retaining a record of specific points
along a linear feature such as the location reference method(s) together with the procedures for storing, maintaining, and
retrieving location information about points and segments on the highways. [NCHRP Synthesis 21, 1974]
4.8
link
directed topological connection between two nodes (junctions), consisting of an edge and a direction
NOTE Link is an alias for directed edge.
4.9
link position
position within a network on a link defined by some strictly monotonic measure associated with that link
NOTE Link positions are often associated with a target feature that is not part of the network. The most common link
measures used for this are the distance from start node or address. The most common use of a link position is to
geolocate an “address”.
4.10
location
identifiable geographic place
[ISO 19112]
NOTE A location is represented by one of a set of data types that describe a position, along with metadata about
that data, including coordinates (from a coordinate reference system), a measure (from a linear referencing system), or
an address (from an address system).
4.11
location-based service
LBS
service whose return or other property is dependent on the location of the client requesting the service or of
some other thing, object or person
4.12
location-dependent service
LDS
service whose availability is dependent upon the location of the client
4.13
main-road rule
set of criteria used at a turn in lieu of a route instruction; default instruction used at a node
NOTE This rule represents what is “most natural” to do at a node (intersection), given the entry link used. The most
common version is “as straight as possible”, or to exit a turn on the most obvious extension of the entry street, which is
usually, but not always, the same named street that was the entry. Every node in a route is either associated with an
instruction or can be navigated by the main-road rule.
4.14
maneuver
manœuvre
collection of related links and turns used in a route in combination
NOTE Maneuvers are used to cluster turns into convenient and legal combinations. They may be as simple as a
single turn, a combination of quick turns (“jogs” in the American mid-west consisting of a turn followed immediately by a
turn in the opposite direction) or very complex combinations consisting of entry, exit, and connecting roadways (“magic
roundabouts” in the UK).
4.15
navigation
combination of routing, route transversal and tracking
NOTE This is essentially the common term navigation, but the definition decomposes the process in terms used in
the packages defined in this International Standard.
4.16
navigation constraint
constraint
restriction on how a link or turn may be traversed by a vehicle, such as vehicle classification, physical or
temporal constraint
4.17
network
abstract structure consisting of a set of 0-dimensional objects called junctions, and a set of 1-dimensional
objects called links that connect the junctions, each link being associated with a start (origin, source)
junction and end (destination, sink) junction
NOTE The network is essentially the universe of discourse for the navigation problem. Networks are a variety of
1-dimensional topological complex. In this light, junction and topological node are synonyms, as are link and directed
edge.
4.18
position
data type that describes a point or geometry potentially occupied by an object or person
NOTE A direct position is a semantic subtype of position. Direct positions as described can only define a point and
therefore not all positions can be represented by a direct position. That is consistent with the “is type of” relation.
An ISO 19107 geometry is also a position, just not a direct position.
4 © ISO 2005 – All rights reserved

4.19
route
sequence of links and/or partial links that describe a path, usually between two positions, within a network
4.20
route instruction
information needed at a point along a route in a network that allows that route to be traversed
NOTE To minimize the number of instructions needed to complete a route traversal, a default instruction can be
assumed at junctions without specifically associated instructions. This default is called the main-road rule.
4.21
route traversal
process of following a route
4.22
routing
finding of optimal (minimal cost function) routes between locations in a network
4.23
slope
rate of change of elevation with respect to curve length
4.24
tracking
monitoring and reporting the location of a vehicle
4.25
traveller
person subject to being navigated or tracked
cf. vehicle
NOTE Includes pedestrians. See ISO 14825. In this International Standard, traveller can be replaced by vehicle
without any change of intent.
4.26
traversable
condition of a link or turn that allows or restricts all traffic’s traversal, as opposed to a more detailed
navigation constraint
NOTE Traversability is usually a function of physical, cultural, or legal conditions. If traversable is false, then the
object cannot be navigated. This effectively removes a link from the usable network. In the case of a node, it effectively
removes the node and all associated links from the useable network. In the case of a turn, it simply removes it from any
viable route. Non-traversable entities are not included in maneuvers or routes.
4.27
turn
part of a route or network consisting of a junction location and an entry and exit link for that junction
4.28
vehicle
object subject to being navigated or tracked
cf. traveller
NOTE Includes pedestrians. See ISO 14825. In this International Standard, vehicle can be replaced by traveller
without any change of intent.
4.29
vehicle classification
type of vehicle, based on the nature of its construction or intended purpose
NOTE Classifications based on construction include automobile, truck, bus, bicycle, etc. Classifications based on
purpose include taxi, emergency vehicle, etc. Vehicle classification can be used to determine the application of navigation
constraints.
4.30
waypoint
location on the network that plays a role in choosing candidate routes potentially satisfying a routing
request
5 Abbreviated terms and UML notation
5.1 Abbreviated terms
CRS Coordinate Reference System
CSL Conceptual Schema Language
ECCMA Electronic Commerce Code Management Association
GDF Geographic Data Files
GML Geography Markup Language
GPS Global Positioning System
IAEC International Address Element Code
LBS Location Based Service
LDS Location Dependent Service
LRM Linear Referencing Method
LRS Linear Reference System
OCL Object Constraint Language
PDA Personal Digital Assistant
UML Unified Modeling language
XML eXtensible Markup Language
5.2 UML notation
The UML notation used in this International Standard is described in ISO 19107, and differs from standard
UML only in the existence and interpretation of some special stereotypes, in particular “CodeList” and “Union”.
The term “context diagram” used extensively in the naming of figures in this International Standard means a
diagram that illustrates the context of a specified central type, meaning the types of it attributes, operations
and association targets. This is the information most useful to the implementer of this central class.
6 © ISO 2005 – All rights reserved

6 Tracking
6.1 Semantics
The package “Tracking” contains other packages that are used in tracking services and related functions
(see Figure 1).
Figure 1 — Tracking packages
6.2 Package: Tracking Service
6.2.1 Semantics
The package “Tracking Service” contains types and classes useful in creating a tracking service. Since this is
the core of many of the navigation functions described elsewhere in this International Standard, this package
contains some important types universal to most if not all location-based services.
6.2.2 TK_Position
6.2.2.1 Semantics
The union class “TK_Position” is used to represent positions in tracking and associated applications. An
instance of this class locates a position or place within the network. It
...

NORME ISO
INTERNATIONALE 19133
Première édition
2005-10-15
Information géographique — Services
basés sur la localisation — Suivi et
navigation
Geographic information — Location-based services — Tracking and
navigation
Numéro de référence
©
ISO 2005
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier
peut être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence
autorisant l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées
acceptent de fait la responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute
responsabilité en la matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info
du fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir
l'exploitation de ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation,
veuillez en informer le Secrétariat central à l'adresse donnée ci-dessous.

DOCUMENT PROTÉGÉ PAR COPYRIGHT

© ISO 2005
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous
quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Version française parue en 2008
Publié en Suisse
ii © ISO 2005 – Tous droits réservés

Sommaire Page
Avant-propos. iv
Introduction . v
1 Domaine d'application. 1
2 Conformité. 1
3 Références normatives . 2
4 Termes et définitions. 2
5 Abréviations et notation UML. 6
5.1 Abréviations . 6
5.2 Notation UML. 7
6 Suivi. 7
6.1 Sémantique. 7
6.2 Package: Tracking Service . 8
6.3 Package: Point Estimates . 23
6.4 Package: Location Transformation. 30
6.5 Package: Measured Coordinates . 31
6.6 Package: Systèmes de référence linéaires . 35
7 Navigation. 42
7.1 Sémantique. 42
7.2 Fonctions coût et algorithmes . 45
7.3 Package: Service de navigation. 46
7.4 Package: Cost Function. 61
7.5 Package: Preferences. 76
8 Modèle d'adresse. 78
8.1 Sémantique. 78
8.2 Package: Address. 79
8.3 Package: Address Elements. 84
9 Network. 97
9.1 Sémantique. 97
9.2 Package: Network Model . 97
9.3 Package: Turn and Junction. 100
9.4 Package: Constraint and Advisory . 107
9.5 Package: Link. 120
9.6 Package: Network Position. 124
9.7 Package: Route . 126
9.8 Package: Combined Networks . 131
10 Packages d'implémentation de base . 135
10.1 Package: Feature Data Model. 135
10.2 Package: New Basic Types. 140
Annexe A (normative) Suite d'essais abstraits . 142
Annexe B (informative) Graphes pondérés dirigés et algorithmes associés . 149
Annexe C (informative) Aperçu de la norme en termes de services RM-ODP. 153
Bibliographie . 155

Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée
aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du
comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par les comités techniques sont soumis aux comités membres pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des comités membres
votants.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable de ne
pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO 19133 a été élaborée par le comité technique ISO/TC 211, Information géographique/Géomatique.
iv © ISO 2005 – Tous droits réservés

Introduction
La présente Norme internationale décrit les données et les services nécessaires au support d'applications de
navigation et de suivi pour les clients mobiles. Les points de vue de la présente Norme internationale en
matière de services web sont indiqués dans l'Annexe C.

NORME INTERNATIONALE ISO 19133:2005(F)

Information géographique — Services basés
sur la localisation — Suivi et navigation
1 Domaine d'application
La présente Norme internationale décrit les types de données ainsi que les opérations associées pour
l'implémentation de services de navigation et de suivi. La présente Norme internationale est conçue, entre
autres, pour spécifier des services web pouvant être accessibles à des dispositifs sans fil par le biais
d'applications web proxy.
2 Conformité
La conformité à la présente Norme internationale revêt deux significations selon le type d'entité déclarant la
conformité.
Les mécanismes de transfert de données sont conformes à la présente Norme internationale à condition de
pouvoir considérer qu'ils assurent le transfert d'enregistrements ou de types implémentant ou étendant un
sous-ensemble cohérent de types d'objets décrits dans la présente Norme internationale.
Les serveurs web destinés au suivi et à la navigation sont conformes à la présente Norme internationale si
leurs interfaces implémentent un ou plusieurs sous-type(s) de service défini(s) dans la présente Norme
internationale et si leurs communications ainsi que leur messagerie utilisent un mécanisme de transfert
conforme.
Les Articles 6 et 7 de la présente Norme internationale font appel au langage de modélisation unifié (UML)
afin de présenter des schémas conceptuels permettant de décrire les informations et les services de suivi et
de navigation. L'Article 8 décrit également un schéma général pour les adresses à utiliser comme
emplacements équivalents pour trois types de services. L'Article 9 décrit les données réseau adéquates pour
ces services. La présente Norme internationale ne concerne que les interfaces visibles et ne place aucune
restriction sur les implémentations sous-jacentes autre que celles qui s'imposent pour répondre aux
spécifications des interfaces dans la situation réelle, telles que les suivantes:
⎯ interfaces vers des services logiciels utilisant des techniques de type CORBA ou COM;
⎯ interfaces vers des bases de données faisant appel à des techniques de type langage SQL;
⎯ échange de données faisant appel au codage défini dans l'ISO 19118.
Peu d'applications nécessiteront l'ensemble des possibilités décrites par ce schéma conceptuel. Par
conséquent, le présent Article définit un ensemble de classes de conformité qui supporteront des applications
dont les exigences vont du minimum nécessaire à la définition de structure de données à l'implémentation
complète d'objets. Cette flexibilité est contrôlée par un ensemble de types UML pouvant être implémentés de
diverses manières. Les implémentations définissant la fonctionnalité complète d'objets doivent implémenter
toutes les opérations définies par les types de la classe de conformité choisie, ce qui est usuel pour les
implémentations d'objets conçues pour le langage UML. Les implémentations, choisissant soit de dépendre
de “fonctions libres” externes pour certaines ou pour l'ensemble de leurs opérations, soit d'y renoncer, n'ont
pas besoin de supporter toutes les opérations, mais doivent toujours supporter un type de données suffisant
pour enregistrer l'état de chacun des types UML choisis tels que définis par les variables de membres
correspondantes.
Des noms communs pour des entités identiques sur un plan “métaphorique”, mais différentes sur le plan
technique sont acceptables. Le modèle UML dans la présente Norme internationale définit des types
abstraits; les schémas d'application définissent des classes conceptuelles; les divers systèmes logiciels
définissent des classes d'implémentation ou des structures de données; enfin, le langage XML extrait du
standard de codage (ISO 19118) définit des étiquettes d'entités. L'ensemble de ces éléments fait référence au
même contenu d'information. L'autorisation d'utiliser un même nom pour la représentation d'un même contenu
d'information ne présente aucune difficulté même si, à un niveau plus fondamental, il existe d'importantes
différences techniques entre les entités numériques implémentées.
Des détails relatifs aux classes de conformité sont donnés dans la suite de tests abstraits dans l'Annexe A.
3 Références normatives
Les documents de référence suivants sont indispensables pour l'application du présent document. Pour les
références datées, seule l'édition citée s'applique. Pour les références non datées, la dernière édition du
document de référence s'applique (y compris les éventuels amendements).
ISO 3166-1, Codes pour la représentation des noms de pays et de leurs subdivisions — Partie 1: Codes de
pays
ISO 19107, Information géographique — Schéma spatial
ISO 19108, Information géographique — Schéma temporel
ISO 19109, Information géographique — Règles de schéma d'application
ISO 19111, Information géographique — Système de références spatiales par coordonnées
ISO 19112, Information géographique — Système de références spatiales par identificateurs géographiques
ISO 19118, Information géographique — Codage
4 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
4.1
itinéraire candidat
tout itinéraire satisfaisant à l'ensemble des contraintes de la requête de routage, avec la possibilité d'en
exclure l'optimalité de la fonction coût
NOTE La navigation désigne le processus consistant à trouver l'itinéraire candidat optimisant une fonction coût
choisie.
4.2
fonction coût
fonction associant une mesure (coût) à un itinéraire
NOTE Le processus normal consiste à appliquer un coût à chaque partie d'un itinéraire et à définir le coût total de
l'itinéraire comme la somme du coût des parties. Cela est nécessaire pour permettre le fonctionnement des algorithmes
de navigation les plus répandus. Les unités des fonctions coût ne se limitent pas aux valeurs et coûts monétaires, mais
incluent, entre autres, des mesures comme celles du temps et de la distance. La seule exigence est que la fonction soit
additive et au moins non négative. Ce dernier critère peut être assoupli dans la mesure où aucun coût égal à zéro ou
négatif n'est associé à une boucle du réseau; en effet, cela empêcherait l'existence d'un itinéraire “à coût minimal”.
2 © ISO 2005 – Tous droits réservés

4.3
graphe de Dijkstra
graphe dirigé positivement pondéré et configuré de manière appropriée afin de rechercher le chemin le plus
court
NOTE Le terme provient de l'algorithme le plus répandu permettant de trouver le plus court chemin dans un graphe
pondéré positivement, d'après l'Article de E. Dijkstra [7]. Bien qu'il ne s'agisse pas du seul algorithme utilisé, les
exigences relatives au graphe s'appliquent à la plupart des algorithmes. En général, l'assouplissement des exigences
concerne les “poids positifs”, qui ne sont pas nécessaires dans l'algorithme de Bellman–Ford [4], [8].
4.4
géocodage
traduction d'une forme de localisation en une autre
NOTE Le géocodage renvoie habituellement à la traduction d'une “adresse” ou d'une “intersection” en “position
directe”. De nombreux fournisseurs de services incluent également une interface de “géocodage inverse” dans leur
géocodeur, étendant ainsi la définition du service à un traducteur général de localisation. Du fait de l'utilisation par les
services de routage de codages internes de localisation auxquels d'autres systèmes n'ont habituellement pas accès, un
géocodeur fait partie intégrante des fonctionnalités internes d'un tel service.
4.5
instancier
représenter (une abstraction) par la création d'une instance concrète ou créer la possibilité de produire une
instance
NOTE Une définition des éléments de données ou des classes instancie un type à condition d'offrir la possibilité de
créer soit des objets, soit des éléments de données pouvant représenter les concepts (opérations et/ou données
d'instance) définis par ce type. Une classe est instanciée par un objet si la classe définit la structure et la fonction de cet
objet. Un schéma de données est instancié par un élément de données si celui-ci définit la structure de cet élément.
4.6
jonction
nœud topologique simple dans un réseau avec son ensemble associé de tournants, de liens entrants et de
liens sortants
NOTE Jonction est synonyme de nœud.
4.7
système de référence linéaire
système de positionnement linéaire [ISO 19116]
système de positionnement mesurant la distance depuis un point de référence le long d'un itinéraire (entité)
NOTE Le système comprend l'ensemble complet de procédures permettant de déterminer et de conserver un
enregistrement de points spécifiques le long d'une entité linéaire, comme la (les) méthode(s) de référence pour la
localisation, accompagné des procédures de stockage, de mise à jour et de récupération des informations relatives à la
localisation de points et de segments sur les autoroutes [synthèse NCHRP 21, 1974].
4.8
lien
connexion topologique dirigée entre deux nœuds (jonctions) composée d'une arête et d'une direction
NOTE Lien est synonyme d'arête dirigée.
4.9
position sur un lien
position dans un réseau sur un lien définie par une mesure strictement monotonique associée à ce lien
NOTE Les positions sur un lien sont souvent associées à une entité cible ne faisant pas partie du réseau. Les
mesures les plus courantes effectuées sur un lien concernent la distance à partir du nœud de départ ou de l'adresse. La
position sur un lien permet le plus généralement de géolocaliser une “adresse”.
4.10
localisation
emplacement géographique identifiable
[ISO 19112]
NOTE Une localisation est représentée par un ensemble de types de données décrivant une position ainsi que des
métadonnées relatives à ces données, y compris des coordonnées (dans un système de référence par coordonnées), une
mesure (à partir d'un système de référence linéaire) ou une adresse (à partir d'un système d'adresses).
4.11
service basé sur la localisation
LBS
service dont la prestation ou toute autre propriété dépend de la localisation du client en faisant la demande
ou de tout autre élément, objet ou personne
4.12
service dépendant de la localisation
LDS
service dont l'accessibilité dépend de la localisation du client
4.13
règle relative à l'itinéraire principal
ensemble de critères utilisés au niveau d'un tournant à la place d'une instruction d'itinéraire, instruction par
défaut utilisée au niveau d'un nœud
NOTE Cette règle représente la manœuvre la “plus naturelle” au niveau d'un nœud (intersection), étant donné le lien
entrant utilisé. La manœuvre la plus répandue consiste à continuer “tout droit si possible” ou à quitter un tournant dans le
prolongement de la rue qui porte habituellement, mais pas toujours, le même nom. Chaque nœud d'un itinéraire est
associé à une instruction ou peut être parcouru en suivant la règle relative à l'itinéraire principal.
4.14
manœuvre
maneuver
ensemble de liens et de tournants associés, utilisés dans un itinéraire
NOTE Les manœuvres permettent de regrouper des tournants en combinaisons pratiques et légales. Il peut s'agir
d'un simple tournant, d'une combinaison de tournants rapides (connus sous le nom de “jogs” en Amérique, composés
d'un braquage immédiatement suivi d'un contre-braquage) ou de combinaisons très complexes composées d'une entrée,
d'une sortie et de bretelles d'accès [“magic roundabouts” (ronds-points) au Royaume Uni].
4.15
navigation
ensemble composé d'opérations de routage, de parcours d'itinéraire et de suivi
NOTE Il s'agit du terme le plus répandu, mais la définition décompose le processus en termes utilisés dans les
packages définis dans la présente Norme internationale.
4.16
contrainte de navigation
restriction portant sur le mode de traversée par un véhicule d'un lien ou d'un tournant, telle que la catégorie
de véhicule ou bien la contrainte physique ou temporelle
4 © ISO 2005 – Tous droits réservés

4.17
réseau
structure abstraite formée d'un ensemble d'objets 0D appelés jonctions et d'un ensemble d'objets 1D
appelés liens assurant la connexion entre les jonctions, chaque lien étant associé à une jonction de départ
(origine, source) et à une jonction finale (destination, réception)
NOTE Le réseau est au centre des débats concernant le problème de la navigation. Les réseaux constituent un
ensemble de complexes topologiques unidimensionnels. Sous cet angle, les termes jonction et nœud topologique sont
synonymes, à l'instar des termes lien et arête dirigée.
4.18
position
type de données décrivant un point ou une géométrie potentiellement occupée par un objet ou une personne
NOTE Une position directe est un sous-type sémantique de position. Les positions directes telles que décrites ne
peuvent définir qu'un seul point; l'ensemble des positions ne peut donc pas être représenté par une position directe. Cela
est compatible avec la relation “est du type de”. Une géométrie, selon l'ISO 19107, constitue également une position, pas
seulement une position directe.
4.19
itinéraire
séquence de liens et/ou de liens partiels décrivant un chemin, habituellement entre deux positions, dans un
réseau
4.20
instruction d'itinéraire
informations nécessaires en un point le long d'un itinéraire dans un réseau et qui permettent le parcours de
cet itinéraire
NOTE Afin de réduire le plus possible le nombre d'instructions nécessaires au parcours d'itinéraire, une
instruction par défaut peut être supposée au niveau des jonctions sans instructions spécifiquement associées. Cette
instruction par défaut s'appelle règle relative à la route principale.
4.21
parcours d'itinéraire
processus consistant à suivre un itinéraire
4.22
routage
recherche des itinéraires optimaux (fonction coût minimale) entre des localisations dans un réseau
4.23
pente
taux de changement de la hauteur par rapport à la longueur de la courbe
4.24
suivi
suivi et consignation de la localisation d'un véhicule
4.25
voyageur
personne soumise à la navigation ou au suivi
cf. véhicule
NOTE Inclut les piétons. Se reporter à l'ISO 14825. Dans la présente Norme internationale, le terme “voyageur” peut
être indifféremment remplacé par le terme “véhicule”.
4.26
caractéristique de parcourabilité
état d'un lien ou d'un tournant autorisant ou limitant le parcours de l'ensemble du trafic, par opposition à une
contrainte de navigation plus détaillée
NOTE La parcourabilité est habituellement fonction de conditions physiques, culturelles ou légales. Si la
caractéristique de parcourabilité est fausse, l'objet ne peut pas être parcouru. Cet état supprime effectivement un lien
dans le réseau utilisable. Dans le cas d'un nœud, il supprime effectivement le nœud ainsi que tous les liens associés
dans le réseau utilisable. Dans le cas d'un tournant, il supprime simplement celui-ci dans tout itinéraire viable. Les
entités dépourvues de caractéristiques de parcourabilité ne sont pas comprises dans les manœuvres ou les itinéraires.
4.27
tournant
partie d'un itinéraire ou d'un réseau se composant d'une jonction ainsi que d'un lien entrant et sortant
correspondant à cette jonction
4.28
véhicule
objet soumis à la navigation ou au suivi
cf. voyageur
NOTE Inclut les piétons. Se reporter à l'ISO 14825. Dans la présente Norme internationale, le terme “véhicule” peut
être
indifféremment remplacé par le terme “voyageur”.
4.29
catégorie de véhicule
type de véhicule, sur la base du type de construction ou de l'utilisation prévue
NOTE Les catégories reposant sur le type de construction incluent les automobiles, les camions, les autobus, les
bicyclettes, etc. Les catégories basées sur l'utilisation prévue comprennent les taxis, les véhicules d'urgence, etc. La
catégorie de véhicule peut permettre de déterminer l'application de contraintes de navigation.
4.30
point de cheminement
localisation sur le réseau jouant un rôle dans le choix d'itinéraires candidats répondant potentiellement à
une requête de routage
5 Abréviations et notation UML
5.1 Abréviations
CRS Coordinate Reference System (système de référence par coordonnées)
CSL Conceptual Schema Language (langage de schéma conceptuel)
ECCMA Electronic Commerce Code Management Association
GDF Geographic Data Files (fichiers de données géographiques)
GML Geography Markup Language (langage de balisage en géographie)
GPS Global Positioning System
IAEC International Address Element Code
LBS Location Based Service (service basé sur la localisation)
6 © ISO 2005 – Tous droits réservés

LDS Location Dependent Service (service dépendant de la localisation)
LRM Linear Referencing Method (méthode de référence linéaire)
LRS Linear Reference System (système de référence linéaire)
OCL Object Constraint Language
PDA Personal Digital Assistant (assistant numérique personnel)
UML Unified Modeling language (langage de modélisation unifié)
XML eXtensible Markup Language (langage de balisage extensible)
5.2 Notation UML
La notation UML utilisée dans la présente Norme internationale est décrite dans l'ISO 19107 et ne diverge du
standard UML que par la présence et l'interprétation de certains stéréotypes particuliers, notamment
“CodeList” et “Union”.
Le terme “diagramme de contexte”, largement utilisé dans la présente Norme internationale pour le nommage
de figures, désigne un diagramme illustrant le contexte d'un type central spécifié, c'est-à-dire le type de ses
attributs, opérations et cibles d'association. Il s'agit des informations les plus utiles pour l'opérateur chargé de
l'implémentation de cette classe centrale.
6 Suivi
6.1 Sémantique
Le package “Tracking” en contient d'autres qui sont utilisés dans les services de suivi et les fonctions
connexes (voir Figure 1).
Figure 1 — Packages de suivi
6.2 Package: Tracking Service
6.2.1 Sémantique
Le package “Tracking Service” contient des types et des classes utiles dans la création d'un service de suivi.
Étant donné qu'il s'agit de l'élément central de nombreuses fonctions de navigation décrites ailleurs dans la
présente Norme internationale, ce package contient des types importants s'appliquant à la plupart, si ce n'est
à l'ensemble, des services basés sur la localisation.
6.2.2 TK_Position
6.2.2.1 Sémantique
La classe union “TK_Position” permet de représenter des positions dans les applications de suivi et dans les
applications associées. Une instance de cette classe repère une position ou un emplacement dans le réseau.
Il convient qu'elle soit toujours interprétable comme une position directe (coordonnée dans un système de
référence), une adresse ou une position dans le réseau. Les discriminateurs pour l'union et les types associés
correspondants sont les suivants:
directPosition: DirectPosition
placeName: SI_LocationInstance
featureID: FD_FeatureName
linearReference: LR_PositionExpression
networkPosition: NT_NetworkPosition
address: AD_AbstractAddress
phone: CharacterString (chaîne de caractères)
8 © ISO 2005 – Tous droits réservés

Les opérations réalisées sur ce type constituent les opérateurs cast permettant aux programmeurs de
déterminer la position sous la forme qui leur est la plus utile. L'UML pour TK_Position est indiqué à la Figure 2.

Figure 2 — Diagramme de contexte: TK_Position
6.2.2.2 Opération: asPosition
L'opérateur “asPosition” extrait les coordonnées du CRS des données correspondant à cet emplacement.
TK_Position :: asPosition() : DirectPosition
6.2.2.3 Opération: asNetworkPosition
L'opérateur “asNetworkPosition” extrait la position dans le réseau correspondant à cet emplacement.
TK_Position :: asNetworkPosition() : NT_NetworkPosition
6.2.2.4 Opération: asAddress
L'opérateur “asAddress” extrait l'adresse correspondant à cet emplacement.
TK_Position :: asAddress() : AD_Address
6.2.3 TK_MobileSubscriber
6.2.3.1 Sémantique
Le type “TK_MobileSubscriber” permet de modéliser les items faisant l'objet d'un suivi dans le service de suivi.
L'application la plus courante concerne un abonné à un service mobile comme la téléphonie portable, pour
lequel le service est capable de déterminer l'emplacement du dispositif. Les interfaces relatives aux services
de suivi sont également applicables aux services demandant au dispositif de préciser son emplacement et
seraient donc également applicables aux dispositifs munis d'un GPS. Le service est un UML <>
opposé à un UML <> en raison de la nécessité d'associer les abonnés à leur service.
L'authentification service/client pose un problème, notamment lorsque le client est différent du souscripteur au
service mobile (se pose alors le problème du respect de la vie privée). La présente Norme internationale part
du principe que ces questions ont été résolues en dehors des interfaces de suivi (ce qui est possible en
passant par un service de “vérification” indépendant de la géographie et, de ce fait, n'entrant pas dans le
domaine d'application de la présente Norme internationale). L'UML pour TK_MobileSubscriber est indiqué à la
Figure 3.
Figure 3 — Diagramme de contexte: TK_MobileSubscriber
6.2.3.2 Attribut: id : CharacterString
L'attribut “id” désigne l'identifiant permettant au service de suivi associé de connaître cet abonné.
TK_MobileSubscriber :: id : CharacterString
6.2.3.3 Attribut: location : TK_TrackingLocation
L'attribut dérivé “location” désigne la localisation de l'abonné au moment de l'accès à l'attribut. Il s'agit
essentiellement d'un autre accès au service de suivi dans de nombreux cas. Dans le cas où l'abonné est un
dispositif muni d'un GPS, l'accès à cet attribut n'activerait pas nécessairement le service de suivi.
TK_MobileSubscriber :: location : TK_TrackingLocation
6.2.3.4 Rôle: trackingService[1.*] : TK_TrackingService
Le rôle association “trackingService” lie les abonnés au service assurant leur suivi.
TK_MobileSubscriber :: trackingService[1.*] : TK_TrackingService
10 © ISO 2005 – Tous droits réservés

6.2.4 TK_TrackingLocation
6.2.4.1 Sémantique
Le type “TK_TrackingLocation” permet de représenter des objets décrivant un emplacement et les
métadonnées qui lui sont associées, telles que le temps de mesure ou le sens du déplacement. L'UML pour
TK_TrackingLocation est indiqué à la Figure 4.

Figure 4 — Diagramme de contexte: TK_TrackingLocation
6.2.4.2 Attribut: position : TK_Position
L'attribut “position” décrit les mesures représentant la position de cet objet.
TK_TrackingLocation :: position : TK_Position
6.2.4.3 Attribut: time[0.1] : TM_Primitive
L'attribut facultatif “time” décrit le temps de mesures représentant la position de cet objet.
TK_TrackingLocation :: time[0.1] : TM_Primitive
6.2.4.4 Attribut: direction[0.1] : Bearing
L'attribut “direction” décrit le sens du déplacement de l'abonné faisant l'objet du suivi.
TK_TrackingLocation :: direction[0.1] : Bearing
6.2.4.5 Attribut: speed[0.1] : Velocity
L'attribut “speed” décrit la vitesse de déplacement de l'abonné faisant l'objet du suivi.
TK_TrackingLocation :: speed[0.1] : Velocity
6.2.4.6 Role: metadata[0.*] : TK_TrackingLocationMetadata
Le rôle association “metadata” regroupe les éléments facultatifs de métadonnées associés à cet emplacement.
TK_TrackingLocation :: metadata[0.*] : TK_TrackingLocationMetadata
6.2.5 TK_TrackingService
6.2.5.1 Sémantique
Le type “TK_TrackingService” définit les interfaces et les associations pour les services de suivi. L'UML pour
TK_TrackingService est indiqué à la Figure 5.

Figure 5 — Diagramme de contexte: TK_TrackingService
6.2.5.2 Role mobileSubscriber[0.*] : TK_MobileSubscriber
Le rôle association “mobileSubscriber” regroupe des items (véhicule ou voyageur) pouvant faire l'objet d'un
suivi en passant par ce service.
TK_TrackingService :: mobileSubscriber[0.*] : TK_MobileSubscriber
6.2.5.3 Opération: locate
L'opération “locate” restitue un emplacement unique pour un item faisant l'objet d'un suivi.
TK_TrackingService ::
locate(ms : TK_MobileSubscriber, type : TK_PositionType) :
TK_TrackingLocation
6.2.5.4 Opération: track
L'opération “track” restitue une séquence d'emplacements pour un item faisant l'objet d'un suivi. Les types de
déclenchement provoquant la mise en place d'un nouvel emplacement dans la séquence sont spécifiés dans
le protocole opérationnel.
TK_TrackingService ::
track(ms : TK_MobileSubscriber, triggerType[1.*] : TK_Trigger) :
TK_TrackingLocationSequence
12 © ISO 2005 – Tous droits réservés

6.2.6 TK_PositionType
La liste des codes “TK_PositionType” dresse la liste des types de positions disponibles dans l'application. Les
types suivants y sont répertoriés depuis l'origine: “coordinate”, “placeName”, “feature”, “linearReference”,
“network”, “address” et “phone”. L'UML pour TK_PositionType est indiqué à la Figure 6.

Figure 6 — Diagramme de contexte: TK_PositionType
6.2.7 TK_TrackingLocationSequence
6.2.7.1 Sémantique
Le type “TK_TrackingLocationSequence” désigne un mécanisme d'accès permettant la restitution d'un suivi
continu relatif à un item. L'UML pour TK_TrackingLocationSequence est indiqué à la Figure 7.

Figure 7 — Diagramme de contexte: TK_TrackingLocationSequence
6.2.7.2 Attribut: ms : TK_MobileSubscriber
L'attribut “ms” donne l'identité de l'item faisant l'objet du suivi.
TK_TrackingLocationSequence :: ms : TK_MobileSubscriber
6.2.7.3 Attribut: sequenceID : CharacterString
L'attribut “sequenceID” indique l'identité de la séquence d'emplacements afin qu'un client puisse y avoir accès
à plusieurs reprises.
TK_TrackingLocationSequence :: sequenceID : CharacterString
6.2.7.4 Opération: next
L'opération “next” restitue l'emplacement suivant dans la séquence.
TK_TrackingLocationSequence :: next() : TK_TrackingLocation
6.2.7.5 Opération: suspend
L'opération “suspend” met temporairement fin aux flux d'emplacements dans la séquence.
TK_TrackingLocationSequence :: suspend() : Boolean
6.2.7.6 Opération: restart
L'opération “restart” relance le flux d'emplacements dans la séquence qui avait été arrêté par l'opération
“suspend”.
TK_TrackingLocationSequence :: restart() : TK_TrackingLocation
6.2.7.7 Opération: terminate
L'opération “terminate” met fin de manière permanente au flux d'emplacements dans la séquence.
TK_TrackingLocationSequence :: terminate() : Boolean
14 © ISO 2005 – Tous droits réservés

6.2.8 TK_Trigger
La classe abstraite “TK_Trigger” fait office de classe racine pour les types de déclenchement à utiliser dans le
contrôle d'une séquence d'emplacements. En général, il existe deux types de déclenchement: déclenchement
par un événement ou déclenchement par écoulement du temps. L'UML pour TK_Trigger est indiqué à la
Figure 8.
Figure 8 — Diagramme de contexte: TK_Trigger
6.2.9 TK_PeriodicTrigger
6.2.9.1 Sémantique
La classe “TK_PeriodicTrigger” permet de contrôler des séquences d'emplacements en paramétrant les
intervalles tempores de prélèvement d'échantillons de suivi. Des valeurs minTime ou maxTime doivent être
indiquées pour un TK_PeriodicTrigger valide. L'UML pour TK_PeriodicTrigger est indiqué à la Figure 9.

Figure 9 — Diagramme de contexte: TK_PeriodicTrigger
6.2.9.2 Attribut: minTime[0.1] : TM_Primitive
L'attribut “minTime” désigne l'intervalle minimal séparant les prélèvements d'échantillons de suivi. En
l'absence d'autres critères, le service de suivi entamera le prélèvement d'échantillons lorsque le temps
minimal (attribut “minTime”) s'est écoulé. En partant de l'hypothèse qu'il n'existe pas de temps mort, le
prélèvement d'échantillons sera espacé de la valeur de l'attribut “minTime”.
TK_PeriodicTrigger :: minTime[0.1] : TM_Primitive
6.2.9.3 Attribut: maxTime[0.1] : TM_Primitive
L'attribut “maxTime” désigne l'espacement maximal des prélèvements d'échantillons de suivi. En l'absence
d'autres critères, le service de suivi veillera à ce que l'espacement des prélèvements ne dépasse pas la
valeur du paramètre “maxTime”.
TK_PeriodicTrigger :: maxTime[0.1] : TM_Primitive
6.2.10 TK_TransitionTrigger
6.2.10.1 Sémantique
La classe “TK_TransitionTrigger” modélise des transitions relatives à l'item faisant l'objet du suivi qui
déclencheront le prélèvement d'un nouvel échantillon d'emplacement. Dans une classe TK_TransitionTrigger,
au moins un des attributs doit être différent de zéro. L'UML pour TK_TransitionTrigger est indiqué à la
Figure 10.
Figure 10 — Diagramme de contexte: TK_TransitionTrigger
6.2.10.2 Attribut: type[0.*] : TK_TransitionType
L'attribut “type” décrit le ou les type(s) de transitions faisant l'objet d'une observation. La liste des codes
associée au service dresse la liste des divers types de transitions.
TK_TransitionTrigger :: type[0.*] : TK_TransitionType
16 © ISO 2005 – Tous droits réservés

6.2.10.3 Attribut: deltaDirection[0.1] : Angle
L'attribut “deltaDirection” décrit l'amplitude du changement de direction déclenchant un nouvel échantillon
d'emplacement.
TK_TransitionTrigger :: deltaDirection[0.1] : Angle
6.2.10.4 Attribut: deltaPosition[0.1] : Distance
L'attribut “deltaPosition” décrit l'amplitude du changement d'emplacement (distance) déclenchant un nouvel
échantillon d'emplacement.
TK_TransitionTrigger :: deltaPosition[0.1] : Distance
6.2.11 TK_TransitionType
La liste des codes “TK_TransitionType” énumère les types de transition suivis par ce service. Les valeurs
initiales de la liste sont les suivantes:
“enterCell” un souscripteur mobile pénètre dans une cellule associée au réseau, par exemple
réseau de téléphones portables
“leaveCell” un souscripteur mobile quitte une cellule associée au réseau
“changeContacts” un souscripteur mobile change de correspondant
“changeDirection” un souscripteur mobile modifie le sens de son déplacement d'une valeur
supérieure à ce que spécifie le paramètre deltaDirection
“changePosition” un souscripteur mobile modifie sa position d'une valeur supérieure à ce
qu'autorise le paramètre deltaPosition
“changeAvailability” perte ou prise de contact avec le souscripteur mobile. En cas de perte de contact,
la position précédant immédiatement la perte est indiquée. En cas de prise de
contact, la première position calculée pour le souscripteur mobile après le
nouveau contact est indiquée
6.2.12 TK_TrackingLocationMetadata
6.2.12.1 Sémantique
Le type de données “TK_TrackingLocationMetadata” contient les métadonnées permettant de décrire la
position restituée par le service de suivi. En tant que tel, ce type de données doit toujours être contenu dans
un type TK_TrackingLocation, ou autre type d'emplacement. L'UML pour TK_TrackingLocationMetadata est
indiqué à la Figure 11.
Figure 11 — Diagramme de contexte: TK_TrackingLocationMetadata
6.2.12.2 Attribut: ms[0.1] : TK_MobileSubscriber
L'attribut “ms” indique l'identité de l'item faisant l'objet du suivi. En l'absence de cet attribut est absent, il
convient de pouvoir le déduire du contexte en utilisant la propriété du contenant TK_TrackingLocation.
TK_TrackingLocationSequence :: ms[0.1]: TK_MobileSubscriber
6.2.12.3 Attribut: quality : TK_QualityOfPosition
L'attribut “quality” décrit la qualité de la position.
TK_TrackingLocationSequence :: quality : TK_QualityOfPosition
6.2.12.4 Attribut: time : TM_Primitive
L'attribut “time” indique l'heure à laquelle la position a été mesurée.
TK_TrackingLocationSequence :: time : TM_Primitive
6.2.12.5 Attribut: clientID : CharacterString
L'attribut “clientID” indique l'identité du client demandant le service de suivi.
TK_TrackingLocationSequence :: clientID : CharacterString
18 © ISO 2005 – Tous droits réservés

6.2.12.6 Attribut: trigger[0.*] : TK_Transition
L'attribut “trigger” décrit la transition ayant déclenché cette mesure d'emplacement.
TK_TrackingLocationSequence :: trigger[0.*] : TK_Transition
6.2.13 TK_Transition
6.2.13.1 Sémantique
La classe “TK_Transition” décrit une transition ou un événement particulier ayant déclenché une mesure de
l'emplacement. L'UML pour TK_Transition est indiqué à la Figure 12.

Figure 12 — Diagramme de contexte: TK_Transition
6.2.13.2 Attribut: type[1.*] : TK_TransitionType
L'attribut “type” décrit le ou les type(s) de transitions.
TK_Transition :: type[1.*] : TK_TransitionType
6.2.13.3 Attribut: time : TM_Primitive
L'attribut “time” décrit l'heure à laquelle la transition s'est produite. Normalement, il convient que celle-ci
corresponde approximativement à celle qui se trouve dans les métadonnées d'emplacement.
TK_Transition :: time : TM_Primitive
...

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Geografske informacije - Storitve na podlagi lokacije - Sledenje in navigacijaInformation géographique - Services basés sur la localisation - Suivi et navigationGeographic information - Location-based services - Tracking and navigation35.240.70Uporabniške rešitve IT v znanostiIT applications in scienceICS:Ta slovenski standard je istoveten z:ISO 19133:2005oSIST ISO 19133:2006en,fr01-oktober-2006oSIST ISO 19133:2006SLOVENSKI
STANDARD
Reference numberISO 19133:2005(E)© ISO 2005
INTERNATIONAL STANDARD ISO19133First edition2005-10-15Geographic information — Location-based services — Tracking and navigation Information géographique — Services basés sur la localisation — Suivi et navigation
©
ISO 2005 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body in the country of the requester. ISO copyright office Case postale 56 • CH-1211 Geneva 20 Tel.
+ 41 22 749 01 11 Fax
+ 41 22 749 09 47 E-mail
[e-mail] Web
www.iso.org Published in Switzerland
ii
iii Contents Page Foreword.viii Introduction.ix 1 Scope.1 2 Conformance.1 3 Normative references.2 4 Terms and definitions.2 5 Abbreviated terms and UML notation.6 5.1 Abbreviated terms.6 5.2 UML notation.6 6 Tracking.7 6.1 Semantics.7 6.2 Package: Tracking Service.7 6.3 Package: Point Estimates.21 6.4 Package: Location Transformation.26 6.5 Package: Measured Coordinates.27 6.6 Package: Linear Reference Systems.32 7 Navigation.39 7.1 Semantics.39 7.2 Cost Functions and algorithms.41 7.3 Package: Navigation Service.42 7.4 Package: Cost Function.55 7.5 Package: Preferences.68 8 Address Model.70 8.1 Semantics.70 8.2 Package: Address.70 8.3 Package: Address Elements.74 9 Network.85 9.1 Semantics.85 9.2 Package: Network Model.85 9.3 Package: Turn and Junction.89 9.4 Package: Constraint and Advisory.95 9.5 Package: Link.108 9.6 Package: Network Position.111 9.7 Package: Route.112 9.8 Package: Combined Networks.117 10 Basic implementation packages.120 10.1 Package: Feature Data Model.120 10.2 Package: New Basic Types.124 Annex A (normative)
Abstract test suite.127 Annex B (informative)
Directed weighted graphs and their algorithms.134 Annex C (informative)
View of Standard in terms of RM-ODP Services.137 Bibliography.139 oSIST ISO 19133:2006

v Figure 39 — Services.42 Figure 40 — Context Diagram: NS_NavigationService.43 Figure 41 — Context Diagram: NS_RouteRequest.46 Figure 42 — Context Diagram: NS_Instruction.48 Figure 43 — Context Diagram: NS_InstructionList.49 Figure 44 — Context Diagram: NS_RouteResponse.50 Figure 45 — Context Diagram: NS_CostedTurn.51 Figure 46 — Context Diagram: NS_RenderingService.51 Figure 47 — Context Diagram: NS_RenderingRequest.52 Figure 48 — Context Diagram: NS_RenderingResponse.53 Figure 49 — Context Diagram: NS_RenderingType.53 Figure 50 — Context Diagram: NS_CostedLink.54 Figure 51 — Context Diagram: NS_CostFunctionCode.54 Figure 52 — Context Diagram: NS_RouteRequestType.55 Figure 53 — Context Diagram: NS_CostFunction.59 Figure 54 — Context Diagram: NS_CostElements.59 Figure 55 — Context Diagram: NS_MonetaryCost.60 Figure 56 — Context Diagram: NS_Tolls.61 Figure 57 — Context Diagram: NS_Fares.61 Figure 58 — Context Diagram: NS_Time.62 Figure 59 — Context Diagram: NS_TravelTime.62 Figure 60 — Context Diagram: NS_WaitingTime.63 Figure 61 — Context Diagram: NS_Counts.64 Figure 62 — Context Diagram: NS_NumberManeuvers.64 Figure 63 — Context Diagram: NS_NumberTurns.65 Figure 64 — Context Diagram: NS_NumberTransfers.65 Figure 65 — Context Diagram: NS_Distance.66 Figure 66 — Context Diagram: NS_WeightedCost.67 Figure 67 — Context Diagram: NS_CostFunctionTerm.68 Figure 68 — Context Diagram: NS_RoutePreferences.68 Figure 69 — Context Diagram: NS_AvoidList.69 Figure 70 — Leaf packages of the Address Model.70 Figure 71 — Basic Address classes.71 Figure 72 — Context Diagram: AD_Address.72 Figure 73 — Context Diagram: AD_AbstractAddress.72 Figure 74 — Context Diagram: AD_USAddress.74 Figure 75 — Context Diagram: AD_AddressElement.75 Figure 76 — Context Diagram: AD_Addressee.76 Figure 77 — Context Diagram: AD_StreetIntersection.76 Figure 78 — Context Diagram: AD_Street.78 oSIST ISO 19133:2006

vii Figure 119 — Combined Networks.117 Figure 120 — Context Diagram: NT_CombinedNetwork.118 Figure 121 — Context Diagram: NT_TransferNode.119 Figure 122 — Context Diagram: NT_Transfer.119 Figure 123 — Context Diagram: NT_TransferLink.120 Figure 124 — Feature data classes.120 Figure 125 — Context Diagram: FD_Feature.121 Figure 126 — Context Diagram: FD_FeatureCollection.122 Figure 127 — Context Diagram: FD_QueryFeatureCollection.123 Figure 128 — Context Diagram: FD_FeatureName.124 Figure 129 — Context Diagram: VoiceStream.125 Figure 130 — Context Diagram: BinaryData.125 Figure 131 — Context Diagram: Map.126 Figure 132 — Context Diagram: Image.126 Figure C.1 — Conceptual architecture equating mobile and non-mobile services.137
ix Introduction This International Standard is a description of the data and services needed to support tracking and navigation applications for mobile clients. The web services views of this International Standard are given in Annex C.
INTERNATIONAL STANDARD ISO 19133:2005(E) © ISO 2005 – All rights reserved
1 Geographic information — Location-based services — Tracking and navigation 1 Scope This International Standard describes the data types, and operations associated with those types, for the implementation of tracking and navigation services. This International Standard is designed to specify web services that can be made available to wireless devices through web-resident proxy applications, but is not restricted to that environment. 2 Conformance Conformance to this International Standard takes on two meanings dependent on the type of entity declaring conformance. Mechanisms for the transfer of data are conformant to this International Standard if they can be considered to consist of transfer record or type definitions that implement or extend a consistent subset of the object types described within this International Standard. Web servers for tracking and navigation are conformant to this International Standard if their interfaces implement one or more of the subtypes of service defined in this International Standard and their communications and messaging are accomplished using a conformant transfer mechanism. Clauses 6 and 7 of this International Standard use the Unified Modeling Language (UML) to present conceptual schemas for describing the information and services for tracking and navigation. Clause 8 further describes a general schema for addresses to be used as location equivalents in three types of services. Clause 9 describes network data appropriate for these services. This International Standard concerns only externally visible interfaces and places no restriction on the underlying implementations other than what is needed to satisfy the interface specifications in the actual situation, such as ⎯ interfaces to software services using techniques such as COM or CORBA; ⎯ interfaces to databases using techniques such as SQL; ⎯ data interchange using encoding as defined in ISO 19118. Few applications will require the full range of capabilities described by this conceptual schema. This clause, therefore, defines a set of conformance classes that will support applications whose requirements range from the minimum necessary to define data structures to full object implementation. This flexibility is controlled by a set of UML types that can be implemented in a variety of manners. Implementations that define full object functionality shall implement all operations defined by the types of the chosen conformance class, as is common for UML designed object implementations. Implementations that choose to depend on external “free functions” for some or all operations, or forgo them altogether, need not support all operations, but shall always support a data type sufficient to record the state of each of the chosen UML types as defined by its member variables. Common names for “metaphorically identical” but technically different entities are acceptable. The UML model in this International Standard defines abstract types, application schemas define conceptual classes, various software systems define implementation classes or data structures, and the XML from the encoding standard (ISO 19118) defines entity tags. All of these reference the same information content. There is no difficulty in allowing the use of the same name to represent the same information content oSIST ISO 19133:2006

3 4.4 geocoding translation of one form of location into another NOTE Geocoding usually refers to the translation of “address” or “intersection” to “direct position”. Many service providers also include a “reverse geocoding” interface to their geocoder, thus extending the definition of the service as a general translator of location. Because routing services use internal location encodings not usually available to others, a geocoder is an integral part of the internals of such a service. 4.5 instantiate to represent (an abstraction) by the creation of a concrete instance or to create the ability to create an instance NOTE A class or data element definition instantiates a type if it creates the ability to create objects or data elements, respectively, that can represent the concepts (instance data and/or operations) defined by that type. A class is instantiated by an object if the class defines that object’s structure and function. A data schema is instantiated by a data element if the data schema defines that element’s structure. 4.6 junction single topological node in a network with its associated collection of turns, incoming and outgoing links NOTE Junction is an alias for node. 4.7 linear referencing system linear positioning system [ISO 19116] positioning system that measures distance from a reference point along a route (feature) NOTE The system includes the complete set of procedures for determining and retaining a record of specific points along a linear feature such as the location reference method(s) together with the procedures for storing, maintaining, and retrieving location information about points and segments on the highways. [NCHRP Synthesis 21, 1974] 4.8 link directed topological connection between two nodes (junctions), consisting of an edge and a direction NOTE Link is an alias for directed edge. 4.9 link position position within a network on a link defined by some strictly monotonic measure associated with that link NOTE Link positions are often associated with a target feature that is not part of the network. The most common link measures used for this are the distance from start node or address. The most common use of a link position is to geolocate an “address”. 4.10 location identifiable geographic place [ISO 19112] NOTE A location is represented by one of a set of data types that describe a position, along with metadata about that data, including coordinates (from a coordinate reference system), a measure (from a linear referencing system), or an address (from an address system). oSIST ISO 19133:2006

5 4.19 route sequence of links and/or partial links that describe a path, usually between two positions, within a network 4.20 route instruction information needed at a point along a route in a network that allows that route to be traversed NOTE To minimize the number of instructions needed to complete a route traversal, a default instruction can be assumed at junctions without specifically associated instructions. This default is called the main-road rule. 4.21 route traversal process of following a route 4.22 routing finding of optimal (minimal cost function) routes between locations in a network 4.23 slope rate of change of elevation with respect to curve length 4.24 tracking monitoring and reporting the location of a vehicle 4.25 traveller person subject to being navigated or tracked cf. vehicle NOTE Includes pedestrians. See ISO 14825. In this International Standard, traveller can be replaced by vehicle without any change of intent. 4.26 traversable condition of a link or turn that allows or restricts all traffic’s traversal, as opposed to a more detailed navigation constraint NOTE Traversability is usually a function of physical, cultural, or legal conditions. If traversable is false, then the object cannot be navigated. This effectively removes a link from the usable network. In the case of a node, it effectively removes the node and all associated links from the useable network. In the case of a turn, it simply removes it from any viable route. Non-traversable entities are not included in maneuvers or routes. 4.27 turn part of a route or network consisting of a junction location and an entry and exit link for that junction 4.28 vehicle object subject to being navigated or tracked cf. traveller NOTE Includes pedestrians. See ISO 14825. In this International Standard, vehicle can be replaced by traveller without any change of intent. oSIST ISO 19133:2006

The term “context diagram” used extensively in the naming of figures in this International Standard means a diagram that illustrates the context of a specified central type, meaning the types of it attributes, operations and association targets. This is the information most useful to the implementer of this central class. oSIST ISO 19133:2006

7 6 Tracking 6.1 Semantics The package “Tracking” contains other packages that are used in tracking services and related functions (see Figure 1).
Figure 1 — Tracking packages 6.2 Package: Tracking Service 6.2.1 Semantics The package “Tracking Service” contains types and classes useful in creating a tracking service. Since this is the core of many of the navigation functions described elsewhere in this International Standard, this package contains some important types universal to most if not all location-based services. 6.2.2 TK_Position 6.2.2.1 Semantics The union class “TK_Position” is used to represent positions in tracking and associated applications. An instance of this class locates a position or place within the network. It should always be interpretable as a direct position (coordinate in a reference system), an address or as a network position. The discriminators for the union, and their associated types are as follows: directPosition: DirectPosition placeName: SI_LocationInstance featureID: FD_FeatureName linearReference: LR_PositionExpression networkPosition: NT_NetworkPosition address: AD_AbstractAddress phone: CharacterString oSIST ISO 19133:2006
...