LoroDux/Requirements
< LoroDux
Jump to navigation
Jump to search
- About
- Navigation app for blind people
- Reason for being historic
- never had any release except an alpha release in 2010
- Captured time
- 2013
Requirements
General Requirements
| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks |
|---|---|---|---|---|---|---|
| Allow Plug-Ins | It shall be possible to add plug-ins to the software, that use additional features, e.g. RFID at bus stops or touristic attractions, time tables of public transportation, traffic signals WLAN communication. These (local) features shall not be part of the core software. |
High | 1 | Jürgen (Mailing-List) | It is hard not to fulfil this requirement if you follow the rules of good code programming ('Cleancode'). Not plugins yet available. | |
| Tell battery power | The software shall tell the battery power percentage or time left on demand of the user, at startup and when it falls below certain levels defined in profile file. | Users depend on the software, they shall be supported as much as possible to keep the system up. | Highest | - | Lulu-Ann | Not possible since J2ME doesn't provide access to this information - --DanielH 16:52, 10 May 2010 (UTC) Rely on function of screenreader instead. Requirement is still valid for Android and other OS. |
| Keep status at failure | The software shall safe all information given during a session in a permanent way and restart with same configuration after a power or other failure. | A failure is annoying enough, after the restart nobody wants to enter the destination again. | High | 2 | Lulu-Ann | |
| OSM License requirements | The software shall tell the license ODBL at startup, this can not be turned off. On demand the license text shall be told. | This is a legal requirement. | Highest | 1 | Lulu-Ann | |
| No graphics | There shall be text only. The text shall not disapper, but scroll up, so that it can be recalled with the screenreader. | Highest | 1 | Lulu-Ann | OK in version 1. This requirement is obsolete. Graphics are OK if suitable for persons with visual impairment. Graphics shall never be used for controls, though. (2013) | |
| Text size and contrast | The text size and color contrast shall be adjustable | High | 1 | Mail from Holger (Mailing-List) to Lulu-Ann | this is contradiction to above (Wolfgang Wasserburger 13:19, 19 April 2010 (UTC)) Depends on Cellphone used. Talks has a function like this, so it will note be implemented in LoroDux --DanielH 16:52, 10 May 2010 (UTC)
|
Compatibility Requirements
| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks |
|---|---|---|---|---|---|---|
| Use common commercial screenreaders | The software shall be fully compatible with commercial screenreaders: Nuance Talks, MobileSpeak and Jaws. Update (2013): The software shall be fully compatible with the free integrated screenreaders: VoiceOver (iOS), Talkback (Android) |
Acceptance. | 1 | 1 (if software is available for testing) | Mailing-List | |
| Use common open source screenreaders | The software shall be fully compatible with open source screenreaders: Orca, ... | Low cost. | 1 | Lulu-Ann | ||
| Import personal POIs from Loadstone | The software shall be able to import Loadstone user data. | For users who are using Loadstone aswell. | 2 | 2 | Mailing-List |
Hardware Requirements
| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks |
|---|---|---|---|---|---|---|
| Any bluetooth GPS | The software shall be able to work with any standard bluetooth GPS receiver, including combinations with Galieo or Glonass receivers. | 1 | 1 | Lulu-Ann | ||
| Any connected GPS | The software shall be able to work with any build in or cable GPS receiver, including combinations with Galieo or Glonass receivers. | 2 | 2 | Lulu-Ann | ||
| D-GPS | The software shall be able to work GPS receivers using correction data like EGNOS/WAAS. | 2 | 2 | Lulu-Ann | ||
| Share GPS | It shall be possible to have several applications running on one device, that share the same GPS receiver. | 3 | 3 | Lulu-Ann | (This might be realized by the use of an additional tool that pretends there are multiple GPS devices on several com ports.)
Look for [1] | |
| Any Keyboard | It shall be possible to use devices with either full size keyboard, mobile phone keyboard (numbers only), touchscreen or braille input/output device. | 3 | 3 | Lulu-Ann | ||
| Any output | It shall be possible to use visual text reading, screenreader and braille output device. | 3 | 3 | |||
| Output for deaf blind persons | It shall be possible to use morse code with vibration. | |||||
| Support integrated compass | If the device has an integrated or bluetooth compass, it shall be possible to turn the use of it on and off. (Autodetect flat orientationif needed?) It shall be possible to have a compass correction so you can have the compass on your shoulder 90° or 180° to how seeing persons would hold it. A function is needed to set the angle at sufficient speed to use it at low speed turns. | 3 | 3 | No device for testing available yet. TI SensorTag could be a cheap device for this use. | ||
| If compass supported, support declination | 3 | 3 | [2] | |||
| Gyrometer and accelerometer shall be supported if available | This is important when GPS signal is lost in underground stations etc. | TI SensorTag? [3] |
Es soll in späteren Versionen möglich sein, ein Ultraschallgerät anzuschließen, daß vor Objekten oberhalb des Blindenstocks warnt.
Profile Requirements
| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks |
|---|---|---|---|---|---|---|
| Store user profiles | The software shall be able to store several different configuration profiles. These profiles can be switched manually and they might be switched by speed or position. | It shall be possible to have different profiles for different users using the same device. Also different profiles for the same user are senseful for different speed (give less information while riding on a bus) or position (give less information if you are in the known area around one's home). | Standard | 2 | Lulu-Ann | (only 1 set of settings) |
| Export / import user profiles | It shall be easy to export or import user profiles. | High | 2 | Lulu-Ann |
More profile needs:
- Language
- Battery Power warning levels
- GPS signal quality / number of satellites in use warning levels
- Areas where other profiles shall be applied
- Speed levels when other profiles shall be applied
- Mobility profile (No steps, avoid steps, etc.)
- List of personal favorites
- Step length
- Metric or Imperial units
- User name and password for OSM data upload
- Offset to GPS time in hours, minutes, seconds
- Personal walking speed for estimated time of arrival
- Time to arrival telling mode
- Distance to arrival telling mode
- Use personal list for excluding translated information (not interested in cigarett vending machines)
- Include / exclude reading of untranslated OSM objects.
- Tell directions in degrees or numbers on the clock.
- For POIs: Tell distance first or name
- For favorites: Tell distance first or name
- For essentials (Streets, crossings): Tell distance first or name
- Use G-Sensor if GPS not available
Routing Requirements
| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks |
|---|---|---|---|---|---|---|
| Where am I | The software shall tell on demand and continuously where the user is. This shall include places, streets and amenities in the first version. | This is the basic requirement. | Highest | 1 | Lulu-Ann | OK, not continuously but on pressed key in version 1. |
| Tell coordinates | The software shall tell on demand the coordinates where the user is. It shall be configurable in the user profile, what format is used. Standard is DD°MM.ttt. | This is important for testing purposes. | Highest | 1 | Lulu-Ann | OK in version 1. |
| Addressfinder | The user shall be able to enter a street or other objects name as a routing start, via or destination point and for routing simulation. | Highest | 3 | Jürg (Email to Lulu-Ann, 2009-05-16) | ||
| Post code | The user shall be able to enter a post code instead of a city to choose a street. | High | 3 | Thomas (Email to blindennavigation at lists.openstreetmap.org 2009-05-18) | ||
| GPS offline mode | In subway stations, when the GPS receiver has no signal or if the GPS receiver is offline, the navigation shall switch to GPS offline mode. Then the user needs to acknoledge the arrival at the next crossing to proceed with the navigation. | High | 4 | Lulu-Ann | ||
| Time to arrival | In routing mode the time to arrival shall be told on demand or regularily. | Medium | 3 | Lulu-Ann | ||
| Distance to arrival | In routing mode the distance to arrival shall be told on demand or regularily. | Medium | 1 | Lulu-Ann | OK in version 1. | |
| Route calculation preferences | The route with the least street crossings without traffic lights shall be prefered. | High | 2 | Lulu-Ann | 3 | |
| Include public transportation | If preferred by the user the routing calculation shall include non dynamic public transportation data like bus and tram routes in the route. | Low | 4 | Lulu-Ann | Prio "nice to have" and version 5 for dynamic public transportation routing. | |
| Smart side-of-the-road choice | The route shall be calculated in a way that the changing of the side of the road is sensible. For example turning left shall be prepared by walking on the left side of the road. | Medium | 3 | Stephan (Mailing-List) | ||
| Real voices | The text shall be spoken by real voices, not by speech synthesizers. | Low | rejected | Stephan (Mailing-List) | This might be realized by the feature to substitute single words by personal voice recordings or sounds. | |
| "Manual compass correction" | If the user turns around, the GPS can not detect it. If the user somehow knows the direction he/she is heading (e.g. by locating noise or by using a tactile compass), it shall be possible to correct the orientation of the system. | 2 | Stephan (Mailing-List) | |||
| Distance by sound | The distance to a destination can be represented by a sound signal that becomes faster or higher during approach. | Stephan (Mailing-List) | 2 | |||
| Direction by vibration | The direction to a destination can be represented by a vibration signal that is short - long for turn right and long - short for turn left. | Idea from the mailing list | 1 | |||
| Sleep mode | While in sleep mode the systen shall be quiet and not try to calculate new routes, but it shall keep the connection to the GPS. | Stephan (Mailing-List) | Depends on Virtual-Machine --DanielH 15:50, 1 March 2010 (UTC) | |||
| Accuracy warning | The system shall give a warning, when the signal quality gets worse. | High | 1 | Stephan (Mailing-List) | Basic function for GPS fix loss in version 1. | |
| GPS-less mode | The system shall be able to calculate a route with given start and end, even if no GPS is connected. It shall give routing information, that will be acknowledged by the user when reached by pressing a key. | Medium | 3 | Stephan (Mailing-List) | ||
| Next navigation step | Not only in route planning mode but also in navigation mode it shall be possible to skip to the next directions for the case that the GPS inaccuracy causes the system not to read out the next direction because it does not detect that the current position is already reached. | High | 3 | Dietmar (Mailing-List) | ||
| It shall be possible to route on an OSM relation. | E.G.for following the Camino de Santiago. | Jens (Forum) | ||||
| It shall be possible to route on an prerecorded GPX track. | E.G.for following the Camino de Santiago. | Jens (Forum) |
Reading Requirements
| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks |
|---|---|---|---|---|---|---|
| Tell streets | The Where-am-I function shall tell the position like in this example: "You are 5 meters on the right side of tertiary street mainstreet, housenumber 10, heading towards residential street church street in 50 meters, in town smalltown, in district mydistrict, in county mycounty, etc." |
Definition of text format. | Highest | 2 | Lulu-Ann | |
| Tell POIs | The Where-am-I function shall tell the surrounding points of interest with their distance and direction, including personal favorites. |
Definition of text format. | Highest | 1 | Lulu-Ann | OK, but without personal favorites in version 1. |
| Tell directions | The software shall tell directions in degrees or in numbers on the clock (12 is straight on, 3 is turn right 90°). | Highest | 1 | Lulu-Ann | OK in version 1. | |
| Pause / skip | At any time (!) it shall be possible to interrupt the speech output. |
It must be possible to listen to the traffic. | Highest | 1 | Lulu-Ann | Since there is no Accesability API for J2ME this can only be a function provided by the screenreader-software --DanielH 16:56, 10 May 2010 (UTC) |
| Replace recurring text by sounds | Für PIOs: Wenn im Text "in 50 Metern" vorkommt, dann könnte man das durch eine
Tonfolge ersetzen, in diesem Fall z.B. durch eine Quinte aufwärts: Pieps (Ton tiefes C) - Pieps (Ton darüber liegendes G)> Wenn man den Ton sicher erkennt ersetzt man weitere, also für "In 30 Metern" mit einer Terz: Pieps (Ton tiefes C) - Pieps (Ton darüber liegendes E) und so weiter. Natürlich nur, wenn man möchte. |
Nice to have | 4 | Lulu-Ann | ||
| Name unnamed roads | Many footways have no name but an OSM ID. Instead of reading "unnamed road" or "road ID 23782583" there shall be an ID-number to syllable representation. e.g. 2=la, 3=do, 7=ke, 8=to, 5=pu which reads out "ladoketolatodo" |
Nice to have | Lulu-Ann | Not realized | ||
| Forward Language Choice to screenreader | It shall be possible to mark street names to be pronounced like in a different Language, e.g. "John-F.-Kennedy-Allee" in Germany would be marked like #en-en#John-F.-Kennedy#fr-fr#Allee#backtonormal# using HTML Tags for that. |
Lulu-Ann | Not realized, not supported by screenreaders yet (2013). | |||
| Auto-detect Language | If the letters change e.g. to kyrillic in street or city names, the reading language shall be switched to the language with the greatest probability. e.g. kyrillic shall be spoken in Russian. (or depending on the coordinates!) If the object name is available in the default language of the user profile, this shall be used as priority. |
Lulu-Ann | Not realized, not supported by screenreaders yet (2013). |
Internationalization Requirements
| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks |
|---|---|---|---|---|---|---|
| Configurable units | The user shall be able to choose between metric and imperial system for way length etc. Nautical miles are nice to have. | Medium. Metric first. | 2-3 | Lulu-Ann | ||
| Multi language support | The user shall be able to choose the language of output in his profile(s). | High. German and English first. | 1 | Lulu-Ann | Not possible due to of the lack of memory the KVM provides.
Possible Alternative: localized Versions of LoroDux --DanielH 16:57, 10 May 2010 (UTC) | |
| Local Plug-Ins | It shall be possible to attach plug-ins, that are only of local interest, for instance bus routing information for a certain area. It shall be possible to install and remove these plug-ins without any install operation on the programm itself. These plug-ins need to be provided GPS and other runtime information on demand or automatically (interfaces). |
Menu Requirements
| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks |
|---|---|---|---|---|---|---|
| Interrupt telling | It shall be possible to interrupt the telling of the position with to buttons: The first one jumps to the next comma, the second one ends the telling. | 1 | 2 | Lulu-Ann | Not possible with all screenreaders. | |
| Screenreader menu | It shall be possible to forward any command to the screen reader like voice choice, reading speed etc. | 3 | 3 | Lulu-Ann |
Editing Requirements
| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks |
|---|---|---|---|---|---|---|
| Add nodes | User is standing at new POI not available in OSM and wants to add it. He shall be able to select if this is only a private change, an exchangeable change, an OSM upload change or an OpenStreetBugs entry. | 2 | 3 | Lulu-Ann | ||
| Move nodes | User has been looking for a POI and found it next to the location it was in OSM (further away than GPS accuracy problem). Then he shall be able to call a function "move node", select one of the nearby POIs and move it to where he is standing. He shall be able to select if this is only a private change, an exchangeable change, an OSM upload change or an OpenStreetBugs entry. | 2 | 3 | Lulu-Ann | ||
| Add node to way | User is standing next to a way and wants to add a POI (bus_stop, traffic signals, barrier, gate, crossing etc.) that shall be an additional node on the way. The position shall be projected 90° to the way and the node shall be added directly on the way. This is for an OSM upload change only. | 2 | 3 | Lulu-Ann | ||
| GPS signal quality information | When the user attempts to add or change a position of an object, there shall be a warning if the GPS signal quality (HDOP) ist too bad. | 1 | 2 | Lulu-Ann | ||
| Average calculation (position) | It shall be possible to make several measurements for one position because the position can not be accessed (for example the middle of a crossing). The values shall be used to calculate an average that can be uploaded. The quality of the result shall be calculated and displayed. This shall not be offered if the HDOP is excellent, like with a GGGPS receiver. |
Lulu-Ann | ||||
| Average calculation (time) | It shall be possible to make several measurements for one position at different times because the data quality is not good. The values shall be used to calculate an average that can be uploaded. The quality of the result shall be calculated and displayed. | Lulu-Ann | ||||
| Add key+value to existing node | When there is an existing node with some key+value pairs, it shall be possible to add more key+value pairs. e.g. it shall be possible to add "tactile_paving=yes/no" / "shelter=yes/no" / "waste_basket=yes/no" / "FIXME=Bus route 353 is missing" to a bus stop or platform. |
Lulu-Ann | ||||
| Conflict management | When there is an editing conflict because the OSM database has been edited by somebody else, there shall be an error message. | 2 | 3 | Lulu-Ann |
Unsortiertes auf deutsch
Quelle: Lulu-Ann
Es soll ganz Deutschland auf einmal in den Speicher passen.
Es soll die Möglichkeit geben, als Einheit "Schritte" zu benuzten, wobei man die eigene Schrittlänge eingeben / und messen können soll.
Es soll möglich sein, einen Punkt oder eine Gegend an einen anderen User per SMS oder Bluetooth zu senden. Es soll ebenfalls möglich sein, eine solche SMS als Zielkoordinate auszulesen oder als Favorit zu speichern.
Es soll möglich sein, daß das Überqueren der Meridiane angesagt wird. In Gegenden, wo kein Kartenmaterial vorhanden ist, soll dies das Standardverhalten sein. Die Dichte der genannten Linien soll abhängig sein von der Reisegeschwindigkeit, bei >100 km/h nur die ganzzahligen Breitengerade, darunter mehr. (z.B. fahre ich mit dem Zug von Hannover nach München und habe Kartenmaterial von Hannover und München heruntergeladen, nicht jedoch von der Strecke dazwischen. Es soll nun angesagt werden, wann ich den 52., den 51., usw. Grad nördlicher Breite kreuze.)
Es soll möglich sein, daß es einen Automatisch alles-ansagen-Modus gibt, der alles nur 1x im vorbeigehen ansagt.
Gefahren-Tags sollen stets angesagt werden, möglichst mit Vibration.
Es soll möglich sein, Routen als .GPX-Dateien abzuspeichern.
Es soll möglich sein, daß Routen Anfangs-und Endpunkt geocodiert genannt werden. ("Die Routendatei 2008-12-31 beginnt in der Schmidtstraße und endet in der Müller-Straße").
Es soll möglich sein, die Route vorher zuhause durchzugehen, damit man sich auf Hindernisse vorbereiten kann.
Es muß ein Konzept für die Benutzerführung erstellt werden - Vergleiche mit den kommerziellen Anbietern wären sinnvoll. (Sendero, Wayfinder Access, Trekker...)
Alle Teile sollen modular angebunden sein.
Auch Karte oder Eingabemodul sollen sich in späteren Versionen austauschen lassen. Das Eingabemodul könnte z.B. später durch eine Voice Control ergänzt oder ausgetauscht werden, oder eine Gestenerkennung auf Touchscreen.
Quelle: Bert von der Blindennavigation@lists.openstreetmap.de Mailingliste
Es sollte möglich sein, sich folgendes ansagen zu lassen, jetzt mal unsortiert aufgezählt: - wo bin ich gerade, Straße, Ort, möglichst Hausnummer? (OK) - in welche Richtung bewege ich mich? Umschaltbar nach Grad, Grad relativ, Uhrzeiger, Himmelsrichtung. (OK) - wie schnell bewege ich mich? (in km/h, mph oder Knoten) (OK) - wie viele Satelliten werden gerade empfangen, für wie genau hält sich der Empfänger? (und das bitte absolut und nicht relativ) - was ist in der Nähe? (bitte mit konfigurierbarem Filter nach Kategorie: Kreuzungen, POIs, Straßen, Bahnhöfe/Bushaltestellen, auf Wunsch detailliertereInfos zu jedem Eintrag, wenn möglich auch mit konfigurierbarem Radius, selbstverständlich mit Entfernung und auch Richtung, wieder Grad, Grad relativ, etc., s.o.) (Konfigurierter Radius: OK) Für die Navigation: - Routenplanung für Fußgänger/Fahrrad/Auto, nach schnellste/kürzeste bzw.bei Fußgänger nach lieber Straßen oder eventuell auch kürzer und dafür mit "Schleichwegen". - Möglichkeit der Abfrage von Entfernung (gesamt/zurückgelegt/verbleibend) und Zeit (gesamt/zurückgelegt/verbleibend). - Eingabe von aktueller GPS-Position als Startpunkt, ansonsten für Start-/Routen-/Zielpunkt nach Adresse/Adreßbuch, freie Eingabe, POI, Länge/Breite (in dezimal oder h/m/s), Historie, Favoriten - Möglichkeit für Zwischenziele - sprachgeführte Geh-/Fahranweisungen, dabei bevorzugt nach Art von Route66, z.B. bei Bedarf "nach 300m an der zweiten Straße rechts", wenn die Möglichkeiten zu dicht aufeinander folgen. Bitte auch Weg/Straße ansagen, in die abgebogen werden soll, gern konfigurierbar. - beim Verlassen der Route gern dynamische Neuberechnung, bitte aber nicht ohne entsprechenden Hinweis, damit man im Zweifel auf Wunsch auf die alte Route zurück kann, ist als Fußgänger ja meist kein Problem. Schön wäre auch noch: Eingabe von Koordinaten nach Länge und Breite mit anschließender Ausgabe dessen, was dort in der Nähe ist... und Eingabe von Adressen mit Ausgabe der Koordinaten nach Länge/Breite. (also forward/reverse Geocoding) Nutzung mit auf Speicherkarte gespeichertem Kartenmaterial oder wahlweise interaktives laden der Daten, auf keinen Fall Zwang zur Online-Nutzung wie bei WFA. (Nutzung der Daten im Programm: OK. Speicherkarte, Download: noch nicht) Möglichkeit der Erkundung eines Kartenabschnitts, z.B. auch durch scrollen auf der Karte.
Android ist inkompatibel mit den Sun-Java-Standards, sie haben die Standards und Community-Prozesse einfach mal komplett ignoriert. Dennoch ist eine große Teilmenge von Standard-Java-APIs unterstützt. Alles was UI und systembezogen ist, ist aber komplett was eigenes. Wenn Du eine App für Java ME und Android machen willst, würde ich raten: - Kapsele Fachlogik und UI/Systemintegration (sollte man ja eh immer machen) - dann bestehen ganz gute Chancen, die Fachlogik wiederverwenden zu können. - Alles andere sollte für jede Plattform selbst gemacht werden.
Quelle: Commi-Liste
Thema unbenannte Wege: > Wie hättet Ihr es denn gerne? Navigieren von GPS-Position zum Ort XY kann mit rechts/links Anweisungen ohne Wegenamen funktionieren. > Reicht das erstmal, oder brauchen wir mehr? Eine Funktion in diesem Zusammenhang wäre wünschenswert. Unter der Suche könnte es eine Möglichkeit geben, die sich "Nächste benennbare Position" osä nennt. Diese sollte die Möglichkeit für Luftlinie und Weg bieten. Hintergrund ist die Möglichkeit, sich bei einem verstauchten Knöchel auf einem Spaziergang ein Taxi dort hin zu bestellen, wo es auch hin kann oder bei noch schlimmeren Dingen, einem allfälligen Notrufdienst nicht die Koordinaten nennen zu müssen, sondern so was wie "200m nördlich der K7654 und 2 km östlich von Kleinkleckersdorf" angeben zu können. In einer höheren Version wäre dass dann auch noch dahingehend ausbaubar, dass diese Ausgabe als SMS vorbereitet oder gar gleich versandt wird. Gruss
Heute um 08:20 Uhr schrieb J. <jbslists@online-rudel.net>: > Unter der Suche könnte es eine Möglichkeit geben, die sich > "Nächste benennbare Position" osä nennt. Diese sollte die > Möglichkeit für Luftlinie und Weg bieten. Imho würde hier Luftlinie und Richtung reichen... Apropos Richtung, die hatte ich in meiner letzten Mail ganz vergessen. Die sollte bei den Suchergebnissen und bei den POIs der Umgebung bitte auch ausgeworfen werden. Möglichst einstellbar nach Himmelsrichtung und Grad, vielleicht auch Grad relativ. > Hintergrund ist die Möglichkeit, sich bei einem verstauchten > Knöchel auf einem Spaziergang ein Taxi dort hin zu > bestellen, wo es auch hin kann oder bei noch schlimmeren > Dingen, einem allfälligen Notrufdienst nicht die Koordinaten > nennen zu müssen, sondern so was wie "200m nördlich der > K7654 [...] Das braucht man nicht. Bei einem Anruf auf der 110 oder 112 kann man gern die Koordinaten angeben, die haben quasi in Nullzeit den genauen Ort inkl. nächster Adresse und können einem auch ein Taxi dahin bestellen. Bei Blindschleichen machen die das auch gern, wenn man sich nur verlaufen hat, dafür muß man sich nicht mal den Fuß verstauchen. Seit NokiaMaps und Loadstone habe ich das allerdings noch nie gebraucht, das Verlaufen ist einfach zu schwer geworden. Bert
> > Unter der Suche könnte es eine Möglichkeit geben, die sich "Nächste > > benennbare Position" osä nennt. Diese sollte die Möglichkeit für > > Luftlinie und Weg bieten. > > Imho würde hier Luftlinie und Richtung reichen... Nö! Stell dir vor, Du bist auf einem Acker, neben dir verläuft eine Bahnlinie, ein Fluss oder ein anderes Ding, das zu überschreiten nicht angezeigt oder möglich ist. Jenseits dieses Flusses befindet sich eine Straße. Also sagen wir mal 50m Luftlinie entfernt. Die betreffende Stelle auf Wegen zu erreichen kann aber mehrere km bedeuten, wenn es keinen Bahnübergang, keine Brücke o.Ä. gibt. In der anderen richtung ist in z.B. 250m aber eine andere Straße, zu der ein dierekter Weg führt. Wollte ich mir nun ein Taxi bestellen oder einen Freund anrufen, auf dass ich aufgesammelt werde, so würde sich dieser Zweite Punkt doch viel eher anbieten. > Bei einem Anruf auf der 110 oder 112 > kann man gern die Koordinaten angeben, die haben quasi in > Nullzeit den genauen Ort inkl. nächster Adresse und können > einem auch ein Taxi dahin bestellen. Ja, schon! Aber ich würde u.U. auch gerne mal einen Freund oder auch selbst ein Taxi anrufen können, ohne über den Notdienst zu gehen. Gruss J.
Viele Sachen ließen sich dort jedoch sehr gut bedienen. Ich erinnere mich noch an die Funktion, dass man sich die Route nach dem berechnen anzeigen lassen konnte. Dann konnte man schritt für Schritt schauen, wie der Weg verlaufen wird. weiter ist es sehr hilfreich, wenn das Navi gleich den nächsten Schritt ansagt. z.B. Nach 300m an der 2. Möglichkeit Rechts in Hauptstraße abbiegen, dann nach 430 m an der 7. Möglichkeit Links. Dies hat zwei Vorteile. Ich weis gleich, dass ich nach der Abbiegung besser auf der linken Straßenseite gehe und ich kann zählen, an wie vielen Querstraßen ich vorbei muss. Wenn ich diese Informationen schon vor der Abbiegung erhalte kann ich auch sicher sein, dass keine ungenauen Positionsangaben des navis falsche angaben machen. Die Länge ist so genau wie die Karte und die Abbiegemöglichkeiten ebenfalls. Wenn diese Informationen erst Gegebenwerden, wenn ich mich in der Straße aufhalte, kann es sein, dass ich schon an einer Querstraße vor bei bin und das Navi hinterher hängt oder das mir das Navi voraus ist. Ebenfalls währe es gut, wenn das Navi so fern vorhanden die Art der Straßen anzeigen kann. Zur Orientierung könnte auch hilfreich sein, wenn das Navi zu überquerende Bahnschienen (Straßenbahn) erwähnt. Anhand solcher Informationen kann der nutzer die Zahl von Navigationsfehlern die durch die Ungenauigkeit des GPS hervorgerufen werden verringern. Wie auf Straßenbahnschienen könnte auch auf Brücken (über eingezeichnete Gewässer) abgefragt werden. Ein eventueller Eintrag könnte dann so aussehen: Straßeninformationen: 2 Querstraßen, 3. Straße mit Schienen 1 Querstraße, Brücke 2 Querstraßen Parkplatz dann abbiegen in Querstraße. So weis ich, dass ich von den Schienen noch relativ weit laufen muss. Nach der Brücke kann ich dann meine Ohren nach einem Parkplatz (Einkaufswaagen Geklapper Motorengeräusche) aufsperren und nach dem Parkplatz nach der Querstraße suchen. Wie oben erwähnt mache ich mich von der GPS Genauigkeit unabhängiger. Diese Informationen sollten aber nur auf Knopfdruck abgefragt werden. Sonst ist das Navi ja nur noch am erzählen. viele Grüße, Stephan
Ich ging bislang von der unausgesprochenen Vermutung aus, dass Lulu-Ann den Erkundungsmodus von Trekker kennt und ins Pflichtenheft mit eingebaut hat. Stephan bringt mich aber wieder zurück auf den OSM-Gedanken: Alles, was dort in der Datenbank gespeichert ist, kann Stützinformation für einen blinden Mobilisten sein. Das könnten natürlich auch Gebläsegeräusche am Hotel sein, Chlormief am Schwimmbad, Geräuschertes vorm Fleischer usw. Spätestens bei diesen Beispielen seht Ihr, dass dies offenbar ausschließlich für Blinde interessante Infos sind. Sowas wie Parkplatz hingegen oder Straßenbahngeleise, Gefällestücke oder Brücken, das dürften ohnehin gespeicherte Daten sein, die auch für Blinde als Stützinfo erschlossen werden sollten: Allgemeine Umgebungsinformationen zum Gehweg. Kapten meldet sich übrigens im Fußgängermodus alle 100 m mit einem Hinweis, was die Nutzersicherheit erhöht - Sicherheitsgefühl halt. Was bei Kapten gerade im Werden ist, das ist die gemischte Navigation per pedes und per ÖPNV. Sowas ist zwar arg komplex, sicherlich wird es aber in einer der späteren Umsetzungsstufen hoch attraktiv sein. Einen KFZ-Begleitmodus1 wünsche ich mir auch, der z.B. unterwegs die wechselnden Straßennamen ansagt, die man entlang fährt. Beim Begleitmodus2 könnte man auf mehr Umgebung eingehen, und Modus3 wär dann schon sehr touristisch. Solch ein Begleitmodus sollte einen Status haben, der Reststrecke und Restdauer ansagt, und der vor besonders schlechten Straßenbelägen warnt. Übrigens - was die Nordlichter so leicht übersehen: Ein Höhenprofil ist für oberflächenoptimierte Schnaufer wie mich durchaus entscheidend, ob ich einen Weg antrete oder ihn lieber von einem Taxi bewältigen lasse. Denn bereits 80 m Höhenunterschied auf 3 km, oder die Summe von 200 m Anstiegen auf der selben Strecke, das sind für mich erhebliche Infos, die die OSM-Datenbank ja doch enthalten dürfte. Und sowas ist hierzulande im Alpenvorland durchaus üblich. (In Marburg ist die Astmatreppe mit jämmerlichen 159 Stufen ein selbstredendes Beispiel). Folglich wären Weginfos beim Start wie "Das Ziel liegt 35 m höher als der Startpunkt, und die Summe der Anstiege auf der Strecke ist 65 m" Durchaus hilfreich. Radfahrer sehens sicherlich ähnlich. Aber es ist ja soooo einfach, Wünsche zu äußern, die andere verwirklichen sollen! ;-) Besten Gruß Franz Erwin
Es soll möglich sein, einer Wanderweg-Relation zu folgen. (Anforderung von Jürgen aus Wipperfürth).
Projekte (deutschsprachig)
- Ein Projekt der Uni Stuttgart [6]
Unsorted English information
Das hier zitierte Dokument ist der "Anforderungskatalog des gemeinsamen „Fachausschusses für Informations- und Telekommunikationssysteme“ (FIT) des DBSV, DVBS, PRDV BKD, ISCB und VBS Berlin, den 03.04.2008" Vollständiges Dokument: http://www.dbsv.org/fileadmin/dbsvupload/Worddateien/FIT/FIT_Anforderungen_an_Navigationssysteme_2008.pdf
| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks |
|---|---|---|---|---|---|---|
| sehbehinderten-/ blindengerechte Interaktion mit dem System | 1 | FIT | Selbstverständlich | |||
| hohe Zuverlässigkeit und Genauigkeit der Positionsbestimmung | Hardwareanforderung / Software kann hier nur Zustand melden. | |||||
| hohe Zuverlässigkeit und Genauigkeit des Kartenmaterials (gegebenenfalls erweitert durch spezielle Angaben wie z. B. akustische Ampeln) | 1 | FIT | Alleinstellungsmerkmal von OSM :-), traffic_signals:sound=* |
"Ausdrücklich soll jedoch auf die folgenden, wichtigen Tatsachen hingewiesen werden"
| Title |
|---|
| Satellitengestützte Navigationssysteme für blinde und sehbehinderte Menschen machen grundlegende Fähigkeiten im Bereich Orientierung und Mobilität nicht überflüssig, sondern setzen diese vielmehr voraus, um die entsprechenden Produkte überhaupt nutzbringend einsetzen zu können. |
| Satellitengestützte Navigationssysteme ersetzen nicht taktile Leitsysteme, denn diese dienen der sicheren Orientierung im Nahbereich und an Gefahrenstellen. |
| Satellitengestützte Navigationssysteme werden elementare Mobilitätshilfsmittel wie den weißen Stock oder den Blindenführhund niemals ersetzen, sondern immer nur ergänzen können und damit den Aktionsradius blinder und sehbehinderter Personen stark erweitern oder ihnen mehr Sicherheit in bekannter Umgebung bieten. |
| Trotz des Gebrauchs satellitengestützter Navigationssysteme wird es weiterhin erforderlich sein, Hilfsangebote sehender Mitmenschen anzunehmen oder entsprechende Hilfestellungen aktiv zu erbitten. |
"Anforderungen"
In den folgenden Abschnitten werden die spezifischen Anforderungen an ein für blinde und sehbehinderte Menschen geeignetes, satellitengestütztes Navigationssystem näher beschrieben und begründet. Sie dienen nicht dazu, ein bestimmtes Gerät zu spezifizieren. Ziel ist vielmehr, Leitlinien für einen verbindlichen, international anerkannten Standard zu schaffen, anhand dessen die Hersteller von sowohl speziellen Hilfsmitteln als auch Geräten für den allgemeinen Markt, Produkte für die Zielgruppe entwickeln können. Bei der Schaffung des Standards sowie bei der konkreten Geräteentwicklung sind die Betroffenen, vertreten durch Interessengemeinschaften, Verbände oder deren Fachgremien zu beteiligen. Die nachstehenden Anforderungen sind grundsätzlich nicht nur auf satellitengestützte Navigationssysteme, sondern auch auf andere z.B. Indoor Navigation anwendbar. Die Priorität wird in „muss“, „soll“ und „kann“ spezifiziert. 4.1 Sehbehinderten-/ blindengerechte Interaktion mit dem System Die Anforderungen sehbehinderter und blinder Menschen sind aufgrund von Erfahrung, Training und persönlicher Lebensführung sehr unterschiedlich.
"Grundsätzlich sind folgende Aufgaben zu unterstützen:"
| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks |
|---|---|---|---|---|---|---|
| Routenplanung (zu Hause) | 2 | 3 | FIT | |||
| Simulation der Route (zu Hause) | 2 | 3 | FIT | |||
| Positionsbestimmung (Information zur direkten Umgebung) | 1 | 1 | Koordinaten, POIs OK in version 1. | |||
| Dynamische Navigation (automatische Neuberechnung der Route bei Abweichung) | 3 | 3 | FIT | |||
| Aufzeichnung der tatsächlichen Routen (Nachbearbeitung) | 2 | 2 | FIT |
Im Einzelnen sind folgende Kriterien zu beachten:
| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks |
|---|---|---|---|---|---|---|
| Die Bedienung muss auch durch sehende Menschen (Familie, Trainer) möglich sein. | 1 | 1 | FIT | OK in version 1. | ||
| Die Bedienung muss an den Wissenstand anpassbar sein:
• Anfänger • Fortgeschritten • Profi |
Einstellungen können als Profil gespeichert werden. Was ist gemeint mit dem Wissensstand? Ein Mobilitätstraining muß vorausgesetzt werden. | |||||
| Die Ausgabe muss optisch und akustisch erfolgen. | Optische Anforderungen sind irrelevant (Kapten!). | |||||
| Das Display zur Ausgabe der optischen Informationen muss über eine ausreichende Größe verfügen, die Darstellung muss klar gegliedert sein. Die Displayeinstellungen (Helligkeit, Farbwahl, Kontrast, Hintergrundbeleuchtung) müssen sich an unterschiedlichste Sehanforderungen und Umweltbedingungen einfach anpassen lassen. | Optische Anforderungen sind irrelevant (Kapten!). | |||||
| Die Sprachausgabe muss gut verständlich und in der Lautstärke äußerst variabel sein. Sie sollte sich automatisch der Umgebungslautstärke anpassen. | Screenreader bzw. Hardware-Anforderung | |||||
| Eingaben müssen durch akustische Signale quittiert werden. Die verschiedenen Formen der Ausgabe (Routenführung, Routenabweichungen, Fehlermeldungen ...) sind mit gut unterscheidbaren akustischen Signalen anzukündigen. Die Lautstärke dieser Signale sollte unabhängig von der Lautstärke der Sprachausgabe einstellbar (bzw. abstellbar) sein. | Akustische Quittung im Fehlerfall: OK in version 1. Lautstärke: Hardware bzw. Screenreader-Anforderung. | |||||
| Die Tastatur muss klar gegliedert sein; die einzelnen Bedientasten müssen ausreichend groß, gut tastbar, in der Form unterscheidbar und mit einem gut erkennbaren Druckpunkt versehen sein. | Hardware-Anforderung | |||||
| Die Tastatur muss für sehbehinderte Nutzer eine große, kontrastreiche und abriebfeste Beschriftung versehen sein. | Hardware-Anforderung | |||||
| Als Alternative zur Eingabe über Tastatur sollten Sprachbefehle wie „Start“ und „Stopp“ möglich sein. Auch die sprachliche Eingabe von Zielen (in Abhängigkeit vom Kartenmaterial) kann die Bedienung vereinfachen. Dabei muss die Spracheingabe auch bei hohem Hintergrundgeräuschpegel zuverlässig funktionieren und gegenüber dem Sprecher tolerant sein. Bei Missverständlichkeit sollte das System Auswahlmöglichkeiten und Hilfestellungen anbieten. | Keine Spracheingabe geplant. | |||||
| Eine genormte Schnittstelle zum optionalen Anschluss von Blindenschriftdisplays muss vorgesehen werden. Sie sind Voraussetzung für die Nutzung durch Taubblinde und verbessern die effiziente Nutzung des Systems für Blindenschriftleser. | Bluetooth. Von der Benutzung durch alleinreisende Taubblinde wird dringend abgeraten. | |||||
| Genormte Anschlüsse für Headsets und andere, spezielle elektronische Hörhilfen sind vorzusehen. | Hardware-Anforderung bzw. Bluetooth. | |||||
| Vibrationssignale sollten insbesondere bei der Routenführung genutzt werden, Sie sind Voraussetzung für die Nutzung durch taubblinde Menschen und entlasten die akustische Wahrnehmung des Nutzers. | OK in Version 1. | |||||
| Die Kompatibilität von Softwarelösungen mit den für das jeweilige Betriebssystem verfügbaren Screenreadern (Bildschirmvorleseprogramm) und Screenmagnifiern (Darstellungsvergrößerung) ist sicherzustellen. | Nuance Talks: OK in version 1. | |||||
| hohe Zuverlässigkeit und Genauigkeit der Positionsbestimmung | Hardware-Anforderung | |||||
| Beim Bewältigen von Wegen gibt es typische Situationen, bei denen blinde und sehbehinderte Menschen Unterstützung erwarten: als Fußgänger unter freiem Himmel, in Unterführungen, Passagen und U-Bahn-Stationen sowie anderen öffentlichen Gebäuden. | Keine Indoor-Navigation. | |||||
| als Fahrgäste in Bussen und Bahnen des öffentlichen Nah- oder Fernverkehrs sowie als Beifahrer in Personenkraftwagen | Bei GPS Empfang ist Funktionalität gegeben, vorerst keine speziellen Features. | |||||
| als Kundinnen und Kunden von Ämtern und Behörden, die einem öffentlichen Gebäude bestimmte Räume aufsuchen müssen. | Keine Indoor-Navigation | |||||
| Sehende Fußgänger benötigen ein Satelliten-Navigationssystem lediglich zur Groborientierung, während sie die nähere Umgebung mit den Augen erfassen. Im Bereich "öffentliche Verkehrsmittel" nutzen normalsichtige Menschen Fahrpläne und die Anzeigen der Fahrgastinformationssysteme, im Bereich "öffentliche Gebäude" machen sie von Übersichtstafeln und Hinweisschildern Gebrauch. Für blinde und hochgradig sehbehinderte Personen, denen die optischen Umgebungsinformationen und Hinweise nicht zur Verfügung stehen, sind deshalb im Einzelnen folgende Kriterien zu beachten: | ||||||
| Der Fehler bei der Positionsbestimmung sollte optimalerweise nicht mehr als einen Meter betragen (Reichweite des weisen Taststocks). | Unrealistische Hardware-Anforderung | |||||
| Sollte eine genaue Positionsbestimmung aktuell nicht möglich sein, muss das System darauf hinweisen, dass die präsentierten Werte ungenau sein könnten. | Info bei GPS Fix Verlust OK in version 1. | |||||
| Beschleunigungssensoren, Schrittzähler oder elektronischer Kompass können dazu beitragen, dass die Position des blinden bzw. sehbehinderten Nutzers auch nach dem Abreißen der Sichtverbindung zu den Satelliten weiterhin metergenau bestimmt werden kann. | Hardware steht nicht zur Verfügung. Geplant für spätere Version. | |||||
| Ein integrierter Kompass kann dazu benutzt werden, dass dem Nutzer die Gehrichtung zuverlässig genannt werden kann, ohne dass er sich bewegt. | Hardware steht nicht zur Verfügung. Feature ist geplant. | |||||
| Das System muss mindestens einen Fußgänger-, einen Fahrzeug- und einen freien Modus (nicht kartografiertes Gebiet) unterstützen. Weitere Modi wie Nahverkehr, barrierefreie Wege, etc. können die Navigation verbessern. | Vorerst nur Fußgänger-Modus. | |||||
| Das Definieren markanter Punkte sowie das Aufzeichnen einer bereits abgegangenen Route muss unterstützt werden. Der Austausch dieser Informationen mit anderen Nutzern sollte vorgesehen werden. | Favoriten OK. OSM Download OK, OSM upload geplant. | |||||
| Auf Knopfdruck muss der Nutzer folgende Informationen erhalten: aktuelle Position, Straßen, Wege und Kreuzungen in unmittelbarer Nähe sowie markante Punkte in der naher Entfernung (Bushaltestellen, akustische Ampeln, etc.). Weitere Angaben wie Höhe über Null, Himmelsrichtung, etc. können hilfreich sein. | OK außer für Straßen in version 1. | |||||
| Routen müssen im Voraus (zu Hause) geplant und erkundet werden können. Die Erkundungsfunktion muss auch die nähere und weitere Umgebung der vorgesehenen Route mit einschließen, um sich so auf notwendige Abweichungen vom geplanten Weg vorbereiten zu können. Schon bei der Routenplanung müssen Richtungs- und Entfernungsangaben zwischen den einzelnen Routenpunkten verfügbar sein. Das System muss die individuelle Routenoptimierung (z.B. akustische Ampeln) durch den Nutzer unterstützen und speichern. | Geplant. | |||||
| Neben den Standardkriterien wie „schnellste Route“ oder „kürzeste Route“ sollten auch spezielle Kriterien wie z.B. „treppenfreie Route“ oder „ nur befestigte Wege“ unterstützt werden. | Geplant. | |||||
| . Weicht der Nutzer von der geplanten Route ab, muss er entscheiden können, ob ihn das System auf die ursprüngliche Route zurückführen oder ihm anhand der aktuellen Position eine neue Route anbieten soll (ein- und ausschaltbare dynamische Routenaktualisierung) | Geplant. | |||||
| Standardisierte Schnittstellen zu weiteren Diensten wie (dynamische) Fahrgastinformationssystemen, Verkehrsleitsystem sowie Informationen zur aktuellen Umgebung (Location based Services) sind vorzusehen. Damit können die von ihnen bereitgestellten Daten (insbesondere GPS-Position) in die Routenplanung einbezogen werden | Da müßten die Standards erst mal auf der anderen Seite vorliegen. | |||||
| Im System müssen standardisierte Schnittstellen zu Indoor-Navigationssystemen vorgesehen werden. Der Übergang von der satellitengestützten Outdoor- zur Indoor-Navigation muss automatisch erfolgen. | Noch nicht. | |||||
| In Verbindung mit Mobiltelefonen kann eine Notfall- oder Hilfefunktion realisiert werden. | Geplant |
"hohe Zuverlässigkeit und Genauigkeit des Kartenmaterials"
- Umfang und Genauigkeit der im Kartenmaterial hinterlegten Informationen sind entscheidend dafür, wie genau die Ortsangaben und Routenbeschreibungen sind, die das System liefert. Welchen Nutzen ein Navigationssystem blinden und sehbehinderten Menschen bringt, hängt damit in erster Linie von der Qualität des zu Grunde liegenden Kartenwerks ab.
- Die Bedürfnisse sehbehinderter und blinder Personen stellen wesentlich höhere Ansprüche an den Detaillierungsgrad und die wahrnehmungs- und handlungs-gerechte Informationsaufbereitung, als dies bei sehenden Menschen der Fall ist.
Im Einzelnen sind folgende Anforderungen an das Kartenmaterial zu beachten:
| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks |
|---|---|---|---|---|---|---|
| Das Kartenmaterial sollte stets auf dem aktuellsten Stand sein. Eine automatische Aktualisierung kann dazu beitragen. | OSM | |||||
| Das Kartenmaterial muss in einem verbreiteten Industriestandard vorliegen. | Abgelehnt. Eigener Standard, dafür weltweite Verbreitung. | |||||
| Kartenmaterial, das die Navigation sehbehinderter und blinder Menschen unterstützt, muss unentgeltlich zur Verfügung gestellt werden. | OK, CC-BY-SA | |||||
| Das Kartenmaterial ist auf die Bedürfnisse blinder Fußgänger abzustimmen. Es ist z.B. um folgende Attribute zu ergänzen: | Proposals laufen. | |||||
| Vollständige Erfassung aller, vom Fußgänger nutzbaren Bereiche: Bürgersteige (beide Straßenseiten!), Gehwege, Treppen, Unterführungen, Straßenquerungen, etc. | OSM | |||||
| Beschaffenheit, Breite und Steigung der Gehwege | Geplant, surface=*, incline=* | |||||
| Richtungswechsel durch Kurven | Geplant | |||||
| Haltestellen und Zuwegungen | highway=bus_stop OK in version 1, highway=service geplant für version 3 | |||||
| Wege mit taktilen Leitsystemen und/ oder akustischen Ampeln | tactile_paving=*, traffic_signals:sound=* | |||||
| Die speziellen Attribute müssen in die Standards für das Kartenmaterial integriert werden, sodass sie systematisch erfasst und von entsprechenden Navigationssystemen ausgewertet werden können. | OSM | |||||
| Das Kartenmaterial muss so aufbereitet sein, dass verschiedene Informationsebenen vom Nutzer gewählt werden können: Bsp. Nutzereinstellungen der Informationsmenge entlang der Route | Profile mit Einstellmöglichkeiten sind geplant. | |||||
| Service zum Austausch aktueller Routeninformationen zwischen den Nutzern erlaubt eine zeitnahe Information über Baustellen und andere Gegebenheiten | TMC ist in späteren Versionen denkbar, aber mehr auf Bedürfnisse von Autofahrern abgestimmt. Ein Baustellen-Informations-Austausch-Portal ist denkbar. |
Accessibility programming Guides
Java
Reports about good and bad things in comparable applications
- http://www.matthias-haenel.de/hdlswfa.html
- Navigon Test Version for Symbian 3rd Edition http://www.navigon.com/site/de/de/products/navigation_software/symbian