Genau so ist es Sven! Eigentlich gibt es zu dem oben beschriebenen Ansatz meiner Meinung nach keine Alternative wenn wir noch mehr aus der Karte machen wollen. Es bleibt sich auf ein Schema zu einigen.
In diesem Sinne ist das dann auch kein Fehler. Ein Fehler wĂ€re es, wenn sich zwei StraĂenlinien schneiden, ohne einen gemeinsamen StĂŒtzpunkt zu haben. Eine StraĂenlinie, die einene FlĂ€che als area:highway=* schneidet und keinen gemeinsamen StĂŒtzpunkt haben, ist fĂŒr mich kein Fehler. Ebenso, bei GewĂ€ssern: ein Waterway=river und schneidet die abgegrenzte FlĂ€che Waterway=riverbank und der Schnittpunkt hat keinen gemeinsamen StĂŒtzpunkt. Ja, JOSM meckert⊠Sehe ich aber nicht als Fehler. Wenn man an diesen stellen StĂŒtzpunkte verwendet, mĂŒĂte man, um RoutingfĂ€hig zu bleiben, diesen StĂŒtzpunkten Restriktionen auferlegen, also âRoute auf dem Linienobjekt weiterâ oder aber Linien, die eine FlĂ€che umgrenzen werden generell beim Routing ignoriert. bei ersterem wĂŒrde das einen erhöhten Tagging-Aufwand bedeuten, den ich aber fĂŒr unsinnig halte, bei letzerem weiĂ ich nicht, ob diese fixe Idee ĂŒberhaupt funktioniert.
Nein. Es ist eine klar spezifizierte, begrenzte Sache. Wr mĂŒssen nur dafĂŒr Sorge tragen, dass es an richtegen Stellen ankommt, damit auch andere QualitĂ€tstools diese Feature unterstĂŒtzen.
Oder aber, man wĂŒrde einfach wie bisher auf FlĂ€chen mit area:highway (oder waterway=riverbank, etc.) nicht routen. Wo ist genau das Problem? Nur weil zwei Linien einen gemeinsamen Punkt haben, heiĂt das ja noch lange nicht, dass ich von der einen auf die andere routen darf. Oder lotsen wir demnĂ€chst Autofahrer ĂŒber FuĂwege, nur weil die gemeinsame Punkte haben.
Das war auch noch nie hier die Idee, darĂŒber zu routen. Im Gegenteil, das dient der klaren Unterscheidung zu highway=* in Verbindung mit area=yes, was einige Programme dazu verleitet ĂŒber die Kanten des area zu routen. Siehe thread-Beginn.
Gut. Dann bin ich mit dem Thema im reinen.
area:highway ist gut.
highway=* mit area=yes ist böse.
Ich habe mich bisher darum gedrĂŒckt, eine der beiden Varianten selbst anzuwenden, bin ja noch nicht so lange bei und taste mich an einiges Schritt fĂŒr Schritt ranâŠ
So krass kann man das nicht sehen.
Es gibt StraĂenflĂ€chen (vor allem bei highway=service), auf denen ĂŒberall gefahren werden darf und kann.
Nicht jede FuĂgĂ€ngerflĂ€che ist ein highway=pedestrian z.B. Schulhöfe. Die sind besser mit highway=footway + area=yes getaggt.
so wie ich das Proposal http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway verstehe, kann es doch genauso auf die von dir angesprochenen FĂ€lle angewendet werden, oder hab ich da einen Knoten im Kopf? Es geht doch darum, StraĂenflĂ€chen sauber zu definieren, um diese Routing-Geschichte zu verbessern.
Noch einmal: highway=* in der Kombination mit area=yes als zulĂ€ssige Kombination mit der Erlaubnis zum ungerichteten Routen ĂŒber diese FlĂ€che kann verwendet werden, wenn diese FlĂ€che nicht von einem oder mehreren highway=* als gerichteter graph geschnitten wird.
Leider nicht ganz richtig:
Die Kombination âhighway=pedestrianâ , âarea=yesâ mit darĂŒberfĂŒhrendem âhighway=serviceâ findet man oft fĂŒr innerstĂ€dtische PlĂ€tze mit markiertem Zufahrtswegen fĂŒr Kfz.
Auch die umgekehrte Kombination (service-FlĂ€che mit FuĂweg) könnte fĂŒr Hafen- oder SpeditionsflĂ€chen mit markierten FuĂwegen sinnvoll sein.
FĂŒr den ersten Fall gebe ich dir recht ( http://wiki.openstreetmap.org/wiki/DE:Key:area unter âStraĂenflĂ€chenâ). Hatte ich vergessen, hier noch mal zu erwĂ€hnen
Der zweite Fall macht IMHO nur Sinn, wenn diese FuĂwege durch Markierungen auf der highway=service-FlĂ€che vorgeschrieben sind. Innerhalb der area-highways kann beliebig ĂŒber die FlĂ€che geroutet werden (sieh Wiki-link), und normalerweise dĂŒrfen sich auf diesen sich auch FuĂgĂ€nger frei bewegen.