Semi-automated Pipeline to Produce Customizable Tactile Maps of Street Intersections for People with Visual Impairments

. Street intersections are very challenging for people with visual impairments. Manually produced tactile maps are an important support in teaching and assisting independent journeys as they can be customized to serve the visually impaired audience with diverse tactile reading and mobility skills in different use scenarios. But the manual map production involves a huge workload that makes the maps less accessible. This paper explores the possibility of semi-automatically producing customizable tactile maps for street intersections. It presents a parameterized semi-automated pipeline based on OSM data that allows the maps to be customized in size, map features, geometry processing choices, and symbolizations. It produces street intersection maps in two scales of three sizes, with different levels of details and styles.


Introduction
Crossing the street is an inevitable part of urban journeys, yet it can be very challenging for people with visual impairments (PVIs). Without vision, it can be difficult to acquire the necessary information about the street intersection, such as the layout of the streets and the location of the pedestrian crossing, in order to execute the crossing at a safe location and time. During orientation and mobility (O&M) training and independent journeys, tactile maps have been an important tool for conveying the geometry layout and the surrounding environments of the street intersections, as well as teaching concepts about traffic flows (Wiener et al., 2010). These tactile maps are still made manually by tactile transcribers or O&M instructors, as currently there is no automated tactile mapping service available for this inevitable but challenging part of the journey.
Although tedious, one advantage of manual mapping is that it can cater to the diverse needs of PVIs, in terms of having maps in different sizes with different levels of detail for it to be used in different scenarios such as classroom teaching, onsite sessions, or independent journeys; and adjusting complexity and styles of the geometries for PVIs with various levels of tactile reading and mobility skills. But the workload of manual mapping restricts the availability of the maps (Baldwin and Higgins, 2022). PVIs, as well as O&M instructors, would benefit from a customizable service that produces tactile street intersection maps on demand (Miele, 2004).
One major challenge for tactile maps is that, with limited space, they have to balance the large amount of information needed to understand the mapped area and the requirements in tactile graphics about being simple and clutter-free to be readable (Braille Authority of North America [BANA], 2010). And the automated production of such maps, apart from satisfying those requirements, would also need to include some possibilities to cater to the diverse needs of the visually impaired audience.
Our objective is to design and develop a modular and parameterized pipeline to semi-automatically produce such street intersection maps to assist O&M instructors and/or PVIs. The maps are designed based on O&M instructions and various tactile graphic guidelines, and the transformation from open data to ready-to-print maps is further implemented as modules in the pipeline. The pipeline will serve as an experimental starting point for a future accessible application to serve on-demand, tactile maps for street intersections that can be customized according to the individual needs of the PVIs.

Related Work: On-demand Tactile Mobility Maps for a Diverse Audience
Some automated services or workflows have been developed to provide on-demand neighborhood-level tactile mobility maps. There are a few services that provide maps of the street network (as lines) along with other features such as buildings or obstacles: the TMAP (Tactile Map Automated Production, Miele, 2004), the TMACS (Tactile Map Automated Creation System, Watanabe, et al., 2010), and the Blindweb (Götzelmann and Eichler, 2016, currently out of service). The maps from Mapy (Červenka et al., 2016) and Štampach and Mulíčková (2016) are more detailed, where the streets are shown in different widths and buildings are represented as detailed footprints. There are also documented workflows (Barvir et al., 2021;Touya et al., 2019) that create 3Dprinted neighborhood maps with streets, buildings, and vegetation areas. These services are already assisting manual mapping to some extent and are appreciated by PVIs and O&M instructors (Biggs et al., 2022). But for street intersections, there is not yet a service to automatically produce the maps.
However, as automated services reduce workload, one major advantage of manual mapping is customization: to produce the maps based on the guidelines on tactile graphics and human haptic perception, but also make specific changes according to a specific user or scenario. Tactile mobility maps have to target the users according to their competence in tactile reading and mobility, as well as their specific mobility tasks. The particular mobility task (e.g. to learn the street and traffic concept of a typical intersection layout, or to learn a particular intersection and its surrounding area to prepare for a crossing) and the occasion where the map is used (e.g. indoor with a table or outdoor on the street) will impact the size and the objects included in the map. The readers' tactile reading ability will impact how these objects are represented. For people less skilled in tactile reading, e.g. children, the maps need to be more simplified, with fewer elements and simpler geometries and spatial relationships, accompanied by strong and clear symbols (BANA, 2010). Catering to such diversity in needs would require the automation to allow customizations in terms of size and scale, object choice, geometry processing, and styling, involving all the major steps in the map production process.
The current automated services already allow some customizations. TMAP (Miele, 2004) supports a series of paper sizes and scales, with options to include different levels of street features (e.g. street, path, service roads.) BlindWeb (Götzelmann and Eichler, 2016) allows the user to choose zoom level and map features (e.g. hospitals) and has different formats for different printing technologies. TMACS (Watanabe et al., 2014) further supports some editing of the map features (e.g. adding a line or polygon). These customizations are appreciated by the users (PVIs and/or professionals involved in tactile document transcription; Biggs et al., 2022, Götzelmann andEichler, 2016). At the same time, they have also expressed their wish for further customization possibilities. A study with TMAP users (Biggs et al., 2022, blind users and O&M instructors) reports that they want, for example, options to customize the features for students with very basic tactile reading skills, change the style (the "looking and feel") of the map, and the possibility to include more features.
Therefore, for the street intersections, we aim to explore the possibility of incorporating customization into the automated process to produce the tactile maps with a parameterized and modular pipeline. This paper focuses on the design of the semi-automated pipeline for map production, and the graphical and technical choices we made about the underlying (geometry) process.

A Semi-automated Pipeline
Overall, the pipeline aims to incorporate the objects typically found near the intersections and process them into meaningful representations for the PVIs, considering their unique cognitive and mobility process during a street-crossing task (Arsal et al., 2022). It should also respect the rules regarding tactile graphics, as well as the practicality of automation.
To adapt a classical mapping pipeline for tactile street intersection maps, we identify the decisions and options unique to this tactile mapping context. This includes: objects to include on the map and their meaningful representations (section 3.1), and the potential parameters that ensure the tactile readability of the maps and also enable the maps to be customized (section 3.2). The involvement of these parameters throughout the pipeline is further illustrated in the implementation (section 3.3).

Objects and Representations
The pipeline aims to represent the common objects found at intersections in a way that suits the unique need of the PVIs. And with very limited space available on the map, the number of objects to be included is very limited to avoid clutter and ensure readability. Based on the O&M instructions and practices about street-crossing (Wiener et al., 2010), the pipeline processes the following objects: • Objects on the street (roadway): the street representation needs to indicate the boundary of the street (the curb line) and the width of the street. Pedestrian crossings should be explicitly marked. Traffic islands should be explicitly represented on the map (Fazzi and Barlow, 2017). • Objects on the sidewalk (roadside): Apart from the sidewalk, buildings and grass/green areas near the sidewalk should also be included, but in simplified geometries to reduce clutter (BANA, 2010). Public transportation (bus) stops should be included as they are an important part of PVIs' mobility (Fazzi and Barlow, 2017).
As the pipeline needs to balance the needs of PVIs and data availability, some objects (e.g. push-button traffic lights) that could also be utilized by PVIs but are often missing in the data are currently not included.

The Parameters and Their Defaults
From choosing an area to eventually producing a printable map with processed geometries and styles, the parameters involved can be grouped into five categories: map basics, object choice, tactile graphic parameters, specific geometry processing choice, and styling choice. Although in a real production environment, the users shouldn't have access to modify all the parameters freely, all the parameters are currently modifiable here for experimental purposes.
Basic map parameters include the size option (A3/A4/A5) and the coordinates of the street intersection. The map scale is then fixed for each map size: 1:1000 for A4/A5 maps and 1:500 for A3.
For object choice, under the intersection context, all roadway objects are essential and mandatory by default, and the choice of roadside objects is open.
The tactile graphic parameters ensure the map can be properly perceived by touch and they are heavily involved in the geometry processing. We set their default values according to the tactile graphic guidelines. Still, they could be modified based on the tactile reading ability of the reader (e.g. children in early grades might need bigger gaps.) • Gap around points: 3mm (TABMAP, 2006) • Gap between parallel lines: 3mm (Bris, 2001) • Gap between line and areas: 4mm (Bris, 2001) • Gap between areas: 5mm (Bris, 2001), but no gap is needed when two area features have contrasting textures (BANA, 2010).
While respecting the guidelines, some geometries can still be processed with multiple possibilities. These specific geometry processing choices mainly affect one specific type of feature but could have a chain effect on others in the subsequent steps.
• Point-line overlay preference: Two options are provided when a point comes close to a line: the default is the "direct" overlay mode where the location of the point is preserved (Fig. 1, bus stop to the left). In the alternative "displace" mode, the point is displaced away from the line to prioritize the line continuity (Fig. 1, bus stop to the right). • Level of detail in buildings. Two levels are provided: the default is the "rough" level ( Fig. 2-c), where all the buildings are merged into a block and only the simplified outline is retained. On an alternative "detailed" level, building footprints are generalized while individual buildings are mostly kept from each other ( Fig. 2-b). For the styling choices, they are provided as an option from a set of pre-defined ones (providing the .qml files). Although symbols and textures can be defined with very basic parameters, such as defining a texture with the pitch and thickness of its line patterns (TABMAP, 2006), such granularity is not necessary for this pipeline. A default set of symbols is also suggested based on guidelines, existing research, and manual practice (BANA, 2010;Martin, 2018;Prescher et al., 2017).

Pipeline Implementation
The semi-automated pipeline is implemented in Python based on pyQGIS (QGIS Development Team, 2023), geopandas (Jordahl et al., 2020), and shapely (Gillies and others, 2019). It processes data from OpenStreetMap (OpenStreetMap contributors, 2015) into tactile maps ready to be printed on microcapsule paper (swell paper).
The steps in the pipeline consist of preparing the data from OSM, processing the geometries, and map export are shown in Fig. 3. The parameters mentioned before are prepared in a .json file to be used throughout the pipeline. Currently, human inspection and curation are needed after major steps.

Data Preparation
This step extracts basic features from the OSM dataset and prepares them for the proceeding steps. It's largely independent of the parameters. Two major sub-processes involved in this step are feature extraction from OSM and street lane count estimation.
Based on the coordinates of the intersection, a processing extent of 400x400m (large enough to cover an intersection and its surrounding areas) is generated based on the intersection coordinates. This processing extent will be used later in the geometry processing steps. Features extracted from the OSM data include • roadway objects: street (lines), pedestrian crossings (points) • roadside objects: sidewalks (lines or areas), bus stops (points), buildings (areas), and green areas (areas).
For the streets, the number of lanes indicates their widths and is important for the upcoming steps. Ideally, the lane count is tagged for street features. In such cases, it can be directly extracted. But often, such tags don't exist for every street segment, and the lane counts need to be estimated. Untagged street segments can "inherit" the tag from connecting segments, providing they have the same name and hierarchy ("highway" tag). When such information is not available, lane counts are assigned based on the hierarchy of the street (e.g. streets tagged as "primary" or "secondary" in OSM often have more than 2 lanes in each direction; OpenStreetMap and contributors, 2015)

Geometry Processing
The geometry processing is centered around the transformation of the roadway objects, especially the streets. It is heavily impacted by the tactile graphic parameters.

Figure 3.
The pipeline: starting from preparing the data from OSM, to the geometry processing of various roadway and roadside objects, to assemble and export the map with the chosen template and styles. The parameters set in param.json is involved throughout the process.
For roadway objects, the processing is centered around the street features, including • street transformation.
• pedestrian crossing integration • traffic island estimation.
The street lines are first transformed into an area feature according to their lane counts, the area geometry is then smoothed and the boundary is extracted as the "curb" line.
For each "pedestrian crossing" point, a line is generated perpendicular to the street line it belongs to and adjusted according to the curb lines.
Traffic islands are estimated from the processed street area feature (where islands are extracted as areas that touch the street area feature from the previous step and disjoint from the roadside features.) Non-reachable islands that are not connected by pedestrian crossings are removed as they are less important for the pedestrian. The configuration of the traffic islands (slope or cut-through) needs to be manually set for each island feature. If an island is cut-through, it will be split using the pedestrian crossing lines generated in the previous step.
For roadside features, the processing starts from the ones closest to the curb line and extends outwards, to maintain the required gaps between the features. It includes: • bus stops placement • sidewalks placement • generalization of buildings and green areas When placing the bus stops along the street, in "direct" mode, the points retain their location; in the "displace" mode, the bus stops are displaced away in the direction perpendicular to the curb using the "gap around point" parameter to maintain the continuity of the curb line.
Sidewalk lines from both the line features in OSM and the "sidewalk" tags on the street features are combined and placed beside the street based on the "gap between lines" parameter. On 1:500 maps, if the data is available, area data of the sidewalk is simplified and smoothed and placed directly next to the curb line without a gap (as the texture for the sidewalk will have enough contrast with the street.) The buildings are generalized with an iterative dilationerosion procedure followed by simplification (Douglas-Pucker) to simplify shapes and merge nearby features. The option of having "detailed" or "rough" buildings determines the exact parameter settings for the dilationerosion iterations (i.e., the dilation distance and the iteration count. "Rough" buildings are treated with bigger dilation distances and more iterations). Green area patches are generalized through a similar dilation-erosionsimplification procedure, without the option of a detailed or rough generalization. The generalized buildings and green areas are then clipped to keep a distance from the streets and the sidewalks according to the gap parameter.

Example Maps
Some example maps from the pipeline are shown in Fig.  4 and Fig. 5. Fig. 4 shows an A3 map of a complex intersection in the default styles with rough buildings, green areas, and some sidewalk lines, and an A4 map with detailed building footprints in different textures. Fig. 5 shows an A3 map of a simpler intersection with area sidewalks, buildings, and a directly overlaid bus stop point.

Data and Software Availability
The code and the data (OSM, param settings, style, and template files) used to generate the example maps are available on GitHub under the GPL-2.0 license (https://github.com/myhjiang/human_crossing). The pipeline is executed as a set of numbered scripts.

Summary and Future Work
We explored a modular and parameterized pipeline to semi-automatically produce tactile maps for street intersections and allow customizations. The parameters are identified in five categories and allow the tactile map to be customized in size, map features, geometry processing choices, and symbolizations. This is an experimental pipeline, and to better represent the urban street intersections, it will need to be extended to handle more objects and more complex street configurations. Some other common objects in urban environments, such as tramways, are not yet included because of their complex relationship with the streets. The pipeline is currently not able to deal with bridges or multilevel junctions either. These issues could be explored in further implementations.
To evaluate the pipeline, automated constraint-based evaluation tools can be developed to verify that the map geometries respect the tactile graphic guidelines. And techniques to measure clutter and information value for visual map images could also be used to evaluate the clutter for tactile maps (Rosenholtz et al., 2007;Touya et al., 2019;Wabiński et al., 2021). These measures could potentially enable the automated comparison between the pipeline maps and manually made ones. But more importantly, because the production process (printing and producing relief) can introduce new uncertainties (e.g. the same textures might eventually "feel" different on different swell paper; TABMAP, 2006), a tactile map needs to be evaluated in print to verify the geometries and symbols can be perceived as intended and to investigate the flaws introduced by the printing process (Touya et al., 2019). Now this evaluation can only be conducted with human low-vision experts (O&M instructors, tactile transcribers) and/or PVIs.
Eventually, the pipeline and the maps it produces will be evaluated by the users, both the low-vision professionals who produce and use these maps in their work and the visually impaired end users. In the follow-up work, the evaluation would gather feedback from both groups. But these evaluations are not in the scope of this paper.  The ultimate goal of the pipeline is to support a service where O&M instructors, families, or visually impaired people themselves can access and make maps on demand. This would require both an accessible interface and instructions and controls in terms of parameter setting to facilitate an informed customization process.