Problem beim "lanes"-taggen

crise · 2013-08-23 01:14:22

Hallo zusammen,

ich habe ein Problem beim taggen mit "lanes".

Folgender Straßenaufbau:

-Straße mit insgs. drei Spuren.
-in OSM-Richtung zwei Spuren, Gegenrichtung eine
-in OSM-Richtung linke Spur zum linksabbiegen und geradeaus-fahren, rechte Spur nur geradeaus

Folgendermaßen getaggt:
lanes:=3
lanes:forward=2
lanes:backward=1
turn:lanes:forward=left;through|through

Der letzte Eintrag erscheint dann im Potlatch mit einem roten Ausrufezeichen und der sinngemäßen Aussage das ich zwei Einträge für einen Wert gemacht habe, bitte prüfen.

Was habe ich falsch gemacht, ich erkenne keinen Fehler?!?

Gruß

crise

rayquaza · 2013-08-23 03:35:25

Für mich sieht das richtig aus, aber Lanes-Tagging ist für mich noch relativ Neuland, also sollte das besser noch jemand bestätigen.

Ich vermute, dass Potlatch einfach bei jedem Wert, der ';' enthält meckert.

hurdygurdyman · 2013-08-23 03:43:33

rayquaza wrote:

Für mich sieht das richtig aus, aber Lanes-Tagging ist für mich noch relativ Neuland, also sollte das besser noch jemand bestätigen.
Ich vermute, dass Potlatch einfach bei jedem Wert, der ';' enthält meckert.

Tagging ist so ok.
Es stimmt: Potlatch meckert bei jedem Wert der ein Semikolon enthält.

Nadjita · 2013-08-23 12:27:08

Meiner Meiung nach kannst Du sogar die ersten 3 Tags weglassen, da sich die Information aus dem letzten Eintrag ableiten lässt. Ansonsten ist der Eintrag definitiv korrekt, so habe ich es diverse Male in JOSM auch gemacht.

crise · 2013-08-23 18:50:23

@Nadjita
Das hatte ich mir auch schon irgendwie so gedacht, da ich ja alles mehrfach definiert habe und es, wie du schon sagst aus dem letzten Tag ersichtlich ist. Ich habe leider bisher kein Bsp. irgendwo in der Karte gefunden, dass so aufgebaut ist (turn:lanes-tags sind nicht so stark vertreten), daher bin ich auf Nummer sicher gegangen und habe alles getaggt. Würde mir die überflüssige Arbeit aber natürlich gerne sparen.

Gibt es die Möglchkeit das lane-tagging anhand simulierter Route und Fahrstreifen-Anzeige irgendwie (in openstreetmap.de) zu prüfen?

chris66 · 2013-08-23 21:07:42

Es gibt ein JOSM Plugin dafür und das Naviprogramm Mapfactor Navigator wertet es (zum Teil) aus.

SunCobalt · 2013-08-23 21:52:45

chris66 wrote:

Es gibt ein JOSM Plugin dafür

Und ich dachte, das Plugin taggt nach einem anderen, alten Schema, das sich nicht durchgesetzt hat

chris66 · 2013-08-23 22:27:22

Hi,
ich meinte den Mappaint-Style für die Fahrspuren.

Chris

Last edited by chris66 (2013-08-23 22:27:49)

hurdygurdyman · 2013-08-24 05:48:43

crise wrote:

@Nadjita
Das hatte ich mir auch schon irgendwie so gedacht, da ich ja alles mehrfach definiert habe und es, wie du schon sagst aus dem letzten Tag ersichtlich ist. Ich habe leider bisher kein Bsp. irgendwo in der Karte gefunden, dass so aufgebaut ist (turn:lanes-tags sind nicht so stark vertreten), daher bin ich auf Nummer sicher gegangen und habe alles getaggt. Würde mir die überflüssige Arbeit aber natürlich gerne sparen.
...

Bitte entferne von den oberen drei tags höchstens "lanes:backward=1". Alle anderen tags sind auch aus Gründen der Abwärtskompatibilität notwendig, um die Informationen sinnvoll auswerten zu können.

g0ldfish · 2013-08-26 08:53:23

hurdygurdyman wrote:

Es stimmt: Potlatch meckert bei jedem Wert der ein Semikolon enthält.

Potlatch erzeugt einerseits Wege, die Semikolonnen enthalten (http://forum.openstreetmap.org/viewtopi … 67#p356467), und meckert andererseits darüber? Ist ja schon ein bisschen inkonsequent...

hurdygurdyman · 2013-08-26 17:57:47

g0ldfish wrote:

hurdygurdyman wrote:
Es stimmt: Potlatch meckert bei jedem Wert der ein Semikolon enthält.
Potlatch erzeugt einerseits Wege, die Semikolonnen enthalten (http://forum.openstreetmap.org/viewtopi … 67#p356467), und meckert andererseits darüber? Ist ja schon ein bisschen inkonsequent...

Na ja...
Potlatch folgt nur dem Willen des Mappers. Wenn dieser fordert, Wege, deren tags sich teilweise unterscheiden, zu mergen, macht er das brav, setzt aber gleichzeitig das Warndreieck in das entsprechende value. Wenn das der Mapper ignoriert und nicht verbessert...

Last edited by hurdygurdyman (2013-08-26 18:44:45)

hurdygurdyman · 2013-08-27 05:57:52

Ich häng mich hier mal ein.
Ich bin in meiner Gegend vermehrt dabei, Spuren zu mappen. Nun geht es um diesen Bereich:
http://www.geoportal.lv-bw.de/mapbender … |5355898.4
Ich habe das wegen der mittleren funktionslosen Spur bisher mit
lanes=3
lanes:forward=1
lanes:backward=1
getaggt. Wie würdet ihr mit dieser mittleren funktionslosen Spur, die durch eine einfache durchgezogene Linie von den beiden anderen getrennt ist, umgehen?

AJoNee · 2013-08-27 08:41:31

hurdygurdyman wrote:

Wie würdet ihr mit dieser mittleren funktionslosen Spur, die durch eine einfache durchgezogene Linie von den beiden anderen getrennt ist, umgehen?

lanes=3
lanes:forward=1
access:lanes:backward=no|yes

Jimmy_K · 2013-08-27 14:33:36

Warum ist die funktionslose Spur eine "backward"?
Bei erstem Vorschlag ist es schwer zu erkennen, wo die nichts genutzte Spur liegt...

EvanE · 2013-08-27 15:24:08

AJoNee wrote:

hurdygurdyman wrote:
Wie würdet ihr mit dieser mittleren funktionslosen Spur, die durch eine einfache durchgezogene Linie von den beiden anderen getrennt ist, umgehen?
lanes=3
lanes:forward=1
access:lanes:backward=no|yes

Übersichtlicher fände ich: lanes=3 + access:lanes=yes|no|yes

Dann stellt sich die Frage von Jimmy_K, zu welcher Richtung die mittlere Spur eigentlich gezählt werden soll, nicht. Um das eindeutig zu machen, kann man lanes:forward/backward jeweils auf 1 setzen.

Da der gesamte Bereich der Anschlussstelle dreispurig aufgebaut ist, mit der mittleren Spur entweder als Linksabbieger oder als gesperrte Spur, kann man sich überlegen, das als zwei getrennte Fahrbahnen zu erfassen. Das würde jedoch die Kreuzungen etwas umfangreicher gestalten.

PS: Ein Link zur OSM-Karte wäre hilfreich. (-> Share-Button)

Edbert (EvanE)

hurdygurdyman · 2013-08-28 04:44:36

EvanE wrote:

...
Übersichtlicher fände ich: lanes=3 + access:lanes=yes|no|yes
Dann stellt sich die Frage von Jimmy_K, zu welcher Richtung die mittlere Spur eigentlich gezählt werden soll, nicht. Um das eindeutig zu machen, kann man lanes:forward/backward jeweils auf 1 setzen.

Das scheint mir die plausibelste Lösung zu sein. Danke, EvanE

EvanE wrote:

Da der gesamte Bereich der Anschlussstelle dreispurig aufgebaut ist, mit der mittleren Spur entweder als Linksabbieger oder als gesperrte Spur, kann man sich überlegen, das als zwei getrennte Fahrbahnen zu erfassen. Das würde jedoch die Kreuzungen etwas umfangreicher gestalten.

Finde ich nicht so gut, denn das wäre für mich dann ein "Missbrauch" von highway für lanes, den es nicht geben soll/darf, weil diese Straße (auch weiter nordöstlich) nicht dem entspricht, was wir mit getrennten Fahrbahnen als getrennte higways taggen.

EvanE wrote:

PS: Ein Link zur OSM-Karte wäre hilfreich. (-> Share-Button)

Hier ist er:
http://www.openstreetmap.org/browse/way/133727670
Ich wählte den link http://www.geoportal.lv-bw.de/mapbender … |5355898.4 , weil dort eine bessere Auflösung als bei bing vorliegt.

geri-oc · 2013-08-28 10:30:41

An den anderen Abschnitten ist durch Pfeil und Linienangaben diese mittler Spurnutzung angezeigt. Hier ist eine geschlossenen Linie zu allen anderen Fahrspuren - einen normale Benutzung also ausgeschlossen (Verkehrsfläche - eventuell mit Sonderrechten befahrbar).

crise · 2013-09-03 06:55:30

Die "dritte Spur" ist in diesem Bereich meiner Meinung überhaupt nicht zu taggen. Sie stellt lediglich eine Fahrspurtrennung bzw. einen Platzhalter dar. Sozusagen eine Verkehrsinsel, bestehend aus durchgezogenen Linien. Ich sehe dort nur zwei Fahrspuren!
Laut StVo darf dieser Bereich von keinem Fahrzeug befahren werden, weshalb auch ein taggen in meinen Augen sinnlos erscheint. Wozu taggen, wenn ich es nicht benutzen darf.
Der Bereich davor und dahinter sieht ja wieder ganz anders aus. Dort ist im mittleren Bereich ein Abbiegestreifen vorhanden.

Korrigiert mich bitte, wenn ich da falsch liege ich habe mir nur Luftbilder angeschaut und besitze keine Ortskenntnisse!

Gruß

crise

hurdygurdyman · 2013-09-09 09:41:40

Hier... http://forum.openstreetmap.org/viewtopi … 44#p359544 in diesem thread http://forum.openstreetmap.org/viewtopic.php?id=22422
Entwickelte sich eine Diskussion zu lanes vollkommen OT, wurde aber nicht abgeschlossen. Deshalb habe ich mal ein paar Zitate von dort gesammelt, um die noch nicht geklärte Angelegenheit hier weiter zu bringen.

hurdygurdyman wrote:

EvanE wrote:
...
Das mag wohl der Grund sein. Für mein Empfinden ist der Default, wenn etwas nicht erfasst ist, eher "unkown, probably xyz". Erst wenn etwas explizit erfasst ist, kann man sich sicher sein, dass es auch so gemeint ist. Aber das betrifft natürlich ebenso viele anderen Eigenschaften.
Solche Straßen mit im Prinzip 1.5 Spuren gibt es sowohl bei Residential (in Bonn 1/3 bis die Hälfte) als auch bei Tertiary (auf dem Lande) recht häufig. Da weiß ich auch nicht, was ich da eintragen soll.
Übrigens habe ich auf Taginfo zum Stichwort lanes neben 1.5 (2000+) oder n;m auch lanes=0 und lanes=-1 (>20k) gefunden. Letzteres ist wohl eine Verwechselung (autocompletion?) mit layer=-1.
In deiner Karte QA for Roads wäre es nicht schlecht, wenn solche seltsamen Werte (alles außer niedrigen ganzzahligen Werten) gesondert angezeigt würden (z.B. schwarz gestrichelt). Ansonsten stolpert man nur durch Zufall über diese Ausreißer.
Edbert (EvanE)
Diese lanes-Debatte ist zwar hier OT...
Für mich sind lanes nur zu erfassen, wenn die Straße entsprechende Markierungen hat, denn wir erfassen ja die Wirklichkeit. Also: keine Markierungen, keine lanes. Das ist z.B. bei einer Menge residential und tertiary so in der großen realen Welt da draußen.
Somit dürfte es lanes=1.5 und lanes=0 nicht geben. Statt lanes=1.5 gehört m.E. die Straßenbreite erfasst. Wenn ich z.B. an meinen Irlandtripp denke, wären da 'ne Menge Straßen, die mit weniger als drei Meter Breite durch das Land ziehen. Da ist keine Markierung und somit gehört da auch kein lanes-tag dran, um etwa hilfsweise annähernd die Breite zu erfassen.

EvanE wrote:

…
Nun ja, auch ein Bordstein wäre für mich eine Markierung. Bei Straßen zwischen Orten hat man in DE meist zumindest eine Markierung für die Fahrbahnränder. In anderen Ländern (wie dem erwähnten Irland) mag das anders gehandhabt werden.
Die Angabe zur Breite einer Straße ist im allgemeinen problematisch, da man nicht weiß, ob damit die Fahrbahn-Breite oder die Breite einschließlich Fahrradspur und Gehwegen gemeint ist. Ein sidewalk/footway:both=no, um die Situation klar zu machen, wird an solchen Überort-Wegen in der Regel nicht erfasst sein.
Edbert (EvanE)

marek kleciak wrote:

Das stimmt. Die Angabe der Breite ist schwierig.
Ich dachte, ich kann solche Standard Straßen mit oneway=no abdecken, denn dadurch ist ja klar, dass man in 2 Richtungen fahren darf
Wenn ich die Lanes nicht angebe und nur mit oneway=no arbeite, dann erwische ich aber solche Fälle nicht:
http://www.openstreetmap.org/#map=19/49.48246/11.01473
Die Schneegasse ist in der Höhe der Kirche eine Spur breit und trotzdem in beide Richtungen befahrbar, Die Fahrer die von der Poppenreuther Straße kommen, haben Vorfahrt.
Ich würde dazu tendieren, die Spurenanzahl anzugeben und stattdessen eine Info geben, dass es keine Mittellinie gibt. Beziehungsweise nichts angeben und nur dort, wo eine ist, diese Info auch eintragen.
Ist es nicht so, dass bei Tempo 30 generell keine Mittellinien gezeichnet weden?
Grüße,
Marek

Wiki...http://wiki.openstreetmap.org/wiki/Key:lanes
verweist auf http://en.wikipedia.org/wiki/Lane
und dort steht: „A lane is a part of the carriageway within a road marked out for use by a single line of vehicles“.
Die deutsche Wikipedia-Version sieht anders aus:
http://de.wikipedia.org/wiki/Stra%C3%9F … hrstreifen

Wie breit ist aber nun ein Fahrstreifen? Laut unserer Wiki müssen Fahrzeuge, die breiter als ein Motorrad sind, darauf fahren können. Hier http://de.wikipedia.org/wiki/Stra%C3%9F … hrstreifen wird die Breite zwischen 2,75 m und 3,75 m angegeben.
Genaues findet man hier http://de.wikipedia.org/wiki/Richtlinie … uerschnitt

Berücksichtigt werden muss dann noch der Gegenverkehrszuschlag http://www.sicherestrassen.de/VKO/Frame … hrbahn.htm
und zusätzlich ggf. Sicherheitsräume zwischen 0,25 m und 1,00 m.

Wer jetzt noch aus der Angabe lanes=1.5 oder so zuverlässige Rückschlüsse auf die Straßenbreite ohne Gehwege ziehen kann und dies einem Renderer beibringt, hat meine volle Bewunderung. Internationale Varianten zu Fahrstreifenbreiten sind da noch gar nicht berücksichtigt.

Aus meiner Sicht muss man die (mal wieder) schwammige Wiki bereinigen und klarer fassen. Allein schon die Definition „breiter als ein Motorrad“ für einen Fahrstreifen ist zu vage. Selbst eine Definition „Autobreite“ trifft es nicht, da etwa ein alter FIAT 500 mit 132 cm und ein Hummer mit über 2 Meter Breite doch recht unterschiedlich sind.

Ich plädiere für eine klare Definition von width im Zusammenhang mit highway in der Form, dass die Straßenbreite von Bordstein zu Bordstein angegeben wird, wenn diese vorhanden sind. Ansonsten gilt die Breite der befahrbaren Befestigung.

Weiterhin plädiere ich dafür, dass die lanes-Anzahl nur dort erfasst wird, wo sie durch Markierungen erkennbar ist. Als default sollte „lanes=2“ für jeden highway gelten, wenn dieser nicht mit „oneway=yes“ erfasst ist. Bei „oneway=yes“ gilt „lanes=1“ als default.

@ marek:
Ich halte nichts von tags wie „oneway=no“ oder Angaben, dass keine Mittellinie vorhanden ist. Wir erfassen, was in der Realität existiert. „oneway=no“ ist für mich unabhängig von der Straßenbreite default. Wir hängen ja auch nicht an jede Autobahn „bicycle=no“. Und sobald Mittellinien oder Fahrstreifen-Markierungen existieren, erfasse ich ab sofort möglichst umfassend lanes=*. Wenn wir genaue Daten über die Breite der einzelnen Spuren haben, kann man diese ja noch mit „width:lanes=3.5|4|…" erfassen.

Außerdem werde ich mal in meiner Gegend die width-Erfassung vervollständigen. Daraus können Router dann aufgrund individueller Parameter berechnen, ob Gegenverkehr zu Problemen führt und einen Malus kalkulieren. Mit „priority=forward/backward“ besteht eine weitere gute Möglichkeit zur Verfeinerung einer Routen-Kalkulation.

marek kleciak · 2013-09-09 10:36:58

Ich plädiere für eine klare Definition von width im Zusammenhang mit highway in der Form, dass die Straßenbreite von Bordstein zu Bordstein angegeben wird, wenn diese vorhanden sind. Ansonsten gilt die Breite der befahrbaren Befestigung.

+1

Ich halte nichts von tags wie „oneway=no“

Ich gebe zu- als ich das erste mal gelesen habe dass wir einensolchen Tag haben, dachte ich: was für ein Unsinn. Völlig überflüssig.
Jetzt aber hat es für mich den gleichen Sinn wie bei der Kreuzung von der wir WISSEN, dass es dort keine Abbiegeverbote gibt (sehe unsere frühere Diskussion darüber).
Was ich meine ist: Seitdem wir gute Bing Bilder haben, gibt es enorm viele Leute die Schreibtischmapping betreiben.
Auf der einen Seite eine schöne Sache, auf der anderen gibt es Leute, die einfach die Karte kaputt verbessern. Unser Kollege Nop weiß es sehr gut.
Ich sehe nun oneway=no als eine Art Qualitätssicherung mit der ich angebe: Ja, ich habe es gesehen, es ist keine Einbahnstraße. Dadurch unterscheide ich zwischen dem tatsächlich vor-Ort kontrollierten von dem, was aus dem Luftbild abgemalt ist. Ich habe selbst viel in Indien, Afrika, Türkei, Nepal abgemalt ohne zu wissen, wei es vor-Ort in Wirklichkeit aussieht.
Grüße,
Marek

hurdygurdyman · 2013-09-09 10:45:57

marek kleciak wrote:

Ich plädiere für eine klare Definition von width im Zusammenhang mit highway in der Form, dass die Straßenbreite von Bordstein zu Bordstein angegeben wird, wenn diese vorhanden sind. Ansonsten gilt die Breite der befahrbaren Befestigung.
+1
Ich halte nichts von tags wie „oneway=no“
Ich gebe zu- als ich das erste mal gelesen habe dass wir einen solchen Tag haben, dachte ich: was für ein Unsinn. Völlig überflüssig.
Jetzt aber hat es für mich den gleichen Sinn wie bei der Kreuzung von der wir WISSEN, dass es dort keine Abbiegeverbote gibt (sehe unsere frühere Diskussion darüber).
Was ich meine ist: Seitdem wir gute Bing Bilder haben, gibt es enorm viele Leute die Schreibtischmapping betreiben.
Auf der einen Seite eine schöne Sache, auf der anderen gibt es Leute, die einfach die Karte kaputt verbessern. Unser Kollege Nop weiß es sehr gut.
Ich sehe nun oneway=no als eine Art Qualitätssicherung mit der ich angebe: Ja, ich habe es gesehen, es ist keine Einbahnstraße. Dadurch unterscheide ich zwischen dem tatsächlich vor-Ort kontrollierten von dem, was aus dem Luftbild abgemalt ist. Ich habe selbst viel in Indien, Afrika, Türkei, Nepal abgemalt ohne zu wissen, wei es vor-Ort in Wirklichkeit aussieht.
Grüße,
Marek

Leider ändert deine Erklärung nichts an meiner Einstellung. Ich kann mir noch viele Sachen vorstellen, wo ein "irgendwas=no" dokumentieren könnte "hab's gesehen; ist nicht da" (abgerissene Häuseretwa). Warum sollten wir für Couchmapper erfassen, wenn wir ja noch nicht einmal für Renderer mappen. Wir müllen uns den nur die Datenbank mit solchen Tags zu. Eher gehört manchen Leuten der Respekt vor den erfassten Daten vermittelt, als dass wir "tagging für Dummies" betreiben.

Last edited by hurdygurdyman (2013-09-09 12:05:55)

marek kleciak · 2013-09-09 11:02:09

Abgerissene Häuser mappen viele Leute mittlerweile, weil es immer wieder Leute gibt, die sie nachzeichnen. Schlichtweg ein Umriss mit der Note "abgerissen". Und es hilft.
Ich verstehe Dich ja. Nur - wie kommen wir an die vernünftige Validierung der Daten?
Respekt vermitteln oder Etwas beibringen bei ständig wachsender Anzahl der User ist ilusorisch. Wir haben in diversen Gebieten einen erfahrenen User der versucht "nur" die Karte sauber zu halten.
Es ist ja im Übrigen nicht für die Dummies, sondern für die Datenvalidierung.
Grüße,
Marek

hurdygurdyman · 2013-09-09 12:05:31

Also gut Soll doch "oneway=no" oder "building=no" usw erfassen, wer will...
... aber was machen wir jetzt bei den lanes, wenn auf der Straße keine Markierungen angebracht sind? lassen wir sowas wie "lanes=1.5" in Zukunft besser weg, erfassen wir dafür die Straßenbreite und sei lanes=2 (bzw. lanes=1 bei oneway=yes) nun default?

marek kleciak · 2013-09-09 12:15:12

Hallo Michael,
bitte versthe mich nicht falsch: Durch die Mapper Brille gesehen ärgert mich sowas überflüssiges wie oneway=no.
Lieber hätte ich einen Tag der in den Editoren ein Muss wäre:
source= <Bing oder ich habe es gesehen, etc etc.) vielleicht wäre das ein Weg für die Zukunft?

Ich kenne sowas wie Lanes =1,5 von keinem Datenlieferanten. Wenn dann benutzt man die Straßenbreite(n) für bestimmte Straßenabschnitte.
Viele Grüße,
Marek

hurdygurdyman · 2013-09-09 12:27:12

marek kleciak wrote:

Ich kenne sowas wie Lanes =1,5 von keinem Datenlieferanten. Wenn dann benutzt man die Straßenbreite(n) für bestimmte Straßenabschnitte.
Marek

Habe mal hier gecheckt: http://taginfo.openstreetmap.org/keys/?key=lanes#values
Da wundert man sich schon, was da alles als value erscheint. Am meisten wundern mich die 23.214mal "lanes=-1"

Announcement

#1 2013-08-23 01:14:22

Problem beim "lanes"-taggen

#2 2013-08-23 03:35:25

Re: Problem beim "lanes"-taggen

#3 2013-08-23 03:43:33

Re: Problem beim "lanes"-taggen

#4 2013-08-23 12:27:08

Re: Problem beim "lanes"-taggen

#5 2013-08-23 18:50:23

Re: Problem beim "lanes"-taggen

#6 2013-08-23 21:07:42

Re: Problem beim "lanes"-taggen

#7 2013-08-23 21:52:45

Re: Problem beim "lanes"-taggen

#8 2013-08-23 22:27:22

Re: Problem beim "lanes"-taggen

#9 2013-08-24 05:48:43

Re: Problem beim "lanes"-taggen

#10 2013-08-26 08:53:23

Re: Problem beim "lanes"-taggen

#11 2013-08-26 17:57:47

Re: Problem beim "lanes"-taggen

#12 2013-08-27 05:57:52

Re: Problem beim "lanes"-taggen

#13 2013-08-27 08:41:31

Re: Problem beim "lanes"-taggen

#14 2013-08-27 14:33:36

Re: Problem beim "lanes"-taggen

#15 2013-08-27 15:24:08

Re: Problem beim "lanes"-taggen

#16 2013-08-28 04:44:36

Re: Problem beim "lanes"-taggen

#17 2013-08-28 10:30:41

Re: Problem beim "lanes"-taggen

#18 2013-09-03 06:55:30

Re: Problem beim "lanes"-taggen

#19 2013-09-09 09:41:40

Re: Problem beim "lanes"-taggen

#20 2013-09-09 10:36:58

Re: Problem beim "lanes"-taggen

#21 2013-09-09 10:45:57

Re: Problem beim "lanes"-taggen

#22 2013-09-09 11:02:09

Re: Problem beim "lanes"-taggen

#23 2013-09-09 12:05:31

Re: Problem beim "lanes"-taggen

#24 2013-09-09 12:15:12

Re: Problem beim "lanes"-taggen

#25 2013-09-09 12:27:12

Re: Problem beim "lanes"-taggen

Board footer