Es geht um diesen Bereich:
http://www.openstreetmap.org/?lat=47.990595&lon=7.845154&zoom=18&layers=M
Da sind nicht nur die Spuren mit highway=* einzeln erfasst, sondern auch noch mehrere higway=primary mit area=yes für mehrspurige Bereiche und auf Brücken mit gemeinsamen nodes. Etwa die:
http://www.openstreetmap.org/browse/way/160420003
http://www.openstreetmap.org/browse/way/119871085
http://www.openstreetmap.org/browse/way/160419996
Da der router auch über Kanten von area=yes einen Weg sucht, passiert in Navigator Free mit aktuellem Material folgendes:
http://ubuntuone.com/0n4X3eUqVb9KZk0orxgGcs
Immer schön auf kürzestem Weg die Bordsteinkante lang und über das Brückengeländer. 
Leider haben OSRM, OpenRouteService, Cloudmade oder mapquest hier kein aktuelles Material, um in diesen den Fehler nachvollziehen zu können, und Osmand kann nicht simulieren.
Ich sehe da nur den Ausweg, diese area-highways mit access=no vom routing zu verbannen und die Wiki entsprechend zu ändern. Das area-tagging werden wir wohl nicht verhindern können. Vielleicht kann da auch QA-Tool helfen.
Mapfactor habe ich schon informiert.
Hat jemand schon ähnliche Erfahrungen mit anderen Routern dazu? Ist access=no eine Lösung?
Da kann man nur sagen: Garbage in - Garbage out. 
wenn Du mit simulieren eine offline-Routenberechnung von A nach B meinst (ohne GPS),
doch das kann er.
Trash!
Aber OSM ist ja eine Spielwiese.
Regeln sind ja verpönt.
Bin nicht der große Osmand-Kenner. Wie?
Long-click on Map (B) : Ziel setzen, Long-click on Map (A) : Route von hier.
Stimmt. Eigentlich stehts da http://wiki.openstreetmap.org/wiki/DE:Key:area unter Straßenflächen deutlich:
Wenn Strassen mit area=yes getagged werden wird davon ausgegangen, dass keine Strassenlinien darin verlaufen, d.h. innerhalb der Fläche gibt es keine Richtung). Beachte: Zur Zeit gibt es keinen Konsens, wie Strassen (ausser highway=pedestrian), welche mit area=yes bezeichnet sind interpretiert werden sollen.
Sollte man das nicht noch klarer ausdrücken. Ich stelle mir folgenden Zusatz vor:
Werden Straßenflächen erfasst, auf denen Straßenlinien verlaufen, muss die Straßenfläche zusätzlich mit acces=no getaggt werden, um fehlerhaftes routing über deren Außenkanten zu verhindern.
Entsprechende Verweise an anderer Stelle machen wohl auch Sinn.
Nein, für Straßenflächen soll das dafür vorgesehenen area:highway genutzt werden. 
Danke, habe es probiert.
Osmand erzeugt auch eine Route über die Bordsteinkanten und Brückengeländer 
edit:
…und schlägt eine vierte linke Spur vor 
Ohne in Tagginschemata eingreifen zu wollen: Es gibt Routingalgorithmen über Flächen. Die sind wohl in OSM nicht implementiert.
Das Problem solcher Algorithmen sind aber die Einbahnstraßen. Für Indoor Mapping wäre das aber nicht verkehrt.
Stellen wir uns einen runden Innenhof in einem Einkaufszentrum un den kürzesten Weg zwischen 2 Punkten.
Wäre der Routing schlau, suchte er nach direkter Verbindung beider Punkte über area=yes…
Das ist klar, beim vorliegenden Fall hat schlicht der Mapper den Unterschied zwischen ungerichteten Plätzen(area=yes) und
gerichteten Straßenflächen(area:highway) nicht verstanden.
bei (a) sollte ein Router den kürzesten Weg innerhalb der Fläche suchen, bei (b) die Fläche ignorieren und
über den Vektor routen.
Dann wäredas Tagging highway=pedestrian + area=yes wohl hinfällig.
OSRM sagt: “data: 121009 06:59Z”
Openrouteservice: “OSM-Data for Routing: 11.03.12”
Cloudmade hat tatsächlich mal wieder aktualisiert (dem Rendering nach), irgendwann mal nach nach Juni.
Mapquest hängt gerade auch etwas zurück, datieren kann ich es nicht. Sollten aber nur wenige Wochen sein.
Cloudmade und Mapquest geben als Lizenz noch CC-BY-SA an, sind also auf einem Stand vor der Lizenzumstellung.
OSRM sollte also aktuell genug sein, finde ich
Man muss allerdings beachten, dass Cloudmade und Openrouteservice ziemliche Scheiße zusammenrouten, da sie Turn Restrictions ignorieren und damit fürs PKW-Routing absolut ungeeignet sind (und damit auch alle darauf aufsetzenden Dienste/Apps).
Openrouteservice schimmelt augenscheinlich kräftig vor sich hin, während Cloudmade durch frische Daten wenigstens mal wieder gezuckt hat.
Wäre dann Taggen für den Router.
Nicht unbedingt. Langgestreckte Fussgängerzonen könnte man mit area:highway+way und große “platzhafte” mit
area=yes ohne zusätzliche ways taggen.
Sicher? das nur aus der Attributierung zu schliessen, halte ich für etwas leichtsinnig.
Gruss
walter
Darf ich bitten, zum Thema zurückzukommen. Es geht nicht um Datenaktualität. Fakt ist, dass zwei Programme (Navigator Free und Osmand) hier mit den Daten nicht klarkommen.
@ Radeln:
Nein, das ist kein taggen für den router, denn generell ist ja das routen über die Kanten eines highway-areas bisher erlaubt.
Die Wahl zwischen einer missbräuchlichen Nutzung eines bestehenden Tags, mit der man sogar Fehler in Anwendungen verursacht, und dem Einsatz eines genau für diesen Zweck gedachten Proposals sollte doch leicht fallen…
Und zu der späteren Anmerkung: Es handelt sich beim Einzeichnen eines Platzes mit access=no, wo eigentlich eine breite Straße verläuft, schon um Tagging für den Router. Denn auch wenn so ein fehlerhaftes Routing verhindert wird, werden Renderer und andere Anwendungen dort immer noch einen Platz zeichnen, statt wie eigentlich korrekt die linienhafte Straße in der Breite an die Straßenfläche anpassen zu können.
(Der Fehler besteht allerdings nicht im Setzen von access=no, was immerhin den Schaden begrenzt, sondern darin, überhaupt highway=* + area=yes statt des zutreffenderen area:highway=* zu verwenden.)
Eben, auch in Fußgängerzonen gibt es Straßen und Plätze. Für erstere war “highway=pedestrian + area=yes” noch nie passend (was manche nicht davon abgehalten hat, es zu verwenden); für letztere ist dieses Tagging weiterhin das Mittel der Wahl.
Die Grenze zwischen den beiden Fällen mag im Fall von Fußgängerzonen in Einzelfällen etwas schwierig zu ziehen sein, aber das ändert nicht grundsätzlich etwas daran, dass es zwei Fälle sind.
Dann fasse ich mal zusammen:
area=yes in Verbindung mit highway=* soll zur 2D-Darstellung von Straßenflächen außer bei highway=pedestrian nicht verwendet werden, um unsinniges routing zu verhindern, weil area=yes in diesen Fällen ein routing über die Flächenkanten erzeugen würde. Eine derartige Verwendung fällt unter “Taggen für den Renderer”.
Für die 2D-Darstellung von Straßenflächen ist area:higway=* das Mittel der Wahl, auch wenn dies noch im Proposal-Stadium steckt.
Zusatz:
Da ich keine Ahnung habe, welcher Renderer schon area:highway=* auswertet und darstellt, befürchte ich tagging-wars, weshalb das proposal schnellstmöglich zur Abstimmung kommen sollte, um den key dann in der Wiki zu dokumentieren.
Fazit:
Ich fange dann mal an, so etwas wie dieses:
http://www.openstreetmap.org/browse/relation/2390077
entsprechend umzubauen.
Dann ist aber nichts mehr zu sehen, z.B. die Tankstelle südlich, das wird dem Ersteller möglicherweise nicht gefallen