LoroDux/Requirements

LoroDux · Requirements · Compatibility list · Pilot regions · Translations

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) This requirement can be fulfilled by several operating systems now. (2013)

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	1 not known	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)

• Easee, ein Projekt der Uni Darmstadt. GPS unterstützte kognitive Laufzettel [4], [5]

• Ein Projekt der Uni Stuttgart [6]

• Ein Doppel-Projekt der TU Graz pontes, Odilia

Unsorted English information

• non visual audio-haptics

Anforderungen aus dem Dokument "Anforderungen an satellitengestützte Navigationssysteme für blinde und sehbehinderte Menschen"

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

"Navigationssysteme für Blinde und Sehbehinderte müssen grundsätzlich folgende Anforderungen erfüllen"

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

• http://docs.blackberry.com/en/developers/deliverables/11937/index.jsp?name=Accessibility+-+Development+Guide+-+BlackBerry+Java+Application5.0+Beta&language=English&userType=21&category=Development+Guides&subCategory= from Blackberry

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