PhoneAbility

Mobilisation and Accessibility Planning for People with Disabilities

Gary Randall

            GARY RANDALL:   I work at the research group BMT at Teddington, talking about Mapped Mobilisation and Accessibility Planning for People with Disabilities. It is a European Commission funded project. It is a targeted research project lasting about three years with about three million euros funding.  

            Just to summarise what I am going to say, I will describe the problem and intended solution, and then introduce the consortium who are working on the project and talk a little bit about the three core technical problems that we have to overcome.

            We are working in the area of accessibility issues. There is an overreliance on car use by disabled users and public transport is notoriously underused. Journey planning across different transport types can be difficult because of lack of information. There is a lack of visibility of information for any user.  

            We have to bear in mind the physical barriers of the type you have heard about today. Levels, steps and gradients are also factors, as are premises concerning the services themselves; the vehicle types, bus types, parking support. There is a different kind of issue regarding user confidence in the system and reliability of the system as well, and a user has to be sure that they are not going to be stranded.  

            So how will Mapped help? It will address social exclusion issues and barriers to movement by developing a disability specific route planner taking into account individual user's needs; that is personal needs and needs on the basis of their disability profile. We will also be including geographically indexed accessibility information of many kinds, all wrapped up in a disabled friendly set of user interfaces.  

            We will do this by largely building on existing journey planners.  Mapped is not an attempt to reinvent the wheel. It's not blue-sky research in any sense. It's a real slog to get the data together and to handle the complexity of that data. So, it's a refined route planning enterprise, in effect.  

We will be testing this system in Dublin and Winchester over the coming summer, and in Barcelona and Genoa towards the end of the project. That's theoretically in co-operation with the ASK-IT project that you heard about.  

            So the expected outcomes are that everyone will have improved confidence in public transport, help planning around barriers to mobility, enabling personalised journey planning, providing accurate information, and also to help achieve corporate aims. That will become clear later.  

            In reality, Mapped is a PDA with a set of input devices, one or two other bits of hardware and different ways of displaying the results, with all that's held on the user, coupled to a series of servers that sit at the back end.  

            I will briefly whizz through the consortium. There are three technical partners: BMT, where I work in Teddington, TXT in Milan, Moviquity software company in Spain. The end users are CRC, Central Remedial Clinic in Dublin, and HCC is Hampshire County Council.  

            BMT has about 1,000 people spread over 12 countries or so, so we do work in all kinds of areas. There is a central AI-oriented group in Teddington. We do applied AI really and try to transfer technology research to industry. Our role in the project is as coordinators and we are working specifically on the disability specific routing component.  

TXT, an Italian software partner, do a lot of work on supply chain and media content management for Mr Berlesconi, so very well connected! Their role is to develop or to fill basically a points of interest server, and they are also responsible for exploiting the project.  

            Moviquity are in Barcelona. They do all the interface work as well as deal with the hand-held hardware.  

The end users, CRC, are the largest Irish provider of services for the treatment, rehabilitation, training and management of physically handicapped people, providing all sorts of services through assistive technology within Dublin. They are our domain experts, if you like. Their role is to specify the requirements and to evaluate the system.  

            In the UK, we are also in with Hampshire County Council, a relatively large county council centred mainly on Winchester. They have a history of being interested in intelligent transport systems. Their role is user requirements and to gather travel and accessibility information for the two test sites and to lead the two trials.  

            Basically, what Mapped will do is to guide the user from wherever they are in the real world along the streets on to the public transport network, and then to manage changes across that public transport network, if necessary, and guide them on to their final destination. All the time the user will receive - you could say, be bombarded - with relevant bits of information that are pertinent to where they are in the course of their journey, and also their personal interests.  

            In order to do this, these are the three things that we are working on. The routing requires new routing algorithms. Maps need to be augmented at the outset and dynamically through the use of the software. We are also building a reservation server of accessibility services for handling of the routing system. BMT leads that task.  

The role of TXT is to provide timely location specific data, so users receive a list of POI in their vicinity providing information relevant to their disability and their journey. There are two methods for doing that. They are either explicitly requesting information about their location or content can be pushed to them - although pushing is notoriously problematic, certainly if you know the history of these things.  

            Moviquity's role is to produce interfaces to be as useful to as many people as possible using user profile. That is the dreaded box diagram.   There are only a couple of these.

The PDA is on the left. We have an interface, and then a series of routers in the central boxes that are combined by BMT into one combined routing server, all of which take input from various accessibility databases. In parallel there is a point of interest server in the box at the bottom which contains usability information which sends data to the client.  

            There is a whole level of complexity below each one of the boxes.

            The route finder that we are developing takes into account street navigation, ie, a user walking up the street, and public transport of many kinds. It will also support the user in using their own car and can allow booking of the necessary services at the appropriate points. It's also our job to highlight to the user where they are, in terms of announcing in various ways which stops have been reached.  

            In terms of the public transport algorithm, it calculates the optimum combination of several public transport services to get a user from close to A to close to B. In Dublin we are using bus, train and tram data. A lot of this, unfortunately, has to be input by hand because the data just doesn't exist in any homogenous form in any large scale.  

            That public transport routing service is also sensitive to accessibility information. Street navigation routing gets the user to the entry point of the public transport system, or from one stage of the public transport journey to the next - from the train station to the bus stop, for instance - and then on to their final destination. It's also sensitive to accessibility information. We support private transport mapping as well using newest maps, realtime traffic sensitivity. All routes are calculated remotely and not on the client.  

            Here is some accessibility information that is used by the routers and other bits of the software. This is a repetition of some of the stuff you have seen today already. We will incorporate gradients, levels, kerbs, the state of buildings, bus shelters, car park information, doorway information, taxi rank, et cetera.  

            Something that might not have been clear so far is that, in order to incorporate this information, we are going to have to do some augmentation, because as you have heard already maps are largely devised for the motorist. There are lots of omissions and mistakes. The omissions in regard to our information, like alleyways, pavements, steps, gradient information, is never provided by the likes of Navteq or TeleAtlases, because they have little motivation to do so, and they are also slow to update the service, so there is no chance of this being done in the short term.  

            MAPPED will provide a mechanism to augment the existing maps with information we would need. The supplier, ie, the technical partners in the consortium, work through offline maps or whatever information sources we can get our hands on. It's relatively expensive in terms of effort and requires regular updates. The system will also allow for augmentation to be done by the user as they are using the system. That's the alternative method. It is slower but it is immediately adaptive. So, we are going to use both of these approaches.  

            It is interesting to hear what our American colleague said this morning about the failure of their attempts to do that using text input, so we will have to bear that in mind. We think we have a very dedicated user group, so it's in their interests to get it right, we hope.  

            Most existing transport planning systems don't use accessibility data. These are ones we are aware of throughout Europe. TXT, on our behalf, will use accessibility data in the calculation and will represent this data via points of interest, so that the user gets the information in place to access a location, and also the user gets relevant information when they change locations.  They do this by identifying their current location with the current direction, and then filter the information accordingly.  

Instead of having our PDA interact with a beacon in the real world, the PDA will query a geographical database of points of interest that we have built up.

            The GPS system, or the PDA wrapped up in a GPS system, is out there in the real world. It talks to the server, tells me whats in the vicinity.   These are the things which are in the vicinity that you might be interested in.   There's no direct communication between the real world locations and the PDA at that point.  

            Another chunk of the software that we will be developing as well is an accessibility booking service, so that, should it be needed, a transport employee can be requested to assist with embarkment or disembarkment, or where a shopping centre has an assistant available. This is predicated on having, in the first instance, in the trials, good agreements with a few entities; usually cinemas, a library and one or two restaurants. So, we think we can automatically make announcements or reservation requests for help if necessary, either by using an automated booking service, if that exists, or by e-mail or text messaging.  

            As you saw in the diagram earlier, MAPPED is built around fairly standard equipment. We are not doing anything novel in terms of hardware.   PDA, GPS, compass, coupled with some external devices to comply with users' requirements. Here is that diagram again.

We are going to be using real keyboards, or virtual keyboard and customised buttons and a touch screen, and a switch or joystick connected by USB. If anybody knows about digital compasses, I would like to talk to them. That;s where our Spanish partner is having problems with sourcing a good compass and connecting it suitably at the moment.  The PDA is connected by WiFi, GPRS or whatever is necessary, and can give output via a loud speaker or an LCD display. There are the user types.  

We use some sub-set of those input and output devices. Again, if anyone has any comments or advice about these choices, I would appreciate any feedback, or if there are any alternatives that we have not really thought about.  

OK. We are about 18 months through the project, just under halfway. We have worked down the left-hand side of this series of boxes.  

The prototypes exist in isolation. They are being integrated at the moment.   There were about four servers involved, so for anyone technically minded that becomes problematic when you are trying to do route calculation because of the database calls you have to do, so we are working towards reducing the disparate nature of that at the moment.  

            Trials will happen over the summer. We have 30 users in Winchester and 30 in Dublin with a view to revising the software and then going on to produce a better system, to test it again next summer. Thank you.  

            APPLAUSE

            John Gill:  Thank you very much. Are there any questions?  

            GARY RANDALL:   Remember, I am not a disability expert.  

            NEW SPEAKER:   Hi, Gary. Not a tricky question. Relax! I was just worried about a couple of phrases. Planning around barriers. I appreciate that if you can't use a restaurant as it's not accessible, you get other options to plan around problems.  

I am a bit worried, for example, if you have an inaccessible taxi rank, that will send you to an accessible one, which is very good. But it's not flagging up that that inaccessible taxi rank should be sorted out. Or you may be able to cross the road but it's not flagging up that a kerb needs lowering. We are talking about mapping the barriers, but what we are doing is identifying the barriers. Are we informing those responsible for creating those barriers to put those matters right and make them more accessible? 

I am very worried that we are preserving the inaccessibility of parts of the environment by flagging them up and giving people alternatives, rather than actually having a feedback route to those who can make the environment more accessible. So, in a way, I think some of this mapping is counterproductive to making a more inclusive and user-friendly environment.  If these problems are flagged up and you create this list of kerb-cuts or inaccessible taxi ranks, you should have feedback to the authorities involved, otherwise I won't have a choice. It won't mention to me the restaurant that's not wheelchair accessible. There are lots of others, but that one isn't even going to be offered to me.  

            That is discrimination. I am not picking on you, but I am worried that we are just accepting the environment and mapping the barriers, but we are not putting that into the feedback route to make these things more inclusive. Sorry, rattle my cage if you want to. Anyone agree? (Yes!)

            GARY RANDALL:  It's technically trivial to send them a result of some kind of input coming into the system, but whether that works in real life, I don't know. What happens at the moment if you see something you don't like in your environment? What's the procedure for getting something done?  

            NEW SPEAKER:   It depends how good your council is! 

            NEW SPEAKER:   It's not just having it mapped out. They would like to know how to put it right. They have an access officer.  

            NEW SPEAKER:   I have a similar question we have to answer in ASK-IT as well. I think your servers, providing the services and content, are located with the Internet, and so your PDA must be able to connect to the Internet by means of 2G or 3G, or even wireless LAN. Are you aware in your project that the access methods and discretion of the access policies are completely different in 2G and 3G compared with wireless LAN, and that this problem must be solved.  

2G and 3G network operators have agreements, in general, so you can have access everywhere, which is not in WiFi networks. WiFi hot-spots have no agreements, so you need a specific policy and a specific subscription, or something like this, to access the Internet via WiFi hot-spots.  
Are you aware of this problem and have you already some solutions?  

            GARY RANDALL:   The interface developer and Moviquity are entering into some agreement with a telephone provider to get cheap contracts and also cheap handsets from them. That's also I think the devices for the trials, but it's not really a question for me. I can put you in contact with the relevant partner if you like.  

            NEW SPEAKER:   Yes. This was my proposal, that you come into contact, because we have the similar problem to solve. OK, thank you.  

            JOHN GILL:   Thank you very much.

  

Contents page

Previous page

Next page