[Talk-de] right/left

[Dimitri Junker]

Hallo,

Ich habe mal ein Proposal geschrieben:


Bitte schaut es Euch an und korigiert formale Fehler und diskutiert es.

Und wo soll ich dies jetzt außer hier noch bekannt geben?

Dimitri

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

Re: [Talk-de] right/left

[André Reichelt]

Dimitri Junker schrieb:
> Hallo,
> 
> Ich habe mal ein Proposal geschrieben:
> 
> 
> Bitte schaut es Euch an und korigiert formale Fehler und diskutiert es.
> 
> Und wo soll ich dies jetzt außer hier noch bekannt geben?

Das Proposal gibt es schon und wurde sofern ich weiss abgelehnt. Schade
zwar, wie ich finde, aber was will man machen. Das Hauptproblem besteht
darin, dass die Tags nicht mehr passen, wenn der Weg gedreht wird.



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] right/left

[Bernd Wurst]

Hallo.

Am Freitag, 2. Januar 2009 schrieb André Reichelt:
> Das Hauptproblem besteht
> darin, dass die Tags nicht mehr passen, wenn der Weg gedreht wird.

Das ist ein No-Op.
oneway ist auch falsch wenn man den Weg dreht. Seit JOSM das automatisch 
dreht, kräht kein Hahn mehr danach. Mit der Begründung ablehnen ist sehr 
armselig.

Gruß, Bernd

-- 
Das Usenet ist prinzipiell ein recht lustiger Haufen, machmal ein
lustiger Haufen kleinkarierter, besserwissender und arroganter
Arschlöcher aber doch immer irgendwie lustig.
  -  Oliver C. Thornton, de.rec.reisen.misc, 26.7.2003



signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] right/left

[Frederik Ramm]

Hallo,

Bernd Wurst wrote:
>> Das Hauptproblem besteht
>> darin, dass die Tags nicht mehr passen, wenn der Weg gedreht wird.
> 
> Das ist ein No-Op.
> oneway ist auch falsch wenn man den Weg dreht. Seit JOSM das automatisch 
> dreht, kräht kein Hahn mehr danach.

Ach? Was ist mit den anderen Editoren?

Ich bin immer ein Gegner von diesem left/right-Gedöns gewesen, ebenso 
auch von oneway (wobei das halt einfach historisch ist) und incline und 
allem, was sich darauf verlaesst, dass die Richtung des Weges 
unveraenderlich ist. Ich habe einfach kein gutes Gefuehl dabei. Unsere 
Wege bräuchten eigentlich gar keine Richtung zu haben, die ist im 
Normalfall völlig unbedeutend und auf der Karte nicht sichtbar.

"Auf der rechten Seite der B123 ist ein Radweg" ist einfach keine Info, 
mit der man irgendwas anfangen kann. Erst zusammen mit der (auf der 
Karte verborgenen) Richtungsinfo ergibt sich ein Sinn. Das gefaellt mir 
nicht. Ich haette gern eine Loesung, die auch ohne verborgene 
Information auskommt. Idealerweise "Auf der Ostseite der B123 ist ein 
Radweg" - das ist absolut, da kann einer mit der Strasse machen, was er 
will, die Info bleibt klar und unkaputtbar. Leider gibt es hierbei 
Unklarheiten bei z.B. einer U-foermigen Strasse (aber da koennte man ja 
von Nord- und Suedseite sprechen?), und eine wirklich gute Loesung hab 
ich also auch nicht. Einen Hilfs-Node auf die Seite setzen, auf der der 
Radweg ist, das ginge, aber waere natuerlich extrem kompliziert...

Bye
Frederik

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

Re: [Talk-de] right/left

[Dirk Stöcker]

On Fri, 2 Jan 2009, Frederik Ramm wrote:


Das ist ein No-Op.
oneway ist auch falsch wenn man den Weg dreht. Seit JOSM das automatisch
dreht, kräht kein Hahn mehr danach.


Ach? Was ist mit den anderen Editoren?


Die Können ja lernen. So kompliziert ist das ja nicht. Das Minimum wäre 
eine Warnung anzuzeugen.



Ich bin immer ein Gegner von diesem left/right-Gedöns gewesen, ebenso
auch von oneway (wobei das halt einfach historisch ist) und incline und
allem, was sich darauf verlaesst, dass die Richtung des Weges
unveraenderlich ist. Ich habe einfach kein gutes Gefuehl dabei. Unsere
Wege bräuchten eigentlich gar keine Richtung zu haben, die ist im
Normalfall völlig unbedeutend und auf der Karte nicht sichtbar.


Für die Karte mag das stimmen, aber für die Datenbasis ist es nicht 
verzichtbar. Statt also jedesmal dagegen zu argumentieren sollte man es 
vernünftig umsetzen. Es kommt auch so, aber mit mehr Problemen.



"Auf der rechten Seite der B123 ist ein Radweg" ist einfach keine Info,
mit der man irgendwas anfangen kann. Erst zusammen mit der (auf der
Karte verborgenen) Richtungsinfo ergibt sich ein Sinn. Das gefaellt mir
nicht. Ich haette gern eine Loesung, die auch ohne verborgene
Information auskommt. Idealerweise "Auf der Ostseite der B123 ist ein
Radweg" - das ist absolut, da kann einer mit der Strasse machen, was er
will, die Info bleibt klar und unkaputtbar. Leider gibt es hierbei
Unklarheiten bei z.B. einer U-foermigen Strasse (aber da koennte man ja
von Nord- und Suedseite sprechen?), und eine wirklich gute Loesung hab
ich also auch nicht. Einen Hilfs-Node auf die Seite setzen, auf der der
Radweg ist, das ginge, aber waere natuerlich extrem kompliziert...


Himmelsrichtungsorientierte Angaben sind nicht brauchbar. Die lokale 
Geometrie arbeitet nun mal im Normallfall links/rechts und der Wechsel von 
lokal auf global ist immer schwer bis unmöglich. Wenn Du lokal auf der 
Erde noch eine Karte machen kannst, ist die Beschreibung der Erde aus 
Sicht des Mars schon ein ganzes Stück schwerer. Genauso kann ich für jede 
nicht-lokale Angabe, die Du vorschlägst immer eine (kurze) Straße 
zeichnen, die damit nicht abgebildet werden kann.


Auch wenn es Dir (und übrigens auch mir) nicht besonders gefällt. Lokale 
Angaben wie left, right, forward, backward sind sinnvoll und müssen ordentlich 
unterstützt werden.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] right/left

[Josias]

ich glaube es ist unumstritten, dass wir zeitnah eine Möglichkeit brauchen die 
eine Seite von der anderen zu unterscheiden,
wenn wir alles in einen way packen wollen.
ansonsten müssen wir wieder mit extra ways arbeiten, aber da sprechen auch 
wieder viele gegen.
anstatt immer nur Argumente zu bringen warum etwas nicht gut ist, sollte man 
lieber einen Vorschlag bringen wie es besser zu machen ist.
dass manche diese rechts links Unterscheidung nicht brauchen ist kein Argument, 
sich keine Gedanken drum zu machen.

in gutes neues Jahr wünscht
Josias


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

Re: [Talk-de] right/left

[Dimitri Junker]

Hallo,

>Ach? Was ist mit den anderen Editoren?

Alles neue muß ggf. zu Anpasuungen aller Editoren führen. Und es ist trivial 
einem Editor der einen Weg drehen kann beizubringen dabei gewisse Tags zu 
verändern. Wenn der Editor in einer Programiersprache ist die ich kenne 
mache ich das wahrscheinlich in 5 min.


>ebenso auch von oneway (wobei das halt einfach historisch ist)

Kannst Du mir eine Alternative nennen? Und jetzt sag nicht, man kann ja 
mehrere Ways zeichnen, denn das ist leider keine Lösung, denn die oneway-
Info fehlt dann immer noch. Wie willst Du also eine Straße zu einer 
Einbahnstraße machen ohne dem Weg eine Richtung zu geben, wie willst Du 
markieren, daß man in die eine Richtung auf einem Fahrradweg fahren kann, in 
die andere aber auf der Straße?

>Wege bräuchten eigentlich gar keine Richtung zu haben, die ist im
>Normalfall völlig unbedeutend und auf der Karte nicht sichtbar.

Die Richtung hat grundsätzlich nichts auf der Karte zu suchen. Was auf die 
Karte gehört ist z.B. ein Pfeil bei Einbahnstraßen. Wenn eine andere 
Eigenschaft gezeichnet wird sollte sie ggf anders gezeichnet werden wenn sie 
nur einseitig vorhanden ist.
Es ist nunmahl eine mathematische Trivialität, daß es Punkte, Vektoren, 
Flächen,... gibt und alles außer Punkten eine Richtung haben, ob uns das 
gefällt oder nicht. Sobald Du definierst aus welchen Nodes ein Weg 
besteht hast Du eine Richtung definiert. Und da es asymetrische 
Eigenschaften bei Straßen gibt ist diese Info für OSM auch wichtig.

>"Auf der rechten Seite der B123 ist ein Radweg" ist einfach keine Info,
>mit der man irgendwas anfangen kann.

Natürlich kann man was damit anfangen. Ein Renderer könnte z.B. je nach 
Zoomlevel der Straßenlinie z.B. einen blauen Rand verleihen oder eine 
abgesetzte blaue Linie neben die Straße zeichnen, je nachdem ob der 
Fahrradweg beidseitig ist könnte er dies entweder beidseitig oder eben 
einseitig machen. benutzt der renderer cycleway garnicht ist es eh egal.
Spätestens aber ein Router kann mit dieser Info etwas anfangen. Nur weil es 
auf der Karte nicht zu sehen ist ist eine Info ja nicht wertlos. Wenn wir 
alle Geschwindihgkeitsbeschränkungen, Verbote für LKW, Anliegerregelungen 
u.ä. auf einer Karte einzeichnen wollten wäre diese so unübersichtlich, daß 
sie unbrauchbar wäre.

>Idealerweise "Auf der Ostseite der B123 ist ein Radweg" - das ist absolut


Lebst Du in New York? In anderen Gegenden gibt es Kreisverkehre, es gibt 
Kurven,...
Es gibt verschiedene Phasen in der Eingabe/Nutzung von OSM:

Eingabe durch den Mapper: Hier kann der Editor die Richtung anzeigen -> es 
ist für ihn einfach rechts von links zu unterscheiden, bei nicht geraden 
Straßen wäre Nord/Süd o.ä. aber nicht eindeutig

Umwandeln der Vektordaten durch einen Renderer in eine Pixelkarte: Solange 
es eindeutig ist kann dieser alles verarbeiten, also rechts/links, N/S, 
vorwärts/rückwärts

Anschauen der Karte durch einen Menschen: Die Info muß so durch den Renderer 
aufgearbeitet worden sein, daß man sieht was gemeint ist, die Richtung des 
Weges ist hier nicht mehr wichtig. Die Karte muß also gleich aussehen ob 
der Weg nach Osten weist und oneway=yes gesetzt ist oder ob er nach Westen 
weist und oneway=-1 gesetzt ist.

Gleiches git für Router. Der Router braucht die Richtungsinfo des Weges muß 
diese aber so an den Nutzer weitergeben wie er sie gerade braucht, ohne ihn 
mit der Wegrichtung zu verwirren. Mir als Nutzer ist egal wierum der Weg 
getaggt ist solange der Router mich nicht falsch durch eine Einbahnstraße 
leitet.

>Einen Hilfs-Node auf die Seite setzen, auf der der Radweg ist, das
>ginge, aber waere natuerlich extrem kompliziert...


Eben deshalb ist diese Lösung schlechter sorry.

Dimitri

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

Re: [Talk-de] right/left

[Frederik Ramm]

Hallo,

Dirk Stöcker wrote:
> Für die Karte mag das stimmen, aber für die Datenbasis ist es nicht 
> verzichtbar. Statt also jedesmal dagegen zu argumentieren sollte man es 
> vernünftig umsetzen. Es kommt auch so, aber mit mehr Problemen.

Du behauptest, dass es (=Richtungen an Ways) nicht verzichtbar sei, 
lieferst aber keine Gruende dafuer. Ich bin nicht ueberzeugt. Vom "haben 
wir immer so gemacht"-Faktor abgesehen, koennte man eine Einbahnstrasse 
ganz prima durch eine Relation abbilden ("Strasse S ist Einbahnstrasse 
von Node A bis Node B").

> Himmelsrichtungsorientierte Angaben sind nicht brauchbar. Die lokale 
> Geometrie arbeitet nun mal im Normallfall links/rechts und der Wechsel 
> von lokal auf global ist immer schwer bis unmöglich. Wenn Du lokal auf 
> der Erde noch eine Karte machen kannst, ist die Beschreibung der Erde 
> aus Sicht des Mars schon ein ganzes Stück schwerer. Genauso kann ich für 
> jede nicht-lokale Angabe, die Du vorschlägst immer eine (kurze) Straße 
> zeichnen, die damit nicht abgebildet werden kann.

Auch das kann ich nicht akzeptieren. Wir haben uns, obwohl das "lokal" 
völlig unnötig wäre, darauf festgelegt, alles schön in WGS84-Koordinaten 
(also "absolut") aufzuschreiben. Wenn an einer Strassenkreuzung ein 
Briefkasten steht, dann speichern wir die Koordinaten des Briefkastens 
separat, und nicht "Rechts der A-Strasse an der Kreuzung mit der 
B-Strasse steht ein Briefkasten 3m vom Bordstein entfernt". Letzteres 
waere aber die logische Konsequenz Deiner Argumentation.

Bye
Frederik

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

Re: [Talk-de] right/left

[Josias]

Frederik Ramm schrieb:
> Hallo,
> 
> Dirk Stöcker wrote:
>> Für die Karte mag das stimmen, aber für die Datenbasis ist es nicht 
>> verzichtbar. Statt also jedesmal dagegen zu argumentieren sollte man es 
>> vernünftig umsetzen. Es kommt auch so, aber mit mehr Problemen.
> 
> Du behauptest, dass es (=Richtungen an Ways) nicht verzichtbar sei, 
> lieferst aber keine Gruende dafuer. Ich bin nicht ueberzeugt. Vom "haben 
> wir immer so gemacht"-Faktor abgesehen, koennte man eine Einbahnstrasse 
> ganz prima durch eine Relation abbilden ("Strasse S ist Einbahnstrasse 
> von Node A bis Node B").
relationen sind sehr kompliziert
zumindest ist es um das 3 fache komplizierter als das bisherige:
du musst 2 Knoten und einen way in die Rel einfügen, und mindestens 1 tags 
einfügen (typ=oneway?)
die Verarbeitung ist ungleich komplizierter,

und:
was ist wenn einer der knoten gelöscht wird?
dann haben wir das gleiche Dilemma wie beim umdrehen der Wege



> 
>> Himmelsrichtungsorientierte Angaben sind nicht brauchbar. Die lokale 
>> Geometrie arbeitet nun mal im Normallfall links/rechts und der Wechsel 
>> von lokal auf global ist immer schwer bis unmöglich. Wenn Du lokal auf 
>> der Erde noch eine Karte machen kannst, ist die Beschreibung der Erde 
>> aus Sicht des Mars schon ein ganzes Stück schwerer. Genauso kann ich für 
>> jede nicht-lokale Angabe, die Du vorschlägst immer eine (kurze) Straße 
>> zeichnen, die damit nicht abgebildet werden kann.
> 
> Auch das kann ich nicht akzeptieren. Wir haben uns, obwohl das "lokal" 
> völlig unnötig wäre, darauf festgelegt, alles schön in WGS84-Koordinaten 
> (also "absolut") aufzuschreiben. Wenn an einer Strassenkreuzung ein 
> Briefkasten steht, dann speichern wir die Koordinaten des Briefkastens 
> separat, und nicht "Rechts der A-Strasse an der Kreuzung mit der 
> B-Strasse steht ein Briefkasten 3m vom Bordstein entfernt". Letzteres 
> waere aber die logische Konsequenz Deiner Argumentation.
> 
> Bye
> Frederik


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

Re: [Talk-de] right/left

[Sven Geggus]

Frederik Ramm  wrote:

> "Auf der rechten Seite der B123 ist ein Radweg" ist einfach keine Info, 
> mit der man irgendwas anfangen kann. Erst zusammen mit der (auf der 
> Karte verborgenen) Richtungsinfo ergibt sich ein Sinn. Das gefaellt mir 
> nicht. Ich haette gern eine Loesung, die auch ohne verborgene 
> Information auskommt. Idealerweise "Auf der Ostseite der B123 ist ein 
> Radweg"

Sorry, aber das halte ich für komplett unpraktikabel. Den Benutzer
der Straße interessiert die Himmelrichtung nicht die Bohne. Man
möchte gerade bei benutzungspflichtigen Radwegen wissen ob ein Weg
rechts, links oder gar nicht existiert. Selbst der Erfasser von
tracks muss das beim Zeichnen der Karte abstarhieren. unterwegs wird
der sich garantiert eher notieren "Radweg links" als "Radweg auf der
Ostseite".

Überhaupt haben solche sraßenbegleitenden Objekte ja gerade die
Straße als Bezugssystem und nicht die umgebende Welt.

Sven

-- 
"If you don't make lower-resolution mapping data publicly
available, there will be people with their cars and GPS
devices, driving around with their laptops" (Tim Berners-Lee)
/me is gig...@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] right/left

[Sven Geggus]

Dimitri Junker  wrote:

> Die Richtung hat grundsätzlich nichts auf der Karte zu suchen. Was
> auf die Karte gehört ist z.B. ein Pfeil bei Einbahnstraßen. Wenn
> eine andere Eigenschaft gezeichnet wird sollte sie ggf anders
> gezeichnet werden wenn sie nur einseitig vorhanden ist.

Genau!

Auf den Freizeitkarten der Landesvermessungsämter werden zum Beispiel
(manche) straßenbegleitenden Radwege als Linien[1] gerendert. Auf der
jeweiligen Seite der Straße bzw. gegebenenfalls beidseitig.

Sven

[1] Dass die Farben für Rad- und Wanderwege in rot und grün bei den
südlichen Landesvermessungsämtern genau umgekehrt vergeben sind wie
bei den nördlichen Landesvermessungsämtern muss man vermutlich nicht
verstehen. Konsequenterweise sind die Wegweiser für Radfahrer daher
ebenfalls im Süden grün und im Norden rot %-/

-- 
"If you don't make lower-resolution mapping data publicly
available, there will be people with their cars and GPS
devices, driving around with their laptops" (Tim Berners-Lee)
/me is gig...@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] right/left

[Wolfgang W. Wasserburger]

> Alles neue muß ggf. zu Anpasuungen aller Editoren führen. Und es
> ist trivial
> einem Editor der einen Weg drehen kann beizubringen dabei gewisse Tags zu
> verändern. Wenn der Editor in einer Programiersprache ist die ich kenne
> mache ich das wahrscheinlich in 5 min.
>
wie waren doch die letzten Worte des Programmierers? Den Fehler behebe ich
noch ehe ich gehe!
SCNR

Wolfgang


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

Re: [Talk-de] right/left

[Dirk Stöcker]

On Fri, 2 Jan 2009, Frederik Ramm wrote:


Für die Karte mag das stimmen, aber für die Datenbasis ist es nicht
verzichtbar. Statt also jedesmal dagegen zu argumentieren sollte man es
vernünftig umsetzen. Es kommt auch so, aber mit mehr Problemen.


Du behauptest, dass es (=Richtungen an Ways) nicht verzichtbar sei,
lieferst aber keine Gruende dafuer. Ich bin nicht ueberzeugt. Vom "haben
wir immer so gemacht"-Faktor abgesehen, koennte man eine Einbahnstrasse
ganz prima durch eine Relation abbilden ("Strasse S ist Einbahnstrasse
von Node A bis Node B").


Sicher. Das kann das gleiche leisten. Nur hast Du jetzt für ein einfaches 
geometrisches Problem gleich eine zweite Datenstruktur eingeführt. Und 
dass es schwieriger ist, zwei Datenstrukturen parallel auf dem gleichen 
Stand zu halten, ist wohl unstrittig. Der Aufwand für die Editoren liegt 
hier ein Vielfaches über dem zur Richtungsabhängigkeit von Wegen. Und die 
Fehlerquote durch Skripte und einfachere Editoren würde enorm sein.


Und wo der Vorteil davon liegen soll weginterne Informationen an die 
Relation durchzureichen konnte mir noch keiner erklären. Jedem, der dass 
in einer Klassenhierarchie in Software versuchen sollte würde ich aber 
ganz schön den Marsch blasen.


Ein Weg hat implizit eine Richtung. Aus welchem Grund willst Du diese 
zugunsten von komplizierten Regelungen aufgeben? Nur weil es auf der Karte 
nicht sichtbar ist? Ich denke "Wir mappen nicht für Renderer".



Himmelsrichtungsorientierte Angaben sind nicht brauchbar. Die lokale
Geometrie arbeitet nun mal im Normallfall links/rechts und der Wechsel
von lokal auf global ist immer schwer bis unmöglich. Wenn Du lokal auf
der Erde noch eine Karte machen kannst, ist die Beschreibung der Erde
aus Sicht des Mars schon ein ganzes Stück schwerer. Genauso kann ich für
jede nicht-lokale Angabe, die Du vorschlägst immer eine (kurze) Straße
zeichnen, die damit nicht abgebildet werden kann.


Auch das kann ich nicht akzeptieren. Wir haben uns, obwohl das "lokal"
völlig unnötig wäre, darauf festgelegt, alles schön in WGS84-Koordinaten
(also "absolut") aufzuschreiben. Wenn an einer Strassenkreuzung ein
Briefkasten steht, dann speichern wir die Koordinaten des Briefkastens
separat, und nicht "Rechts der A-Strasse an der Kreuzung mit der
B-Strasse steht ein Briefkasten 3m vom Bordstein entfernt". Letzteres
waere aber die logische Konsequenz Deiner Argumentation.


Das wäre die zweite Alternative: Massenweise parallele Wege für jede der 
Einzelinformationen. Auch hier stellt sich wieder die Frage: Warum so 
umständlich, wenn es auch einfacher geht (mal davon abgesehen, dass Du 
einige Fälle damit nicht abdecken kannst, z.B. die Einbahnstraße).


P.S. Übrigens ist das genau die Art, wie ich Briefkästen aufnehme: Ich 
setze einen Punkt auf der Straße und sage "Briefkasten links/rechts" ins 
Mikro. Der Mensch denkt selten in Himmelsrichtugen, sondern in Begriffen 
wie vorn/hinten/links/rechts. Dort wo es sinnvoll ist, sollte auch der 
OSM-Datenbestand für solche Angaben spezifiziert sein.


Wenn Du TagWatch mal anschaust, wirst Du sehen, dass links und rechts 
wirklich sehr sehr häufig genutzt werden. Alle, die gegen eine 
Standardisierung sprechen werden das nicht ändern können. Eine 
Standardisierung würde allerdings den Vorteil haben, dass man den 
Wildwuchs eindämmen könnte.


Sachen wie coastlines und oneway wieder aus der Welt zu schaffen ist 
aus meiner Sicht sowieso utopisch.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] right/left

[Dimitri Junker]

Hallo,

>was ist wenn einer der knoten gelöscht wird?


Oder wenn 2 solcher Straßen verbunden werden.

Dimitri

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

Re: [Talk-de] right/left

[Dimitri Junker]

Hallo,

>koennte man eine Einbahnstrasse ganz prima durch eine Relation
>abbilden ("Strasse S ist Einbahnstrasse von Node A bis Node B").

Und was ist 

>von Node A bis Node B


anderes als die Richtungsinfo des Weges? Node A ist der erste Node und NodeB 
der letzte des Weges. Nur ist es für den Mapper viel aufwändiger so eine 
Relation zu definieren als die jetzige Methode. Außerdem sieht er im Editor 
nicht welches Node A und welches Node B ist, während ein vom Editor 
gezeichneter Pfeil viel einfacher zu erkennen ist.

>dann speichern wir die Koordinaten des Briefkastens separat, und
>nicht "Rechts der A-Strasse an der Kreuzung mit der B-Strasse steht ein
>Briefkasten 3m vom Bordstein entfernt". Letzteres waere aber die
>logische Konsequenz Deiner Argumentation.


Nein. Ein Briefkasten wird als Punkt markiert, ein Punkt hat 2 (Höheninfos 
mappen wir ja meist nicht) Koordinaten. Er ist ein unabhängiges Element, 
nicht Teil der Kreuzung -> eigene Koordinaten. Ein Weg ist ein Vektor, bzw 
wenn er nicht gerade ist eine Folge von Vektoren. Wenn man ihm 
Seitenabhängige Eigenschaften vergeben will ist dies Eindeutig und für den 
Mapper leicht erfassbar nur per rechts/links möglich, es sei denn der Mapper 
kann rechts und links nicht unterscheiden.
Es gibt ja Fälle wo so etwas schon existiert. Nämlich in der Schiffsfahrt. 
Hier gibt es richtungsabhängige Gesetze. Auf Flüssen richten sie sich nach 
der Fliesrichtung, das entspricht der Richtung eines Weges. Auf See gilt 
(ich zitiere :

>Das heißt "nicht-nautisch": die Frage rechts/links wird durch die 
>einlaufenden Schiffe definiert.
Hier definiert man also wieder eine Richtung und kann so rechts/links 
verwenden, hilft uns aber nicht.
>Verbindet ein Fahrwasser zwei Meeresteile (anstelle von See- und 
>Binnenrevier), so gilt diejenige Seite als Steuerbordseite des Fahrwassers, 
>die steuerbord querab von den Schiffen liegt, die von westlicher Richtung 
>(von Nord(west) bis Südsüdwest) in dieses Fahrwasser fahren. Ist das 
>Fahrwasser aber stark gekrümmt, so dass die Einfahrt jeweils aus westlicher 
>Richtung erfolgen kann, so zählt die weiter nördlich liegende Einfahrt als 
>die maßgebliche (º2 Abs.1 Ziff.2 SeeSchStrO).

Wenn man also nicht eine 'natürliche' Richtung hat mit deren Hilfe man die 
Seite eines Fahrwassers definieren kann wird es kompliziert, und 
Kreisverkehre kommen im Meer sehr selten vor.

Schreib doch mal etwas vergleichbar eindeutiges zur Definition der 
nördlichen,... Seite einer Straße. Und schreibe ein Regelwerk wie man beim 
Verbinden von 2 Straßen automatisch die Seiteninfo anpassen kann, Angenommen 
Du verbindest z.B. eine 'L' mit einer 'J' förmigen Straße zu einer 'U'-
förmigen. Wenn Du da etwas hinbekommst was auch nur annähernd gleich einfach 
und eindeutig ist wie rechts links werde ich das vehement unterstützen. Aber 
nur sagen rechts/links ist blöd bringt uns nicht weiter.

Dimitri

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

Re: [Talk-de] right/left

[Josias]

Dimitri Junker schrieb:
> Oder wenn 2 solcher Straßen verbunden werden.

genau...
es gibt da kein System das nicht vor ungewollten Veränderungen geschützt ist. 
(falls doch sagt es bitte)

desshalb sollten wir uns immer für das einfachste entscheiden


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

Re: [Talk-de] right/left

[Frederik Ramm]

Hallo,

Dirk Stöcker wrote:
> Ein Weg hat implizit eine Richtung.

Müsste er aber nicht haben; wenn wir Menschen über eine Strasse 
nachdenken, dann hat diese Strasse in unserem Kopf keine Richtung, oder?

> Sachen wie coastlines und oneway wieder aus der Welt zu schaffen ist aus 
> meiner Sicht sowieso utopisch.

Dass die Kuesten eine Richtung haben, ist einem ganz anderen Problem 
geschuldet, das hat hiermit nichts zu tun; das ist ja nur ein Workaround 
fuer Flaechenmodelleriung.

Bye
Frederik


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

Re: [Talk-de] right/left

[Frederik Ramm]

Hallo,

Josias wrote:
> relationen sind sehr kompliziert

Das ist richtig, aber Dirk sagte nicht "dass Wege eine Richtung haben, 
macht vieles einfacher", sondern "dass Wege eine Richtung haben, ist 
unverzichtbar".

> was ist wenn einer der knoten gelöscht wird?

Das geht nicht, das wird die API nicht zulassen; der Node muesste zuvor 
aus der Relation entfernt werden.

Bye
Frederik


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

Re: [Talk-de] right/left

[Bjørn Bürger]

Josias wrote:
> ich glaube es ist unumstritten, dass wir zeitnah eine Möglichkeit 
 > brauchen die eine Seite von der anderen zu unterscheiden,
> wenn wir alles in einen way packen wollen.

Ich denke, der obige Anspruch (alles in einen way packen) beschreibt 
schon das Hauptproblem.

> ansonsten müssen wir wieder mit extra ways arbeiten, aber da 
 > sprechen auch wieder viele gegen.

Das mag sein. Mittel- bis langfristig werden die extra Ways allerdings
die Situation wesentlich transparenter darstellen, als eine Rotte von
extra Attributen an nicht weiter vorhersagbarer Stelle. Zumal sich
die z.t. komplexen Abbiegebeziehungen an Kreuzungen mit Radweganteil
ohne extra-ways auch gar nicht vernünftig darstellen lassen.

Es wäre besser, den Editoren eine vernünftige Gruppierung von
Wegseqmenten (meinetwegen intern abgebildet als Relation) und die
entsprechende Darstellung analog zu einem aktuellen DTP- oder CAD- 
Programm beizubringen, als immer mehr Spezialtags auszudenken, mit
denen sich die Realität am Ende doch nicht vernünftig darstellen läßt
und die zudem viel zu schnell verloren gehen können.

> anstatt immer nur Argumente zu bringen warum etwas nicht gut ist, 
 > sollte man lieber einen Vorschlag bringen wie es besser zu machen
 > ist.

- Jedes Element mit besonderen Eigenschaften wird mit einem eigenen
   Objekt in der Datenbank verewigt

- Über eine Group-Relation werden die zueinander gehörenden
   Objekte gebündelt. Ob diese Relation nur eine abstrakte Gruppe
   oder tatsächlich ein vorhandenes Feature (Bundesstraße XY)
   beschreibt, ist erstmal irrelevant.

- Damit die Übersicht beim editieren nicht verloren geht,
   sollten alle Editoren einen vernünftigen Group-Support
   bekommen: Beim betreten einer Gruppe/Relation wird alles
   andere ausgeblendet, nur noch die einzelnen Elemente
   sind editierbar.

- Was die jammernden Autofahrer betrifft, die z.B. extra
   Ways für Radwege ablehnen, weil das die "schönen Autokarten
   verunstaltet"¹: Das ist eine Sache, die sich schnell
   über die Renderer (und nur dort) lösen lassen sollte.

> dass manche diese rechts links Unterscheidung nicht brauchen 
 > ist kein Argument, sich keine Gedanken drum zu machen.

Meiner Meinung nach werden rechts/links Unterscheidungen durchaus
gebraucht, sie als richtungsabhängige Extratags statt als eigene
Ways zu realisieren ist jedoch IMO fahrläßiger Unsinn und wird
unweigerlich zu unnötigem Datenverlust führen. Schon die jetzige
Oneway Lösung ist haarsträubend.

Just my 2¢.

Bjørn

¹) Begründung des Users, der vor einiger Zeit mal in Braunschweig
einige Kilometer straßenbegleitenden Radweg gelöscht hat.

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

Re: [Talk-de] right/left

[Christoph Wagner]

Frederik Ramm schrieb:
> Hallo,
> 
> Dirk Stöcker wrote:
>> Ein Weg hat implizit eine Richtung.
> 
> Müsste er aber nicht haben; wenn wir Menschen über eine Strasse 
> nachdenken, dann hat diese Strasse in unserem Kopf keine Richtung, oder?
> 

Wenn ich über eine Straße nachdenke, dann hat die auch keine
Knotenpunkte und Verbindungslinien.
Irgendwo muss man doch mal modellieren. Und ehrlich gesagt finde ich
diese left/right Sachen wesentlich handlicher als irgendwelche
Himmelsrichtungen oder Relationen.

Wenn das einzige Problem nun darin besteht, dass die Wege auch umgedreht
werden können, ist doch alles klar. Die Editoren lassen sich ja anpassen.
Ach ja - kennt ihr Leute die einfach mal aus Lust und Laune
Wegrichtungen umdrehen? Ich nicht. Das hat doch meist einen der
folgenden Gründe:
- Wege werden verbunden und dabei einer gedreht
- eine Einbahnstraße wird eingetragen und der Weg wird in die passende
Richtung gedreht (für alle, die sich auch nicht mit -1 anfreunden...)

Mehr fällt mir schon gar nicht ein. Also ist das wirklich so ein großes
Problem?

Grüße
Christoph



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] right/left

[Frederik Ramm]

Hallo,

Dimitri Junker wrote:
> Und was ist 
>> von Node A bis Node B
> anderes als die Richtungsinfo des Weges?

Hier iwrd explizit gesagt: Die Einbahnrichtung ist von X nach Y. Das 
aendert nur jemand, der ausdruecklich die Einbahnrichtung umdrehen will. 
Das funktioniert auch noch, wenn der Way in der mitte aufgeteilt wird, 
oder wenn der Way mit einem anderen Teil verbunden wird, der kein 
Einbahnway ist, oder was auch immer. Es ist eine ganz klare und direkte 
Aussage: Von X bis Y ist das Ding Einbahn. Mit der Richtung des Weges 
hat das gar nichts zu tun.

Bye
Frederik


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

Re: [Talk-de] right/left

[Sven Anders]

Am Freitag, 2. Januar 2009 17:09 schrieb Frederik Ramm:
> Hallo,
>
> Dimitri Junker wrote:
> > Und was ist
> >
> >> von Node A bis Node B
> >
> > anderes als die Richtungsinfo des Weges?
>
> Hier iwrd explizit gesagt: Die Einbahnrichtung ist von X nach Y. Das
> aendert nur jemand, der ausdruecklich die Einbahnrichtung umdrehen will.
> Das funktioniert auch noch, wenn der Way in der mitte aufgeteilt wird,
> oder wenn der Way mit einem anderen Teil verbunden wird, der kein
> Einbahnway ist, oder was auch immer. Es ist eine ganz klare und direkte
> Aussage: Von X bis Y ist das Ding Einbahn. Mit der Richtung des Weges
> hat das gar nichts zu tun.

Ja, genau so "krank" ist es das wir nicht sagen, die Straßen hat von A bis B 
den Namen: Dorfstraße
Dann kann man sie aufteilen und der Name bleibt erhalten.

Gruß
Sven

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

Re: [Talk-de] right/left

[Dirk Stöcker]

On Fri, 2 Jan 2009, Frederik Ramm wrote:


Dimitri Junker wrote:

Und was ist

von Node A bis Node B

anderes als die Richtungsinfo des Weges?


Hier iwrd explizit gesagt: Die Einbahnrichtung ist von X nach Y. Das
aendert nur jemand, der ausdruecklich die Einbahnrichtung umdrehen will.
Das funktioniert auch noch, wenn der Way in der mitte aufgeteilt wird,
oder wenn der Way mit einem anderen Teil verbunden wird, der kein
Einbahnway ist, oder was auch immer. Es ist eine ganz klare und direkte


Nein. Funktioniert es nicht. Wenn Du nur über die Knoten gehst, dann 
kannst Du keinen Bezug herstellen. Es gibt viele Wege, die von A nach B 
führen (nämlich nahezu unendlich viele). Als gehört die Weginformation 
dazu.


Und durch Teilen und Zusammenfügen werden im Hintergrund vollkommen 
intransparent Wege gelöscht, neu erzeugt, umgeändert, verschoben, ...
Die Auswirkungen davon sieht man deutlich, wenn man versucht Wege in der 
Datenbank wiederherzustellen. Teilweise ist es nicht nachvollziehbar aus 
welchem Weg jetzt welcher geworden ist und wie man den ursprünglichen 
Zustand wiederherstellen kann. Neuzeichnen oder erneute Anpassung der 
Merkmale ist in der Regel einfacher.


Es ist nicht unmöglich das in den Griff zu bekommen, aber sehr viel 
schwieriger, als der schon existierende Ansatz mit richtungsgebundenen 
Wegen.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] right/left

[Dimitri Junker]

>Hier iwrd explizit gesagt: Die Einbahnrichtung ist von X nach Y.


Und das Bisherige oneway=yes bedeutet: Die Einbahnrichtung ist von Startnode 
nach Endnode des Weges.
Der einzige Vorteil Deiner Relation ist, daß man so auch Teile einer Straße 
zur Einbahnstraße machen kann. Genau so etwas hatte ich auch schonmal 
vorgeschlagen. Für den Normalfall, daß die ganze Straße Einbahnstraße ist 
bietet es aber nur Nachteile.

>Das funktioniert auch noch, wenn der Way in der mitte aufgeteilt wird,


Nein tut es nicht, es sei denn der Editor macht aus der einen Relation 2 mit 
dem Schnittpunkt als neue Anfangs/Endpunkte. Und bei Kreisverkehren 
funktioniert es garnicht, da ist nämlich X=Y.



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

Re: [Talk-de] right/left

[Dimitri Junker]

>Ich denke, der obige Anspruch (alles in einen way packen) beschreibt
>schon das Hauptproblem.


Vergiß dieses 'Hauptproblem' erstmal. Nehme an es geht um etwas wo auch Du 
sagen würdest man soll eine Straßenseite definieren können. Wenn wir uns 
geeinigt haben wie man das macht (rechts/links, Nord/Süd, 
Vorwärts/rückwärts, Mekkazugewand oder Mekkaabgewand oder was auch immer 
kann man sich dann überlegen wo man es einsetzt.

>- Jedes Element mit besonderen Eigenschaften wird mit einem eigenen
>Objekt in der Datenbank verewigt


Also jede Spur, jede Linie (die definiert ja ob man die Spur wechseln darf, 
der Bordstein (seine Höhe bestimmt ob man ihn per Rad überwinden kann), der 
Fahrradweg, der Fußgängerweg,... Und auf so einer Karte willst Du Dich 
zurechtfinden? Ich vermute, auch Du wirst dieses als übertrieben abtuen -> 
"Jedes Element" ist unsinn -> man muß sich überlegen welche Elemente man 
getrost zusammenfassen kann.

>- Was die jammernden Autofahrer betrifft, die z.B. extra Ways für
>Radwege ablehnen, weil das die "schönen Autokarten verunstaltet"π: Das
>ist eine Sache, die sich schnell über die Renderer (und nur dort) lösen
>lassen sollte.


Jeder Verkehrsteilnehmer nutzt eine Minderheit der Spuren. Eine typische 
innerstädtiche Straße hat 2 Auto, 0-2 Fahrrad- und 2 Fußgängerspuren also 4-
6 Spuren davon interessierten jeden nur 2. Es geht also wirklich nicht um 
Fahrrad gegen Auto oder so einen Mist. Es geht darum eine für alle nützliche 
Datenbank zu erstellen und daraus entweder eine Karte für alle oder 
Spezialkarten für einzelne Teilnehmergruppen.

>Schon die jetzige Oneway Lösung ist haarsträubend.


Ich lese immer nur was Mist ist aber keine Alternativen.

>Begründung des Users, der vor einiger Zeit mal in Braunschweig einige
>Kilometer straßenbegleitenden Radweg gelöscht hat.


Arbeit anderer löschen ist immer unverschmt. Zuerst kann man mit ihm 
diskutieren, wenn das nicht geht weil er es anonym eingegeben hat und 
Konsens besteht, daß es weg soll kann man einfach einen Tag löschen und ein 
note einfügen, so läßt es sich einfach wieder reaktivieren.

Dimitri

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

Re: [Talk-de] right/left

[Dimitri Junker]

Hallo,

>Müsste er aber nicht haben


Doch, definier doch mal einen Weg ohne implizit eine Richtung vorzugeben. 
Das geht nicht.

>wenn wir Menschen über eine Strasse nachdenken, dann hat diese Strasse
>in unserem Kopf keine Richtung, oder?


1. Definieren wir dann nicht diese Straße
2. sehen wir dann auch keine Himmelsrichtung
3. Es geht ja gerade darum eine Straßenseite ze definieren. Und da muß man 
halt irgendeine Methode finden, und die einfachste ist eben rechts/links. 
Einfach für den Mapper, einfach für die Software (Editor, Renderer, Router)


>Dass die Kuesten eine Richtung haben, ist einem ganz anderen Problem
>geschuldet, das hat hiermit nichts zu tun; das ist ja nur ein Workaround
>fuer Flaechenmodelleriung.


Doch es ist genau das gleiche, es geht jeweils darum bei einer Kurve zu 
bestimmen auf welcher Seite was ist, sei es nun der Fahrradweg oder das 
Meer. Der Unterschied ist, daß bei allen Vorschlägen zu Fahrradwegen man 
diesen auf beide Seiten des Weges legen kann während man bei Küstenlinien 
gesagt hat sie sollen immer auf einer festen Seite sein. Man hätte aber 
genau so gut definieren können:
coustline.sea=left
oder coastline.left=sea

oder was auch immer.

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

Re: [Talk-de] right/left

[Frederik Ramm]

Hallo,

Dimitri Junker wrote:
> Also jede Spur, jede Linie (die definiert ja ob man die Spur wechseln darf, 
> der Bordstein (seine Höhe bestimmt ob man ihn per Rad überwinden kann), der 
> Fahrradweg, der Fußgängerweg,

Ich stimme zu, dass das Erfassen dieser Daten lästig ist, aber *haben* 
würde ich sie schon gern.

> ... Und auf so einer Karte willst Du Dich 
> zurechtfinden?

Sagt ja keiner, dass die alle in "die" Karte eingezeichnet werden 
müssen. Aber ich könnte mit solchen Daten sehr gut arbeiten, wenn ich 
eine Karte für das jährliche Radrennen in der Stadt (-> durchgezogene 
Linien ignorieren, aber 1cm Bordstein ist schon zu viel), für das 
Cruisen mit dem Quad (-> Bordstein egal, durchgezogene Linie sollte man 
beachten) oder für die Krötenwanderung zeichnen will ;-)

Bye
Frederik


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

Re: [Talk-de] right/left

[Dirk Stöcker]

On Fri, 2 Jan 2009, Frederik Ramm wrote:


Dimitri Junker wrote:

Also jede Spur, jede Linie (die definiert ja ob man die Spur wechseln darf,
der Bordstein (seine Höhe bestimmt ob man ihn per Rad überwinden kann), der
Fahrradweg, der Fußgängerweg,


Ich stimme zu, dass das Erfassen dieser Daten lästig ist, aber *haben*
würde ich sie schon gern.


Können wir nicht erstmal versuchen die gleichen Daten wie die Konkurrenz 
zu haben? "Überholen ohne einzuholen" hat schon der DDR nicht gutgetan.


Wenn es sich in 10 Jahren als sinnvoll erweist alles einzeln zu haben, 
dann kann man das left/right automatisch konvertieren. Bis dahin würde ich 
gerne eine in der Gegenwart praktikable Lösung wollen.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] right/left

[André Reichelt]

Dimitri Junker schrieb:
> Schreib doch mal etwas vergleichbar eindeutiges zur Definition der 
> nördlichen,... Seite einer Straße. Und schreibe ein Regelwerk wie man beim 
> Verbinden von 2 Straßen automatisch die Seiteninfo anpassen kann, Angenommen 
> Du verbindest z.B. eine 'L' mit einer 'J' förmigen Straße zu einer 'U'-
> förmigen. Wenn Du da etwas hinbekommst was auch nur annähernd gleich einfach 
> und eindeutig ist wie rechts links werde ich das vehement unterstützen. Aber 
> nur sagen rechts/links ist blöd bringt uns nicht weiter.

Genau das ist der Punkt. Ich halte Relations auch für unnötig, da sie
keine Vorteile bringen. Warum denn mit einer komplizierten Methode das
Selbe sagen, dass man auch mit einer Einfachen kann? Relations bringen
keinerlei Vorteile bis auf den Winzigen, dass ich Straßenteile zur
Einbahnstraße machen kann. Dann kann ich sie aber auch gleich auftrennen
- das geht um Einiges einfacher.

Auch dieses Himmelsrichtungs-Gedöns hat einige Nachteile, wie sich
gezeigt hat. Außerdem hat es keine Vorteile gegenüber der
Rechts/Links-Methode.

Ich frage mich wirklich, warum sich hier einige so wehemend wehren. Es
ist bisher *mit Abstand* der Beste vorschlag, der genannt wurde. Es ist
leicht in die Editoren einzubauen, für jeden Menschen leicht
verständlich und belastet die Datenbank nicht.



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] right/left

[Frederik Ramm]

Hallo,

André Reichelt wrote:
> Ich frage mich wirklich, warum sich hier einige so wehemend wehren. Es
> ist bisher *mit Abstand* der Beste vorschlag, der genannt wurde. 

Was ist genau bitte "Es"? Das rechts/links oder das gemeinsame Taggen 
von mehreren baulich mehr oder weniger getrennten Fahr/Gehwegen an eine 
Basislinie?

Ich hab ein bisschen die Uebersicht verloren. Bei "Linienbuendel" denke 
ich instinktiv immer an sowas wie (absichtlich etwas übertrieben)

highway=secondary
lanes=3
lane:right:width=4
lane:middle:width=3
lane:left:width=4
cycleway=right:lane;left:separate
cycleway:right:lane:width=1m
cycleway:right:lane:surface=mud
cycleway:left:separate:surface=concrete
cycleway:left:separate:benutzungspflicht=true
footway=both:lane
footway:left:lane:surface=asphalt
footway:right:lane:surface=gravel
cycleway:right:barrier:left=bordstein
cycleway:right:location=between_footway_and_road
...

Will sagen: Solange man einfach nur sagen will, diese Strasse hat einen 
Radweg nebendran - fein. Dann ist der Radweg ein "Attribut" der Strasse. 
  Haben wir ja jetzt schon mehr oder weniger im Einsatz.

Sobald man aber anfangen moechte, den Radweg genauer zu beschreiben, 
wird er ein Objekt und kein blosses Attribut - dann faengt das Chaos an, 
weil der Original-Way dann nicht nur Traeger seiner eigenen Attribute 
wird, sondern auch Traeger der Attribute aller an ihm haengenden anderen 
Ways. Das kann in meinen Augen nicht gut gehen; der Way muss auch in der 
Datenbank ein eigenes Objekt sein. (Man *koennte* dafuer eine Relation 
verwenden: Fuer jede Fahrspur, die man extra beschreiben will, legt man 
eine Relation an die die ganzen Tags dieser Fahrspur enthaelt und die 
nur ein Member hat, naemlich den geometriestiftenden Way...)

Aber ihr macht ja sowieso was ihr wollt ;-)

Bye
Frederik

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

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

Re: [Talk-de] right/left

[Bjørn Bürger]

Dimitri Junker wrote:
> Vergiß dieses 'Hauptproblem' erstmal. Nehme an es geht um etwas wo auch Du 
> sagen würdest man soll eine Straßenseite definieren können. Wenn wir uns 
> geeinigt haben wie man das macht (rechts/links, Nord/Süd, 
> Vorwärts/rückwärts, Mekkazugewand oder Mekkaabgewand oder was auch immer 
> kann man sich dann überlegen wo man es einsetzt.

Alle Situationen, die mir dazu einfallen, schreien nach eigenen
Objekten, die entsprechend ihrer realen Position angelegt sind.
Ich kann mir zur Zeit keine Situation vorstellen, in der ein
Tag "links " sinnvoll erscheint.

>> - Jedes Element mit besonderen Eigenschaften wird mit einem eigenen
>> Objekt in der Datenbank verewigt
> 
> Also jede Spur, jede Linie (die definiert ja ob man die Spur wechseln darf, 
> der Bordstein (seine Höhe bestimmt ob man ihn per Rad überwinden kann), der 
> Fahrradweg, der Fußgängerweg,... Und auf so einer Karte willst Du Dich 
> zurechtfinden? 

Ja, letztlich wird es genau darauf hinauslaufen. Die Übersichtlichkeit
ist wiederum nur eine Frage der Darstellung im Editor. Er könnte z.B.
Gruppen zunächst nur als eine "besondere" Linie anzeigen und beim
betreten der Gruppe die Details auffächern.

Der im Vergleich höhere Aufwand ist IMO auch kein Argument. Lieber eine
korrekte, nützliche Karte - als eine schnell erzeugte, die einen
hinterher einschränkt. Solange eine bauliche Trennung (Bordstein, etc)
besteht, muss IMO ein eigenes Objekt her.

> Ich vermute, auch Du wirst dieses als übertrieben abtuen ->

Nein, im Gegenteil. Ich befürworte sowas ganz und gar.

> "Jedes Element" ist unsinn -> man muß sich überlegen welche Elemente man 
> getrost zusammenfassen kann.

Anfangs habe ich das auch gedacht. Aber das Desaster bei den Radwegen
hat mir vor Augen geführt, daß es so einfach nicht funktionieren kann.

> Jeder Verkehrsteilnehmer nutzt eine Minderheit der Spuren. Eine typische 
> innerstädtiche Straße hat 2 Auto, 0-2 Fahrrad- und 2 Fußgängerspuren also 4-
> 6 Spuren davon interessierten jeden nur 2. Es geht also wirklich nicht um 
> Fahrrad gegen Auto oder so einen Mist. Es geht darum eine für alle nützliche 
> Datenbank zu erstellen und daraus entweder eine Karte für alle oder 
> Spezialkarten für einzelne Teilnehmergruppen.

Eben. Genau aus diesem Grund solten die verschiedenen Verkehrstypen
ihren bedürfnissen gerecht aufgenommen werden, anstatt sie als
Sonderfälle eine Autostraße zu behandeln.

>> Schon die jetzige Oneway Lösung ist haarsträubend.
> Ich lese immer nur was Mist ist aber keine Alternativen.

Ich bevorzuge die Alternative, die auch von Frederick schon genannt
wurde: "Oneway von Punkt x bis Punkt y". Damit ist IMO alles klar
darstellbar und überlebt auch eine Auftrennen des Weges sinnvoll.

Bjørn


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

Re: [Talk-de] right/left

[André Reichelt]

Frederik Ramm schrieb:
> Sobald man aber anfangen moechte, den Radweg genauer zu beschreiben, 
> wird er ein Objekt und kein blosses Attribut - dann faengt das Chaos an, 
> weil der Original-Way dann nicht nur Traeger seiner eigenen Attribute 
> wird, sondern auch Traeger der Attribute aller an ihm haengenden anderen 
> Ways. Das kann in meinen Augen nicht gut gehen; der Way muss auch in der 
> Datenbank ein eigenes Objekt sein. (Man *koennte* dafuer eine Relation 
> verwenden: Fuer jede Fahrspur, die man extra beschreiben will, legt man 
> eine Relation an die die ganzen Tags dieser Fahrspur enthaelt und die 
> nur ein Member hat, naemlich den geometriestiftenden Way...)

Da gebe ich Dir recht. Spätestens dann wird es etwas übersichtlich.
Allerdings halte ich Relations für schlicht und ergreifend viel zu
kompliziert.

Vielleicht sollte man sich dazu eine Methode ausdenken, wie man die
einzelnen Wegteile separat taggen kann, ohne mehrere Ways übereinander
zu pinseln. Man könnte dass so erreichen, dass man zunächst die
Eigenschaften des Hauptweges (in der Mitte) definiert und darunter
mehrere Kategorien hat, die den unterpunkten weitere Dinge hinzufügen:

highway=residental
surface=paved
cycleway=left;0
  surface=clobberstone
footway=left;1
  surface=clobberstone
footway=right
  surface=clobberstone

Die Nummern dienen hier dazu, dass man mehrere Wege definieren kann. Die
Zählweise wäre da von links nach rechts, also

|   |   | R | |
| C | F | E |  F  |
| Y | O | S |  O  |
| C | O | I |  O  |
| L | T | D |  T  |
| E | W | E |  W  |
| W | A | N |  A  |
| A | Y | T |  Y  |
| Y |   | A | |
|   |   | L | |



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] right/left

[Torsten Leistikow]

Bjørn Bürger schrieb:
>>> - Jedes Element mit besonderen Eigenschaften wird mit einem eigenen
>>> Objekt in der Datenbank verewigt
>> Also jede Spur, jede Linie (die definiert ja ob man die Spur wechseln darf, 
>> der Bordstein (seine Höhe bestimmt ob man ihn per Rad überwinden kann), der 
>> Fahrradweg, der Fußgängerweg,... Und auf so einer Karte willst Du Dich 
>> zurechtfinden? 
> 
> Ja, letztlich wird es genau darauf hinauslaufen. Die Übersichtlichkeit
> ist wiederum nur eine Frage der Darstellung im Editor. Er könnte z.B.
> Gruppen zunächst nur als eine "besondere" Linie anzeigen und beim
> betreten der Gruppe die Details auffächern.

Momentan ist es so, dass man genau an den Beruehrungspunkten von einem
Weg zu einem anderen wechseln kann. Wie soll das aussehen, wenn jeder
Buergersteig als eigener Weg erfasst wird? Soll der dann alle 5cm mit
dem Weg fuer die Fahrbahn verbunden werden, weil ein Fussgaenger ja an
jeder Stelle die Fahrbahn ueberqueren kann?

> Ich bevorzuge die Alternative, die auch von Frederick schon genannt
> wurde: "Oneway von Punkt x bis Punkt y". Damit ist IMO alles klar
> darstellbar und überlebt auch eine Auftrennen des Weges sinnvoll.

Das Funktioniert aber nur, wenn
a) in der Relation auch der betroffene Weg mit abgespeichert wird. Dann
geht aber das Ueberleben beim Auftrennen auch nicht mehr, und man ist
mit etwas erhoehtem Aufwand wieder da, wo man mit der jetzigen
Weg-Anfangspunkt-Endpunkt-Loesung bereits ist.

oder

b) der Weg "von Punkt x bis Punkt y" im Graphen eindeutig waere. Denn
woher soll man sonst wissen, welcher Weg von x nach y gemeint ist.
Leider scheint mir diese Eindeutigkeit im Strassennetz doch gelinde
gesagt ziemlich unwahrscheinlich.

Gruss
Torsten

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

Re: [Talk-de] right/left

[Dirk Stöcker]

On Fri, 2 Jan 2009, Frederik Ramm wrote:


Will sagen: Solange man einfach nur sagen will, diese Strasse hat einen
Radweg nebendran - fein. Dann ist der Radweg ein "Attribut" der Strasse.
 Haben wir ja jetzt schon mehr oder weniger im Einsatz.


Wenn wir das noch endlich für die generelle Nutzung standardisieren, haben 
wir ja schon was erreicht.



Sobald man aber anfangen moechte, den Radweg genauer zu beschreiben,
wird er ein Objekt und kein blosses Attribut - dann faengt das Chaos an,
weil der Original-Way dann nicht nur Traeger seiner eigenen Attribute
wird, sondern auch Traeger der Attribute aller an ihm haengenden anderen
Ways. Das kann in meinen Augen nicht gut gehen; der Way muss auch in der


Ja. Und spätestens dann sollte man auch trennen. Und wenn wir genaue 
Luftbilder haben, dann kann man das sogar geometrisch ordentlich 
darstellen. Aber deswegen muss man doch die einfache left/right-Variante 
nicht ablehnen. Beide habe ihre Berechtigung. Hier draußen auf dem Land 
wäre ich froh, wenn wir alle Straßen hätten. Bis auf weiteres wird sich 
hier keiner darum kümmern, wie breit die Straßen sind, o.ä. Ein Attribut, 
dass links ein Fahrradweg läuft ist das höchste der Gefühle.



Aber ihr macht ja sowieso was ihr wollt ;-)


Der Preis der Freiheit. In der Diktatur ist vieles einfacher und jeder 
wünscht sich insgeheim eine Diktatur mit sich selbst als Diktator. 
Bewundernswert sind jene, die diesem Drang immer wieder widerstehen 
können.


P.S. Ich bin natürlich für die Diktatur der geodätischen 
Softwareentwickler aus Sachsen, ist doch klar ;-)


Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] right/left

[Bernd Wurst]

Hallo.

Am Freitag, 2. Januar 2009 schrieb Dirk Stöcker:
> > Ich stimme zu, dass das Erfassen dieser Daten lästig ist, aber *haben*
> > würde ich sie schon gern.
> Können wir nicht erstmal versuchen die gleichen Daten wie die Konkurrenz
> zu haben? "Überholen ohne einzuholen" hat schon der DDR nicht gutgetan.
>
> Wenn es sich in 10 Jahren als sinnvoll erweist alles einzeln zu haben,
> dann kann man das left/right automatisch konvertieren. Bis dahin würde ich
> gerne eine in der Gegenwart praktikable Lösung wollen.

Ich bin bisher ganz zufrieden mit dem Ansatz, für alles eine *Möglichkeit* zur 
volständigen Erfassung zu haben und dennoch auch eine Möglichkeit, Dinge 
praktikabel, subjektiv und total trivial zu erfassen.

Siehe tracktypes: Es ist allgemeiner Konsens, dass das System nicht taugt um 
langfristig alle Detail über einen numerischen tracktype auszudrücken. Dennoch 
werden diese tracktypes von gefühlten 99% der Feldweg-Mapper benutzt und die 
genaueren (surface, ...) weitaus weniger. Mit tracktypes kann man momentan 
schon was anfangen.

Gruß, Bernd

-- 
Mitglied des VzVvA - Verein zur Vermeidung von Abkürzungen



signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] right/left

[Bernd Wurst]

Hallo.

Am Freitag, 2. Januar 2009 schrieb Dimitri Junker:
> >Das funktioniert auch noch, wenn der Way in der mitte aufgeteilt wird,
> Nein tut es nicht, es sei denn der Editor macht aus der einen Relation 2
> mit dem Schnittpunkt als neue Anfangs/Endpunkte. Und bei Kreisverkehren
> funktioniert es garnicht, da ist nämlich X=Y.

Also JOSM fragt dann, ob er den einen Weg in der Relation jetzt durch die zwei 
neuen Wege ersetezen soll. Damit wäre dieser Teil schon korrekt, die 
Einbahnstraße geht einfach über beide Wege, immer noch vom Start- zum 
Endpunkt.

Gruß, Bernd

-- 
Windows Error 005: Multitasking attempted. System confused.



signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] right/left

[Bjørn Bürger]

Torsten Leistikow wrote:
> Momentan ist es so, dass man genau an den Beruehrungspunkten von einem
> Weg zu einem anderen wechseln kann. Wie soll das aussehen, wenn jeder
> Buergersteig als eigener Weg erfasst wird? Soll der dann alle 5cm mit
> dem Weg fuer die Fahrbahn verbunden werden, weil ein Fussgaenger ja an
> jeder Stelle die Fahrbahn ueberqueren kann?

Nein, Du markierst ja eine Autobahn auch nicht als Fungängerweg,
weil das theoretisch möglich ist.

Auch Fuß- und Radwege haben baulich definierte Übergangspunkte.
Und die willst Du definitiv haben, da sonst ein vernünftiges Fußgänger- 
und Radrouting immer nur Makulatur bleiben wird.

Ja, das sind eine Menge Daten. Aber wo ist das Problem? Vom jetzigen
OSM Stand haben die "Experten" vor Jahren ja auch behauptet, daß
man sowas niemals als freies Projekt umsetzen könne, weil es zu
viele Daten seien. Wenn inzwischen Strom- und Lichtmasten gemappt
werden, ist der Weg zu Rad- und Fußwegen IMO eh nicht mehr weit.

> b) der Weg "von Punkt x bis Punkt y" im Graphen eindeutig waere. Denn
> woher soll man sonst wissen, welcher Weg von x nach y gemeint ist.
> Leider scheint mir diese Eindeutigkeit im Strassennetz doch gelinde
> gesagt ziemlich unwahrscheinlich.

Ich sehe das Problem nicht.

Nehmen wir eine Straße mit anhängendem Radweg. Die Straße ist zwei mal 
Oneway in entgegengesetzter Richtung, der eine Radweg ist oneway in 
entgegengesetzter Richtung des benachbarten Straßen-Oneway, wird dann
Dualway und der andere Radweg ist für einige hundert Meter Dualway und 
wird dann Oneway in Richtung des angrenzenden Straßen-Oneway. Die 
Radwege sind zum Teil benutzungspflichtig und zum Teil nicht, es gibt
eine Reihe definierter Wechselpunkte, die man kennen sollte. Sowas gibt 
es hier um die Ecke und es läßt sich problemlos mit Frederiks System und 
einzelnen Ways für die jeweiligen Komponenten Abbilden, nicht jedoch mit 
Zusatztags. Wenn wir jemals in die Lage versetzt werden sollen, dafür 
ein vernünftiges Routing zu entwerfen, brauchen wir diese Details.

Bjørn



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

Re: [Talk-de] right/left

[Torsten Leistikow]

Bjørn Bürger schrieb:
>> Soll der dann alle 5cm mit
>> dem Weg fuer die Fahrbahn verbunden werden, weil ein Fussgaenger ja an
>> jeder Stelle die Fahrbahn ueberqueren kann?
> 
> Nein, Du markierst ja eine Autobahn auch nicht als Fungängerweg,
> weil das theoretisch möglich ist.

Ich rede hier nicht vom theoretisch Moeglichem sondern vom praktisch
Passierenden. Abgesehen von stark befahrenen Hauptstrassen ueberqueren
Fussgaenger die Strasse an beliebigen Punkten. Nun mag man sicherlich
argumentieren, dass fuer ein Routing diese Vielfallt nicht noetig ist
und man sich auf eine sinnvolle Auswahl von Uebergangspunkten
beschraenken kann. Aber was waere dann diese sinnvolle Auswahl?
Letztendlich muesste man doch fuer jedes Haus einen Uebergang machen,
genauso wie fuer jede Einfahrt auf der anderen Strassenseite ein
Uebergang notwendig waere, wenn man als Auto dorthin links abbiegen darf.
Das ist theoretisch sicherlich moeglich. Aber der dabei entstehende
Datenhaufen duerfte doch extrem unuebersichtlich und entsprechend
fehleranfaellig sein.


>> b) der Weg "von Punkt x bis Punkt y" im Graphen eindeutig waere. Denn
>> woher soll man sonst wissen, welcher Weg von x nach y gemeint ist.
>> Leider scheint mir diese Eindeutigkeit im Strassennetz doch gelinde
>> gesagt ziemlich unwahrscheinlich.
> 
> Ich sehe das Problem nicht.

Wenn die Relation genau die folgenden Daten enthaellt: Oneway, von Punkt
x, nach Punkt y.

- Dann kann der Weg von x ueber a nach y gemeint sein.
- Es kann ja aber natuerlich auch der Weg von x ueber i, j ,k und l nach
y gemeint sein.
- Oder aber der Weg von x ueber a, b und c nach y. Woher soll die
Relation wissen, ob b und c nachtraeglich in die urspruenglich gemeinte
Strecke eingefuehrt worden sind?

Und wenn man nun fuer die Relation fordert, dass x und y an (genau
einem) gemeinsamen Weg liegen, dann funktioniert das von dir angebrachte
Aufspalten von Oneways auch mit Relationen halt nicht mehr.


Gruss
Torsten

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

Re: [Talk-de] right/left

[André Reichelt]

Bjørn Bürger schrieb:
> Auch Fuß- und Radwege haben baulich definierte Übergangspunkte.
> Und die willst Du definitiv haben, da sonst ein vernünftiges Fußgänger- 
> und Radrouting immer nur Makulatur bleiben wird.

Ich sehe aktuell das Hauptproblem darin, dass wir nicht definieren
können, ob die Wege baulich getrennt sind oder ob man einfach
rüberlaufen kann.



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] right/left

[Dimitri Junker]

Hallo,
>Also JOSM fragt dann, ob er den einen Weg in der Relation jetzt durch
>die zwei neuen Wege ersetezen soll


Wenn ich so für right/left arumentiere kommt regelmäßig ein "es gibt auch 
noch andere Editoren"

Sind wir us einig, daß wenn man einen ganzen Weg zur Einbahnstraße machen 
will beide Lösungen:
1)den gleichen Informationsgehalt haben, beide mit entsprechender 
Untersttzung des Editors kein Problem mit Drehen haben.
2)die Relation aufwändiger ist

Wenn man nur einen Teil eines Weges zur Einbahnstraße machen will könnte man 
mit der Relation das Zerteilen des Weges umgehen. Dies sollte aber nicht auf 
Einbahnstraßen beschränkt sein. Ich habe ja schonmal vorgeschlagen eine 
Relation zu definieren, die Weg, Anfangs und Endpunkt enthält und zusätzlich 
alle Tags akzeptiert die man auch für einen ganzen Weg vergeben könnte. So 
könnte man auch z.B. unterschiedliche Geschwindigkeitsbeschränkungen auf 
einem Teil der Straße, usw eintragen. Aber auch da wäre es sinnvoll angeben 
zu können ob es für beide Seiten/Fahrtrichtungen gilt oder nur für eine. 

Dimitri

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

Re: [Talk-de] right/left

[Dimitri Junker]

Hallo,

>Auch Fuß- und Radwege haben baulich definierte Übergangspunkte.


Ich weiß ja nicht wo Du wohnst, aber in der realen Welt gibt es große 
Straßen mit Ampeln wo man die Straße nur dort überqueren soll, aber kleine 
Straßen haben keine Übergänge, da kann man die Straße also überall 
überquern. Und wenn mir ein Router sagt ich soll an der T-Kreuzung rechts 
abbiegen, bis zur nächsten Kreuzung gehen, dann zurück gehen und stelle dann 
fest, daß das gesuchte Haus fast genau gegenüber der T-Kreuzung war, das ist 
das Müll. Es müßte also auch bei getrennten Wegen entweder jede 
mögliche/erlaubte Wechselmöglichkeit als Querweg eingezeichnet werden, oder 
per Relation gesagt werden, man kann zwischen Spur A und Spur B:
-immer
-etwa alle 10m
-nur an Kreuzungen
-nie
wechseln


>Ja, das sind eine Menge Daten. Aber wo ist das Problem? Vom jetzigen OSM
>Stand haben die "Experten" vor Jahren ja auch behauptet, daß man sowas
>niemals als freies Projekt umsetzen könne, weil es zu viele Daten seien.


Wir haben jetzt in vielen Gebieten einen Stand erreicht wo die Karte schon 
brauchbar ist. Wir sollten also Mappingregeln finden mit denen man einfach 
und schnell die fehlenden Infos hinzufügen können, wenn dann jemand später 
dies nach detailierter machen will soll er es machen, vorausgesetzt die 
Daten werden dadurch nicht unbrauchbar, wir brauchen meiner Meinung nach 
also beides.
Wenn ein Autofahrer sieht, daß neben der langen Straße die er fährt ein 
Fahrradweg verläuft, ist es mir lieber er trägt ihn per cycleway=track ein, 
als er zuckt mit den Schultern und man wartet bis mal jemand wirklich per 
Fahrrad diesen abfährt. Die Info ob da ein Fahrradweg ist ist viel wichtiger 
als die Info ob er 10cm oder 1m neben der Straße verläuft oder auch ob er an 
der Kreuzung einen Schlenker macht. Ohne eine einfache Möglichkeit z.B. 
Fahrradwege zu mappen schrecken wir viele Mapper ab die sich eigentlich 
nicht für Fahrradwege interessieren. Ich mappe hauptsächlich zu Fuß, trage 
dann aber natürlich Auto, Fahrrad und Fußgängerinfos ein. Ich werde aber 
nicht auf der Straße laufen um diese zu vermessen, und wenn ich mal per Auto 
eine Autobahn aufnehme werde ich nicht dauernd auf der linken Fahrbahn 
fahren um diese als getrennten Weg mappen zu können.

>Wenn wir jemals in die Lage versetzt werden sollen, dafür ein
>vernünftiges Routing zu entwerfen, brauchen wir diese Details.


Nochmal. Natürlich gibt es Fälle wo Zusatztags nicht ausreichen, oft reichen 
sie aber oder sind als Zwischenlösung besser als nichts. Nehmen wir hier die 
Triererstraße, dort verläuft ein Fahrradweg auf dem Bürgersteig absolut 
parallel zur Fahrbahn, teils durch einen 1m Grünstreifen getrennt. Aber etwa 
alle 10m ist der Grünstreifen unterbrachen, wegen Garageneinfahrten o.ä. Ein 
cycleway=track würde ein Router so interpretieren, daß man jederzeit 
wechseln kann, was fast stimmt, der jetzt dort vorhandene abgesetzte Weg 
ohne Querverbindungen zwischen den Kreuzungen würde dagegen so 
interpretiert, daß man immer zu nächsten Kreuzung muß um zu wechseln. Das 
ist deutlich ungeauer.

Dimitri

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

Re: [Talk-de] right/left

[Frederik Ramm]

Hallo,

Dimitri Junker wrote:
> Ich weiß ja nicht wo Du wohnst, aber in der realen Welt gibt es große 
> Straßen mit Ampeln wo man die Straße nur dort überqueren soll, aber kleine 
> Straßen haben keine Übergänge, da kann man die Straße also überall 
> überquern. Und wenn mir ein Router sagt ich soll an der T-Kreuzung rechts 
> abbiegen, bis zur nächsten Kreuzung gehen, dann zurück gehen und stelle dann 
> fest, daß das gesuchte Haus fast genau gegenüber der T-Kreuzung war, das ist 
> das Müll. Es müßte also auch bei getrennten Wegen entweder jede 
> mögliche/erlaubte Wechselmöglichkeit als Querweg eingezeichnet werden, oder 
> per Relation gesagt werden, man kann zwischen Spur A und Spur B:

Prinzipiell laesst sich jede Strasse zu Fuss ueberqueren, nur das 
Gesundheitsrisiko dabei ist unterschiedlich.

(Wie ist das rechtlich - ab welcher Strassenklasse/Bauart darf man die 
Fahrban nicht mehr betreten? Oder gibts da eine Gummiregel a la "Verkehr 
nicht gefaehrden" oder so?)

Allerdings waere es gut, wenn wir sowohl ein pragmatisches Routing fuer 
gesunde Buerger im besten Alter anbieten koennen ("folgen Sie der 
Xy-Strasse... gehen Sie links in die Zz-Strasse, und wenn Sie gerade 
dafuer auf der falschen Strassenseite sind, dann gehen sie halt rueber") 
als auch eines, das beispielsweise einen sicheren Schulweg berechnet und 
daher bei allem oberhalb von "residential" die Strasse nur an Ampeln und 
Zebrastreifen quert. (Und bei "residential" ebenso, falls in der Naehe 
eine Ampel ist, diese nutzt...)

Oder sollte man die "Querbarkeit durch Fussgaenger" explizit an eine 
Strasse drantaggen?

In einem Wohngebiet, in dem jede Strasse beliebig gequert werden kann, 
ist es m.E. zudem voellig irrelevant, auf welcher Seite der Strasse sich 
Fusswege befinden. Graphentechnisch gesprochen, wuerde in einem solchen 
Wohngebiet der Fussgaenger-Routing-Graph eine Kante pro Strasse haben; 
sobald es aber zu groesseren Strassen geht, waeren es zwei Kanten pro 
Strasse, eine links, eine rechts. Aeh... eine suedlich, eine noerdlich 
wollte ich sagen ;-)

Bye
Frederik


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

Re: [Talk-de] right/left

[Sven Sommerkamp]

Am Freitag, 2. Januar 2009 15:18:27 schrieb talk-de-requ...@openstreetmap.org:
> Dimitri Junker schrieb:
> > Oder wenn 2 solcher Stra?en verbunden werden.
>
> genau...
> es gibt da kein System das nicht vor ungewollten Ver?nderungen gesch?tzt
> ist. (falls doch sagt es bitte)
>
> desshalb sollten wir uns immer f?r das einfachste entscheiden

Üblicherweise neigen wir dazu, manche Dinge zu verkomplizieren.
Das bisherige System mit den Richtungspfeilen ist sehr einfach zu bedienen.
Hat man im Editor das Anzeigen der Pfeile eingestellt, dann hat man eine 
schnelle optische Kontrolle.
Ich denke so wie es ist, ist es gut!


Gruß Sven S.


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

Re: [Talk-de] right/left

[Sven Sommerkamp]

Sven S.
Messenger: sven...@yahoo.de
   sven1971sommerk...@gizmo5.com
Voip: sip: 17472402163
Am Freitag, 2. Januar 2009 16:45:11 schrieb talk-de-requ...@openstreetmap.org:
> Josias wrote:
> > ich glaube es ist unumstritten, dass wir zeitnah eine M?glichkeit
>
>  > brauchen die eine Seite von der anderen zu unterscheiden,
Rechts ist in Pfeilrichtung rechts, ist doch total simpel.
>
> > wenn wir alles in einen way packen wollen.
>
> Ich denke, der obige Anspruch (alles in einen way packen) beschreibt
> schon das Hauptproblem.
>
> > ansonsten m?ssen wir wieder mit extra ways arbeiten, aber da
>
>  > sprechen auch wieder viele gegen.
>
> Das mag sein. Mittel- bis langfristig werden die extra Ways allerdings
> die Situation wesentlich transparenter darstellen, als eine Rotte von
> extra Attributen an nicht weiter vorhersagbarer Stelle. Zumal sich
> die z.t. komplexen Abbiegebeziehungen an Kreuzungen mit Radweganteil
> ohne extra-ways auch gar nicht vern?nftig darstellen lassen.
Wenn man den komplizierten Abbiegebeziehungen dadurch Rechnung trägt, das man 
sie als komplizierte Extrawege anlegt, wird derjenige der die 
Routenanweisungen (oder Karte) deuten soll überfordert.
Dann schau ich als Radfahrer nur noch auf Display, statt auf die Straße.
Das ist nicht sinnvoll.
Ich hab das schon durchprobiert.
Radwege haben sehr viele sehr komplizierte Wegebziehungen, gängige Navis sind 
mit solchen Sachen schnell überfordert und brechen ab (Garmingeräte bspw.) 
>
> Es w?re besser, den Editoren eine vern?nftige Gruppierung von
> Wegseqmenten (meinetwegen intern abgebildet als Relation) und die
> entsprechende Darstellung analog zu einem aktuellen DTP- oder CAD-
> Programm beizubringen, als immer mehr Spezialtags auszudenken, mit
> denen sich die Realit?t am Ende doch nicht vern?nftig darstellen l??t
> und die zudem viel zu schnell verloren gehen k?nnen.
>
> > anstatt immer nur Argumente zu bringen warum etwas nicht gut ist,
>
>  > sollte man lieber einen Vorschlag bringen wie es besser zu machen
>  > ist.
Es wurden doch in den vergangenen Tagen gute Ideen zu Tage gefördert.
Es wird durchaus nicht nur gegen Argumentiert, was tatsächlich zu einfach 
wäre.
>
> - Jedes Element mit besonderen Eigenschaften wird mit einem eigenen
>    Objekt in der Datenbank verewigt
>
> - ?ber eine Group-Relation werden die zueinander geh?renden
>    Objekte geb?ndelt. Ob diese Relation nur eine abstrakte Gruppe
>    oder tats?chlich ein vorhandenes Feature (Bundesstra?e XY)
>    beschreibt, ist erstmal irrelevant.
>
> - Damit die ?bersicht beim editieren nicht verloren geht,
>    sollten alle Editoren einen vern?nftigen Group-Support
>    bekommen: Beim betreten einer Gruppe/Relation wird alles
>    andere ausgeblendet, nur noch die einzelnen Elemente
>    sind editierbar.
Das Handling mit Relationen müßte wirklich besser werden, ich komm ganz 
ehrlich nicht damit klar.
Ich stelle mir vor das man das vielleicht in die Voreinstellungen integrieren 
könnte.
Würde das Ganze erheblich vereinfachen.
>
> - Was die jammernden Autofahrer betrifft, die z.B. extra
>    Ways f?r Radwege ablehnen, weil das die "sch?nen Autokarten
>    verunstaltet"?: Das ist eine Sache, die sich schnell
>    ?ber die Renderer (und nur dort) l?sen lassen sollte.
Dazu muß ich mich als Radfahrer mal melden.
Ich jammere über Extrawege die unnötig sind, die Gründe hab ich mehrfach 
geschildert.
Das ist kein Autofahrer-->Radfahrer Problem.
Und genau, es ließe sich bestimmt einfacher schön rendern, wenn die 
entsprechende Information als Tags an den Weg gehängt wird.
Es gab dazu vielversprechende Ansätze in den letzten Tagen...
>
> > dass manche diese rechts links Unterscheidung nicht brauchen
>
>  > ist kein Argument, sich keine Gedanken drum zu machen.
>
> Meiner Meinung nach werden rechts/links Unterscheidungen durchaus
> gebraucht, sie als richtungsabh?ngige Extratags statt als eigene
> Ways zu realisieren ist jedoch IMO fahrl??iger Unsinn und wird
> unweigerlich zu unn?tigem Datenverlust f?hren. Schon die jetzige
> Oneway L?sung ist haarstr?ubend.
>
> Just my 2?.
>
> Bj?rn
>
> ?) Begr?ndung des Users, der vor einiger Zeit mal in Braunschweig
>     einige Kilometer stra?enbegleitenden Radweg gel?scht hat.

Gruß Sven S.



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

Re: [Talk-de] right/left

[Mario Salvini]

André Reichelt schrieb:
> Bjørn Bürger schrieb:
>   
>> Auch Fuß- und Radwege haben baulich definierte Übergangspunkte.
>> Und die willst Du definitiv haben, da sonst ein vernünftiges Fußgänger- 
>> und Radrouting immer nur Makulatur bleiben wird.
>> 
>
> Ich sehe aktuell das Hauptproblem darin, dass wir nicht definieren
> können, ob die Wege baulich getrennt sind oder ob man einfach
> rüberlaufen kann.
>   
mit lane-Relations könnte man dieses Problem sauber lösen.

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

Re: [Talk-de] right/left

[Sven Sommerkamp]

> Hallo,
>
> >Auch Fu?- und Radwege haben baulich definierte ?bergangspunkte.
>
> Ich wei? ja nicht wo Du wohnst, aber in der realen Welt gibt es gro?e
> Stra?en mit Ampeln wo man die Stra?e nur dort ?berqueren soll, aber kleine
> Stra?en haben keine ?berg?nge, da kann man die Stra?e also ?berall
> ?berquern. Und wenn mir ein Router sagt ich soll an der T-Kreuzung rechts
> abbiegen, bis zur n?chsten Kreuzung gehen, dann zur?ck gehen und stelle
> dann fest, da? das gesuchte Haus fast genau gegen?ber der T-Kreuzung war,
> das ist das M?ll. Es m??te also auch bei getrennten Wegen entweder jede
> m?gliche/erlaubte Wechselm?glichkeit als Querweg eingezeichnet werden, oder
> per Relation gesagt werden, man kann zwischen Spur A und Spur B:
> -immer
> -etwa alle 10m
> -nur an Kreuzungen
> -nie
> wechseln
>
> >Ja, das sind eine Menge Daten. Aber wo ist das Problem? Vom jetzigen OSM
> >Stand haben die "Experten" vor Jahren ja auch behauptet, da? man sowas
> >niemals als freies Projekt umsetzen k?nne, weil es zu viele Daten seien.
>
> Wir haben jetzt in vielen Gebieten einen Stand erreicht wo die Karte schon
> brauchbar ist. Wir sollten also Mappingregeln finden mit denen man einfach
> und schnell die fehlenden Infos hinzuf?gen k?nnen, wenn dann jemand sp?ter
> dies nach detailierter machen will soll er es machen, vorausgesetzt die
> Daten werden dadurch nicht unbrauchbar, wir brauchen meiner Meinung nach
> also beides.
> Wenn ein Autofahrer sieht, da? neben der langen Stra?e die er f?hrt ein
> Fahrradweg verl?uft, ist es mir lieber er tr?gt ihn per cycleway=track ein,
> als er zuckt mit den Schultern und man wartet bis mal jemand wirklich per
> Fahrrad diesen abf?hrt. Die Info ob da ein Fahrradweg ist ist viel
> wichtiger als die Info ob er 10cm oder 1m neben der Stra?e verl?uft oder
> auch ob er an der Kreuzung einen Schlenker macht.
Letztlich ist meistens nur diese Info von Wichtigkeit und vielleicht noch der 
Zustand.
> Ohne eine einfache 
> M?glichkeit z.B. Fahrradwege zu mappen schrecken wir viele Mapper ab die
> sich eigentlich nicht f?r Fahrradwege interessieren.
Eben.
Sogar die die Radfahren, wie ich.
> Ich mappe 
> haupts?chlich zu Fu?, trage dann aber nat?rlich Auto, Fahrrad und
> Fu?g?ngerinfos ein. Ich werde aber nicht auf der Stra?e laufen um diese zu
> vermessen, und wenn ich mal per Auto eine Autobahn aufnehme werde ich nicht
> dauernd auf der linken Fahrbahn fahren um diese als getrennten Weg mappen
> zu k?nnen.
>
> >Wenn wir jemals in die Lage versetzt werden sollen, daf?r ein
> >vern?nftiges Routing zu entwerfen, brauchen wir diese Details.
Vernünftiges Routing funktioniert nur nach dem weniger ist mehr Prinzip.
Ob ich eine Straße überqueren kann um auf der anderen Seite wieder zurück zu 
fahren oder zu laufen, wird jeder anders beurteilen!
Also lassen wir es doch in der Entscheidungskompetenz des Einzelnen.
>
> Nochmal. Nat?rlich gibt es F?lle wo Zusatztags nicht ausreichen, oft
> reichen sie aber oder sind als Zwischenl?sung besser als nichts. Nehmen wir
> hier die Triererstra?e, dort verl?uft ein Fahrradweg auf dem B?rgersteig
> absolut parallel zur Fahrbahn, teils durch einen 1m Gr?nstreifen getrennt.
> Aber etwa alle 10m ist der Gr?nstreifen unterbrachen, wegen
> Garageneinfahrten o.?. Ein cycleway=track w?rde ein Router so
> interpretieren, da? man jederzeit wechseln kann, was fast stimmt, der jetzt
> dort vorhandene abgesetzte Weg ohne Querverbindungen zwischen den
> Kreuzungen w?rde dagegen so
> interpretiert, da? man immer zu n?chsten Kreuzung mu? um zu wechseln. Das
> ist deutlich ungeauer.
>
> Dimitri

Gruß Sven S.


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