Routing mit OSRM funktioniert jetzt:
https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot&route=53.10908%2C9.14698%3B53.10947%2C9.14559
BRouter (Wandern beta) möchte es allen Recht machen und verwendet Fußweg und Straße: https://brouter.de/brouter-web/#map=19/53.10931/9.14637/standard&lonlats=9.146979,53.109072;9.145576,53.109469&profile=hiking-beta
Hallo JochenB,
ich gebe zu, dass ich bei meiner knappen Formulierung wohl zu sehr auf Deine Aussage des systematischen Fehlers beim Separat-Mapping sowie die (alleinige) Aussage des “die Fahrbahn kann überall gequert werden”
und den ewigen Madige-Äpfel - Klasse-I-Birnen - Vergleich der Routing-Graphen “Separat mit fehlenden Querungsverbindungen” sowie “Key-Mapping ohne Berücksichtigung des Key-Mappings” eingestiegen bin.
Daher mal etwas ausführlicher:
Mit dieser (alleinstehenden) Aussage beschränkst Du das Routing systematisch auf die Nutzergruppe
Kategorie A: Nutzer, für die ein Bordstein kein Hindernis ist.
Damit grenzt Du die
Kategorie B: Nutzer, für die ein Bordstein ein Hindernis ist
systematisch aus.
Allerdings sagst Du ja zusätzlich aus, dass man Querungshilfen auch per node angeben kann - wodurch das Routing auch für Kategorie B möglich wäre.
Und insofern gehe ich auch mit Dir konform, dass bei korrekter und vollständiger Erfassung das Separat- wie das Key-Mapping bezüglich Deiner 8-Punkte-Liste ziemlich gleichwertig ist.
Key-Mapping hat dabei einen Vorteil beim Punkt 7 Rendering, sobald es um Überzeichnung bei kleinen Maßstäben geht.
Separat-Mapping hat da ein Alleinstellungsmerkmal bei Punkt 8 Exakte Geometrie.
Insofern ist es tatsächlich eher eine persönliche Präferenzierung der eigenen Wichtung.
Ich würde allerdings dann gerne verstehen, was Du mit
meinst?
Ich kann nur vermuten, dass sich das auf den obigen Äpfel-Birnen-Vergleich bezieht.
Und
ja, ich bin mir sicher - und das Tagging ist ja durchaus schon vorhanden - ob es leicht auszuwerten ist, sei mal dahingestellt.
Aktuelle Router arbeiten auf (bereits vorhandenen) Kanten - das Key-Mapping müssten “ambitionierte” Router erst in seitenrichtige (virtuelle) Kanten umformen für ihren Graphen.
Und dann würden sie eine fehlende Querungsangabe genauso gnadenlos mit “fehlerhaftem” Umweg darstellen.
Mein persönliches Fazit:
Beide Mappingvarianten bieten die notwendigen Voraussetzungen für ein Kategorie-B-Routing - und der Mapping-Aufwand ist bei beiden in meinen Augen identisch. Ich persönlich bevorzuge dabei das für mich klarer abgegrenzte und übersichtlichere Separat-Erfassen.
Beim Key-Mapping ist höherer Aufwand auf der Auswerteseite erforderlich.
Aktuell erzeugen Auswerter aus Key-Mapping kein korrektes Routing für Kategorie-B-Nutzer - bis ambitionierte Router soweit sind, bietet das Separat-Mapping bereits jetzt die Möglichkeit.
Und meine Präferenzen liegen nunmal eindeutig bei Denen, für die ein Routing essentiell wichtig ist, als bei Denen, für die es nur eine mentale Erleichterung darstellt.
Grüße
Georg
Je nachdem, wie viel Gepäck ich habe und ob mit/ohne Anhänger, fahre ich ja auch gerne mal gesetzeskonform mit dem Fahrrad. Heißt, ich möchte wissen an welcher Stelle ich von dem Radweg auf die Straße wechseln sollte um dann auch flüssig Linksabbiegen zu können. Das hinzubekommen, halte ich ohne getrenntes Mappen für unmöglich, da es öfter mal vor einer Kreuzung dafür ein Stück abgesenkten Bordstein gibt. So was kann nicht gemappt werden.
das tag sagt aus, dass beidseits ein Gehweg verläuft, aber ob man da queren kann und darf ist dadurch noch nicht völlig klar. AFAIK haben wir noch gar keine tags um sagen zu können hier darf man queren oder nicht, vielmehr vermutet jeder, ist ja klar dass man überall (nicht) queren darf, je nach Rechtslage (ist vielleicht auch ein Fall von: „länderspezifische allgemeine Regelungen werden nicht getaggt“-eine Regel die sowieso eher nicht befolgt wird). Bei sidewalk ist davon abgesehen glaube ich auch nicht immer sichergestellt, dass der nicht doch baulich getrennt von der Straße ist (da könnte ich mich aber auch täuschen ).
Du hast Recht, ansich sagt ‘sidewalk=both’ nur, dass es zwei Gehsteige gibt und nichtmal, ob sie abgesetzt sind oder nicht.
Die Frage ist, wovon gehen wir aus, wenn keine Angaben zum Querungswiderstand gemappt sind.
Ich dachte immer, wenn nichts anderes getaggt ist gehen wir davon aus, dass man queren kann, anders bekäme man heute kein routing hin.
Ich sehe, da wurden ein paar neue Schienen gelegt. Offensichtlich immer noch zu wenige, denn die Router benutzen auf weiten Strecken nicht den Gehweg sondern die Straße. Nicht was Eltern ihren Kindern beibringen wollen. Nicht was Leute mit eingeschränktem Sehvermögen vorgeschlagen haben wollen.
Genau deswegen ist das Getrennt-Erfassen von Gehsteigen wie ganz speziell diesem nicht zielführend.
Update: Verzeihung skyper, dem ich die Worte von GeorgFausB in den Mund gelegt hatte.
Ich bezog mich auf das Vorgehen von OSM_RogerWilco für straßenbegleitende Gehwege. Er taggt an jedem möglichen Ziel eine Verbindung zwischen seperater Gehweglinie und der Straßenline. Im Mappen ist das recht aufwändig.
Er trifft dabei Annahmen, wo Querungen sinnvoll sein könnten. Nehmen wir mal an, diese Annahmen sind richtig, dann sollten die Router immer den besten Weg finden. Für die Anwendung “Routing” wäre dann das Problem gelöst.
In der Karte ist es aber weiterhin nicht korrekt abgebildet. Dort sieht das so aus, als wenn nur an bestimmten (vielen) Punkten gequert werden kann. In der Realität kann man aber überall queren. Das lässt sich mit diesem Mappingverfahren nicht abbilden. Sowas bezeichne ich als “systemetischen Fehler”.
Und nun zum Routingalgorithmus und wie er sich seinen Routing-Graphen erzeugt. Das ist eine echt spannende Frage!
Für die simple Frage “hat die Straße einen Gehweg” braucht es das noch nicht. Die Frage stellt sich erst, wenn die Lage der Gehwege im Routingalgorithmus berücksichtigt werden soll.
Aber nur, wenn man ‘crossing=no’ als Standardwert bei fehlenden Querungsangaben annimmt, siehe zwei Post früher an DieterDreist (#131). Das wäre jedoch inkonsistent zum bisherigen Umgang mit fehlenden Querungsangaben:
Bei Kreuzungen steht heute häufig nichts zu ‘crossing’, auch bei vielen Kreuzungen zwischen Gehwegen und Straßen. Vermutlich alle Router gehen davon aus, dass man dort die andere Straße queren kann, sonst würde das Routing oft schon an der ersten Kreuzung abbechen.
Genauso würde ich es auch mit Querungsangaben an Linien machen. Wenn keine Angabe da ist, so nehmen wir an, dass ein Queren möglich und der Querungswiderstand überall gleich ist.
Dann ergeben sich vier sinnvolle Querungsstellen:
wo ich auf eine Straße treffe
wo sich seitenraumbezogene Eigenschaften der Straße ändern können
wo Querungen getaggt sind
wo ich die Straße verlasse
Das sind
alle Knoten, wo Linien beginnen/enden/abzweigen.
alle Knoten mit Querungsangaben (außer ‘crossing=no’)
die Stellen, wo Start und Ziel der aktuellen Routingaufgabe liegen.
Ich denke, wenn der Routingalgorithmus dafür die virtuellen Gehwegkanten erzeugt, sollte er sie genau dort mit der Gegenseite bzw Fahrbahnkante verknüpfen. Dann solllte es auch keine fehlerhaften Umwege geben.
a. und b. kann man einmal im Pre-Prozess für das Netz machen.
c. ist für jede Routingaufgabe speziell, dafür müsste der Router jedes mal virtuelle Knoten im Graph setzen.
Ich bin mir allerdings nicht sicher, ob die Gehwege immer als eigene Kanten im Routing-Graphen abgebildet werden müssen. Womöglich ist das nicht notwendig, wenn es keine Angaben für Querungswiderstände gibt und sich routing-relevante Eigenschaften rechts und links nicht unterscheiden. Dann kann man einfach an der Hauptlinie routen wie bisher auch. Will man Querungen mit einem Malus versehen, wirds schon schwieriger.
Natürlich habe ich das gelesen, verstanden und auch die Beispiele angeschaut. Daher komme ich zu dem Fazit, dass dieser “Workaround” das Problem für Routinganwendungen auf nahezu Null reduzieren kann. Der systematische Fehler bleibt allerdings und der ist auf der Karte sehr gut zu erkennen.
Eine Motivation für einen Seitenwechsel hast du nicht genannt: Ein Wechsel der Eigenschaften der Geh- bzw. Radwege (z. B. einen Wechsel von ‘cycleway:right:smoothness=good’ zu ‘bad’). Hier müsstest du auch noch rechten und linken Geh-/Radweg verbinden.
Hätte er mit meinem Vorgehen beim Zusammenmappen auch.
Was mir aufgefallen ist: Im vorherigen Post habe ich beschreiben, wo der Router in seinen Graphen (virtuelle) Gehwege und Fahrbahnen miteinander verbinden muss:
an allen Knoten, wo Linien beginnen/enden/abzweigen.
an allen Knoten mit Querungsangaben (außer ‘crossing=no’)
an Stellen, wo Start und Ziel der aktuellen Routingaufgabe liegen.
Mit deinem Vorgehen nimmst die im Prinzip dem Router die Aufgabe c. ab, indem du das für alle potentiellen Ziele vorab manuell Verbindungen einträgst entsprechend b. .
Böse formuliert könnte man sagen, weil die Routingalgorithmen es nicht können, wird etwas in die Karte gezeichnet, was es in dieser Form draußen nicht gibt.
An anderer Stelle hat sowas zu heftigen Diskussionen geführt. Dort leiten Mapper aus Radwegnamen Abkürzungen ab, weil die Renderer das selber nicht gut können (zusammengesetzte Substantive). Das war für Einige ein No Go, auch du und u. a. SafetyIng gehörten dazu. Dein Vorgehen hier ist aber ganz ähnlich.
Ne, kann ich bei deinem Vorgehen eben nicht, weil du dort keine Verbindungen mappst.
Wie gesagt, ich will dein Vorgehen nicht schlecht reden. Wenn allo so mappen würden, wäre OSM viel besser!
Ich möchte nur nicht, dass diese Lösung als überlegen dargestellt wird. Mit dem Zusammenmappen kann man das ähnlich gut machen und das hat noch einen großen Vorteil: Fehlende Angaben führen nicht zu Umwegen im Routing - das Standardproblem bei seeerh vielen getrennt gemappten Gehwegen.
Zudem werden Dinge in den Karten so dargestellt, wie sie draußen auch sind (durchgängige Verbindung Radweg/Gehweg mit der Fahrbahn). Nachteil ist die v. a. die fehlende genaue Geometrie.
Ja, das sind vom Mapper festgelegte “Schienen”. Das Problem hast Du beim Tagging übrigens auch. Da musst Du diese Schienen via Tags abbilden, wenn man ein barrierefreies Routing möchte. Deine Schlussfolgerung aus dem fehlerhaften Routing von brouter (Profil Wandern beta!), dass es zu wenig Verbindungen seien, ist aber falsch. Das zeigt Dir z.B. OSRM.
Natürlich. GeorgFausB hat das gut zusammengefasst. Der systematische Fehler beim Getrennt-Mapping ist, dass man nicht überall die Straße erreichen kann, der systematische Fehler beim Tagging ist, dass man man überall die Straße erreichen kann. Für beides gibt es natürlich Anwendungsfälle, wo dieser Fehler nicht zutrifft, weil man die Straße tatsächlich nirgendwo erreichen oder überqueren kann (bauliche Trennung) oder der Gehweg nur durch einen abgesenkten oder ebenerdigen Bordstein von der Straße abgegrenzt ist und es keinerlei Hindernisse, wie Grünflächen, Bäume, Mülleimer, Fahrradbügel oder ähnliches gibt. Das eine ist quasi default crossing=no, das andere default crossing=yes. Beides kann richtig sein aber auch falsch sein und muss durch entsprechendes ergänzendes Mapping oder Tagging angepasst/korrigiert werden. Und das kann je nach Situation bei beiden Varianten in sehr viel Arbeit ausarten und unübersichtlich werden.
Ich sage nicht, dass getrenntes Gehwegmapping keine Fehler hat, sondern ich widerspreche Dir nur, dass das Gehweg-Mapping in erster Linie dafür da sei, die Geometrie besser abzubilden und das durch schlechtes Routing in Kauf nimmt. Es ist für mich oftmals das Mittel der Wahl um die Routing-Probleme eines unvollständiges sidewalk-Tagging zu lösen.
Ja, natürlich. Ich habe nichts anderes behauptet. Macht nur keiner so detailiert. Da wird getaggt, dass rechts und links ein Gehweg ist und die speziellen crossings werden getaggt. Ist genau so fehlerhaft, wie getrennt gemappte Gehwege, die nur an Ampeln und Zebrastreifen verbunden werden.
Nein, das mache ich nicht. Siehe die unterschiedlichen Routing-Ergebnisse der unterschiedlichen Routern. Aber es liegt natürlich am Mapper, wieviele Varianten er mappt und dem Router somit zur Verfügung stellt.
Es ging darum, dass ich angeblich keine Verbindungen mappen würde, wo es keinen abgesenkten Bordstein gibt und Du nicht in den Genuss der erhöhten Bordsteinkanten kommst, wenn Du unterwegs bist 
. Und ich habe entgegnet, dass ich solche Stelle sehr wohl auch eintrage und entsprechend kennzeichne. Somt kannst Du Deinen Router anweisen alle abgesenkten Bordsteine zu ignorieren und nur über erhöhte Bordsteine zu navigieren. Wenn Du aber sagst, dass Du nicht direkt vor Hausnummer 6 über die Straße (mit erhöhten Bordstein) geroutet werden möchtest, sondern 10m davor schon die Straße wechseln möchtest, dann gebe ich Dir recht: Diese Wahl hat der Router bei mir nicht, sofern es keinen (sinnvollen) Grund gibt, an dieser Stelle ein Verbindung einzutragen. Ich wüsste aber nicht, warum die Tagging-Variante da ein anderes Routing-Ergebnis liefern sollte. Auch dann würde der Router vermutlich die Stellen, die besonders gut zum überqueren sind bevorzugen und er wüsste immer noch nicht, dass Du 10 m vor Haus Nr. 6 über den erhöhten Bordstein fahren möchtest, außer Du teilst es dem Router über einen Wegpunkt mit. Und genau für diesen speziellen Fall hat die Tagging Variante tatsächlich einen Vorteil. Ob das jetzt als Argument gegen das Getrennt-Mapping ausreicht?
Ich bin mal (gedacht) ein sportlicher Fußgänger im Detailmapping - getrenntes mappen (ob wohl mir abgesenkte Bordsteine und Zebrastreifen lieber sind):
Als Autofahrer verlasse ich die vorgegebene Route und erhalte neu Anweisungen.
Als Fußgänger sehe ich den gegenüberliegenden Fußweg und wechsele über die Straße und erhalte neue Anweisungen.
Was natürlich “blöd” ist, wenn man ways einträgt, die keinen abgesenkten Bordstein haben, um nur das Routing zu den gegenüberliegenden Weg zu erreichen.
Hier sollte der gesunde Menschenverstand sagen: “Ja, ich kann dort schon mit dem Rollator über den Bordstein wechseln oder ich fahre lieber den vorgegebenen Umweg.”
Du musst nur den Startpunkt auf das Hinterstüberl der Pizzeria Flott legen, dann siehst du, dass OSRM um keinen Deut besser agiert. Wieso auch? Diese Router sind für den Autoverkehr gemacht.
Apropos barrierefrei: Es gibt Kurse, in denen Leute, die im Rollstuhl sitzen lernen, wie sie ohne fremde Hilfe über einen Bordstein kommen. Die Leute mit dem Stock mit weißer Kugel vorn dran schaffen das auch. Innerhalb der Gruppe, für die barrierefreies Routing Sinn macht, gibt es unterschiedliche Bedürfnisse.
Manche ziehen es eventuell vor, länger auf der Straße zu bleiben, während andere es vorziehen, schneller auf den Gehweg zu gelangen. Das ist eine Entscheidung, die der Router treffen sollte, nicht der Mapper.
Für einen Router, der sidewalk tags auswertet wäre es übrigens kein Problem, wenn es an der linken Straßenseite los geht und da ein sidewalk=right an der Straße hängt, dieser bis zur nächsten Garageneinfahrt zu folgen und erst dann “Nach rechts auf Bürgersteig wechseln” anzuweisen. Wenn der Sidewalk separat erfasst ist, dann bleibt keine andere Lösung.
Das ist nicht “blöd” sondern sehr wichtig und nützlich! Natürlich sollte der Bordstein mit barrier=kerb + kerb=* gemappt werden, damit Router die Wahl haben den sportlichen JürgenB freudestrahlend ( :D) diesen Bordstein hochfahren zu lassen und Oma Erna lieber 30 m weiter zur nächsten Grundstückseinfahrt oder Zebrastreifen zu lotsen.
Der Grund liegt an dem fehlerhaften sidewark-Mapping. Du vergleichst hier Äpfel mit Birnen! Diese Seite des separat erfassten Gehweg müsste man erst noch überarbeiten. Der westliche Teil ist auch noch nicht fertig, da noch keine Informationen wie kerb erfasst wurden. Das fehlt dort noch. Velleicht gibt es auch noch weitere sinnvolle Verbindungsstellen, die ich auf dem Luftbild leider nicht erkennen kann.
Ganz genau! Daher benötigen Router alle Daten, um auf die unterschiedlichen Bedürfnisse eingehen zu können.
https://www.openstreetmap.org/way/993871294
ist nicht vorhanden. Wir tragen ein, was wir sehen, wie es vor Ort ist.
Ich hätte nichts dagegen eine Linie mit virtual:highway=* ( 56 x https://taginfo.openstreetmap.org/search?q=virtual%3Ahighway ) einzutragen, dann hat ein Router die Möglichkeit es zu verwenden und der Renderer die Möglichkeit es auszublenden.
Ich würde sogar vorschlagen das highway:virtual=* ( 48 x https://taginfo.openstreetmap.org/search?q=highway%3Avirtual#keys ) in virtual:highway=* zu ändern, damit highway:= für tatsächliche Wege frei wird / bleibt und virtual:*= * auch z.B. für Fährlinien und (Wasserwander-)routen frei ist.
( Gab es schon mindestens einmal https://forum.openstreetmap.org/viewtopic.php?id=66678 - Leider bin ich kein Proposal-Fan …)
Betrifft auch virtuelle Wege auf Plätzen. Aber auch die Mittellinie von mehrspurigen Straßen ist letztendlich nur eine Art virtuelle Linie. Auf der Mittellinie fährt niemand. Das Flächen-Mapping von Straßen und Wegen könnte eine Lösung sein.
Aber auch ich würde ein Tag zum Kennzeichnen solcher Verbindungen begrüßen.
Hat er leider nicht. Wir haben ja schon erkannt, dass beim Taggen der Gehwege an der Straßenlinie kein systematischer Fehler vorhanden ist. Man kann dort durchaus darstellen, dass man abschnittsweise nicht queren kann. Das hatte ich hier mehrfach gezeigt.
Ein systematischer Fehler wäre es, wenn das nicht möglich wäre. Dass es kaum jemand macht hat nichts mit dem System zu tun sondern eher damit, dass es nicht ausreichend dokumentiert ist.
Beim Seperat-Mapping ist es anders, da kann man die kontinuierliche Querungsmöglichkeit nicht sauber abbilden. Man kann aber mit punktuellen (virtuellen) Verbindungen negative Auswirkungen auf das Routing minimieren.
OK, verstanden. Diese Generalisierung ist nicht korrekt. Bei vielem, was ich so sehe, denkt allerdings offensichtlich niemand ans Routing. Da vermute ich zwei Motivationen:
Geometrien möglichst genau zu erfassen (Informationen aus dem Luftbild möglichst exakt übernehmen)
Den Renderer dazu bringen, es darzustellen (Mapping für Renderer, ‘sidewalk=*’ wird ja kaum gerendert)
Der Unterschied ist aber, dass das übliche unvollständige Getrenntmapping zu den Umwegen führt. Das unvollständige Zusammenmapping erzeugt dagegen keine Umwege.
Für Mobilitätseingeschränkte sind beide Mappingarten wenig hilfreich, wenn sie unvollständig sind.
Bezieht sich dein “Nein” auf das “alle potentielle Ziele”?
Letzten Endes ist das “dem Router zur Verfügung stellen” genau diese Vorarbeit, die du ihm abnimmst, weil er es selber beim Getrennt-Mapping nicht kann. Beim Mappen des Gehsteigs an der Fahrbahn muss und kann er diese Arbeit selber leisten.
Stimmt, sorry, du mappst ja auch hohe Bordsteinkanten, wo du ein Ziel vermutest. Ich ziehe die Bemerkung zurück 
Ich weiß, für das Routing ist bei deiner Mappingweise diese Diskussion ziemlich akademisch. Praktisch macht es leider kaum jemand so gut wie du. Drum fände ich es halt besser, auf das Getrennt-Mapping bei durchgehender Querungsmöglichkeit zu verzichten. Alles andere kann man damit ja auch abbilden, außer die exakte Geometrie.
Die exakte Geometrie der Straße ist allerdings auch beim Getrennt-Mapping nicht komplett abgebildet. Für die Fahrbahn- und Gehweglinien wird ja nur eine durchgängige Breite angenommen, ist draußen insbesondere im Kreuzungsbereich ja auch nicht so.
edit: Wort zuviel
Leider nicht: Ist der separate Gehweg einmal zwischen Haustüre und Straße eingezogen, dann kann kein Fußrouter mehr den einfach überspringen. Es ist dann nicht mehr möglich, die Unterscheidung zu treffen, die ich angesprochen habe. Diese Tür ist dann zu. So wird aus einem mehr an Information ein weniger an Möglichkeiten.
Wenn man barrierefreies Routing mit dem Autorouter OSRM machen will, dann bleibt freilich keine andere Wahl. Man bedient dann die Bedürfnisse einer kleinen Gruppe innerhalb derer, die barrierefrei geroutet werden wollen, nämlich die, die mit etwas Autoähnlichem unterwegs sind, sogenannte mobility scooter zB. Und ignoriert, dass des einen Barriere dem andren keine.
Getrennt Mapping von straßenbegleitenden Gehwegen wird um so was nicht herumkommen. Es werden Millionen werden. Man kann die alle dann noch sehr detailliert ausstatten: surface, smoothness, etc. Die prefix-Methode finde ich tragbar. Mehrmals wurde schon der Wunsch nach highway=path+path=virtual vorgeschlagen, weil das nämlich gleich rendert. So ist das eben. Eine weitere Möglichkeit wäre highway=virtual+virtual=footway.
Eines davon könnte am “Alten Weg” gleich in die Tat umgesetzt werden OSRM wird nicht aktiv, wenn nicht eine kritische Masse überschritten wird.
Nicht drauf vergessen: ein highway=primary mit Sidewalks links und rechts wird auch nicht so einfach gequert. Es gibt auch lineare Einschränkungen.
Leider beobachte ich das auch so. Der “Alte Weg” ist kein Einzelfall. Warum Luftbildäquivalenz so hoch bewertet wird, das wundert mich dabei am meisten: Unterwegs zeigt mich das GPS meist in irgendeinem Gebäude oder gleich auf der anderen Straßenseite.
Danke JochenB, wenigstens einer hier der versteht
Echte Fußrouter ignorieren diese auch. Die machen Plaza-Routing und anderes Routing über Flächen. Steckt noch ein wenig in den Kinderschuhen, alt genug wäre es zwar, um herausgewachsen zu sein, aber was noch klein ist, kann noch groß werden. Mapperfleiß dagegen regnet es vom Himmel, aber die Erde ist ganz schön riesig.
kann man schon, aber man braucht eine Relation dafür.