Towards a Landmark-Based Pedestrian Navigation Service Using OSM Data

1. Introduction

In recent years with the advent of mobile devices, which are connected to the Internet and have GPS functionality, more and more people are making use of routing and navigation services, which are now available whenever and wherever they are. Whereas car-based navigation applications tend to focus on distances and street names/numbers, pedestrians generally use (and prefer) landmarks to navigate from one place to another. However, mainstream routing services such as Google, Bing and MapQuest, still (at the time of writing) use pedestrian navigation instructions similar to those found in car navigation systems. Not only can this be problematic in cases where users are not good at judging distances or the street names used are occluded, a poor GPS signal can indicate to the user that they are far from the intended turn even after they may have actually already passed it. By using landmarks in routing instructions, a concrete reference point in the environment is formed. If the traveler’s GPS accuracy drops, they will still be able to see the physical object in the environment and make decisions based on that rather than what the GPS is telling them. Overall, commercial navigation services that are available today use similar principles for both car and pedestrian navigation, even though there is evidence that the distance-/direction-based instructions are not ideal for pedestrian navigation.

With the increase in GPS-enabled devices and aerial imagery, services such as OpenStreetMap have also seen a rise in usage. OpenStreetMap (OSM) is a prime example of Volunteered Geographic Information (VGI). VGI is a term coined by Goodchild [1] and refers to the geographical case of the user-generated content web phenomenon, whereby anybody can contribute information about the geographic world. Users can trace outlines of buildings, draw boundaries of urban districts and add information to objects, such as the name of a shop or the opening times of a sports center. In the case of OSM, all of this information is readily available to access and thus forms a vital data source for a number of scientific investigations. That said, it is important to be aware that the completeness of the OSM dataset is particularly heterogeneous with dense cities in Western Europe often having a far higher level of completeness than other places in the world. There is however always the possibility of the completeness of the OSM data to increase over time. The apparent availability of both geographical and semantic information contained within OSM makes it a prime candidate for containing information about features that could be seen as landmarks. The use of this dataset for such a landmark identification task is the topic of the investigation presented here.

The focus of this paper is the description of a prototype currently being developed for a pedestrian-based navigation service and the methods used within it. Within this service, the identification of suitable landmarks for delivery in routing instructions has been the primary research focus. Unlike a number of previous works, the landmark identification service presented only uses the potentially global OSM dataset as a data source for the landmarks, meaning that it is technically scalable to a larger scale implementation. The remainder of this paper is structured as follows. After a review in Section 2 of related works in the fields of navigation, landmark identification and OSM completeness, Section 3 and Section 4 present the methods used for landmark detection and the prototype developed for the navigation service. Focus is placed on the data used (OSM), methods for calculating metrics, which can aid in determining whether a feature could be seen as a landmark, and the overall architecture of the service. Section 5 then looks at the output of the service to provide a short comparison with mainstream routing services and the effects when routing is performed through an area with low OSM completeness. In addition, a short investigation is conducted to look at the suitability of the landmarks detected in comparison to those used by people when giving routing directions. Finally, Section 6 summarizes the work and presents the next stages for the prototype development along with suggestions for topics of future research.

2. Related Works

The use of landmarks in navigational instructions is closely linked to how we understand and construct mental representations of the environment around us. Over the years, much research has been conducted in this perception topic. In one of the earliest and most influential studies conducted by Lynch [2], it was described that when understanding an urban environment, all features can be placed into one (or more) of five categories: districts, ways, edges, nodes and landmarks. As such, the characteristics and usage of individual features alter how we perceive them and their role in the city as a whole. Appleyard [3] goes beyond the work of Lynch [2] to investigate the reasons why such features are “known”. From user studies, he determined that these attributes are linked to the visibility, form and cultural significance of a feature. The individual attributes identified were movement, contour, size, shape, surface, quality and signs (all for form), visibility from road structures, visibility at decision points and centrality to the line of view (all linking to visibility) and the intensity of use, the singularity of the feature in an environment and symbolic value (all representing cultural significance). Over the years, such attributes have become to be referred to as salience. Another highly influential study with regards to mental spatial representation is that of Siegel and White [4]. In their research, they identified that when learning an environment, three forms of spatial knowledge are generated: landmark, route and configuration. Landmark knowledge forms a representation of distinct features in an environment; route knowledge refers to routes between these distinct features; and configuration knowledge is a general overview of the environment as a whole. The necessity of landmarks for forming this knowledge highlights that landmarks are an important aspect of the navigation process.

2.1. Landmarks in Navigation

From the early studies, one aspect that appears to be extremely important with regards to understanding space is that of landmarks. Indeed, within wayfinding and navigation tasks, the use of landmarks has been found to be a key aspect [5,6], and a large amount of research has been conducted as to how landmarks are used in navigational tasks [4,7,8] with a distinct importance being found in relation to routing descriptions [6,9,10]. In particular, much research has emerged relating to pedestrian-based navigation [11,12,13,14,15,16], where the use of landmarks can be seen as highly beneficial.

As well as being presented at key decision points, May et al. [10] identified that it is also beneficial to provide landmarks in interim locations as a means of improving user confidence. They also state that distances and road names should not be relied upon in pedestrian navigation, though secondary information (which could be a road name) to confirm that the user has made a correct decision should be provided (i.e., “Turn left after Starbucks, onto Market Square”). Indeed, landmarks have already been integrated into commercial routing platforms, such as Australia’s WhereIs service (http://whereis.com.au). The methods implemented were those of Duckham, Winter and Robinson [17], and the research highlighted that landmark selection is direction dependent (the landmarks used on a return journey would be different from those used on the outward journey) and route dependent (landmarks mentioned at a turning point of one route may not necessarily appear in another route where the traveler continues straight forward at the same intersection). They also note that the commercially available routing services that claimed to use landmarks in navigation instructions did not appear to take into account many of the basic cognitive principles discussed in the literature. However, at the time of writing, routes generated through the WhereIs service no longer appear to provide landmarks within routing instructions.

In some research studies investigating routing and landmarks, rather than associating landmarks to generated routing instructions, the routes themselves are generated based on the presence of landmarks in the environments (i.e., [18,19]). Within these implementations, the structure of the landmarks in relation to the route being followed form a vital component for assessment, which highlights that the selection of landmarks is not solely dependent on their relation to their surroundings, but also is related to the route the person is following.

It is clear that landmarks form a vital role in navigation with many works discussing this concept. However, what makes a feature a landmark is another topic that needs addressing before features can automatically be presented in navigation instructions.

2.2. Characteristics and Detection of Landmarks

As mentioned, the salience of features is an important aspect of whether they can be used as landmarks [8,14]. This salience can be seen as forming from a relationship between the observer, the environment and the feature itself [20]. In work by Sorrows and Hirtle [21], the attributes that contribute to the saliency of a feature were split into three main categories: visual salience, cognitive salience and structural salience. These categories and the attributes within them are used in a number of later studies, such as those by Raubal and Winter [8] and Nothegger, Winter and Raubal [14]. These higher level categories can be mapped to those presented by Appleyard [3] with cognitive saliency mapping to symbolic value, structural saliency mapping closer to the attributes of Appleyard’s visibility category and finally visual saliency mapping closer to the form category.

Throughout the landmark salience literature, many studies have identified what types of attributes and characteristics of a feature contribute to its saliency. Often, these attributes are in turn mapped to the three salience categories mentioned. When looking at visual saliency, the predominant attributes include shape [8,14,15], size [8,14,15,22,23], color [8,14,15,22,24], complexity [23,24], height [23,24], age [22], name [22] and roof style [23]. The visibility of the feature is also important [8,14,15,22,25,26], which could be seen as both a visual and structural characteristic. Other structural characteristics include the relation of the feature to a road intersection or turning point [6,24,26], as well as distance from the road and the angle in relation to it [27]. Cognitive salience can often be attributed to aspects such as cultural and historic significance [14,15] and activity [28].

In general, a number of studies aimed at identifying landmarks from a dataset based on individual characteristics (i.e., color and height). Though it is indeed the case that such characteristics contribute to the overall salience of a feature, the presence of information for these characteristics is often lacking in datasets. Throughout the studies relating to landmark identification, a number of different data sources have been utilized. Such datasets include cadastral datasets [27], collections of street level photography [14,15] and 3D city models [23]. Though many of these data sources have the potential to provide useful information, many require either manual interpretation and data collection or are only available for smaller areas. As such, many methods for landmark extraction have been successful in determining what makes a landmark and thus selecting appropriate features from a dataset, but are generally not applicable for large-scale deployment.

In more recent studies, a trend has emerged of using types of feature as a proxy to its salience. In the methods presented by Duckham, Winter and Robinson [17], the type of a feature (i.e., if it is a restaurant, church or embassy) is used in the identification process as opposed to individual characteristics. The basic concept is that some types of features generally stand out in the environment and, as such, could become landmarks. The method itself aims at identifying how salient a type of building is and how likely that an individual instance of that type would fit with this salience. In an example provided, they highlight that a church could be typically seen as a landmark, due to (in a large part) its physical characteristics, but in some cases (such as a hospital chapel), the “church” might not be visible and, so, would not be suitable. Using a method for taking into account both of these aspects, scores were assigned to the types of features. The implementation of this method in the WhereIs platform shows that such a method is viable for large-scale usage. In fact, Richter [29] indicates that the use of categories as opposed to individual characteristics is a promising direction of implementation, as it reduces the need for detailed datasets describing individual properties.

Following a similar approach of using feature type as a salience indicator, Dräger and Koller [16] propose the use of specific features for inclusion in navigation instructions for car drivers. Though their selection methods appear to be less well formed than those of Duckham, Winter and Robinson [17], an aspect of particular interest is the data source: OpenStreetMap (OSM). The usage of OSM as a data source directly helps in relieving a challenge identified by May et al. [10]. They remark that a predominant challenge when they performed their investigation was the availability of a navigable database containing information that could be used to identify landmarks. OSM could be this navigable database.

Away from the aspects that make a feature a possible landmark, the study presented by Richter [30] presents a promising approach that looks at detecting the role of landmarks for routing instructions based on their relation to a decision point. Such analysis is performed by automatically deriving information regarding the in and out direction of travel for the decision point and how the vertices of a feature relate positionally to these directions. Though the paper admittedly does not provide information regarding how the features that are landmarks are themselves determined, the methods detailed could be applied to a pre-existing service that defines these landmarks. Therefore, the methods can be seen as primarily addressing the structural component of landmark saliency as opposed to the often more documented visual and semantic saliency aspects.

From the studies reviewed, several characteristics relating to what makes a feature a landmark have been identified. A major challenge however is that data relating to these characteristics are often hard to come by and time consuming to collect. One of the most promising approaches to circumnavigate this issue is (as mentioned) the use of feature types as a proxy to their saliency. Such information is much more widely available in datasets such as OpenStreetMap.

2.3. OpenStreetMap as a Data Source

In more recent years, OpenStreetMap (OSM) has emerged as a vast source of Volunteered Geographic Information (VGI) that could be used as a source for such information. Indeed, a number of the studies mentioned have either suggested the use of or have made use of the OSM dataset. OSM aims at creating open geodata where users can actively contribute and edit geographic information [31], which can be used by other services. Two primary benefits of the OSM dataset are that it contains a vast amount of semantic information that often surpasses that provided by commercial suppliers and the data can be quickly updated in response to errors [32].

Several services have made use of OSM data, including the OpenRouteService (ORS) (http://openrouteservice.org) and Wheelmap (http://wheelmap.org). The ORS [32,33] uses the road network data from OSM within routing algorithms and provides an open API supporting the OpenLS framework [34]. In the past, attempts were made to add landmark-based navigation directly into the OpenLS framework and ORS, though selection processes were limited based on a limited source of properties about potential landmark candidates [35]. More recent studies (as already mentioned) that attempt to use OSM as a source for landmark information include Dräger and Koller [16] and Zhu and Karimi [36]. OSM has also been used by humanitarian organizations as a source of valuable information [37,38].

OSM is not without its weaknesses, however. Though the OSM dataset contains a vast wealth of information, the coverage is not the same for the whole globe, and several studies have addressed the quality of the data. In densely-populated areas of the Western world, the OSM dataset can however be seen as being comparable to authoritative datasets in terms of quality [39,40]. For such areas, it could be seen as a useful source of data that can be used for identifying landmarks. However, in rural areas, the completeness of OSM data can cause problems with landmark detection processes [41], but pedestrian navigation could generally be seen as having a higher use case within more urbanized areas where data availability is higher.

2.4. Summary

From the literature reviewed, it is clear that landmarks are an important aspect of navigation and that the suitability of a feature for being used as a landmark is highly dependent on a number of characteristics. In a number of studies, in-depth evaluation has taken place, which used detailed information about features in the environment. Though these studies generally provided useful reasoning behind why some features are landmarks and others are not, the underlying evaluation of features required information, which is not widely available and is time consuming to collect. As such, these fine-scale methods are not suitable for implementation in services that cover large areas. The alternative proposed in other research investigations is to use types of features as a proxy to whether they could be seen as a landmark. Though such methods likely introduce more instances where unsuitable features are detected as landmarks, the benefits are that the level of detail for attributes in the data is much lower. This means that more generic datasets can be used as a source for the features and landmark detection algorithms. Even with this capability, however, global data sources such as OpenStreetMap are not being utilized as a repository for detecting and providing landmarks in navigational instructions. One reasoning behind the lack of using OSM is that in rural areas, the completeness of data can cause problems with landmark detection processes [41]. Though this can cause problems, OSM could still be a valuable source of information in urbanized areas, and the use of its data in a landmark detection algorithm is the focus of the remainder of this paper.

3. Landmark Identification Methods

As identified in the literature, it is clear that to successfully extract landmarks from a set of features, it is important to take into account several characteristics, such as distance from the decision point and the visual saliency of the feature. Based on the prior literature discussed in Section 2, several methods have been implemented within the navigation service currently being developed in an attempt to identify and deliver landmarks in routing instructions. This section describes the data source used (OSM) and the methods implemented.

3.1. Data Source

Within the navigation service developed, OSM was chosen as the data source. The primary reason for this decision was, as mentioned earlier, that the data, which contain both geographical and semantic information, are openly accessible and, in the target areas for usage (predominantly urban areas of Western Europe), can be seen as relatively complete. The underlying data structure for OSM comprises three primitive feature types: nodes, linestrings and relations. Nodes are point-like features; linestrings are a collection of joined node features; and relations are used to describe relationships between features that may not be obviously physically connected (i.e., bus stops on a bus route). Polygon features are not directly stored in OSM, but are instead generated from closed linestrings. As well as the geographic coordinates being stored for the features, attributes are also stored in the form of “tags”. These tags are key-value pairs, and each feature can have any number of tags (though no key can be duplicated in the same feature). For example, a hospital building could be represented as a closed linestring with the tags building = yes and amenity = hospital. Within OSM there is in fact a key for landmarks, though globally less than 1700 features have a tag with this key.

When looking at OSM data for the Greater London area (U.K.), several characteristics can be identified regarding aspects that could be used in landmark identification. When assessing the availability of information required for individual characteristic methods (such as color and height), it becomes evident that there is a lack of such information. Of the 291,801 polygon features identified as being buildings (contains a building tag, which is not set to no), 6822 (2.3%) contain a tag indicating the color (building:colour or colour) and 398 (0.14%) carry a height value (building:height or height). For the 299,572 nodes that have some attributes associated with them (they have one or more tags), only 228 (0.076%) contain a color value and 57 (0.019%) contain a height value. Of all features in the greater London area, 14 nodes (0.005%) have a landmark tag, with no polygons/linestrings carrying the tag.

On the other hand, if particular types of features are used (see

Table 1. Feature types used for landmark selection.

Key	Value	Additional Requirements	Salience Weight
amenity	arts_center	-	0.1
	bank	name/brand	0.5
	bar	name/brand	0.8
	café	name/brand	0.8
	courthouse	-	0.4
	embassy	name/brand	0.1
	fast_food	name/brand	0.8
	fuel	name/brand	0.9
	pharmacy	name/brand	0.3
	pub	name/brand	0.8
	restaurant	name/brand	0.9
	theatre	-	0.4
	town_hall	-	0.5
building	cathedral	-	1
	chapel	-	1
	church	-	1
	mosque	-	1
	synagogue	-	1
	temple	-	1
crossing	traffic_signals	-	0.3
highway	traffic_signals	-	0.3
historic	clock	name/brand	0.4
	memorial	name/brand	0.7
	monument	name/brand	0.7
	statue	name/brand	0.6
leisure	park	-	0.2
	pitch	sport	0.3
	playground	-	0.7
	sports_center	-	0.3
	swimming_pool	-	0.1
railway	station	name/brand	1
	subway_entrance	name/brand	0.7
	tram_stop	name/brand	0.6
shop	*	name/brand	0.8
tourism	artwork	artwork_type	0.5
	attraction	name/brand	0.5
	gallery	name/brand	0.1
	hotel	name/brand	0.9
	information	-	0.3
	museum	name/brand	0.6

for a list of feature types), then 22,299 (7.4%) node features are obtained. If the polygon features are queried, then 15,860 features of 359,847 polygons (4.4%) are identified. The polygon search parameters were relaxed to include all polygons in this search and not just buildings. This is because features such as parks and playgrounds, which could be seen as landmarks, would not necessarily be buildings. From these values, it is clear that OSM generally lacks the information about individual visual characteristics of features, but a large number of features contains information regarding the type/usage.

Obviously, as mentioned earlier, the completeness of OSM data varies between locations, but in an urban setting where pedestrian navigation is of more use, the presence of data should be sufficient (in particular in Western Europe). In the county of Hertfordshire in the U.K. (~1640 km²), which has a similar area to Greater London (~1570 km²), there are only 2225 nodes and 2306 polygons that match the feature type parameters. These figures represent 4.0% of 57,855 polygons (any polygon in the dataset, not just buildings) and 3.6% of 61,859 nodes (containing at least one tag). Obviously, the number of real-world features that the landmarks can be drawn from is much smaller in the Hertfordshire area, which has a much lower average population density (approximately 700 persons/km²) than Greater London (approximately 5500 persons/km²), which is a result of far less urbanized area in Hertfordshire than Greater London. Figure 1 shows the landmark candidate density based on the feature type method within the Greater London and Hertfordshire areas.

From this investigation into the availability of landmark candidates in these two areas, it can be seen that in more densely-populated areas, there is a larger pool of landmark candidates. This is likely due to two reasons: in higher density population areas, there would likely be more amenities and facilities that could be landmarks, and it has been shown in the literature that higher density population areas are more complete with regards to OSM data [39]. Therefore, it must be noted that in less densely-populated areas, the effectiveness of any tool relying on OSM data could be diminished.

Overall, the information regarding the usage of feature types vs. individual characteristics and the distribution of features in urban and rural regions has shown that considering the type of feature yields many more landmark candidates, but even then, the availability of candidates in rural areas is limited. Such results should be taken into account when assessing the usage of OSM data in landmark identification processes as performance in one geographical area may not be the same in another.

3.2. Landmark Identification Methods

Using OSM as a source of information about features in the environment that could become landmarks, methods based on previous studies in the field of landmark identification and navigation have been implemented. These processes have been integrated into a service (described in Section 4) that generates navigation instructions that contain landmarks for a route. This section will now discuss the methods used in the identification process which focusses on the identification of six primary attributes: visual/semantic saliency, distance from waypoint, visibility, position, location, and uniqueness.

When identifying a suitable landmark for a decision point on a route, it is important to know the location of the decision point, the direction the traveler is coming from and the direction they should end up taking. Once the location of the decision point is known, the first step is to select all features within the vicinity that could be a possible landmark for the decision point. This is accomplished in the service by selecting all features that are identified in OSM as being of a particular type or usage within a 50-meter buffer around the turning point. This distance is a value selected based on experimentation with different distances to cover enough area to provide landmark candidates, but not so large as to include features at too large a distance. Using a smaller value also increases the performance of the service. In the case that the previous decision point is less than 50 meters from the current decision point, the buffer distance is set to be the distance between the previous and current decision points. This ensures that landmarks are not selected behind the traveler. The type/usage tags used for selection can be seen in Table 1. The tags have been selected based on a combination of previous studies, the frequency of tag usage in OSM and the opinion of the authors regarding the generic feature types that could be seen as landmarks under the correct circumstances. This will however be updated in future prototypes to take into account feature types identified by end users.

In some cases, such as features marked as shops, additional information must be present, which indicates the name or brand of the shop. This is because in many cases, multiple shops would be in the same vicinity, and thus, the extra information is needed to distinguish individuals.

When selected, each feature is also assigned a salience weight value, which is shown in Table 1. This value represents a proposed visible/semantic saliency value when used in the overall suitability scoring. These saliency weights have been initially derived by the authors following similar principles to those presented by Duckham, Winter and Robinson [17]. After initial determination, the values have been subjected to iterative changes based on the results obtained from running the extraction process. It was identified that in some cases, particular feature types that were popular in an area were becoming dominant even though other factors (such as distance from the decision point and uniqueness) should make the individual features less suitable. By updating the visible/semantic saliency weight, such over-selection was reduced.

Once the landmark candidates have been selected, geometric evaluation is performed to identify additional aspects of the features in relation to the decision point, which can contribute to the overall suitability as a landmark. These processes aim at determining:

• The distance of the feature from the decision point,
• The visibility of the feature as the decision point is approached,
• The position of the feature in relation to the decision point (before, after, alongside)
• The location of the feature in relation to the current direction of travel (to the left or right)

Within the calculation of these aspects, a number of locations on the route and landmark candidates are required. These locations are:

• The waypoint (decision point) itself (WP)
• The reference point on the current route segment (RP). This point is a location on the route approaching the waypoint that is the same distance from the waypoint as the value used as the distance of the buffer for selecting features in the area (default 50 meters)
• The point on the perimeter of the landmark candidate that is closest to the waypoint (LWP)
• The point on the perimeter of the landmark candidate that is closest to RP (LRP)

In the case that the feature is a point, some extra steps are taken before the aforementioned locations are derived. Firstly, if the point feature is located within a building polygon (as is often the case in OSM), then it is moved to the closest point on the perimeter of the building footprint. If it is not within a footprint, the location of it stays the same. Next, a small buffer of 0.000001 decimal degrees is placed around it and the resultant perimeter of the buffer used as the feature. The main reason for applying this buffer is that it ensures that the algorithms described can be applied to both point and polygon OSM features, as ultimately both are represented as polygons within the processes.

Distance from the waypoint: When looking at distance from the waypoint, it has been identified from the literature that closer features to the waypoint are often more suitable. Therefore, the indicator for distance is determined by calculating the Euclidean distance from WP to LWP. This value is then normalized before final suitability calculation to be between zero and one based on the equation:

$$D=1-d/MD$$

(1)

where D is the final value, d is the Euclidean distance between WP and LWP and MD is the maximum distance signified by the maximum search distance for landmarks (50 meters in this implementation).

Visibility of feature: For determining the visibility of a feature, a simple and naive approach is currently being used. Though not optimal, the method is relatively fast and would give correct results in most circumstances, and an assessment of visibility is often seen as a very important metric [10,22,25,26]. To calculate the visibility, a line is created between RP and LRP. This line is then compared to building footprints in the area to determine the visibility based on intersections with the footprint polygons. The building footprints are identified from OSM by selecting all features in the area that are a polygon and carry a building tag. Rather than simply identifying if the line crossed a building footprint, the length of any intersection was calculated. In the case that no footprint was crossed, then this value would be zero. However, due to artifacts created from geographic projection and slight data inaccuracies, it is often the case that the landmark candidate would have minute intersections with the feature in the building footprint set that represents it (i.e., a polygon feature for a church would be present in the candidate dataset, and the same polygon would be present in the building footprint dataset). Using a minimum threshold value (approximately 10 cm), it is possible to remove the majority of errors introduced due to this problem. The resultant calculation is a binary value of zero if the feature is not visible on the approach to the waypoint (there are intersection lines with building footprints of more than 10 cm) and one if it is visible.

Position in relation to the decision point: Calculation of the location of the feature with regards to the decision point is a more complicated value to derive as it requires a number of comparisons. The end result is an indication that the feature is before, after or alongside the waypoint. The metric of location in relation to the turning point is derived by identifying differences between the distances of WP to RP, RP to LRP and RP to LWP. In the case that RP → LRP and RP → LWP are less that RP → WP, it can be assumed that the landmark candidate is before the turning point. If RP → LRP is greater than RP → WP, then the landmark can be assumed to be after the turning point. When RP → LRP is less than RP → WP and RP → LWP is greater than RP → WP, then it can be assumed that the landmark candidate is found alongside the WP. Looking at Figure 2, it can be seen that the distance between RP → LRP₁ is less than RP → WP, but RP → LWP₁ is larger than RP → WP; therefore, that feature is said to be alongside the turning point. RP → LRP₂ and RP → LWP₂ are both larger than RP → WP; therefore, that feature is seen as being after the turning point. Finally, both RP → LRP₃ and RP → LWP₃ are smaller than RP → WP, and so that feature is seen as being before the turning point. Figure 2 shows the information used for calculating the position of three features in relation to a turning point.

The location of the feature in relation to the current direction of travel: The final geometric calculation is used to determine whether the feature is on the same side of the road as the turning point, or on the opposite side. To determine this, the azimuth angles between LWP → RP and RP → WP are compared. If the angle LWP → RP → WP is between −180° and 0°, then the feature is seen as being on the left of the waypoint. If the angle is between 0° and 180°, it is deemed as being on the right-hand side. This information is then compared to the direction of travel to determine whether the feature is on the same side as the turning or not.

After calculation of the geometric aspects of the features in relation to the decision point, the uniqueness of the feature within the candidate set is determined. Obviously, if there are multiple features of the same type in the vicinity of the decision point, it will be more difficult for the user to determine which feature is being referenced as a landmark. The uniqueness of the feature is calculated using:

$$U_t=1/n_t$$

(2)

where U_t is the uniqueness of feature with type t and n_t is the number of features within the candidate population with a type of t. This calculation results in features whose type does not occur again in the candidate selection as having a value of one and those with multiple occurrences having a proportionally smaller value (two features of the same type would both have a uniqueness value of 0.5).

Once all of the values described have been calculated, they are used to derive an overall suitability score. The landmark candidate with the highest score is used as the landmark in the routing instruction. The final suitability metric S is determined as:

$$S=V\times P\times Ld\times \left(D+U+Sa\right),$$

(3)

where V is the visibility of the feature (zero or one), P is the position of the feature in relation to the decision point (after = 1, alongside = 2, before = 3), Ld is the location in relation to the direction of travelling (opposite side = 1, same side = 2), D is a normalized distance from the waypoint value (zero to one, with one being closer), U is the uniqueness of the type in the candidate set (zero to one with one being the most unique) and Sa is the proposed salience based on the feature type (zero to one with one being the highest salience value). By using the visibility metric as a multiplier, it is ensured that candidates that are not visible on the approach are always given a suitability value of zero. For position, one is given to candidates that are after the way point, two for those alongside it, and three is given to those candidates that are before the way point. The weighting values (i.e., two for alongside and three for before the turning point, and weightings for the side of the road) have been determined based on findings from the literature where it is documented that landmarks before and on the same side as the direction of turning are preferable [17,26]. In the case that the decision point does not require a change in direction (the person continues forwards), the value for Ld is always set to one no matter what side of the road the feature is located.

As an example of this process, consider a decision point as shown in Figure 3. In that location, the traveler is coming from the west, must cross the street and then continue east. The waypoint (WP) is depicted as the five-pointed star, and the reference point (RP) is the six-pointed star. Based on visibility, only three of the 15 candidates can be seen as being suitable as landmarks, as all others can only be seen when relatively close to the waypoint (the building footprints are shown as solid polygons). The resultant values used in the calculation of suitability can be seen in

Table 2. Landmark candidates for a decision point.

	Type	Visibility	Position	Location	Uniqueness	Distance	Score
1	theatre	visible	before	left	1	0.487	5.062
2	restaurant	visible	after	right	0.2	0.088	1.155
3	pub	visible	before	right	0.5	0.597	5.692

. As the direction of travel is to continue forward, the value used for location in for all features is deemed to be one, no matter which side of the road they are located. From the potential candidates, Feature 3 is deemed to be the most suitable (1 × 3 × 1 × (0.597 + 0.5 + 0.8) = 5.692). This results in the instruction being “After the Salisbury pub, continue forwards”.

Though the usage of these metrics in a landmark suitability calculation is not a new aspect of the research, their implementation here shows that all of the required information is available from the OSM dataset. All calculations are performed automatically and require no additional input other than this single dataset.

4. Service Development

As discussed, the purpose of identifying landmarks is that they can be delivered in navigational instructions within a routing service. For this, a navigation service prototype has been developed. The overall navigation service developed comprises two main components: the Landmark Identification Service (LIS) and a mobile client. The LIS implements the methods described above to generate routing instructions, which contain landmarks where possible, and then, this information is passed to the mobile client, where it is provided to the users during their navigation process.

4.1. Landmark Identification Service

The Landmark Identification Service (LIS) is an Apache Tomcat web service that generates landmark-based routing instructions and handles all communication with third party services (such as ORS and an external OSM database) required for this task. Its primary function is to obtain a pedestrian route from the ORS and then derive landmarks to be given in instructions based on this route and user location. All requests to the LIS are performed through an open API. The workflow for generating a route and providing instructions can be seen in Figure 4.

In a general instance of pedestrian navigation, the requesting agent would first send a request to the LIS for a route. This request consists of a starting point, an ending point and places to avoid (i.e., if the user selects that they do not want the route to go to a particular location). Depending on the circumstances, the request can also contain additional parameters describing restrictions (i.e., avoiding raised curbs). The LIS then passes this information to the ORS, which generates a suitable route. This route is then passed back to the LIS, where it is stored in a local database, and the route information is in turn passed back to the requesting agent. Then, when the user is travelling along the route, the agent would send requests at specific intervals to request the next navigation instruction based on the user position and the route being followed. The LIS then uses this information to identify a landmark that is determined to be suitable for the next turning point and passes it back to the requesting agent along with directional and positional information (i.e., “Turn left after the Starbucks café”). This landmark selection process is based on querying an external OSM database for landmark candidates and computing suitability based on methods described in the previous section.

The instructions generated are associated with segments of the route and are in reference to the action to take at the end of the current route segment. These route segments may contain a number of smaller line segments, with algorithms implemented to split the route at major decision points as opposed to at all points that the route changes direction. Though this results in more instructions than other services (such as multiple “continue forward” instructions), such information could be useful not only in ensuring that the users continue following the route, but also acts as confirmation that they are on the correct path.

When returning information to a requesting client, the information is communicated in a structured data format. Rather than a textual sentence being returned back to the user, such as ‘Turn right after the Starbucks café, following Hauptstraße’, the instruction is returned as a series of text parts in the form of “|left|Starbucks|café||after|following|Hauptstraße|turn” following the pattern “adjective|direction|name|noun|ordinal|preposition|road action|road name|verb”. These parts describe all elements of the instruction in a format where individual components can be extracted and interpreted. For example, in the mobile client, the direction and verb components are used to draw a directional arrow on the display. In other applications, these components could be translated into vibrations or other feedback methods. To convert the instruction into a human readable format, the LIS API can also be called to decode the information via natural language processing. This natural language processing is performed using the SimpleNLG package [42], which has been extended for several localizations [43,44,45].

4.2. Mobile Client

The mobile client for the navigation service has been developed as a native Android application. Though this app has been developed specifically for use with the LIS, any agent can make use of the LIS through its open API.

The primary purpose of the mobile client is to deliver the navigational instructions to the end user whilst they are travelling along a generated route. At the first instance, the user is able to select target destinations through either textual searching or dropping a pin on a map view, or by selecting a place of interest from a list of locations obtained from the Wheelmap (http://www.wheelmap.org) service. Communication with Wheelmap is performed directly from the client to the Wheelmap API and not through the LIS API.

When a route is generated based on parameters set by the user (currently mobility-orientated restrictions, such as avoiding specified heights of drop curbs and specific surfaces), the user is presented with instructions for navigation. These instructions are generated by using the GPS location of the device and the unique id of the route being followed, then passing this information to the LIS. This process is performed constantly throughout the navigation task at predefined temporal spacings. As well as a visual display (see Figure 5) of the instruction, the user can also switch to a map view for a general overview of the route as a whole. The instructions are also vocalized via the text-to-speech functionality of the user’s mobile device. This vocalization is performed once when the instruction changes and once when the user approaches the way point. To aid in determining the direction that should be followed, a compass-like display is presented, which indicates the relative direction to the way point for which the instruction is.

In the event that the user deviates from the intended route, the client will receive an empty instruction from the LIS. When that happens, the application knows that the user has deviated too far from the route for some reason and thus sends a request to regenerate the route with the users current position used as the starting point.

5. Service Evaluation

As a means of assessing the landmarks generated by the service, two short investigations have been conducted. These investigations aimed at identifying whether the service can provide landmarks at decision points along a route and whether these landmarks match those given by people providing routing instructions.

5.1. Landmark Detection

To assess the performance of the service in comparison to instructions generated from mainstream routing service, the same route was generated in the different services and instructions compared. With a route generated within central London (see Figure 6), the navigation service provides landmarks for six out of nine waypoints along the route (the end point is not counted as a waypoint as there are no actions to be taken there). The instructions themselves were comparable to the Google, Bing and MapQuest services, though none of those services provided landmarks in their instructions. An example of the instructions for Point 5 for each of the services is as follows:

• Google: “Continue onto New Row”
• Bing: “Road name changes to New Row”
• MapQuest: “Turn left onto B404/St. Martin's Lane; Turn right onto New Row.”
• Navigation Service: “Continue forward after the Salisbury pub, following New Row.”

Obviously, the inclusion of landmarks in instructions is dependent on the completeness of OSM data. In areas where data are lacking, the instructions given are much more similar to those of the mainstream services (i.e., landmarks are not included). In Figure 7a, the route was generated in Gospić, Croatia, where OSM data completeness is low in terms of features that could be landmarks even though it is a relatively urbanized location. This location was selected due to the author’s existent knowledge of the area and that whilst still located within Europe (a primary target region for the prototype), it has a lower population density and is in a region with relatively low OSM completeness. In that route, no landmarks were provided for the instructions. At WP 8, the instructions for each service are as follows:

• Google: “Turn left onto Budačka ul.”
• Bing: “[Turn right on to Ž5154], and then immediately turn left on to D25/Budačka Ulica”
• MapQuest: “Turn left onto D25/D50/Budačka ulica.
• Navigation Service: “Turn left, following Budačka ulica.”

One thing that should be noted is that extra instructions were provided by the navigation service (namely WPs 3, 9, 10 and 12) compared to the other services (11 for the navigation service, 7 Google, 6 Bing and 6 for MapQuest). Instructions generated from the different services can be seen in

Table 3. Instructions generated for route in Gospić, Croatia.

WP	Google	Bing	Map Quest	Navigation Service
2	Walk south-east on Trg Stjepana Radića towards Ul. popa Marka Mesića	Leave Ulica Bana Ivana Karlovića towards Ulica Popa Marka Mesića	-	Turn left, following Trg Stjepana Radića.
3	-	Turn left, and then immediately turn left on to Ulica Vile Velebita	-	Continue forward, following bana Ivana Karlovića.
4	Turn left to stay on Trg Stjepana Radića		Turn left.	Turn left, following bana Ivana Karlovića.
5	Turn left to stay on Trg Stjepana Radića	-	Turn left onto Trg Stjepana Radića.	Turn left, following Trg Stjepana Radića.
6	Turn right onto Ul. Nikole Tesle	Turn right on to Ulica Nikole Tesle	Turn right onto Ulica Nikole Tesle.	Turn right, following Ulica Nikole Tesle.
7	Turn right onto Ul. Dr. Franje Tudmana	Turn right on to Ž5154, and then immediately turn left on to D25/Budačka Ulica	Turn right onto 59082.	Turn right, following Ulica Nikole Tesle.
8	Turn left onto Budačka ul.		Turn left onto D25/D50/Budačka ulica.	Turn left, following Budačka ulica.
9	-	-	-	Continue forward, following Budačka ulica.
10	-	-	-	Continue forward, following Budačka ulica.
11	Turn right	Turn right on to road	Turn right.	Turn right, following Budačka ulica.
12	-	Keep left on to road	-	Continue forward.

. In some cases, more instructions could be confusing to users, and so, efforts should be taken to avoid a surplus of instructions. As such, it may be the case that the navigation service requires some modification to reduce the amount of instructions that are generated, especially when landmarks are not provided.

This short comparison shows that the landmarks detected can be integrated into routing instructions when they are available. When landmarks are not available, the instructions generated are more similar to mainstream services in that only road names and direction (and distance) are provided. However, it does not show whether the landmarks detected are suitable for the instructions. As a means of assessing the suitability, a brief investigation has been performed comparing instructions generated by people and those generated by the service. This investigation will now be discussed in the following section.

5.2 Landmark Suitability

As a short investigation into the landmarks that are being detected by the service, some routing instructions were obtained from participants and the information compared with the instructions obtained for the same routes via the navigation service. Participants were recruited from the GIScience research group at the University of Heidelberg and comprised employees and students. The participants were asked to provide a textual description of a route that they are familiar with as if they were providing instructions to a person not familiar to the area. In total, six routes were obtained, which contained in total 31 landmark mentions. Landmarks were extracted based on the mention of explicit features that are used at key decision points, such as “… there must be a Burger King on your right…” and “… there is a traffic light and several bus stops”. The decision points where these landmarks were mentioned were then compared with the same decision points on the routes generated from the navigation service. Aspects such as “cross the road” and “walk across the bridge” were not counted as landmarks, as the features form an integral part of the route that must be traversed as opposed to being a feature used to guide the person.

When comparison was undertaken, it becomes apparent that there is a considerable difference between the features described by the participants and the landmarks detected by the service. In some cases, this can be accounted for by the geometry of the landmark or the use of landmarks that are more global in nature. For example, in one instruction where a restaurant was given as a landmark, the same feature was not included from the navigation service due to its geometrical representation in the dataset as a point. This point representation resulted in landmark location being shifted to the closest edge on the building footprint. The restaurant itself is located on the corner of the building and, so, is visible on the approach to the turning point, as well as after it, but the shifted point is only visible after the turning point. This means that the service perceives the landmark as being not visible and, thus, not selected, even though in reality, it is visible due to being present on both sides of the corner feature (see Figure 8). With regards to the more global landmarks, instructions were given, such as “… you will see the water tower and follow this direction...”. In the case of that instruction, though the water tower is visible, it is actually 1.2 km in the distance from the decision point. As the navigation service in its current form only looks for local landmarks, such a feature would not be included in the instructions.

Overall, from the 31 landmarks provided by participants, only four matched the landmarks selected by the navigation service at the same decision point. Though these results appear sub-optimal, it does not necessarily show that landmarks chosen by the system were unsuitable. In many instances, it is likely the case that the landmark selected is simply not as memorable as the ones chosen by the participants in their instructions. The service does not necessarily aim to produce memorable landmarks, but when people recall familiar routes from their own memory (as done in this comparison), they would obviously only use landmarks that were memorable enough for them to stay in memory. For example, in one instruction where an urban square/park is provided by the participant as the landmark, the service chooses a nearby shop instead. A reason for the participant selection of this feature is that the park is a well-defined green area amongst buildings. It was likely not selected by the service due to being at a greater distance from the waypoint and a lower weighting given to park features over shops. However, the shop used in the instruction is relatively easy to notice, but obviously not as memorable in the area as the park. Ultimately, a more in-depth investigation that takes into account the recollection and remembrance factor of features in the routes recalled from memory needs to be conducted to ascertain the full suitability of the derived landmarks.

6. Conclusions and Future Work

This paper has presented a prototype system that has been developed for providing landmarks in pedestrian-based navigation instructions. Though a large number of studies have been conducted previously that focus on attempting to (and often succeeding in) deriving and presenting landmarks in navigation instructions, they often rely on detailed datasets and are thus only applicable in small areas. In the methods implemented in this prototype, OpenStreetMap has been used as the only data source for landmark identification. This means that dependent on OSM completeness, the method could be used in potentially any location with minimal modifications to the data source and methods. Though landmarks were successfully selected from OSM using various methods to identify suitability, the process is not without its shortcomings. Initial testing has shown limitations based on underlying OSM completeness, and more sophisticated methods are required to investigate the suitability of those landmarks detected.

One problem identified early is the availability of features in the OSM dataset that could become landmark candidates. When looking at the Greater London and Hertfordshire areas of the U.K., it was apparent that in less urbanized areas, the availability of landmark candidates dropped. This is likely due to the areas being less well mapped in OSM and a general lack of features in the real world that would match the criteria proposed here for landmarks. This results in the provision of landmark-based navigational instructions being diminished in less urbanized areas, but as shown, in those instances, the service reverts to the more classical road name method of navigation. As the road names are derived from OSM, however, a lack of data is still an issue, but the road networks tend to be much better documented in OSM than other features.

Overall, the primary contribution of the methods presented here is that they demonstrate that OSM has the potential to be used as a data source for landmarks when combined with previously identified methods for deriving saliency. The service successfully extracted landmarks from the OSM dataset without the need for additional attributes and data and was then able to provide these in navigational instructions. Obviously, the effectiveness of the landmark identification service diminishes in areas with low OSM data completeness or in regions where less features are present that could actually be seen as landmarks, but this should not discourage the usage of OSM as a data source, as in time, it will continue to grow and the information will become more complete. As such, though, it should be highlighted that though it appears that landmarks can be provided in routing instructions within urban areas when OSM is used as a data source, the same data source should not be relied on for the same purposes in rural areas or where OSM completeness is low. Furthermore, the short investigation regarding the suitability of the derived landmarks has indicated a difference between those selected by the service and the landmarks provided in instructions by people providing routing instructions. As mentioned, this difference does not necessarily mean that the derived landmarks are not suitable for the instructions provided as the differences could be easily accounted for by memorability of features. For example, a park that does not meet many criteria in the algorithm (such as distance and visibility) would likely be much more memorable than a shop that does meet all of the criteria and thus would be suitable as a general landmark for the instruction. This paper has shown however that the methods described can be applied to an OSM database and in turn could also be applied to any geospatial dataset that provides the location of features and their type/usage. Therefore, the further investigation of the suitability of landmarks detected is not necessarily restricted to OSM data alone, but could be applied to other datasets using the same methods.

In the next iterations of the prototype, focus will be placed on enhancing the selection process with regards to more structural aspects. Methods such as those presented by Richter [30] will be further investigated in the hope for increasing both the efficiency and effectiveness of the landmark identification process. There are several additional aspects that warrant further investigation as additional prototypes are developed for the navigation service. On the one hand, the algorithms used should be the subject of a more in-depth investigation to identify whether optimizations could be made. Furthermore, the weightings used for the proposed salience of feature types requires modification to take into account the perceptions of the general public. For instance, would the same feature type be more salient in one country than another? On the other hand, for these algorithmic investigations, continued research with relation to the use of OSM as a data source is a topic of high importance to assess where the service can be used successfully and what can be done in the areas with lower OSM completeness. These topics will be investigated as the service matures.