Re: [Talk-de] Lane oder SharedLane?

2013-12-05 Thread pmsg
Hallo,

2013/12/5 Masi Master :

> [...] Der
> Schutzsteifen ist allerdings eine Radspur (nicht verpflichtend und auch
> nicht ganz exklusiv), die nur im Bedarfsfall von KFZ befahren/benutzt werden
> darf, und auch nur wenn kein Radfahrer behindert wird.

behindert -> gefährdet [1]

Bei Bedarf dürfen Kraftfahrzeuge auf dem Schutzstreifen anscheinend
auch behindern und müssen auch nicht die Geschwindigkeit reduzieren.
Das ist eine wesentlich schwächere Beschränkung als gilt für Radfahrer
auf Gehwegen mit "Radfahrer-frei" Schild (dort müssen Radfahrer
Schritttempo fahren und dürfen nicht Fussgänger behindern [2]).

Von daher kann man schon von "shared_lane" in Zusammenhang mit
Schutzstreifen sprechen.

Grüße,
Nils

[1] http://dejure.org/gesetze/StVO/Anlage_3.html, Anlage 3 (zu § 42
Absatz 2) Richtzeichen, lfd nr 22
[2] http://dejure.org/gesetze/StVO/Anlage_2.html, Anlage 2 (zu § 41
Absatz 1) Richtzeichen, lfd nr 18

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Voting landuse=highway

2013-12-05 Thread Florian Lohoff
On Thu, Dec 05, 2013 at 12:05:55AM +0100, Garry wrote:
> Eine 6spurige Autobahn nebst Böschung, Entwässerungsgräben,
> Sicherheitszonen etc.
> kann man nicht mehr einfach ignorieren und den umgebenden landuse zuordnen.
> 
> Allerdings würde ich für landuse=road plädieren und die eigentliche
> befestigte Fahrbahnfläche inklusive
> der Sperrflächen einem landcover=highway zuordnen.

Ich bin ja nicht dagegen das zu tun - Ich sage nur es fehlt ein
Gesamtkonzept wie in 2017 wir Straßen erfassen.

landuse + highway + highway/area ?

Und was ist in Wohngebieten ohne Fußgängerweg (e.g. Verkehrsberuhigt)
wenn A und C identisch sind?

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Voting landuse=highway

2013-12-05 Thread Peter Wendorff
Am 05.12.2013 10:15, schrieb Florian Lohoff:
> On Thu, Dec 05, 2013 at 12:05:55AM +0100, Garry wrote:
>> Eine 6spurige Autobahn nebst Böschung, Entwässerungsgräben,
>> Sicherheitszonen etc.
>> kann man nicht mehr einfach ignorieren und den umgebenden landuse zuordnen.
>>
>> Allerdings würde ich für landuse=road plädieren und die eigentliche
>> befestigte Fahrbahnfläche inklusive
>> der Sperrflächen einem landcover=highway zuordnen.
> 
> Ich bin ja nicht dagegen das zu tun - Ich sage nur es fehlt ein
> Gesamtkonzept wie in 2017 wir Straßen erfassen.
+10

Dabei hilft es auch nicht alleine, Straßen-linien über Flächen zu legen.
Wir haben auch immer noch kein umfassend brauchbares Spurenkonzept, das
für Bürgersteige, Radwege, Radspuren, Radschutzstreifen, Abbiegespuren,
Busspuren etc. sowie Abbiegespuren und unterschiedliche
Fahrbahnmarkierungen (Überfahrungserlaubnisse etc.) funktioniert.

Vielleicht ist eine Fläche rundrum ein Teil der Lösung, aber die
"einfach mal so einzuführen" bringt vermutlich wenig.

Ein landuse=highway für den Straßenkörper ist bestimmt nicht ganz
falsch, aber es löst nur einen kleinen Teil der Probleme, die wir mit
Straßen haben, nämlich die Ausdehnung in der Breite, die bisher kaum
abbildbar ist.

Gruß
Peter

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Voting landuse=highway

2013-12-05 Thread cracklinrain
Am 05.12.2013 00:05, schrieb Garry:
> Eine 6spurige Autobahn nebst Böschung, Entwässerungsgräben,
> Sicherheitszonen etc.
> kann man nicht mehr einfach ignorieren und den umgebenden landuse zuordnen.

Bisher war die sinnvollste Regelung, dass man keinen landuse nutzt und
die Fläche ungetagt lässt.

Bei highway=residential in/auf landuse=residential würde ich komplett
von landuse=highway absehen. Bei highway=track auf landuse=farm ebenso.

> Allerdings würde ich für landuse=road plädieren und die eigentliche
> befestigte Fahrbahnfläche inklusive
> der Sperrflächen einem landcover=highway zuordnen.

-1 landcover=highway geht mir deutlich zu weit. Wenn jemand landcover
für z.B. sein 3D-rendering haben möchte, soll er es taggen, dabei aber
niemanden stören. Aber so etwas offiziell zu empfehlen, führt dazu, dass
wir nicht einmal die Straßen in unserer Nachbarschaft (ganz zu schweigen
von den Hausnummern) erfassen und mit landcover beschäftigt sein werden.
So wie bei landuse=village_green.

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Voting landuse=highway

2013-12-05 Thread Martin Koppenhoefer
Am 4. Dezember 2013 22:36 schrieb Florian Lohoff :

> Das ist aber etwas was man nicht "on the ground" nachvollziehen kann
> wo das Grundstück aufhört.
>


und das aus dem Land der Jägerzäune? Man kann sehr oft nachvollziehen, wo
das Grundstück aufhört, nur aus einer Begehung der Gegend und ohne weitere
Pläne. Weiterhin gibt es in Deutschland oft Bebauungspläne, wo es
grundsätzlich drin ist. Wenn man überhaupt keine Ahnung hat, und auch
keinen best-guess wagen will oder recherchieren, ob es einen B-Plan gibt,
dann trägt man es halt nicht ein. In der Stadt (und prinzipiell auch im
Dorf) sollte es grundsätzlich kein Problem sein (von Vorderfassade der
Häuser bzw. Vorgarten bis zur gegenüberliegenden Straßenseite).

Hast Du mal ein Beispiel wo Du denkst, man könnte überhaupt nicht erkennen,
wo die Grundstücke aufhören?

Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


[Talk-de] SotM-EU 2014 in Karlsruhe!

2013-12-05 Thread Frederik Ramm
Hallo,

   ich habe heute das besondere Vergnuegen, die SotM-EU 2014 in
Karlsruhe (13.-15.6.) anzukuendigen. Die Webseite auf www.sotm-eu.org
ist schon aktualisiert, und alle Neuigkeiten gibt es dort sowie auch
unter @sotmeu auf Twitter.

Ich hoffe, es gelingt uns, an den grossen Erfolg der ersten SotM-EU 2011
in Wien anzuknuepfen und alle, die irgendwo in Europa irgendwas
interessantes bei oder mit OpenStreetMap machen, in Karlsruhe
zusammenzubringen.

Der Call for papers kommt demnaechst raus, und anmelden kann man sich ab
Anfang 2014. Wir haben schon ein ganz gutes internationales
Programmkomitee, das sich darum kuemmern wird, aber wenn noch jemand im
Programmkomitee oder bei der sonstigen Veranstaltungsorganisation
mithelfen moechte, so moege der- oder diejenige sich doch bitte bei
i...@sotm-eu.org melden, wir haben ganz bestimmt Arbeit genug ;)

Ich wuerde mich auch freuen, wenn ihr diese Ankuendigung in Euren
"OpenStreetMap-Kreisen" weiter verbreiten wuerdet.

Die Konferenz-Sprache ist englisch. (Der naechste deutschsprachige Event
mit grosser OSM-Beteiligung ist ja die FOSSGIS im Maerz in Berlin!)

Ich freue mich schon auf die Konferenz - wir habe ja schon viel
OSM-Zeugs gemacht in Karlsruhe, aber eine internationale Konferenz
hatten wir noch nie ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


[Talk-de] Pugi zu automatischen nachladen...

2013-12-05 Thread Steffen Heinz
Ich hatte bis vor kurzem noch die Möglichkeit das beim Verschieben der 
Karte diese automatisch aktualisiert wurde, brauchte also nicht mehr per 
Hmd den OSM Server anzusprechen, auch BING wurde nachgeladen.
DIe Tage ist mal JOSM tatal abgestürzt, seitdem geht das nicht mehr. 
Kann mir bitte mal wer helfen das wieder so hinzubiegen das das 
automatisch geht?


Grüße aus der Eifel
Steffen

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Stolpersteine Elternrelation gelöscht?

2013-12-05 Thread Frederik Ramm
Hi,

On 12/05/2013 08:21 AM, gmbo wrote:
> Ich habe heute morgen festgestellt dass die Elternrelation Stolpersteine 
> gelöscht wurde.
> Warum ist das gemacht worden?

Ich hab zwar nicht vor, das zu machen, aber es gaebe eine Menge Gruende
dafuer - wurde ja hier schon lang und breit diskutiert. Relationen sind
nicht dazu da, um die Datenabfrage einfacher zu machen, und nur diesen
Nutzen hat die genannte Relation.

Wer alle Stolpersteine aus OSM rausladen will, kann doch Overpass nehmen.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Stolpersteine Elternrelation gelöscht?

2013-12-05 Thread gmbo

Am 05.12.2013 16:04, schrieb Frederik Ramm:

Hi,

On 12/05/2013 08:21 AM, gmbo wrote:

Ich habe heute morgen festgestellt dass die Elternrelation Stolpersteine
gelöscht wurde.
Warum ist das gemacht worden?

Ich hab zwar nicht vor, das zu machen, aber es gaebe eine Menge Gruende
dafuer - wurde ja hier schon lang und breit diskutiert. Relationen sind
nicht dazu da, um die Datenabfrage einfacher zu machen, und nur diesen
Nutzen hat die genannte Relation.

Wer alle Stolpersteine aus OSM rausladen will, kann doch Overpass nehmen.

Bye
Frederik

Sicher kann man Overpass nehmen, dann benötigt eine solche Abfrage aber 
eine Menge Zeit.  Außerdem dachte ich bisher bei 4 Knoten, die 
gemeinsamen Daten wie Künstler, übergeordnete Website wäre vorteilhafter 
in der Relation.


Gruß Gisbert


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Stolpersteine Elternrelation gelöscht?

2013-12-05 Thread Peter Wendorff
Hallo Gisbert,

ich glaube, du missverstehst die normale API und den Vergleich zur
Overpass-API.
Beide sind prinzipiell optimiert für die Abfrage nach Geometrie, also
von zusammenhängenden Boundingboxen.
Beide können auch Objekte nach Typ+ID (Typ im Sinne von node, way,
relation) zurückliefern.
Während aber bei der API die bbox-Abfragen und Anfragen nach einzelnen
Objekten im Vordergrund stehen und der normale Fall sind, ist die
Overpass-API gezielt auf die Abfragesprache hin entwickelt und
implementiert deshalb auch für gleiche Tags wahrscheinlich einige
Strategien.
Genaueres musst Du den Entwickler fragen, aber in der API ist da in der
Hinsicht absolut gar nichts drin, da muss man vor allem auch noch
schreibzugriff zum Bearbeiten erlauben, außerdem Versionierung voll
unterstützen und so weiter.

Bist Du dir sicher, dass die Abfrage per Overpass länger dauert als per
API? Ich hätte jetzt gerne Zahlen dazu gesehen (wohlgemerkt: per API
musst Du dazu die Relation selbst UND die member runterladen, bei
overpass nur die eine Abfrage ausführen).

Gruß
Peter

Am 05.12.2013 16:31, schrieb gmbo:
> Am 05.12.2013 16:04, schrieb Frederik Ramm:
>> Hi,
>>
>> On 12/05/2013 08:21 AM, gmbo wrote:
>>> Ich habe heute morgen festgestellt dass die Elternrelation Stolpersteine
>>> gelöscht wurde.
>>> Warum ist das gemacht worden?
>> Ich hab zwar nicht vor, das zu machen, aber es gaebe eine Menge Gruende
>> dafuer - wurde ja hier schon lang und breit diskutiert. Relationen sind
>> nicht dazu da, um die Datenabfrage einfacher zu machen, und nur diesen
>> Nutzen hat die genannte Relation.
>>
>> Wer alle Stolpersteine aus OSM rausladen will, kann doch Overpass nehmen.
>>
>> Bye
>> Frederik
>>
> Sicher kann man Overpass nehmen, dann benötigt eine solche Abfrage aber
> eine Menge Zeit.  Außerdem dachte ich bisher bei 4 Knoten, die
> gemeinsamen Daten wie Künstler, übergeordnete Website wäre vorteilhafter
> in der Relation.
> 
> Gruß Gisbert
> 
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
> 


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Stolpersteine Elternrelation gelöscht?

2013-12-05 Thread Frederik Ramm
Hallo,

On 05.12.2013 16:31, gmbo wrote:
> Sicher kann man Overpass nehmen, dann benötigt eine solche Abfrage aber
> eine Menge Zeit.

Die Frage ist halt, wie skaliert es?

Wenn einer sich das Recht herausnimmt, eine Relation "Stolpersteine in
Karlsruhe" zu machen, dann kommt der naechste und macht mit gleichem
Recht "Apotheken in Karlsruhe", "Supermaerkte in Karlsruhe" und
"Nadelbaeume in Karlsruhe". Und das gleiche natuerlich auch noch fuer
alle anderen Staedte. Oder macht man vielleicht "Nadelbaeume in
Baden-Wuerttemberg" und dann "Nadelbaeume in Karlsruhe" als
Kind-Relation, hm, auch moeglich ;)

Ich glaube gern, dass eine Anfrage nach einer konkreten Relation und
ihren Kindern schneller geht als "alle Objekte mit Eigenschaft X im
Bereich Y". Aber: Das letztere geht fuer alle Arten von Objekten und
alle Arten von Bereichen. Stolpersteine in Karlsruhe, in
Baden-Wuerttemberg, in Deutschland - alles machbar. Selbst dann, wenn
der Mapper vergessen hat, den Stolperstein in eine Relation einzutragen.

Wenn wir stattdessen durch solche Sammelrelationen den Leuten den
Eindruck vermitteln, das waere normal und richtig so, dann hoert das
nicht mehr auf, dann kommt der naechste und macht "Sportplaetze in
Baden-Wuerttemberg" und einige deren Member sind zugleich auch in
"Ausrichtungsstaetten nationaler Sportwettkaempfe"...

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Stolpersteine Elternrelation gelöscht?

2013-12-05 Thread Dietmar
Hallo,

Am 05.12.2013 16:31, schrieb gmbo:
> Am 05.12.2013 16:04, schrieb Frederik Ramm:
>> Hi,
>>
>> On 12/05/2013 08:21 AM, gmbo wrote:
>>> Ich habe heute morgen festgestellt dass die Elternrelation
>>> Stolpersteine
>>> gelöscht wurde.
>>> Warum ist das gemacht worden?
>> Ich hab zwar nicht vor, das zu machen, aber es gaebe eine Menge Gruende
>> dafuer - wurde ja hier schon lang und breit diskutiert. Relationen sind
>> nicht dazu da, um die Datenabfrage einfacher zu machen, und nur diesen
>> Nutzen hat die genannte Relation.
>>
>> Wer alle Stolpersteine aus OSM rausladen will, kann doch Overpass
>> nehmen.

Alle Stolpersteine sind aktuelle NUR per Overpass herauszuholen. Die
Elternrelation für die Stolpersteine bringt nur etwa die Hälfte aller
Steine, wenn sie rekursiv in Josm geladen wird. Und nur dort kann die
Relation aus meiner Sicht sinnvoll geholt werden.
Ich verwende eine osmpgsql und da werden die meisten Relationstypen
nicht unterstützt.

Ich habe nur am Anfang einige Stadt-Relationen erzeugt, aber die sind
überflüssig wie ein Kropf und nerven mich total, weil die am meisten
Overhead beim aktuell halten einer OSM-DB bringen. Die meisten Steine
haben ein addr:city, so sind Kommunenorientiert Steine zu holen und nur
mit der Overpass-Api können auch Websites den aktuellen Bestand der
Steine auf einfache Weise in einer Openlayer-Anwendung integrieren.

Die meisten der von mir erfassten Steine (> 1000) sind in keiner
Relation enthalten.

Viele Grüße

Dietmar

>>
>> Bye
>> Frederik
>>
> Sicher kann man Overpass nehmen, dann benötigt eine solche Abfrage
> aber eine Menge Zeit.  Außerdem dachte ich bisher bei 4 Knoten,
> die gemeinsamen Daten wie Künstler, übergeordnete Website wäre
> vorteilhafter in der Relation.
>
> Gruß Gisbert
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Stolpersteine Elternrelation gelöscht?

2013-12-05 Thread Martin Koppenhoefer
Am 5. Dezember 2013 18:23 schrieb Peter Wendorff 
:

> (wohlgemerkt: per API
> musst Du dazu die Relation selbst UND die member runterladen, bei
> overpass nur die eine Abfrage ausführen).
>


ja, eines der Hauptprobleme der Relation (neben der Tatsache, dass sie dem
Gesamtsystem viel schwerer auf dem Magen liegt als tags, und sich auch
leichter Konflikte durch paralleles Editing bilden) ist ja, dass sie
permanent "von Hand" aktualisiert werden muss, während man per API Abfrage
alle Objekte mit dem tag bekommen kann. Gegen Vandalismus ist
zugegebenermaßen die Relation resistenter, weil man da sozusagen ein Backup
im System hat (man findet die gelöschten Nodes über die Relation einfach,
genauso wie es "nichts ausmacht", wenn die relevanten tags gelöscht werden
aber das Objekt noch bleibt).

Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Stolpersteine Elternrelation gelöscht?

2013-12-05 Thread Roland Olbricht
Hallo zusammen,

persönlich würde ich zum Editieren in JOSM empfehlen, eine Hintergrundkarte, 
z.B. die OSM-Karte einzuschalten und dann mit dem mirrored_download-Plugin 
unter dem Menüpunkt "Datei > Mittels Overpass-API laden" im Dialogfenster

[timeout:180];node["memorial:type"="stolperstein"];out meta;

eingeben und den Bereich der Wahl im Auswahlfenster wählen. Für eine Bounding-
Box in der Größe von Köln dauert der Download etwa 7 Sekunden, und JOSM 
reagiert dank kleiner Objektzahl sehr flott.

Außerdem kann ich sehr die Dorstener Lösung empfehlen:

http://wiki.openstreetmap.org/wiki/Dorsten#.C3.9Cbersichtskarten

Dort wird ohne Gebrauch irgendwelcher Relationen aus einem Wiki-Template eine 
Übersichtskarte generiert.

Kurz noch ein paar Zahlen zu dem Thema:

http://api.openstreetmap.org/api/0.6/relation/407359/full

braucht 3-5 Sekunden (je nach Cache-Zustand), findet aber neben mehreren 
Relationen auch nur 3 Stolpersteine.

Das exakte Äquivalent dazu ist:

http://overpass-api.de/api/interpreter?data=(rel(407359);rel(r)-
>.a;node(r););out meta;

braucht etwa 3-7 Sekunden (je nach Cache-Zustand)

Mit der Abfrage, die auch alle indirekten Referenzen verfolgt:

http://overpass-api.de/api/interpreter?data=(rel(407359);>>;);out meta;

findet man 7572 Stolpersteine in 60-80 Sekunden.

Mit der Abfrage, die alle Stolpersteine sucht:

http://overpass-
api.de/api/interpreter?data=node["memorial:type"="stolperstein"];out meta;

findet man 10753 Stolpersteine in 60-90 Sekunden.

Relationen über mehrere Relationen-Level aufzulösen ist meines Erachtens mit 
der Main API nicht möglich.

Viele Grüße,

Roland


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Stolpersteine Elternrelation gelöscht?

2013-12-05 Thread Roland Olbricht
Hallo,

> Außerdem dachte ich bisher bei 4 Knoten, die
> gemeinsamen Daten wie Künstler, übergeordnete Website wäre vorteilhafter
> in der Relation.

Nein. Mindestens die Main API, komprimiertes XML, PBF und auch die OVerpass 
API ersetzen Strings intern durch Referenzen auf Strings, d.h. sie speichern 
jeden String nur einmal. Das deckt aber auch schon so ziemlich alles ab.

Zum groben Vergleich: schreibt man 1000 Nodes mit dem gleichen Tag in eine 
.osm.gz-Datei, so braucht das nur etwa halb so viel Platz (unter 3 KB) wie 
1000 Nodes ohne Tag und mit dem Tag einmalig an der Relation (knapp über 6 
KB).

Viele Grüße,

Roland


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Lane oder SharedLane?

2013-12-05 Thread Masi Master

Am 05.12.2013, 09:34 Uhr, schrieb pmsg :


Hallo,

2013/12/5 Masi Master :


[...] Der
Schutzsteifen ist allerdings eine Radspur (nicht verpflichtend und auch
nicht ganz exklusiv), die nur im Bedarfsfall von KFZ befahren/benutzt  
werden

darf, und auch nur wenn kein Radfahrer behindert wird.


behindert -> gefährdet [1]

Bei Bedarf dürfen Kraftfahrzeuge auf dem Schutzstreifen anscheinend
auch behindern und müssen auch nicht die Geschwindigkeit reduzieren.
Das ist eine wesentlich schwächere Beschränkung als gilt für Radfahrer
auf Gehwegen mit "Radfahrer-frei" Schild (dort müssen Radfahrer
Schritttempo fahren und dürfen nicht Fussgänger behindern [2]).

Von daher kann man schon von "shared_lane" in Zusammenhang mit
Schutzstreifen sprechen.


Danke für die Richtigstellung! Hatte das nur aus dem Kopf wiedergegeben.
Etwas schwerer wiegt die Tatsache, dass Fahrzeuge die Linie des
Schutzstreifens "nur bei Bedarf" überfahren dürfen. In dem Zusammenhang
von gemeinsam Nutzung zu sprechen finde ich ein wenig fraglich.

Ohne jetzt in der StVO nach feinen Details zu suchen (die in anderen
Ländern eh unterschiedlich sind), finde ich es viel wichtiger die
Schutzstreifen von wirklichen gemeinsam benutzten Spuren zu unterscheiden,
den Sharrows (gibts auch ohne die Pfeile).

Radfahrstreifen und Schutzstreifen finde ich auf den ersten Blick
ähnlicher als eine komplette Spur die von verschiedenen Verkehren
verwendet wird. Wirkt sonst irgendwie wie eine komplette Fahrspur.


[1] http://dejure.org/gesetze/StVO/Anlage_3.html, Anlage 3 (zu § 42
Absatz 2) Richtzeichen, lfd nr 22
[2] http://dejure.org/gesetze/StVO/Anlage_2.html, Anlage 2 (zu § 41
Absatz 1) Richtzeichen, lfd nr 18






--

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de