MAPPING THE ACCESSIBILITY IN OPENSTREETMAP: A COMPARISON OF DIFFERENT TECHNIQUES

Architectural barriers are physical elements that limit the freedom of movement and use of services of a person. The lack of accessibility is one of the physical barriers that most limit people with motor disabilities, as recognised by the World Health Organization. The work aims to identify the optimal methodology to map accessible ways and critical barriers, in order to produce cartographic support for people with motor disabilities. It should also be a tool that allows citizens to report barriers to public authority. The work is part of the ViaLibera?! project, which aims to apply the methodology in the Municipality 9 of the city of Milan. The project is founded by Fondazione di Comunità Milano; Politecnico di Milano is the scientific partner, while the other partners are associations that represent people with disabilities: Spazio Vita Niguarda Onlus, Ledha Milano and AUS Niguarda Onlus. The mapping elements of interest for the project were identified in collaboration with the other partners, also studying the state of the art. In the framework of Open Street Map, a comparison between different existing mapping techniques was done to select the optimal compromise between rigour and simplicity. In addition, the different techniques must be suitable for the chosen tagging scheme to map accessibility elements. The techniques analysed involve the use of paper maps, Field Papers, and street-level images or applications for smartphones. They are compared to identify the best one.


INTRODUCTION
Smart cities combine technological infrastructures to improve the life quality of citizenship: accessibility is one of the modern challenges. Accessibility could be considered in different aspects of the life of people with disabilities: very different kinds of disability exist, that really have different needs. The World Health Organisation report (World Health Organization, 2011) identified eight different kinds of barriers that limit accessibility. Beside the obvious physical aspects, the barriers regard also economical and psychological factors. The report estimates that over one billion people, about 15% of the world's population, present some form of disability. This rate is going to increase due to the ageing of the population, in particular in developed countries. This work is within the project ViaLibera?!. It is founded by Fondazione di Comunità Milano and the partners are: Spazio Vita Niguarda Onlus (a volunteers association for people with disability), with the role of leader; Politecnico di Milano, as scientific/technical partner, Ledha Milano and AUS Niguarda Onlus, other associations for disability, to represent stakeholders. Municipality 9 of the city of Milano supports the project. The scope of ViaLibera?! is twofold: from one side, we want to identify the optimal way to map accessible ways and critical points, in order to provide effective directions to wheelchair users. On the other side, the citizen should access to an easy tool to report barriers and obstacles to the public authority. The project will use the Municipality 9 of Milano as a case study. The city of Milano has 1.35 millions of inhabitants with a surface of about 182 square kilometres: the city is divided into nine Municipalities: municipality 9 has 184.000 inhabitants and a surface of 21 square kilometres: it contains * Corresponding author Porta Garibaldi and the suburb areas of Bicocca, Comasina and Niguarda. The mapping will be experimented in three specific areas (case studies): Greco Pirelli -Bicocca; Garibaldi -Maciachini -Ca' Granda; Comasina. The experimental activity will be planned and designed by the partners of the project: then, it will be carried out by volunteers, at the beginning students from high schools with the help of AUS volunteers. Data will be uploaded in OpenStreetMap. The paper is structured in the following way. Section 2 describes the current state of the art for mapping the accessibility: in particular the transition from the use of authoritative data to the crowdsourcing collection is discussed. Section 3 describes the elements of interest that are chosen to be mapped. Section 4 contains a description of the different methodologies tested for the insertion of the data in OpenStreetMap. Finally, Section 5 concludes the paper by discussing the main results and the future development.

STATE OF THE ART
MAGUS was the first project about the collection of accessibility data for wheelchair users (Matthews et al., 2003, Beale et al., 2006). The routing system was implemented in the Northampton (UK) area. MAGUS was provided as a desktop application; the routing was done by the analysis of the following data: slope and surface type of the sidewalks, barriers like steps or kerbs. These characteristics were selected by consulting stakeholders, i. e. wheelchair users: so, the project already introduced the idea to aggregate information from volunteer contributors.

Volunteered Geographic Information
The idea of collecting data from volunteers spread with the diffusion of Volunteered Geographic Information (VGI) (Good-child, 2007), so new applications were created with this aim. The collection of data was organised in different ways: in some cases volunteers actively mapped the obstacles, in other cases they simply acted as carriers for sensors (for example gyroscopes, accelerometers and global navigation satellite system (GNSS) receivers) that collected data for mapping. The project PATH 2.0 (Palazzi et al., 2010) adapted the idea of Web 2.0 of collective intelligence (O'Reilly, Battelle, 2009), to the idea of collecting accessibility information. Supposing that a path frequently travelled by people with limited mobility is accessible, an application was implemented, able to track autonomously the paths of the users. The paths were uploaded into a server, providing a routing website for other users. The project "mobile Pervasive Accessibility Social Sensing" (mPASS) (Prandi et al., 2014a) expanded this idea. Data collected by the sensors of volunteers smartphones were integrated by the direct contribution of the users. In particular he volunteers inserted accessibility data for six types of Point of Interest (POI): gap, cross, obstruction, parking, surface and pathway. Crowdsourcing is based on the availability of volunteers. Many studies tried to identify how to stimulate them to insert data. The approach could be based on an awarding system or gamification. The two approaches increase the number of elements added by the users. Also, the award version keeps more the attention of the users in continuing the activities, and with a game version, the users were motivated to change the route to find new features (Salomoni et al., 2015). Also Artificial Intelligence and Machine Learning were tested in other applications to collect data about accessibility (Iwasawa et al., 2015), the most recent application WheelShare (Edinger et al., 2019) being provided to collect information and also routing according to accessible paths. AI is used to analyse the sensors present in the smartphone. An application has been implemented that records data while the user on wheelchair moves. After, the AI and Machine Learning process the data to classify the quality of the sidewalks. A similar approach is implemented in Maps for Easy Paths (MEP) project, that creates a routing service (Biagi et al., 2016) (Comai et al., 2017) based on a server side processing of data acquired by users (Carlini, 2019). "Project Sidewalks" (Saha et al., 2019) presents a new approach to collect the data on the field. A website is implemented, where volunteers, also remotely, can map obstacles in sidewalks using the images from Google Street View. However, according to the Term of Use of Google Street View 1 this is reported in the prohibited uses: "Creating data from Street View images, such as digitising or tracing information from the imagery;". More explicitly, "these restrictions apply to academic and commercial projects.". Another problem that is not considered is the time resolution of the dataset, since the photos can be updated only by Google.
2.1.1 OpenStreetMap case A new approach is followed by other projects that select to use an existing database based on OpenStreetMap (OSM), instead of creating proprietary database. OSM was founded in 2004 at the University College London by Steve Coast (Haklay, Weber, 2008), and constitutes an example of a VGI project. The project aims to create a free and open database of geographic information of the whole world acquired by volunteers. This approach could affect the homogeneity and quality of the data (Goodchild, Li, 2012) and some actions in order to improve the collected data are taken into consideration by the community behind the project . The number of volunteers registered into OSM is continuously increasing and reached 5.5 million users in June 2019, with a mean of 40 000 users active per month. The collected data are licensed under the Open Data Commons Open Database License (ODbL) by the OSM Foundation (OSMF) 2 . Following this license, copy, distribution, transmission and modification of the data are allowed under the conditions of attributing and, if data are modified, distributing them again under the same license. OSM has been widely used for different topics as routing, navigation and transportation studies in research and professional applications (Bakillah et al., 2013, Bakillah et al., 2014, Graser et al., 2015, Zhang, Ai, 2015, but also in land-use studies (Costa et al., 2019) or building classification (Fonte et al., 2018).
Into OSM community, the problem of mapping the accessibility started to be popular since 2010, when the application Wheel-Map was launched. The app proposes a simple tagging schema with the use of green, orange and red scale according to the level of accessibility of specific Points of Interests, like hotels, restaurants or public transport's stops. These data are added into the OSM database with the key "wheelchair": the three colours are associated with the relevant values "yes", "limited" and "no" according to the level of accessibility (Mobasheri et al., 2017a). More recently, the tagging schema evolved with the key "barrier", that gives the possibility to add information for an obstacle.
In some projects the collection of data is relevant to the presence and the geometry of sidewalks. Two European projects had the scope of collecting this type of data, i-Scope (Prandi et al., 2014b) and Cap4Access (Mobasheri et al., 2018b, Voigt et al., 2016. iScope project had the purpose of deploying a set of services for improving the life quality in Smart Cities, one of these services regarded the study of a routing algorithm for disabled people. Two different cities, Vienna and Cles, were chosen as test areas. An application was implemented to collect the data in OSM: these data were used to create the routing service, that provided also support in the creation of paths for wheelchair and visually impaired people. Cap4Access was aimed to improve the accessibility in 4 cities in Europe: London (UK), Vienna (AU), Elche (SPA) and Heidelberg (GER). Different approaches were implemented and tested in the different cities, trying to find the optimal way, considering both quantity and accuracy, to collect data. In Heidelberg the project generated several interesting derived projects relevant the mapping of sidewalks (Mobasheri et al., 2017b, Mobasheri et al., 2018a.
In Italy two recent projects started to store sidewalks as separate ways instead of simple attributes of the roads: in such a way more data relevant their accessibility can be stored: see also Section 4. The two projects are: • "Milano facile" done in Milan from Agenzia Mobilità Ambiente e Territorio (AMAT) (Canevazzi, 2018), Milan's transportation agency; • "Padova + Accessibile" (Sarretta et al., 2019) for mapping the actual state of the barriers of the city. The new "Plan for the elimination of architectural barriers" (PEBA) by the municipality can easily understand where the improvements are needed.
Other projects are now underway like OpenSidewalks 3 that aims to import in OSM some dataset of sidewalks geometry in different cities of the United States of America. Another project 2 Copyright and License of OpenStreetMap URL: www.openstreetmap.org/copyright 3 OpenSidewalks website URL: www.opensidewalks.com/ The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLIII-B4-2020, 2020 XXIV ISPRS Congress (2020 edition) is AccessMap 4 that provides a routing service according to the accessibility of the slope of different sidewalks. The service is now available in three different USA cities.

TAGGING SCHEMA
In this section, after a short introduction about the legislation related to accessibility, our proposed model to map accessibility is described. To understand the elements of interest regarding the accessibility of people using wheelchair, an analysis was done on the normative, that for Italy is provided at least at three different levels.
Firstly, we have to consider the European Accessibility Act, the directive of the European Parliament and of the Council (European Parliament and of the Council, 2015). This act of 2015 mainly focuses on services and how they can be made more accessible for people with disability; examples are transport or telephony services. This directive did not directly regard pedestrian mobility on roads and their sidewalks. The Italian legislation is based on the "Decreto Ministeriale del Ministero dei Lavori Publici" (Ministerial decree of the ministry of public works) n. 236 art. 8 of the 14 June 1989 (Ministero dei Lavori Publici, 1989). The law considers in details the elements that define accessibility, both outdoor and indoor: the next section discusses only outdoor. The main element of interest is the width of sidewalks: it must be at least 90 centimetres, and every 10 meters there should be a widening of 140 centimetres. Crossings must have a lowered kerb with a maximum step of 2.5 centimetres. The maximum slope along the paths should be 5%, with a rest space of 1.5 meters every 15 meters. The cross inclination must be smaller than 1%. Road signs must be placed at more than 2.10 meters in height. Drains and every other grilled element present in the sidewalks must not have holes wider than 2 centimeters. Finally, one parking lot every 50 must be reserved to people with disabilities: its width should be at least of 3.20 meters. The elements previously described were partially improved in the "Decreto del Presidente della Repubblica" (Decree of the President of the Republic) n. 503 of the 24 July 1996 (Presidente Della Repubblica, 1996). In particular disposals are given about crossings: new traffic lights should have acoustic warning devices for people with visual impairments. A more recent law (Parlamento Italiano, 2001), stated the need to improve and consider the aspect of accessibility inside the highway code. The 20 February 1989 before the issue of the national law, the Lombardy region council issued a regional law (Consiglio Regione Lombardia, 1989) related to the removal of the architectural barriers. The considered elements were the same of the national law but more restrictive: for example the width of pedestrian paths should be generally at least of 150 centimetres; in places with more traffic, 180 cm; only in cramped passages, it can be just 90 centimetres.
In the framework of ViaLibera?! project, we had several meetings with the other partners, i. e. the associations of people with disability, in order to identify their needs and classify their priorities. The discussed elements were essentially the same described in the national and regional laws; few other fixed obstacles were added and will be presented in section 3.1.5. It should be noted that also temporary obstacles, like cars parked on the sidewalks, are critical but clearly cannot be in any way objects of mapping.

OSM tagging schema for accessibility
In this section, the tagging schema that we decided to adopt for ViaLibera?! is discussed. In OSM, the general tagging schema for highways provides the starting point to understand the tagging schema for the sidewalks. Note that tags are not univocally defined at the global scale, because in every region of the world they are adapted to local rules and laws. For example, the tag "highway = primary" in Italy describes only the main roads that connect important cities; on the opposite, in Africa it is used for any asphalted roads. Due to these differences, the tagging schema that is going to be presented is valid for Italy and in particular for an urban area, in this case Milano. The application of this schema to other places has to be checked case by case. To contextualize the scenario, in the metropolitan area of Milano, the roads are mainly classified as residential or service, as shown in Figure 1. Residential roads present local traffic; service roads are typically used to access parking areas. These two classes contain more than 50% of the total length of the network. Avenues ("viali") represents another 20% of the network. These streets represent the ring roads around the city centre and the radial accesses from the suburbs to the metropolitan area. Then, there are the motorways around Milano, that are defined as "highway = motorway" or "highway = trunk" but are not part of this study, due to the absence of sidewalks on them. 3.1.1 Sidewalks The presence of sidewalks in a street can be defined with a specific tag ("sidewalk = no/left/right/both") of the street: however, this simple way does not allow to store several attributes that are needed to quantify the accessibility of the sidewalks. A sidewalk can therefore be added as an independent way that is parallel to the street and intersect it and other streets in the crossings. The used tags are "highway = footway" combined with "footway = sidewalk". The tag "width = <number> m", in meters, provides the fundamental information on the sidewalk width. Other useful tags, like slope,will be discussed in the following sections, but now we want to focus on the natural connections between sidewalks, i.e. crossings.

Crossings
A crossing is mapped as a separate way from the sidewalks that it connects: it can be represented with a new way with five nodes, as shown in Figure 2. This is the simplest case, but more complex cases are based on different combinations of it.
The crossing (4) shares the first node (A) with the sidewalk (1); node (B) is simply the kerb from sidewalk (1) to the street, the node (C) is the connection between the crossing and the street (2). The node (D) is the kerb between the street and the other sidewalk, (3), and finally (E) is the connection between B and D are the nodes that represent the kerbs. Note that in OSM standards, kerbs with steps bigger than 3 cm are considered non accessible to wheelchairs and bicycles. They need the use of the key "kerb" with a value that can be: • "raised": the step is more than 3 cm and does not guarantee accessibility; • "lowered": the step is approximately 3 centimetres or less, and a structure (ramp) exist to ease the passage from the sidewalk to the street; • "flush": there is not a significant step between the street and the sidewalk.
As described before, for the Italian normative the threshold for a kerb is 2.5 cm instead of 3 cm. To solve the different definitions, another tag that specifies the height of the kerb can be added: the tag is "kerb:height = <number> m", in meters. The node C is shared between the street and the crossing, therefore the tag has to represent the presence on the street of a crossing; the used tag is "highway = crossing".The way (4) also has to be tagged with a schema that depends on the different types of crossings. Firstly, a tagging is needed to define the users of the crossing, as follows: • crossing for pedestrians-only: mapped with the combination of the tags "highway = footway" and "footway = crossing"; • crossing for bikers only: mapped using the tags "highway = cycleway" and "cycleway = crossing"; • shared crossing: the schema is more complex, composed of the combination of five tags: "highway = path", "path = crossing", "foot = designated", "bicycle = designated" and "segregated = no".
Another tagging is needed to define the kind of crossing, with the key "crossing", that can be as follows: • "traffic signals" where traffic lights regulate the crossing; • "uncontrolled" for simple crossing that is not regulated; • "unmarked" for crossing where kerbs give the possibility to cross, but crossing is not marked on the street.
This tagging schema describes the crossing and its accessibility for people with motor disability. However, as we described before, it is also possible to store attributes for people with other disabilities, for example people with visual impairments: in this case the elements of interest are the tactile paving and the sound traffic lights. The tactile paving is represented with the tag "tactile paving = yes": when present, it should be added on the sidewalks and on the nodes that represent the kerbs. For the sound traffic lights, the tag to be used is "traffic signals:sound = yes" on the way where the tag "crossing = traffic signals" is present. In some cases, the signals do not start automatically, but only by pushing a button: this situation can be mapped with the tag "button operated = yes".

Surface
The surface is another import aspect of sidewalk and crossing: it is described by two different keys: "surface" and "smoothness". When referred to sidewalks, "surface" can assume the following values: • "paved" just indicates that the way is paved with some material; • "asphalt" means that is composed of asphalt concrete; • "paving stones" means that it is covered by blocks well connected, and the surface is smooth; • "sett" means that it is covered by natural stones, even with large gaps and a rougher surface than the previous one.
Smoothness really describes the accessibility of the sidewalks, since quantify the quality of the way. The values can be: • "excellent": for very new asphalt surface without holes and gaps; the way is suitable even for small wheels like skateboards; • "good": still an excellent accessibility for all the users, however, some imperfection can be present; • "intermediate": the quality of the paved is compromised, but the presence of some holes does not compromise the usability of a wheelchair user; • "bad": the way is not accessible to wheelchairs, due to the presence of wide or deep holes.
Note that the quality and the surface of the crossings are generally the same of the streets the crossing belongs to and therefore they can be derived from the tag used in the highway.

Inclination
The longitudinal slope is another important element: it regards both sidewalks and ramps. The tagging in the OSM is possible by the keys "incline". The tag has to be inserted on the way of the sidewalks or on the nodes of the kerbs. The value is expressed as a percentage, "<number>%". it is positive or negative if the way is upward or downward respectively. The transverse inclination has also to be considered: it is almost imperceptible for ordinary people walking on the sidewalk but it can influence and create problems for wheelchairs, especially for electrics ones. It is quantified by the key "incline:across"; considering the direction of the way, it is positive for a downward slope toward the right, negative in the opposite case.
3.1.5 Barriers Barriers or obstacles are mapped in OSM as single nodes. It is better to do not add this node as part of the way of the sidewalks, but instead, a node closer to it since they are external elements and part of the sidewalks. The different types of obstacles have different tags: • traffic signals: use the key "traffic sign" with different values according to the signal, and the tag "support = pole" to indicate the presence of the pole; The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLIII-B4-2020, 2020 XXIV ISPRS Congress (2020 edition) • streetlight: use the tag "highway = street lamp" plus the tag "support = pole"; • storm drain: using the tag "manhole = drain" with the possibility of adding the size of the holes, if they are larger than 2 cm: this can be tagged with the key "obstacle : description"; • tree: described with the tag "natural = tree".
The description of the obstacle can be added with the key " obstacle:description". Obstacles can represent a problem just for some specific type of users. This can be tagged with the key "obstacle : <type of transport>", one example can be "obstacle : wheelchair = yes" for obstacles that stop wheelchairs. The presence of an obstacle may reduce the width of the sidewalk; this can be expressed with two different methods. One is to add the key "maxwidth : physical" to the node of the obstacle, with the value expressed in meters. The other option is to split the way of the sidewalk near the obstacle and correct the corresponding tag "width".
The height of traffic signals or advertising panels on sidewalks are also an important element, in particular for blind people. The tagging schema in OSM starts by creating the obstacle. Height can be tagged by the combination of "support = pole" and "height = <number> m", as shown in Figure 3. 3.1.6 Parkings A parking for cars is mapped as an area with the tag "amenity = parking". An important tag associated to it is the tag "capacity" and a particular subkey is "capacity : disabled" to specify the number of lots reserved for people with disability. Generally, this tagging schema is not sufficient to identify the reserved lots, in particular in huge parking areas. This issue can be solved inserting individually the reserved lots inside a parking area. A closed area is created and the tag "amenity = parking space" and "parking space = disabled" are associated. In such a way it is also possible to add the width of the lots, as shown in Figure 4.

METHODS
In this section, the different methodologies to insert data in OSM are explained. The first one is a two steps process: data and notes are mapped and written on paper in field, then are inserted in OSM by desktop applications. In the second case, data are directly inserted in the field by mobile applications.

Field Papers
The first methodology that has been analysed is based on Field Papers. This tool is web-based and allows to create printable maps by OSM. The area of interest is selected, then it divided in several maps (squares), whose dimensions are chosen by the user; also different options of styling, orientation and size of the paper are available. The set of the created maps is called "atlas". An atlas can be private or set public, so other users can find it and use it. The created atlas is exported as a PDF file and contains a summary map with the full area of interest plus all the individual split maps. The printed atlas is then used on the field to take and write notes of the elements of interest. In many applications, and also in our case, many interest elements require to write several attributes, that could not be easy on the printed maps. In such cases, Field paper maps must be combined with tables: in the map, for each element an identifier is just annotated, in the table all its attributes are written. After the collection in the field, the mapped elements need to be uploaded on the OSM database using the relevant editors, like iDeditor or JOSM.

Field Papers and street-level images
A possible improvement can be obtained by collecting also images at the street level during the survey. This can reduce the needed time. Indeed, qualitative data can be provided from the images without the need to write them on the field: for example, through an image the type of the surface and its quality can be identified. In general the collection of images can be done in different ways: here we consider only the methodologies that are optimal for a following usage with OSM: on this regard, the main two projects are Mapillary 5 and OpenStreetCam 6 , that provide applications for smartphones, both Android and iOS, and websites and different tools for the upload of the images. These instruments give the opportunity to collect images not only with smartphones but also with other devices: for our application the considered cameras are: • single-lens reflex cameras; • smartphone cameras; • action cameras (like GoPro or Sony X3000); • 360-degree cameras.
Generally, the reflex cameras provide the best images and can mount different photographic lenses: in our case, short focal or fisheye are the most interesting lenses. However the reflex cameras are not anymore considered because it is quite unlikely that volunteers have and want use such expensive tools. Action cams and smartphones will be considered instead, because they mount the desired lenses and are significantly less expensive and more popular: clearly the quality of the photos is not the same but it is still acceptable for our applications. The cameras can be classified according to the parameters explained in the following paragraphs.

Angle of view
The angle of view (AOV) is the solid angle in which the camera collects the images. Different angles describe AOV: the horizontal, the vertical or the diagonal. For example, the so called 360-degree cameras have an horizontal angle of 360 degrees and a vertical one typically few less than 180 degrees so that they can capture all the elements around the camera. The angle of the 360-degree cameras is optimal for mapping the accessibility elements since it will include in the photos all the elements in the proximity of the photo. This avoids the risk to miss elements between consecutive photos.

Position
The knowledge of the position of an image is another important element in mapping: positions can be collected with accuracy of 1-10 meters by GNSS point positioning. Mainly all the modern smartphones contain a GNSS receiver. On the contrary, few action and 360 degrees cameras have it: however, tracks can be collected by external GNSS (for example on smartphones) and can be used to georeference images a posteriori, provided that a time synchronization is available; this technical process is here not discussed. Clearly more accurate positioning tools exist, like for example GNSS Real Time Kinematic: in our project they are not considered because they require professional technicians in the field while we focus on the activity of volunteers citizens.

Time interval
Another important parameter is the frequency at which the photos can be taken. Considering that in certain cases photos are needed every 2 meters and the walking velocity is around 5 km/h the camera should take a photo at least every 1 or 2 seconds. Most of the cameras have a timelapse modality that allow this acquisition interval. For some devices, like for the Insta 360 One X, the photos are combined into a video. However, it is possible to overcome this issue with a Python script using the OpenCV library. Note that it is fundamental the time tagging for each photo, otherwise the synchronisation with a GNSS track is no more possible.

Mobile applications
The use of mobile applications could overcome the previous two-step process. Thousands of applications exist that use the data of OSM: some of them provide navigation and show the map, like OSMAnd and MAPS.ME; others can be used as mobile editors to directly insert data. The applications are different for Android and iOS. Multiple applications exist for Android, and the most used are OSMContributors, Geopaparazzi and Vespucci. On the contrary for iOS, most of the existing applications are no more maintained: the only two iOS remaining working applications for editing data are GoMap!! and MAPS.ME.
OSM wiki website publishes different tables that report the pros and cons of the different applications for every operating system. In particular, a specific If an internet connection is available the download of the data is possible; then, data can be modified even off line; finally, the upload is possible once the connection is again available. For the most common elements, a list of presets is available, while nothing is implemented for the specific application of mapping the accessibility.

Vespucci
Vespucci has a similar interface, with a central map. The download of the data is not automatic, and the user has to download it with the double arrow button. This option is useful to download different areas for offline mapping. The main differences with respect to GoMap!!, are the editing options and the possibility of locking the editing. The editing modality, are: • Normal: adding and editing elements and tags are allowed; • Tag only: only editing and adding the tags of existing elements are allowed; • Indoor: only the elements related to the indoor tagging schema, and there is the possibility to visualize the elements present on a specific floor of the building; • Check mode (C-mode): shows only elements with the key "fixme".
In Vespucci, but also in GoMap!!, there is the possibility to edit and modify the geometry of the ways. However, this process is not recommended due to the small dimensions of screen available with mobile phones or tablets.

CONCLUSIONS
For the comparison among the different methodologies, some parameters are chosen: • the simplicity of the method: a score from 1 to 5 is given to the simplicity for volunteers and users; • the usability of the methods by people with disabilities, in our case people with wheelchairs; • the time required: the amount of time needed for the full insertion of the data into OSM. The unit of measure is time for mapping 100 m 2 ; • the number of steps: the amount of different steps required to insert the data; • the accuracy of the survey that could be achieved with the specific methodology; • the cost of the instruments: order of magnitude of the total coast of the devices required by the method; • the percentage of elements that can be mapped with this method.
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLIII-B4-2020, 2020 XXIV ISPRS Congress (2020 edition) The proposed methodologies are ranked following the previous parameters.
The test on the time required is done on an area in the village of Sulbiate, shown in Figure 5. In the selected area different public services are present, like the public library and the town hall, and a park. The area has a low density of buildings, but there are fifteen crossings and different types of sidewalks. The total area is 34.000 m 2 , but the effective area of the streets is 9.000 m 2 : only the second value is interesting for our study, because this is exactly the object of mobility mapping. The results based on our preliminary test are summarised in The simplicity of the different methods is in general high, while the acquisition of the street photos could request some more technical knowledge, due to the geolocalization process of the photos.
The required time depends on the adopted methodology. The first method requests a mandatory second step for the insertion of data in OSM: this is clearly time consuming. However, also the mapping on the field often needs to be finalized by desktop applications. Indeed an accurate and complete mapping with mobile applications is not possible: this is caused by the reduced dimension of the touchscreen of the smartphones, that makes difficult to correctly map elements and nodes, like kerbs in crossing.
Time measurements of the table do not consider the time needed to upload the data or the photos because it depends on the internet connection, and the time for processing the photos, that depends on the used camera.
In particular, the estimates of the time requested to map 100 m 2 are: • 57 seconds for the collection of the data with Field Papers; • 34 seconds for the insertion of the data using the JOSM editor of the collected data; • 11 seconds for the collection of the images on the ground on both the sidewalks of the streets; • 41 seconds for the direct insertion with the mobile application (in our test, GoMap!!).
All the tested methodologies are fully working and fulfil the requirements agreed with the partners of ViaLibera?! project. These methodologies are the chosen mainly used for the collection on the field by the OSM community; in particular, we are oriented to apply the two step process by Field paper, even if it is slower than the direct insertion of elements in the field: indeed, it is easier for volunteers citizens and allows a complete population of OSM database. Future development could include the test of more professional methodologies as photogrammetry and LiDAR (Laser Imaging Detection and Ranging), as decribed in (Stucchi, 2020). However, clearly these approaches are restricted to professional technicians and cannot be proposed to ViaLibera?! volunteers or, more generally, for crowdsourcing.