The term ˜localisation , when applied to a physical communicating object, refers to the function that represents a given object and specifies its physical location, i.e. the place where the object is situated. This is the function that describes the geolocation services, i.e. the services that depend on the object's physical location.
Localisation of a physical object is, indeed, useful for the services that rely on the material or immaterial resources located near to the object [1] . But localisation is in itself not all-important; usually knowledge of the resources near to the object is enough to fulfill the service.
Moreover, knowing the coordinates of an object does not guarantee ability to identify the resources located near to the object and/or the resources related to its location.
So, to implement geolocation related services, localisation is neither necessary nor sufficient.
Reverse localisation is, as its name implies, the reverse of the localisation function: it is the function that takes a physical location as an input argument and returns the communicating objects located near or associated with this location.
And among the "objects" that are associated with a given location, it is possible to include the databases that register the non-computational resources located or related with this location.
Reverse localisation completes and extends the localisation of communicating objects, and if both are available, all localisation problems are probably covered.
But, are all these functions needed for most geolocation services?
It is worthy to note that the problems of localizing an object from nearby and localizing it from afar are not the same. For example:
A physical communicating object having at its disposal a GPS, or even better, a motionless physical communicating object, is able to know precisely where it is located. Nevertheless, it is not sure that this object could be remotely located.
Indeed, localisation and reverse localisation cover four different functions:
Localisation | Reverse Localisation | |
---|---|---|
From far | A) Telelocalisation | C) Telelocalisation |
Local | B) Local localisation | D) Local reverse localisation |
Some comments regarding these "localisation" functions:
These functions are related one to each other and they partly overlap. Particularly and trivially, if function (A) is available, a fortiori, function (B) will be so. And similarly, if functions (C) and (B) are available, (D) will be also available.
Provided that some conditions are fulfilled (see further on), the availability of local reverse localisation (D) is enough to compute functions (B) and (C).
So, depending on the kind of geolocation service, some functions may not be needed. Even more, for privacy reasons, some functions, like telelocalisation, might be unwanted or forbidden. Also, reverse telelocalisation could be also restricted to public spaces.
[1] Not all geolocation services fit in this scheme. Particularly, this is not the case of services that rely more on the path followed by the object than on its actual location: management of vehicle fleets, computation of an "optimal" path for a vehicle (car, plane, boat etc) or a pedestrian.