Am 28. April 2010 12:09 schrieb Chris66 <chris66...@gmx.de>: > Am 28.04.2010 12:02, schrieb Martin Simon:
> Du möchtest wenn ich Dich richtig verstehe pro Barrierentyp > entsprechende Default-Implizierungen haben. Die haben wir im Prinzip schon: es ist die Realität draußen vor der Tür. Ungefähr wie die implikation, daß man an einem amenity=fuel Treibstoff kaufen kann. ;-) > Da bin ich dagegen, weil es erstens unterschiedliche > Auffassungen geben kann welches Fahrzeug welche Barriere > überwinden kann Und wo ist der Unterschied zu einem subjektiv gesetzten bicycle=no an einer Umlaufsperre (barrier=cycle_barrier)? Wie interpretiere ich das? War der Mapper Rennradler und genervt von der Radverkehrsberuhigungsmaßnahme? Hatte er ein Liegerad? Einen Anhänger? Steht dort ein Verbotsschild? etc... ($fahrzeug=yes/no/bla drückt *eigentlich* eine rechtliche Zugangsbeschränkung aus.) Da ist es deutlich sinnvoller, wie bei OSM üblich, an der Ausgabeseite zu bewerten, nämlich beim Aufbau des Routinggraphen. Wenn du wirklich detailiert mappen willst, solltest du eher die Öffnungsmaße z.B. einer Pollerreihe mit maxwidth= eintragen. Dann hast du das relevante physische Maß für die physische Passierbarkeit des Hindernisses und kannst deinen Router so einstellen, daß er deinen Messerschmitt Kabinenroller durch entsprechend großzügige Pollerreihen routet. ;-) > und zweitens werden laufend neue > Barrieren "erfunden", so dass ein Router hier ständig > angepasst werden müsste. Das ist Blödsinn. Die Liste hat sich seit langer Zeit nicht wesentlich verändert und der Anteil an barrier-tags für nodes, die nicht bollard, cycle_barrier, block, gate , lift_gate oder entrance sind, liegt in Deutschland grob überschlagen irgendwo bei 1%: http://tagwatch.stoecker.eu/Germany/De/tags.html Gruß, Martin _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
