Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
Am 28.04.2010 14:01, schrieb Martin Simon: 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%: Naja, wenn ich mir den aktuellen Thread Weitere Barrieretypen? anschaue dann habe ich Zweifel, dass das in einem Jahr auch noch so sein wird. ;-) Egal, solange Node-Infos von den meisten Routern eh nicht ausgewertet werden ist die Diskussion sinnfrei. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
Am 28. April 2010 11:20 schrieb Thomas Zimmermann m...@vdm-design.de: Da es so im Wiki steht habe ich bisher aller poller und ähnliche Barieren ohne access=no getagged. Werde ich wohl nochmal drüber gucken müssen. Wieso? barrier=bollard ist in allen mir bekannten Inkarnationen ein Hindernis für zweispurige Fahrzeuge, nicht aber für Fußgänger, Radfahrer, Rollstuhlpiloten, Reiter, Skater, Motorräder etc. Wenn der Durchgang nicht extrem breit oder extrem schmal (z.B. zu schmal für einen Rollstuhl) ist, sind hier also keine zusätzlichen Angaben nötig, nur weil Cloudmade es (noch) nicht auf die Kette kriegt. Die rendern ja auch seit Ewigkeiten in ihren Karten kein highway=path... ihr Problem. ;-) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
Am 28.04.2010 11:31, schrieb Martin Simon: Da es so im Wiki steht habe ich bisher aller poller und ähnliche Barieren ohne access=no getagged. Werde ich wohl nochmal drüber gucken müssen. Wieso? barrier=bollard ist in allen mir bekannten Inkarnationen ein Hindernis für zweispurige Fahrzeuge, nicht aber für Fußgänger, Radfahrer, Rollstuhlpiloten, Reiter, Skater, Motorräder etc. Der Wiki Artikel bezieht sich auf alle möglichen Formen von Barrieren, auch zB Sachen wie traffic_calming oder cattle_grit, wo man zwar abbremsen muss, aber keinesfalls umdrehen muss. ;-) Hier immer ein access=no zu implizieren ist IMHO keine gute Idee. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
Am 28. April 2010 11:40 schrieb Chris66 chris66...@gmx.de: Am 28.04.2010 11:31, schrieb Martin Simon: Wieso? barrier=bollard ist in allen mir bekannten Inkarnationen ein Hindernis für zweispurige Fahrzeuge, nicht aber für Fußgänger, Radfahrer, Rollstuhlpiloten, Reiter, Skater, Motorräder etc. Der Wiki Artikel bezieht sich auf alle möglichen Formen von Barrieren, auch zB Sachen wie traffic_calming oder cattle_grit, wo man zwar abbremsen muss, aber keinesfalls umdrehen muss. ;-) Hier immer ein access=no zu implizieren ist IMHO keine gute Idee. Nichts anderes sage ich ja. access=no sperrt *alles*, das ist nicht sonnvoll. Die Art des Hindernisses gibt an, wer durchkommt - sollte es wirklich aus der Art schlagen kann man immer noch einzelne Teilnehmer per *=no/yes verbieten oder durchlassen. Ich kenne aber z.B. keine Poller-Sperre, die Autos durchlässt, keine cycle_barrier, durch die keine Fußgänger passen und kein cattle_grid das zu Fuß nicht überwindbar ist... Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
Am 28.04.2010 12:02, schrieb Martin Simon: Der Wiki Artikel bezieht sich auf alle möglichen Formen von Barrieren, auch zB Sachen wie traffic_calming oder cattle_grit, wo man zwar abbremsen muss, aber keinesfalls umdrehen muss. ;-) Hier immer ein access=no zu implizieren ist IMHO keine gute Idee. Nichts anderes sage ich ja. access=no sperrt *alles*, das ist nicht sonnvoll. Die Art des Hindernisses gibt an, wer durchkommt - sollte es wirklich aus der Art schlagen kann man immer noch einzelne Teilnehmer per *=no/yes verbieten oder durchlassen. Du möchtest wenn ich Dich richtig verstehe pro Barrierentyp entsprechende Default-Implizierungen haben. Da bin ich dagegen, weil es erstens unterschiedliche Auffassungen geben kann welches Fahrzeug welche Barriere überwinden kann und zweitens werden laufend neue Barrieren erfunden, so dass ein Router hier ständig angepasst werden müsste. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
Am 28. April 2010 12:09 schrieb Chris66 chris66...@gmx.de: Am 28.04.2010 12:02, schrieb Martin Simon: Der Wiki Artikel bezieht sich auf alle möglichen Formen von Barrieren, auch zB Sachen wie traffic_calming oder cattle_grit, wo man zwar abbremsen muss, aber keinesfalls umdrehen muss. ;-) Hier immer ein access=no zu implizieren ist IMHO keine gute Idee. Nichts anderes sage ich ja. access=no sperrt *alles*, das ist nicht sonnvoll. Die Art des Hindernisses gibt an, wer durchkommt - sollte es wirklich aus der Art schlagen kann man immer noch einzelne Teilnehmer per *=no/yes verbieten oder durchlassen. Du möchtest wenn ich Dich richtig verstehe pro Barrierentyp entsprechende Default-Implizierungen haben. Das sehe ich genau so. Da bin ich dagegen, weil es erstens unterschiedliche Auffassungen geben kann welches Fahrzeug welche Barriere überwinden kann und zweitens werden laufend neue Barrieren erfunden, so dass ein Router hier ständig angepasst werden müsste. Warum unterscheiden wir sonst überhaupt verschiedene Barrieretypen? Das wir ein schönes Kartensymbol bekommen? Das ist wohl ein wenig zu kurz gegriffen. Nicht jeder hat den Nerv überall noch einmal access-Tags zu setzen, wo sich dies bereits aus dem Barrieretypen ergibt. Das ist extrem umständlich und wir wollen es doch dem Mapper so einfach wie möglich machen und nicht den Programmierern :-) Nur wenn etwas vom Normalfall abweicht ist ein zusätzliches access-Tag sinnvoll. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
Falk Zscheile schrieb: Nicht jeder hat den Nerv überall noch einmal access-Tags zu setzen, wo sich dies bereits aus dem Barrieretypen ergibt. Das ist extrem umständlich und wir wollen es doch dem Mapper so einfach wie möglich machen und nicht den Programmierern :-) Nur wenn etwas vom Normalfall abweicht ist ein zusätzliches access-Tag sinnvoll. Warum unterscheiden wir sonst überhaupt verschiedene Barrieretypen? Gibt es denn irgendwo eine Übersicht, zu welchen barrier-Typ welche default access-Tags gehören? Das wäre m.E. die Voraussetzung dazu, dass das sinnvoll implementiert werden kann. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
Am 28. April 2010 12:48 schrieb Stefan Dettenhofer (StefanDausR) o...@dentro.info: Falk Zscheile schrieb: Nicht jeder hat den Nerv überall noch einmal access-Tags zu setzen, wo sich dies bereits aus dem Barrieretypen ergibt. Das ist extrem umständlich und wir wollen es doch dem Mapper so einfach wie möglich machen und nicht den Programmierern :-) Nur wenn etwas vom Normalfall abweicht ist ein zusätzliches access-Tag sinnvoll. Warum unterscheiden wir sonst überhaupt verschiedene Barrieretypen? Gibt es denn irgendwo eine Übersicht, zu welchen barrier-Typ welche default access-Tags gehören? Das wäre m.E. die Voraussetzung dazu, dass das sinnvoll implementiert werden kann. Wünschenswert ist die Dokumentation natürlich, aber ich halte Personen, die den Router mit seinen Regeln versorgen, für Intellektuell durchaus fähig, das selbst heraus zu arbeiten :-) Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
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
Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
Am 28.04.2010 um 19:42 schrieb Christian Knorr: Am Mittwoch 28 April 2010 19:30:17 schrieb Rolf Bode-Meyer: Schön dass es CM endlich kann. Nach längerem habe ich gerade mal wieder Yournavigation überprüft und dort werden Turn-Restrictions mittlerweilen auch berücksichtigt (sogar an einer STelle wo CM patzt). Was ist Yournavigation, hast Du einen Link? http://lmgtfy.com/?q=yournavigationl=1 -Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
Stefan Dettenhofer (StefanDausR) schrieb: Gibt es denn irgendwo eine Übersicht, zu welchen barrier-Typ welche default access-Tags gehören? Das wäre m.E. die Voraussetzung dazu, dass das sinnvoll implementiert werden kann. Wie für jedes andere Tag auch finden sich Implikationen bei barrier=*-Tags in prinzipiell maschinell parsbarer Form in den Key/Value-Templates im OSM-Wiki. Beispiel: http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dbollard * access=no * foot=yes * bicycle=yes Für die meisten Werte fehlt diese Information bisher, so dass dort momentan das laut Key:barrier standardmäßig implizierte access=no angenommen werden muss. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
Am 28. April 2010 20:07 schrieb Tobias Knerr o...@tobias-knerr.de: Stefan Dettenhofer (StefanDausR) schrieb: Gibt es denn irgendwo eine Übersicht, zu welchen barrier-Typ welche default access-Tags gehören? Das wäre m.E. die Voraussetzung dazu, dass das sinnvoll implementiert werden kann. Wie für jedes andere Tag auch finden sich Implikationen bei barrier=*-Tags in prinzipiell maschinell parsbarer Form in den Key/Value-Templates im OSM-Wiki. Beispiel: http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dbollard * access=no * foot=yes * bicycle=yes Für die meisten Werte fehlt diese Information bisher, so dass dort momentan das laut Key:barrier standardmäßig implizierte access=no angenommen werden muss. Bitte erkläre es für mich nochmal ausführlicher. Ich verstehe den Sinn immer noch nicht. Wo genau ist der Unterschied ob der Router auf ein barrier=* stößt und dann in einer Datei nachschaut welche access-Tags der Programmierer für dieses barrier-Tag vorgesehen hat oder ob wir die access-Tags zusätzlich an alle barrier-Tags setzen? Das ein Arbeitsschritt eingespart wird will mir als Grund nicht als ausreichend für dieses umständliche vorgehen erscheinen. Zumal wird zum Routen doch ohnehin eine extra Datenbank angelegt, da lässt sich so etwas auch sehr gut automatisiert einbauen, wenn die OSM-Daten für die Routingdatenbank aufbereitet werden. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
Falk Zscheile schrieb: Am 28. April 2010 20:07 schrieb Tobias Knerr o...@tobias-knerr.de: Wie für jedes andere Tag auch finden sich Implikationen bei barrier=*-Tags in prinzipiell maschinell parsbarer Form in den Key/Value-Templates im OSM-Wiki. [...] Für die meisten Werte fehlt diese Information bisher, so dass dort momentan das laut Key:barrier standardmäßig implizierte access=no angenommen werden muss. Bitte erkläre es für mich nochmal ausführlicher. Da bei fast allen Pollern die gleichen Zugangsberechtigungen gelten dürften, kann man es als unnötige Arbeit ansehen, diese Information an jeden einzelnen Node mit barrier=bollard zusätzlich zu taggen. Stattdessen ist im Wiki eben festgelegt*, dass Poller den Verkehr grundsätzlich blockieren, mit Ausnahme von Fußgängern und Radfahrern. Dank dieser Festlegung braucht man jetzt nur noch solche Zugangsrechte taggen, die vom Normalfall abweichen. Wenn das für andere Barrierentypen auch gewünscht ist, kann man natürlich auch dort entsprechende Festlegungen treffen. Sie sollten aber möglichst offensichtlich sein (d.h. der intuitiven Annahme möglichst vieler Mapper entsprechen), damit es nicht zu viele Missverständnisse gibt. Wo genau ist der Unterschied ob der Router auf ein barrier=* stößt und dann in einer Datei nachschaut welche access-Tags der Programmierer für dieses barrier-Tag vorgesehen hat oder ob wir die access-Tags zusätzlich an alle barrier-Tags setzen? Im ersten Fall hat der Programmierer einmalig mehr Arbeit, im zweiten die Mapper bei jedem einzelnen neuen Poller. Zumindest aus dieser Perspektive wäre der erste Weg vorzuziehen. Tobias Knerr * unter Berücksichtigung der üblichen Vorbehalte gegenüber Festlegungen im Wiki natürlich... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
