On-the-fly location referencing - the iloc method -

ON-THE-FLY LOCATION REFERENCING
- THE ILOC METHOD -
This paper describes a promising new location referencing method for map-basedITS applications. The method uses a combination of WGS84 co-ordinates and de-scriptive identifiers to reference locations (real world objects), and has an on-the-flycharacter, which means that location tables are not required. ILOC referencing wasdeveloped by the ERTICO Committee on Location Referencing (1995-1997), fol-lowing earlier work in the Socrates projects. Manual tests between 5 different data-bases showed good results. Currently the method is being refined, tested and pre-pared for future implementation by the one-year EVIDENCE project, started 01 April1998. The method could also be used with non- map-based systems, if these havesome storage capacity for location information. TPEG has adopted ILOC as its pre-mier location referencing method.
LOCATION REFERENCING
Traffic and traveller information (TTI) is a key issue in transport telematics. Such in-
formation is always related to objects in the real world (like e.g. a stretch of road, an
intersection, a hotel, a public transport facility). In the terminology of transport telem-
atics such real world objects are called locations.
A TTI message provides information about a location, and refers to it by using a lo-
cation reference: an identifier used by the system that creates and sends the in-
formation, which can be interpreted without ambiguity by the receiving system. In
current systems for traffic information, locations are pre-defined and pre-coded, and
the codes are stored in location tables. The disadvantage of such tables is that they
need to be created and maintained, and need to be stored in the receiving system.
This becomes a problem when e.g. every street section in Europe needs to be ad-
dressable.
HISTORY OF LOCATION REFERENCING IN EUROPE
Early location referencing work in Europe was done in the framework of the RDS-TMC and Socrates developments, which both started end of the eighties [1]. InRDS-TMC, designed for the narrow-band FM subcarrier, a numbering system for lo- cations was developed. Location numbers, together with relevant information aboutthe location is stored in tables. Location number in combination with table numberand country code uniquely defines a location. The locations have a hierarchicalstructure.
Socrates was developed for the medium-band GSM cellular system. A primary Soc-rates requirement was the ability to address every road element. Furthermore, thereference code should include an area reference, for filtering purposes (called DirectArea Addressing). The Socrates location reference was named SLRN (standard lo-cation reference number). While RDS-TMC, partly as a consequence of the limitedbandwidth, focused only on the major road network, the arena of Socrates was thewhole network.
The idea for a common referencing system was introduced in the document"Proposals for a European Highway Network Referencing Standard" (Pandora project,1990) [2]. This document is a good example of an early description of locationreferencing requirements.
In the early 1990's it was actually tried to integrate RDS-TMC and SLRN coding.
SLRNs should be linked with an 8 bits subcode to an RDS-TMC location code.
Requirement from the Socrates side was that the RDS-TMC code would have a built-in area reference. This requirement was a major stumbling block, and after severalworkshops, it was decided mid 1994 to uncouple both approaches. The developmentof RDS-TMC location coding continued on its own, while the SLRN developmentswere discontinued. In Socrates tests during that period the link numbers of thedatabase applied, were used as SLRNs.
DIFFERENT METHODS FOR DIFFERENT PURPOSES
It is important to realise that requirements for map-based applications with respect tolocation referencing differ from requirements for applications that do not carry a mapdatabase. In most cases non-map-based systems will require some form of pre-coded locations, and as a consequence, location tables. The Socrates develop-ments focused on applications that do carry a map database. One could say that insuch systems the map database should be able to replace the location database,because it already contains most of the information stored in a location table (andeven more). A location referencing method to be developed for such systems shouldtake advantage of this fact.
ON-THE-FLY CODING: THE INTERSECTION LOCATION
The ERTICO Committee on Location Referencing was established to continue thework on Socrates type detailed location referencing, and started its work in September1995. It developed a new, universal method for location referencing for systems thatuse a map database [3]. The method is GDF compatible, although it can in principlealso work with non-GDF compatible map databases. A key characteristic is the on- the-fly coding approach. A code is created when needed by the system that sendsthe information, interpreted and used by the receiving system, and then discarded.
Pre-coding, maintenance and storage of location codes are not needed.
The coding basis of the new method is the combination of a geodetic identifier andone or more geographical identifiers. The geodetic identifier is a WGS84 co-ordinatepair that represents the position of the location. The geographical (or descriptive)identifiers, which are named road descriptors in ILOC terminology, help to reduceambiguity.
This approach has been worked out in detail for the Intersection Location or ILOC,from which the method derives its name. A Road Section can be referenced by anidentifier that combines the ILOC codes of the road section's two bounding intersec-tions. This means that with these two location types the whole road network can beaddressed, except for road sections inside a complex intersection.
An ILOC exists where two or more roads having different sets of road descriptors(like numbers and names) meet (i.e. at a crossing of 3 or more roads, or at oneroad, in a functional sense, where a road descriptor changes). The ILOC referenceconsists of the WGS84 co-ordinate pair of the approximate centre of the location,and 3 road descriptors.
The co-ordinates are longitude latitude in degrees decimal degrees, with a resolutionof 10 microdegrees. The road descriptor consists of the first 5 significant charactersof a road number or name (main road descriptor), or of another permitted descriptor.
Rules have been drafted to: • determine the approximate centre of a location Although in many cases the co-ordinate pair alone will be sufficient to determine thelocation in the receiving database, the descriptive part is used to resolve ambiguitiesthat may arise because map databases of different origin generally differ in specifi-cation, detail and resolution. The standard ILOC reference has the following physicalformat (see also Figure 1): long/lat
Figure 1 - Format of the standard ILOC reference. RD = road descriptor.
An extended ILOC reference has been defined to include a language code, for multi-lingual situations, and a location type code to further resolve ambiguity problems.
ILOC REFERENCE EXAMPLES
The following is an example of two ILOC references. The locations are close to theERTICO offices in Brussels (see Figure 2). Although a bi-lingual situation exists inBrussels, this makes no difference for the first example.
The first ILOC is a simple road crossing of the Ernest Allardstraat (in 2 directions),the Charles Hanssensstraat, the Watteustraat and the Van Moerstraat. The WGS84co-ordinates of the approximate crossing, taken from the NavTech map database,are (eastern) longitude 4,35388, (northern) latitude 50,83940.
Figure 2 - Brussels, ERTICO premises and nearby example intersection locations.
Coppensstraa
Rue Coppens
Charles Hanssensstraat/
ILOC 1
Rue Charles Hanssens
mstraat/Rue de l’Arbre
Rue Ernes
Rue de la Régence
ILOC 2
Joseph Duponts
Rue Joseph Dupon
BR
Regentschapsstraa USSELS
The road descriptor identifiers are, in alphabetical order, CHARL, ERNES, VANMO(the space is left out), and WATTE, of which the first 3 are used in the ILOC de-scriptor. The ILOC descriptor then reads: +00435388+5083940CHARLERNESVANMO
For the second example it is the question if one or two ILOCs exist. The approximatecentres of those two crossings are only 9 m apart. However, if we, for this example,take them as two separate ILOCs, then for the south-western crossing (the oneclosest to ERTICO) the two languages would lead to different ILOC descriptors, asshown below. Note that only two road descriptors are available. Spaces are indi-cated by an asterisk (*).
+00435455+5083875BOOM*REGEN*****
+00435455+5083875ARBREREGEN*****
ILOC AND OTHER LOCATION TYPES
Three location categories are currently being distinguished (Figure 3): Point Loca-tion, Link Location and Area Location. Each category may contain one or more loca-tion types.
The ILOC clearly is a Point Location, and it forms the backbone of the ILOC refer-encing method. A Point Along Road also is a Point Location by nature, but it may bedefined in two different ways. Although it may be described by the co-ordinate pair ofthe point combined with just one road descriptor of the road in question, it is (cur-rently) preferred to describe the point in terms of ILOC by a (directed) Road Section,and an offset relative to the From-ILOC. In this way it is possible to indicate to whichroad direction the point applies.
Figure 3 - Location categories and location types.
location category
location type
description
(directed) Road Section+offsetrelative to From-ILOC A Road Section is a Link Location, and is described by its two bounding ILOCs. Itcan be just a short stretch of a road between two consecutive intersections, it mayhave intermediate intersections, and it may even comprise a whole road. The identi-fier of a Road Section is the ordered combination of the two ILOC identifiers, the firstconsidered the From-ILOC, the other one the To-ILOC.
Area Location types have not yet been defined. It may be difficult to catch area loca-tions efficiently in the basic model (co-ordinates plus descriptors), except for somesimple approaches, like a circle or a box of a certain size with the co-ordinate pair ascentrepoint. An alternative coding scheme using e.g. NUTS administrative codesmay be feasible for administrative areas, as these are often defined in map data-bases.
Based on the current model, in principle the whole road network can be described interms of ILOCs, except for road sections that are internal to a complex intersection(that forms one ILOC). For these internal road sections a manoeuvre location wasdefined in [3]. A manoeuvre location is referenced by an ordered set of 3 ILOCs(From-ILOC, Via-ILOC and To-ILOC). The internal road section to be described ispart of the Via-ILOC, and the described manoeuvre is through that road section. Forone internal road section often two or more manoeuvre locations can be defined.
The manoeuvre location is currently not adopted by the EVIDENCE project.
A provisional logical data model for location referencing, adapted after the modeladopted by EVIDENCE [5], is shown in Figure 4. The model is suited for future ex-tensions with other location types that relate to the road network, but are not part ofit (e.g. POI locations - POI = point of interest).
PHYSICAL DATA FORMAT
The format of the ILOC reference as described before may change due to the testsperformed in the EVIDENCE project. In a message the size of the ILOC reference islarge compared to the sizes of other message elements (cf e.g. [6]). As air timecosts money, even for wide-band systems, there is an underlying goal to keep espe-cially the location references as short as possible. Looking at the ILOC reference,size reduction may result from less precise co-ordinates (e.g. 4 instead of 5 micro-degrees), less road descriptors (e.g. two instead of three), and shorter road de-scriptors (e.g. three characters instead of five). Currently a Road Section referenceis the concatenation of two ILOC references. If an ILOC reference would need threeroad descriptors, the currently defined Road Section reference would have six.
However, maybe four would be sufficient.
As the references of the different location types will differ in size, it will be necessaryto include in the reference a location type identifier. One could even imagine that fora location type two or more different size location references will be defined, also tobe distinguished by a type (sub)code. Which size will be used will then be dependenton ambiguity considerations.
Figure 4 - Logical data model for ILOC referencing. Adapted after [5].
THE EVIDENCE PROJECT
The one-year EU funded, ERTICO-led EVIDENCE project started 01 April 1998. Itfollows earlier manual tests between five different map databases, that were carriedout by the ERTICO Committee. These tests showed promising results. The mission of EVIDENCE is to refine and test the ILOC method for location referencing, and toprepare the method for future implementation. The project has nine partners, andalready eleven so-called sponsoring (i.e. non-EU-funded) partners, that joined at orafter the start of the actual project. This shows the great interest that exists for thistopic in the industry.
Refining and testing will be an iterative process. The current rules will be translatedinto algorithms, that will be implemented by each of the 5 participating databaseowners in their own database environment. Location references then will be createdby each, and sent to the other (mapping) partners. A received code will be decodedby the receiving partner, who will then will recode that same location in his own envi-ronment, and send the code back to the original sender. Of course a lot of additionalinformation needs to be exchanged during this process.
The rules for ILOC referencing as they were developed by the ERTICO Committee,entirely concentrated on the coding of a location, and not so much on decoding areceived location code. In the EVIDENCE project both aspects need to be thor-oughly addressed. The approach to coding and decoding will concentrate in the firstplace on the Road Section, as it is the most important location type for traffic infor-mation messages. As a Road Section is defined by two ILOCs, it in fact boils downto coding and decoding ILOCs.
Coding an Road Section means creating reference codes for the two boundingILOCs of the road section from a map database. In the future, when ILOC referenc-ing will be implemented, such codes will be created manually by an operator in aTraffic Information Centre, by clicking a piece of road in a map database on ascreen, or automatically (i.e. by software) from road sensor information, from theoutput of processed Floating Car Data, from information that was entered manuallyinto the system, or from a combination of these sources, using a model and softwarefor integration, and a map database to create the references. In the project the ap-proach for coding will be to use the map in a GIS platform on the screen, and to in-dicate a road section by selecting (clicking) it.
Decoding is different from coding. For each of the ILOCs a search area having itsco-ordinate pair as centrepoint, with radius of e.g. 100 m will be created. Within thisarea in the first place a search for matching road descriptors will be done. From theroad elements found the ILOC needs to be established. It will then be checked if thetwo ILOCs that are found indeed bound one Road Section.
Constraints for future implementation may be processing power and map data or-ganisation in the on-board unit. Although these aspects are not in the remit of EVI-DENCE, they deserve serious consideration.
ILOC REFERENCING FOR NON-MAP-BASED SYSTEMS
Although ILOC referencing has been created in the first place for use with systemsthat carry a map database, it could be used with systems that are not equipped with digital map data. Such lower-end systems as a minimum requirement need to havesome storage capacity for an event list. Part of this storage capacity could be allo-cated to store information on locations, allowing the low-end receiver to decodemessages carrying ILOC codes as the location reference. Which information isstored regarding the location, is essentially up to the service provider. The locationdescriptions can be provided on a smart card, or sent through the air. A set of loca-tion descriptions make up a location database, which in this approach may have adynamic character.
ILOC ADOPTED BY TPEG
TPEG is a bearer-independent, byte-oriented protocol for broadcast of traffic andtravel telematics services. It is being developed by Committee B/TPEG of the EBU inGeneva. The first application under development is Road Event Messages. ILOCreferencing has been adopted by TPEG as its premier method for location referenc-ing [6]. In a TPEG Road Event Message the ILOC code will be mandatory, whileother location identifiers (like RDS-TMC location code, GATS geocode, free text lo-cation description), pointing to the same location, may be used in a particular mes-sage in conjunction with the ILOC reference.
REFERENCES
1. Kees Wevers; Concise history of location referencing (based on introduction notes for the first meeting of the ERTICO Committee on Location Referencing);September 1995.
2. H. Claussen; Proposals for a European Highway Network Referencing Standard; PANDORA (DRIVE project V1010); 08 October 1990.
3. Ralf Duckeck, Volker Hiestermann, Hugh Milton, Michael Sena, Kees Wevers; Rules for defining and referencing an Intersection Location (ILOC): Detailed Lo-cation Referencing (DLR) for ITS based on ILOCs; ERTICO Committee on Loca-tion Referencing, Final Report (version 1.0); 15 April 1998.
4. EVIDENCE, Telematics Applications Programme, Sector Transport, Project No TR 4011; Annex 1 - Project Programme; EVIDENCE Consortium; 11 November1997.
5. Claus Dorenbeck, Hugh Milton, Michael Sena, Kees Wevers; Agreed location ref- erencing rules; EVIDENCE project deliverable D 2.1; 19 June 1998.
6. Kees Wevers; Road event messages for TPEG; paper to be presented at the 5th World Congress on Intelligent Transport Systems, Seoul, 13 October 1998.

Source: http://motfgds.mot.go.th/joomla1512/doc/download/gis/On_the_Fly_ILOC.pdf