ISO 17267-2009 Intelligent transport systems - Navigation systems - Application programming interface (API)《智能运输系统 导航系统 应用程序接口(API)》.pdf

1、 Reference number ISO 17267:2009(E) ISO 2009INTERNATIONAL STANDARD ISO 17267 First edition 2009-11-15 Intelligent transport systems Navigation systems Application programming interface (API) Systmes intelligents de transport Systmes de navigation Interface de programmation (API) ISO 17267:2009(E) PD

2、F disclaimer This PDF file may contain embedded typefaces. In accordance with Adobes 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, pa

3、rties accept therein the responsibility of not infringing Adobes 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 relativ

4、e 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. COPYRIGH

5、T PROTECTED DOCUMENT ISO 2009 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

6、ISOs 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 copyrightiso.org Web www.iso.org Published in Switzerland ii ISO 2009 All rights reservedISO 17267:2009(E) ISO 2009 All rights reserved iiiCont

7、ents Page Foreword iv Introduction.v 1 Scope1 2 Terms and definitions .1 3 Abbreviated terms .7 4 Architecture of the API8 4.1 General .8 4.2 Paradigm 8 4.3 Minimum low level platform interface .8 4.4 Forward compatibility .8 4.5 Error handling8 4.6 Memory allocation .9 4.7 Prioritization and cancel

8、lation .9 4.8 Byte ordering .9 4.9 Generic data types 9 4.10 Handling of large result sets 10 4.10.1 Background10 4.10.2 Requirements.11 4.10.3 Object-oriented example.11 4.11 Multimedia issues13 4.12 Location of application software, DAL and data13 4.12.1 Application software .13 4.12.2 Data access

9、 library14 4.12.3 Data.14 4.12.4 Conclusions .15 4.13 Base and extended APIs.21 4.13.1 Terms21 4.13.2 Description.21 5 Functional specification of the API .22 5.1 Introduction and level of API22 5.1.1 General .22 5.1.2 Functional definition of the API level 23 5.1.3 ISO-API level policy.24 5.2 Speci

10、fication convention25 5.2.1 General .25 5.2.2 Naming conventions .25 5.2.3 Hungarian notation convention .26 5.3 Application categories30 5.3.1 General .30 5.3.2 Global module specification 31 5.3.3 Definitions common to all functional categories .31 5.3.4 Route planning 70 5.3.5 Route guidance87 5.

11、3.6 Positioning .92 5.3.7 Map display 93 5.3.8 Address location .100 5.3.9 Services/POIs.109 5.3.10 Utility functions .114 Annex A (normative) Condition policy .121 Annex B (normative) Attribute types 129 Bibliography139 ISO 17267:2009(E) iv ISO 2009 All rights reservedForeword ISO (the Internationa

12、l 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 es

13、tablished 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 standardi

14、zation. 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 vot

15、ing. 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 suc

16、h patent rights. ISO 17267 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems. ISO 17267:2009(E) ISO 2009 All rights reserved vIntroduction The impetus for this International Standard was the recognition by the intelligent transport systems (ITS) industry of the need for s

17、tandardization with respect to data access for map databases used by navigation applications. As the vehicle navigation industry has grown, so has incompatibility between navigation systems and map databases. Both a standardized physical storage format (PSF) and a standardized navigation application

18、 programming interface (API) can facilitate the interoperability between navigation systems and map databases. The purpose of this International Standard is to define and structure the model for data access for Vehicle Navigation and Traveller Information Systems. This International Standard is not

19、restricted to physical media and will be independent of any underlying physical storage format. While this API is primarily targeted at self- contained in-vehicle systems, it is expected to be usable by other applications that use map data results in essentially the same way. For example, it may be

20、usable by client/server or distributed navigation systems and location-based services without further specialization. This International Standard is the Application programming interface (API) specification. It represents the comprehensive specification of the API standard for navigation application

21、s. This International Standard builds upon, and is consistent with, the other International Standards developed by ISO/TC 204/WG 3: ISO 14825, Intelligent transport systems Geographic Data Files (GDF) Overall data specification; ISO 17572 (all parts), Intelligent transport systems (ITS) Location ref

22、erencing for geographic databases. INTERNATIONAL STANDARD ISO 17267:2009(E) ISO 2009 All rights reserved 1Intelligent transport systems Navigation systems Application programming interface (API) 1 Scope This International Standard specifies an application programming interface (API) for navigation s

23、ystems. It specifies the data that may be retrieved from the map database and defines the interface for access. This International Standard specifies a set of function calls. It also specifies the design of the API and gives examples of its intended use. Furthermore, it gives the criteria to determi

24、ne whether a data access library is in accordance with this International Standard. This International Standard is applicable to the following functional categories of navigation applications: positioning; route planning; route guidance; map display; address location; services and point of interest

25、(POI) information access. 2 Terms and definitions For the purposes of this document, the following terms and definitions apply. 2.1 address location application category that deals with the task of expressing a real world position in terms of the data representation NOTE Address location is one of t

26、he six application categories supported by the API. 2.2 address type attribute of road section entity that specifies the type of house number ranges EXAMPLE Distinction between base address, county address, commercial address, etc., or no address. 2.3 application category basic sub-function within t

27、he set of functionality for vehicle navigation and traveller information system applications NOTE This International Standard identifies six application categories: positioning; route planning; route guidance; map display; address location; services and POI information access. ISO 17267:2009(E) 2 IS

28、O 2009 All rights reserved2.4 application programming interface API standard interface and set of function calls between application software and data access libraries of vehicle navigation systems, in accordance with this International Standard 2.5 base map all transportation elements and all servi

29、ces, including their relationships to transportation elements 2.6 branded third-party data BTPD information about services which is supplied by third-party data providers (e.g. tourist or motoring organizations), who may impose proprietary restrictions on the use and presentation of the data NOTE 1

30、Access is subject to authorization and licensing. NOTE 2 BTPD is a subset of third party data (TPD); see 2.54. 2.7 cartographic feature data model entity that represents geometrical information for display purposes NOTE A cartographic feature has non-explicit topology; it has zero-, one- and two-dim

31、ensional types, i.e. Display Point, Polyline, and Polygon. 2.8 cartographic text data model entity that stores name text associated with all or part of a cartographic feature NOTE Cartographic text is language dependent and may contain a suggested display location, orientation, language code, priori

32、ty (or importance), suggested scale range, and bounding box. 2.9 condition information related to link(s) composed of condition type, condition modifiers, and condition scope 2.10 crossroad data model entity that represents the single instance of the crossing of two named navigable features NOTE Cro

33、ssroad relates to the set of links and nodes which comprise the crossing, and to the crossing of the navigable features to a place. 2.11 destination node node at the end of the link toward which travel takes place NOTE See also origin node (2.25), “from” node (2.14), “to” node (2.55), source node (2

34、.50), and target node (2.53). When a link is travelled in the direction of topological orientation, the destination node is the “to” node. When it is travelled in the direction opposite topological orientation, the destination node is the “from” node. 2.12 display point zero-dimensional type of cart

35、ographic feature ISO 17267:2009(E) ISO 2009 All rights reserved 32.13 dummy point optional entity that represents a position along a link where the link crosses a parcel boundary and does not necessarily coincide with a shape point or node 2.14 “from” node node at the end of a link away from which t

36、he link is topologically oriented NOTE See also “to” node (2.55), origin node (2.25), destination node (2.11), source node (2.50), and target node (2.54). When a link is travelled in the direction of topological orientation, the “from” node is the origin node. When it is travelled in the direction o

37、pposite topological orientation, the “from” node is the destination node. 2.15 geocoding determination of a link or node based on address information describing and/or naming a location 2.16 intersection geographic data file (GDF) level 2 representation of a crossing which bounds a road or a ferry a

38、s a complex feature composed of one or more GDF level 1 junctions, road elements and enclosed traffic areas 2.17 junction data model entity that represents a navigable feature which is either a named GDF junction or named GDF intersection, and that relates a named navigable feature to a set of links

39、 and nodes and a place 2.18 landmark point, line, or area feature, possibly associated with a node or link, that can be used to clarify the directions generated to describe a route NOTE A landmark may not be in the Services, Administrative Areas, or Public Transportation feature themes of a GDF; a f

40、acility in which a service is located may be a landmark. 2.19 layer subset of map data resulting from a subdivision of data of the same coverage area based on contents and which is typically related to one or only a few of the application categories NOTE This is similar to an ISO-GDF layer. EXAMPLE

41、Route guidance data may be considered as one layer. 2.20 level subset of map data resulting from a classification of data of the same semantic content based on the level of detail or density, related to the concept of different map scales NOTE Level 0 is considered the lowest level (greatest detail)

42、; higher levels are numbered level 1, level 2, etc. EXAMPLE Map display data may be organised into 6 levels representing different zoom scales. 2.21 link directed topological connection between two nodes, composed of an ordered sequence of one or more segments and represented by an ordered sequence

43、of zero or more shape points (2.48) ISO 17267:2009(E) 4 ISO 2009 All rights reserved2.22 map display application category that deals with graphical information presentation NOTE Map display is one of the six application categories supported by the API. 2.23 multilink ordered aggregation of links whi

44、ch are at the same level, are connected in sequence, and share the same functional classification, form of way, direction of travel, and perhaps additional characteristics EXAMPLE Each link is contained in exactly one multilink. 2.24 navigable feature name data model entity that represents the name

45、for the transportation element, including GDF road element, GDF ferry connection, GDF junction, GDF intersection NOTE Navigable feature name is related to places, crossroads, junctions, and road sections. 2.25 node data model entity for a topological junction of two or more links or for end-bounding

46、 a link NOTE A node stores the coordinate value of the corresponding GDF junction. 2.26 origin node node at the end of a link from which travel takes place NOTE See also destination node (2.11), “from” node (2.14), “to” node (2.55), source node (2.50), and target node (2.54). When a link is travelle

47、d in the direction of topological orientation, the origin node is the “from” node. When it is travelled in the direction opposite topological orientation, the origin node is the “to” node. 2.27 parcel database partitioning unit corresponding to a certain coverage area, associated with one level and

48、containing data of one or more layers NOTE A parcel contains (at least) all nodes with positions enclosed by or located on the outline of its coverage area plus (parts of) all links attached to these nodes; it can be partitioned so that the amount of data of a parcel may be nearly the same as that o

49、f another. 2.28 place named area which can be used as part of the address location 2.29 place class attribute of place entity, classifying into highest administrative or geographic division, administrative subdivision, postal, or colloquial (e.g. regions or neighbourhoods) NOTE Place class can be partially ordered as “place class A is below place class B“. This does not imply strict or complete containment. 2.30 place level level associated with places of place classification “administrative subdivision” NOTE Higher/l