Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 01.08.2010 um 20:57 schrieb Guenther Meyer: >> Es bleibt also dabei: es hängt am User. Und diese menschliche >> Fehlerquelle kann man IMHO nur durch einen eigenen way minimieren. > > den Menschen kannst du gar nicht eliminieren, weil der der einzige ist, der > weiss, wa wohin gehoert. Der Editor ist der, der ihm das Eingeben seines > Wissens so einfach machen muss wie moeglich. jetzt gebe ich diesen Zweig der Diskussion auf. Du willst mich missverstehen? Nein, aber wir kommen auch nicht weiter. Wir drehen uns im Kreis. Aber Dein Vorschlag mit der grafischen Umsetzung des Taggings ist dennoch eine gute Möglichkeit, wie ich finde, die mein Modell unnötig machen würde. Das fände ich ja auch gut. Bringe es zu einem Proposal und ich werde dafür stimmen. Bis dann, hole Dir ein paar Entwickler ins Boot und ich wünsche Dir viel Erfolg beim Erstellen des Proposal. Das meine ich ernst. Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 31.07.2010 um 21:39 schrieb Tobias Knerr: > Am 27.07.2010 17:56, schrieb steffterra: >> >> Am 27.07.2010 um 15:09 schrieb Tobias Knerr: >>> Daher eine prinzipielle Frage: Repräsentiert ein Way in deinem Modell >>> * eine Fahrtrichtung >>> oder >>> * eine Fahrspur bzw. Gruppe von Fahrspuren >> >> Das Modell kann beides. > > Diese Eigenschaft macht es m.E. etwas verwirrend. "Ein zusätzlicher Way > repräsentiert eine Fahrspur" wäre beispielsweise deutlich einfacher zu > erklären (und im Editor darzustellen) als ein "kommt darauf an". Aus dem Zusammenhang heraus gesehen stimme ich Dir zu. Doch wenn man es aus sicht des Bedarf siehst: Wenn man richtungsabhängige Tags nicht nötig wären auf _einem_ way, wozu dann Fahrspuren für jede Richtung erstellen? Einfache Logik, oder? Ebenso grundsätzlich zur Fahrspur. Wenn die Fahrspuren sich nicht unterscheiden, wozu diese dann zeichnen, wenn ein lanes=2 es auch tun würde? Auch einfache Logik, oder? > Diese Beurteilung meinerseits liegt natürlich auch daran, dass ich > bekanntlich :forward/:backward nicht als echtes Problem sehe, so dass > die Fahrspurdarstellung aus meiner Sicht der einzige gute Grund für die > Einführung eines Linienbündel-Modells ist. ;) Sehr gute Selbsteinschätzung :-) >> Beispiel 1: in der "Wirklichkeit" sieht unsere Beispielstraße so aus: ganz >> normale Straße mit zwei Fahrspuren (pro Richtung eine Fahrspur) ohne >> Unterschiede, egal aus welcher Richtung man kommt. >> Geschwindigkeitsbegrenzung: 50km/h. >> [...] >> Beispiel 2: die gleiche Straße bekommt eine Geschwindigkeitsbeschränkung von >> 60 km/hverpasst, die nur in einer Richtung (z.B. in Richtung Süden) gilt. >> Eingezeichnet ist der way in JOSM von Nord nach Süd. Ausserdem werden >> Schilder für die Fahrrichtung aufgestellt, da es eine neuralgische >> Verbindugnsstraße wird. Die Süd->Nord-Richtung führt nach Hamburg, die >> Nord-Süd-Richtung nach München und ist auch so ausgeschildert (Es ist ein >> Beispiel ;-) >> [...] >> -way (Nord->Süd): maxspeed=60, destination=München >> -daten-way: highway=secondary, name=Beispielstraße >> -way (Süd-Nord): maxspeed=50, destination=Hamburg > > Beispiel 2a: > > Dasselbe, aber die Straße hat keine getrennten Fahrspuren - ist also > einspurig. Wird das dennoch mit zwei Zusatzways dargestellt? Wie jetzt - eine Spur? Dann muss es ja eine Einbahnstraße sein, oder meinst Du jetzt einen Feldweg? Ich bitte doch davon abzusehen, richtungsabhängige Tags an Feldwegen zu plazieren. Scherz beiseite. Aus Spaß wurde Ernst: Welche Straßentypen meist du - Wo hat man denn nur eine Fahrspur, auf der es Gegenverkehr gibt, die gleichzeitig richtungsabhängige Tags benötigt? Welche richtungsabhängigen Tags wären dass beispielsweise? Bitte beachte, dass nicht jede Straße, die _keine_ Mitellinien-Strichelchen besitzt automatisch "einspurig" ist. Darauf können selbstverständlich 2 Fahrzeuge, die sich entgegenkommen nebeneinander fahren, ohne dass einer davon zur Hälfte in den Graben ausweichen muss. Und selbst wenn so eine Straße dann von einem Radweg auf einer Seite begleitet wird, dann ist dieser baulich getrennt, weil sonst dies immer als Ausweichmöglichkeit bei Gegenverkehr genutzt würde Ich bin gespannt auf Dein Beispiel. >> Beispiel 3: die gleiche Straße wird um eine Fahrspur in Richtung >> Norden->Süden erweitert, auf der anderen Seite jedoch nicht >> [...] >> Beispiel 4: die gleiche Straße bekommt auf der äußersten Fahrspur der >> Richtung Nord->Süd zusätzlich zur Fahrspur aus Beispiel 3 noch einen Radweg >> verpasst, weil diese Straßenseite so gefährlich wurde. >> [...] >> -> in meinem Modell: >> >> -way (außen eingezeichnet Nord->Süd): maxspeed=60, destination=München, >> cycleway=lane, bicycle=designated >> -way (innen eingezeichnet Nord->Süd): maxspeed=60, destination=München >> -daten-way: highway=secondary, name=Beispielstraße >> -way (Süd->Nord): maxspeed=50 > > Beispiel 4a: > > Nehmen wir weiter an, die äußere Fahrspur Nord->Süd ist 3m breit, der > Radweg daneben 1,5m. Außerdem möchte ich die Oberfläche des Radwegs per > surface/smoothness-Tags beschreiben. Wie werden diese diese > Informationen ergänzt? So, wie man es an _einem_ way auch machen würde. Nur dass Du das _jedesmal_ dann nötige :forward weglassen kannst, weil ja schon klar ist, auf welchem Richtungsway Du das taggst. > Beispiel 4b: > > Nehmen wir an, es gibt einen Parkstreifen zwischen dem Radweg und der > Fahrbahn. Wie sieht die entsprechende Ergänzung aus? Du meinst nicht Fahrbahn, sondern Fahrspur. Denn die Fahrbahn ist das ganze, sofern keine bauliche Trennung zwischen der Radfahrspur, dem Parkstreifen oder ähnlichem vorliegt. Also kommt es darauf an, ob eine bauliche Trennung (z.b. durch Bäume zwischen den Parkständen) vorliegt oder nicht. _Wenn bauliche Trennung_ , ist es klar, wie bisher auch: dann hat der Radweg eine eigenen way "verdient" und dessen tags dran, parking:lane an den Richtungsway. Doch dann darf der Radweg nic
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 27.07.2010 17:56, schrieb steffterra: > > Am 27.07.2010 um 15:09 schrieb Tobias Knerr: >> Daher eine prinzipielle Frage: Repräsentiert ein Way in deinem Modell >> * eine Fahrtrichtung >> oder >> * eine Fahrspur bzw. Gruppe von Fahrspuren > > Das Modell kann beides. Diese Eigenschaft macht es m.E. etwas verwirrend. "Ein zusätzlicher Way repräsentiert eine Fahrspur" wäre beispielsweise deutlich einfacher zu erklären (und im Editor darzustellen) als ein "kommt darauf an". Diese Beurteilung meinerseits liegt natürlich auch daran, dass ich bekanntlich :forward/:backward nicht als echtes Problem sehe, so dass die Fahrspurdarstellung aus meiner Sicht der einzige gute Grund für die Einführung eines Linienbündel-Modells ist. ;) Aber ich wollte ja eigentlich auf einige Detailfragen zu deinem Modell zu sprechen kommen. Ich habe im Folgenden mal diejenigen Beispiele herausgegriffen, bei denen eine leichte Änderung am Szenario besser klar macht, worauf ich hinaus will. > Beispiel 1: in der "Wirklichkeit" sieht unsere Beispielstraße so aus: ganz > normale Straße mit zwei Fahrspuren (pro Richtung eine Fahrspur) ohne > Unterschiede, egal aus welcher Richtung man kommt. > Geschwindigkeitsbegrenzung: 50km/h. > [...] > Beispiel 2: die gleiche Straße bekommt eine Geschwindigkeitsbeschränkung von > 60 km/hverpasst, die nur in einer Richtung (z.B. in Richtung Süden) gilt. > Eingezeichnet ist der way in JOSM von Nord nach Süd. Ausserdem werden > Schilder für die Fahrrichtung aufgestellt, da es eine neuralgische > Verbindugnsstraße wird. Die Süd->Nord-Richtung führt nach Hamburg, die > Nord-Süd-Richtung nach München und ist auch so ausgeschildert (Es ist ein > Beispiel ;-) > [...] > -way (Nord->Süd): maxspeed=60, destination=München > -daten-way: highway=secondary, name=Beispielstraße > -way (Süd-Nord): maxspeed=50, destination=Hamburg Beispiel 2a: Dasselbe, aber die Straße hat keine getrennten Fahrspuren - ist also einspurig. Wird das dennoch mit zwei Zusatzways dargestellt? > Beispiel 3: die gleiche Straße wird um eine Fahrspur in Richtung > Norden->Süden erweitert, auf der anderen Seite jedoch nicht > [...] > Beispiel 4: die gleiche Straße bekommt auf der äußersten Fahrspur der > Richtung Nord->Süd zusätzlich zur Fahrspur aus Beispiel 3 noch einen Radweg > verpasst, weil diese Straßenseite so gefährlich wurde. > [...] > -> in meinem Modell: > > -way (außen eingezeichnet Nord->Süd): maxspeed=60, destination=München, > cycleway=lane, bicycle=designated > -way (innen eingezeichnet Nord->Süd): maxspeed=60, destination=München > -daten-way: highway=secondary, name=Beispielstraße > -way (Süd->Nord): maxspeed=50 Beispiel 4a: Nehmen wir weiter an, die äußere Fahrspur Nord->Süd ist 3m breit, der Radweg daneben 1,5m. Außerdem möchte ich die Oberfläche des Radwegs per surface/smoothness-Tags beschreiben. Wie werden diese diese Informationen ergänzt? Beispiel 4b: Nehmen wir an, es gibt einen Parkstreifen zwischen dem Radweg und der Fahrbahn. Wie sieht die entsprechende Ergänzung aus? Beispiel 4c: Anders als bei 4b ist der Radweg jetzt zwischen der Fahrbahn und dem Parkstreifen. Wie unterscheidet sich dieser Fall vom Tagging zu 4b? Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 29.07.2010 um 23:15 schrieb Guenther Meyer: > Am Mittwoch 28 Juli 2010, 15:23:35 schrieb steffterra: >> Am 28.07.2010 um 08:05 schrieb Guenther Meyer : >>> ich weiss nicht, ob ich's sschon mal erwaehnt hatte, aber fuer >>> Fahrspurtagging >>> gab's schon mal ein Konzept, dass ohne separate ways auskommt... >>> Das ist also nichts neues. >> >> Die seperaten ways helfen hier aber auch bei dem Problem der >> richtungsanhängigen ways und eben nicht nur bei der Abbildung von >> Fahrspuren! >> >> Aber da Du es erwähnst: hättest Fu bitte einen Link für uns? Danke. >> > > nagel mich nicht drauf fest, aber ich glaub das war das hier: > http://www.mail-archive.com/talk-de@openstreetmap.org/msg59559.html Nunja. da gehts ja um die aktuell etablierten Autobahnspuren, die bei jeder baulichen Trennung ja auch so gezeichnet werden sollten. Oder habe ich etwas übersehen? >> Das mag für Dich gelten, ich kenne hier aber keine Diskussion des >> letzten Monats, das es zu irgendeinem Konsens brachte. > an das wirst du dich bei OSM gewoehnen muessen ;-) Nein das meinte ich nicht. Iss schon klar ;-) Ich hatte aus Deinen Worten gelesen, dass alles geklärt sei und dass das tagging, wie es ist doch ausreicht. >> Zumal das Thema ja immer wieder aufs neue aufs Tapet gebracht wird ;-) >> >> Du meinst es gibt kein Problem mit richtungsanhängigen tags, andere >> denken schon. Aus diesem Grund entstand mein Engagement für dieses >> Thema mit der Gruppierung von ways wie im Eingangsposting ausführlich >> geschildert. >> > > Fuer mich ist das Problem hausgemacht. Hat aber auch wieder mal mit > "gewachsener Struktur" zu tun: Nunja, Du klangst schon, als ob es kein Problem gäbe, oder schlimmer, dass der Karren so festgefahren ist, dass sich das für Dich somit erledigt hat und das aktuelle Tagging in Deinen Augen ausreichen _muss_. > wenn es nur darum geht, das "Richtungsproblem" zu loesen, finde ich deinen > Vorschlag absoluten Overkill. Nein ich führe ja auch andere Vorteile auf, wie z.b. die Möglichkeit der Fahrspuren-Nutzuzng für Navis, exaktere Abbildung von komplizierten Kreuzungen, etc. > Nichtsdestotrotz ist es ein interessantes Konzept, das denke ich, mehr > bringen > kann als die Losloesung von der Richtung. Das sehe ich auch so. Danke. >> Wenn Du diese Diskussion positiv beeinflussen möchtest, bitte ich >> Dich, etwas konstruktiv dazu beizutragen, anstatt hier groß zu >> erklären, dass doch alles in Butter ist. Mache bitte gerne >> _diskussionslos_ so weiter wie bisher, denn im Moment gibt es eh keine >> andere Möglichkeit. >> >> Aber bitte demotiviere nicht andere, neue, evtl. bessere >> Lösungsansätze zu verfolgen. >> > Dann hast du mich vielleicht falsch verstanden. Leute demotivieren ist das > letzte was ich vorhabe. Nur bin ich auch so realistisch, dass ich weiss, > dass es nicht so einfach ist, technisch durchdachte Dinge und vor allem > Veraenderungen dem OSM-Volk nahezubringen. Das beste Konzept nutzt nunmal > nichts, wenn es keiner benutzt... Aber dann unterstütze nicht indirekt das den derzeit festgefahrenen Karren ;-) Indem Du sagts, dass man die wayrichtung in ruhe lassen sollte, udn dann gehe das tagging schon klar. Ich denke vielmehr, dass egal sein sollte, die Wayrichtung zu ändern. Und das wäre es bei meinem Modell. > Ich habe uebrigens nie behauptet, das alles in Butter ist. Ganz im Gegenteil, > bei OSM gibt es jede Menge an Dingen, die verbessert werden koennten und auch > muessten. Nur ist mein Weg eher der, auf Basis des vorhandenen die einfachste > Loesung zu finden. Und ich denke, die gibt es fuer viele Dinge durchaus. Das finde ich auch, wenn das denn möglich ist. Wenn jetzt jemand ein völlig anderes Konzept hätte, das Relationen/Gruppierung oder ähnliches und gleichzeitig die richtungsabhängigen tags unnötig machen würde, wäre ich der erste, der es unterstützt und sein eigenes Modell fallen lässt. >>> Auch wenn du es Gruppe nennst, ist es nichts anderes als eine einfache >>> Relation. Die automatische Erstellung durch den Editor aendert daran >>> genau >>> nichts. >> >> Woher weißt Du dass es nichts anderes ist? Wäre das technisch die >> Lösung, das gewollte so umzusetzen? >> > > Irgendwie musst du die Gruppierung ja in der Datenbank speichern. > Das naheliegendste ist da natuerlich eine einfache Relation. > Eine andere Moeglichkeit waere, die Information an den mittleren Weg zu > taggen > (wahrscheinlich sogar die bessere). ich dachte an eine ID die durch einen einfachen Algorithmus aus den beteiligten ways automatisch errechnet wird. Ist das bei Relationen genauso? >> Dann mache doch mal einen Vorschlag, wie das auch für Spezialfälle >> _dieses Modells_ incl. der Möglichkeit des Fahrspurtaggings (wo nötig/ >> sinnvoll), die dieses Model bietet. >> > > wie jetzt, dein Modell? Ja meines. Wie wäre mein Modell mit Relationen für alle angesprochenen Spezialfälle umsetzbar? > da warte ich noch auf dein versprochenes Beispiel (realisiert z.B. mit josm)
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 28.07.2010 um 16:38 schrieb Simon Kokolakis: > Am 25.07.2010 20:43, schrieb steffterra: > >> - Manche versuchen das Problem zu umgehen, indem sie zwei ways für jede >> Fahrrichtung zeichnen, was aber nur bei baulicher Trennung korrekt wäre, und >> deshalb falsch ist. > > Das kommt auf die Interpretation des Objektes "way" an. Daran scheitern sich die Geister. Es scheint aber einen weltweiten Konsens darüber zu geben, dass ein way in osm eine Straße repräsentiert und eben nicht eine Fahrspur. Das ist sicher geschichtlich zu sehen, daß man froh war, dass überhaupt eine Straße eingezeichnet wurde. Daß das immer noch so gesehen wird, konnte ich in vielen persönlichen Gesprächen in unserer lokalen OSM-Gruppe und auch hier recherchieren. Hauptgrund dafür ist die visuelle Wahrnehmung des Objekts im Editor. Gestützt wird diese These auch dadurch, dass viele meinen, dass es völig ausreichend ist, alles mit tags und Relationen an _einem_ way abzubilden. > Warum ist es falsch die einzelnen Elemente einer Straße als eigene > oneways darszustellen? Ich erweitere obige Begründung mit dem (für mich am verständlichsten) Argument der "baulichen Trennung". Im Wik ist z.B. definiert, dass bei baulicher Trennung der Fahrspuren einer Straße auch je ein way pro Fahrtrichtung gezeichnet werden _muß_. Das heisst im Umkehrschluss: Ohne bauliche Trennung: ein way. Die baulichte Trennung teilt beide Fahrrichtungen so vn einander, dass man die Trennung in der Wirklichkeit auch sehen kann, da es nicht eine durchgehende Fahrbahndecke ist, sondern ein Grünstreifen oder andere bauliche Maßnahmen vorhanden sind. Da diese Trennung der Fahrbahnen auch Verkehrsregelungen automatisch nach sich zieht (man darf und kann halt nicht mehr wenden, etc.). Wenn man nun Deiner Meinung nach grundsätzlich zwei ways zeichnen würde, dann impliziert das nicht nur die optische Wahrnehmung der baulichen Trennung, sondern erstellt nebenbei auch die Verkehrsregeln, wie wenn baulich getrennt wäre, dem aber nicht so ist, da durchgehende Fahrbahndecke. Die Folge ist, dass bei Abzweigungen und ähnlichem künstliche Verbindungen zwischen beiden Fahrspuren geschaffen werden müssten, die in der Realität so gar nicht vorhanden sind. Deshalb ein way für eine geschlossene Fahrbahndecke. Da es auch selten bauliche Trennungen zu Gehwegen und Radwegen gibt, wird hier ebenso verfahren: alles wird an dem einen way getaggt, ausser es ist ein Grünstreifen zwischen der Straße und dem Gehweg. Dann kann der Gehweg auch einzeln eingezeichnet und entsprechend getaggt werden. > Im Prinzip ist dein vorgeschlagenes Modell ja nichts anderes als eine > Gruppierung von einzelnen (one)ways.. Deshalb heisst mein Vorschlag ja auch so. Um aber deutlich zu machen, dass es eben keine bauliche Trennung gibt, sollte alles nicht zu per Relation oder wie auch immer in einer Gruppe zusammengefasst werden, sondern dies auch visuell im Editor für die optische Wahrnehmung mit einer gemeinsamen Hintergrundfarbe kenntlich gemacht werden. Zudem ist auch im Modell enthalten, dass zunächst immer nur der datenway sichtbar ist, da auf ihm auch die richtungsunabhängigen Tags wie die der Straßenart und des Namens liegen, was die Straße eindeutig identifiziert. Erst wenn man auf den datenway klickt "gehen die anderen ways/Fahrspuren auf" und man kann detaillierter bis zur Fahrspur wenn nötig fein säuberlich getrennt taggen und ist dabei völlig flexibel, da so auf einfache Weise alles abgebildet werden kann, was nötig ist. Der Editor und später auch der Renderer tragen jedoch maßgeblich dazu bei, dass eine Gruppe von ways als eine Straße und nicht als mehrere verschiedene Parallelstraßen interpretiert wird. > Gegenvorschlag: > > Einzeichnen aller Straßenuntereinheiten (Fahrbahn, Fahrspur, > Fahrradspur, Parkplätze, je nach dem wie detailliert man es will) als > oneways. Wenn man unbedingt mitgeben will dass diese Elemente > zusammengehören und eine (baulich ungetrennte) Straße darstellen dann > gruppiert man sie in einer Relation. associatedStreet wäre da eine > Möglichkeit. kann es sein, dass Du damit das Proposal der Linienbündel wiedergibst? Während dieses Threads bin ich mehrfach auf die Unterschiede meines Gruppierungs-Modells zum Linienbündel-Modell eingegangen, denn es hat auch Gründe, warum sich dieses nicht durchgesetzt hat. Und dass sind nicht der Editor und der Rednerer alleine. Danke für Dein Feedback, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 25.07.2010 20:43, schrieb steffterra: > - Manche versuchen das Problem zu umgehen, indem sie zwei ways für jede > Fahrrichtung zeichnen, was aber nur bei baulicher Trennung korrekt wäre, und > deshalb falsch ist. Das kommt auf die Interpretation des Objektes "way" an. Warum ist es falsch die einzelnen Elemente einer Straße als eigene oneways darszustellen? Im Prinzip ist dein vorgeschlagenes Modell ja nichts anderes als eine Gruppierung von einzelnen (one)ways. Gegenvorschlag: Einzeichnen aller Straßenuntereinheiten (Fahrbahn, Fahrspur, Fahrradspur, Parkplätze, je nach dem wie detailliert man es will) als oneways. Wenn man unbedingt mitgeben will dass diese Elemente zusammengehören und eine (baulich ungetrennte) Straße darstellen dann gruppiert man sie in einer Relation. associatedStreet wäre da eine Möglichkeit. Beste Grüße, Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 27.07.2010 um 15:09 schrieb Tobias Knerr: > Du sprichst in deinem Vorschlag mehrfach sowohl von Fahrtrichtungen als > auch von Fahrspuren. Das sind aber zwei verschiedene Dinge. richtig. Über welche Stellen stolperst Du denn, wo die Verwendung der beiden Begriffe nicht ganz klar ist? > Daher eine prinzipielle Frage: Repräsentiert ein Way in deinem Modell > * eine Fahrtrichtung > oder > * eine Fahrspur bzw. Gruppe von Fahrspuren Das Modell kann beides. Wie man es jeweils einsetzt ist eine Frage dessen, wie man am effektivsten die Wirklichkeit abbilden kann und gleichzeitig bietet es die nötige Flexibilität, falls mehr Detailtiefe nötig ist. Derzeit repräsentiert ein way in JOSM eine ganze Straße, mit Gehweg, Radweg, parking:lanes und allem, was dazu gehört und es wird alles auf diesem einen way getaggt. In meinem Modell repräsentiert ein gezeichneter way nicht mehr unbedingt die gesamte Straße. Welche "Zustände" ein JOSM-way in meinem Modell bekommen kann, hängt vom Tagging ab, das an dieser Straße nötig wäre. Beispiel 1: in der "Wirklichkeit" sieht unsere Beispielstraße so aus: ganz normale Straße mit zwei Fahrspuren (pro Richtung eine Fahrspur) ohne Unterschiede, egal aus welcher Richtung man kommt. Geschwindigkeitsbegrenzung: 50km/h. -> bisheriges Tagging auf einem way mit: highway=secondary name=Beispielstraße maxspeed=50 -> in meinem Modell: wie bisher auch, da keine richtungsabhängigen Tags vorhanden sind. Beispiel 2: die gleiche Straße bekommt eine Geschwindigkeitsbeschränkung von 60 km/hverpasst, die nur in einer Richtung (z.B. in Richtung Süden) gilt. Eingezeichnet ist der way in JOSM von Nord nach Süd. Ausserdem werden Schilder für die Fahrrichtung aufgestellt, da es eine neuralgische Verbindugnsstraße wird. Die Süd->Nord-Richtung führt nach Hamburg, die Nord-Süd-Richtung nach München und ist auch so ausgeschildert (Es ist ein Beispiel ;-) Also würde man den maxspeed-Tag ändern müssen: -> bisher: highway=secondary name=Beispielstraße maxspeed:forward=60 maxspeed:backward=50 destination:forward=München destination:backward=Hamburg (bekanntes Problem bei way-Richtungsänderung, wurde ausführlich diskutiert, deshalb mein neues Modell) -> in meinem Modell: zeichnen zwei zusätzlicher ways parallel zum bisherigen. Der mittlere way wird zum daten-way, der den highway- und name-Tag bekommt, wird aber als reiner daten-way nicht mehr gerendert. Die beiden anderen ways repräsentieren die Fahrtrichtungen. Für jede Fahrtrichtung ein way. Der way, der von Nord nach Süd geht bekommt maxspeed=60, der von Süd nach Nord geht bekommt maxspeed=50. (Beide ways werden gerendert. (Probleme, die sich daraus ergeben könnten habe ich bereits angesprochen) In JOSM werden alle drei ways zu einer Gruppe zusammengefasst und mit einer Farbe hinterlegt, dass dies auch optisch für die Wahrnehmung eine Straße bleibt. Wie das im Einzelnen gehen könnte, habe ich im Startposting beschrieben.) Es würde also so getaggt werden: -way (Nord->Süd): maxspeed=60, destination=München -daten-way: highway=secondary, name=Beispielstraße -way (Süd-Nord): maxspeed=50, destination=Hamburg - Beispiel 3: die gleiche Straße wird um eine Fahrspur in Richtung Norden->Süden erweitert, auf der anderen Seite jedoch nicht -> bisher: zusätzlicher tag: lanes=3 (bezieht sich auf alle drei Fahrspuren der Straße, egal welche Richtung), zusätzlich erinnern wir uns, dass maxspeed:forward:60 und maxspeed:backward:50 getagt ist. highway=secondary name=Beispielstraße maxspeed:forward=60 maxspeed:backward=50 destination:forward=München destination:backward=Hamburg lanes=3 (oder auch lanes:forward=2, lanes:backward=1) -> in meinem Modell: way, der von Nord nach Süd geht bekommt den tag: lanes=2 ERGO: es sind immernoch 3 ways (zwei richtungs-ways und ein daten-way) in der Gruppe. Da lanes=2 ausreichend beschreibt, dass dieser way zwei Fahrspuren breit ist. Der Renderer _kann_ das also nutzen um diese Straßenseite doppelt so breit zu zeichnen, ohne dass ich dazu einen weiteren way einzeichnen müsste in meinem Modell. Es würde also getaggt werden: -way (Nord->Süd): maxspeed=60, lanes=2, destination=München -daten-way: highway=secondary, name=Beispielstraße -way (Süd->Nord): maxspeed=50, destination=Hamburg Beispiel 4: die gleiche Straße bekommt auf der äußersten Fahrspur der Richtung Nord->Süd zusätzlich zur Fahrspur aus Beispiel 3 noch einen Radweg verpasst, weil diese Straßenseite so gefährlich wurde. -> bisher sieht das vollständige tagging des way so aus: highway=secondary name=Beispielstraße maxspeed:forward=60 maxspeed:backward=50 destination:forward=München destination:backward=Hamburg lanes=3 (oder auch lanes:forward=2, lanes:backward=1) cycleway:right=lane bicycle=designated (und jetzt geht es schon los - müsste es jetzt auch bicycle:right=destinated heissen? Bitte nicht beantworten, ist eine rhetorische Frage und soll nur der Verdeutlichung der Problematik mit diese
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Du sprichst in deinem Vorschlag mehrfach sowohl von Fahrtrichtungen als auch von Fahrspuren. Das sind aber zwei verschiedene Dinge. Daher eine prinzipielle Frage: Repräsentiert ein Way in deinem Modell * eine Fahrtrichtung oder * eine Fahrspur bzw. Gruppe von Fahrspuren ? Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
steffterra schrieb: a) Einzeichnen zusätzlicher paralleler ways, die _nicht_ extra durch eine Relation oder einen Tag als zum gleichen way =ohne bauliche Trennung, gehörig verbunden werden müssen. Das sollte durch eine neue Datenart ermöglicht werden. Ich würde diese Funkion "Gruppierung" nennen und könnte durch eine gemeinsame abstrakte Signatur/ID erreicht werden, die von der DB (oder einem Algorithmus aus den way-id's jedes mal neu errechnet wird, wenn ein way dazukommt, oder abgezogen wird) vergeben wird. Könnte man das Ziel nicht auch ohne neue "Datenart" realisieren? Ich denke eine Änderung an der API ist nur schwer durchsetzbar. Es würde ja erst mal reichen, wenn man solche Gebilde anlegen und editieren kann. Der Schutz gegen Vandalismus bzw. versehentliches Ändern könnte ja immer noch später folgen. Was mir an Deinem Vorschlag gut gefällt, ist die Tatsache, dass man das highway-Element (datenway) nicht unnötig auftrennen muss um ein (richtungsabhängiges) Attribut zu setzten, sondern dass es reicht, wenn man einen Knoten setzt und von da ab einen way zeichnet. Natürlich kann man die selben Informationen auch über Attribute (und Auftrennen des highway-Elements) modellieren. Das Drehen der Wege sehe ich aber nicht so als Problem, das ja JOSM auch schon jetzt die Attribute entsprechend anpasst. Vielleicht können auch beide Systeme parallel existieren und je nach Anwendungsfall die einfachere Variante gewählt werden. Bei einer Kreuzung sehe ich die Attribut-Variante am Ende, sobald man einzelne Fahrspuren abbilden will. Bei einer einfachen richtungsabhängigen Geschwindigkeitsbeschränkung könnte aber 3 ways etwas übertrieben sein. Ich versuche mal ein einfaches Beispiel: "Einseitige Geschwindigkeitsbeschränkung auf dem Weg von A nach D zwischen B und C" Realität: Ein Weg von A bis D (B und C sind nur Knoten) o>**=*=o A B 70 km/h C D Zur Abbildung mit Attributen muss der Weg bei B und C aufgetrennt werden Weg AB: highway=secondary Weg BC: highway=secondary | maxspeed:forward=70 Weg CD: highway=secondary o>o>===*=o>o A B C D "Neues Datenmodell" (so wie ich es verstanden habe): Weg AD: highway=secondary Weg BC: maxspeed=70 Weg CB: (nichts) B*-C o>**=*=o A B*-C D Zu beachten ist aber, dass die Wege BC und CB in den OSM-Daten deckungsgleich (selbe Koordinaten) mit dem Abschnitt BC des Weges AD sind. Die "Spreizung" ist nur im Editor zu sehen. Ich weiß nicht, ob die Wege BC und CB mit einem speziellen Attribut gekennzeichnet werden müssen. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Hallo, Tirkon wrote: Ich denke mal, dass es unmöglich ist, auf der Originalkarte dafür einen verlassenes Plätzchen zu bekommen, oder? Das würde nämlich Einiges vereinfachen. Das ist in der Vergangenheit immer scharf kritisiert worden, wenn Leute das gemacht haben. Es gibt natuerlich api06.dev.openstreetmap.org, wo man sich leicht einen Account holen und herumspielen kann. Man kann da auch mal eben ein kleines Dorf selber hochladen zum Spielen, aber dazu muss man natuerlich ein bisschen mit dem Editor tricksen. Vielleicht sollte man mal ganz klein anfangen und eine Webseite machen, mit der man einen kleinen Datenbereich vom echten Server auswaehlen und auf api06.dev einspielen kann... Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Frederik Ramm wrote: >Ausserdem ist so ein "Miniplanet" beileibe kein Wundermittel - der >Vorschlag, der hier von "steffterra" als, wie Du sagst, "Textwueste" >unterbreitet wurde, wuerde mit oder ohne Miniplanet Wochen >konzentrierter Arbeit brauchen, um ihn zur Demonstrationsreife zu >bringen (Aenderungen an Renderern und Editoren!). Jemand, der *das* >kann, der kann auch schnell noch eine Rails-API gemaess Wiki-Anleitung >aufsetzen, der braucht keinen "Miniplanet". In einer ersten Phase geht es erst einmal darum, einfach dasselbe vorzufinden, was man auch auf der Originalkarte hat. Das würde für viele Zwecke schon reichen. z.B. Anfänger, Schulung, Demonstrationen, Wiki-Illustrierung etc. - oder z.B. für den derzeitigen PLZ-Import üben, ohne das man Gefahr läuft, etwas zu beschädigen. Die tatsächliche Änderung von Apis, Renderern oder Ahnlichem zu testen, wäre dann schon sehr advanced fortgesponnen und erst in einem Stadium denkbar, wenn sich die "einfache" Version etabliert hat. Dann kann man immer noch weiter sehen. Und auch auf der einfachen Oberfläche kann man gemeinschaftlich ein neues System ausprobieren, ohne dass es anders als normal gerendert wird. Wenn man dort beginnt, verschiedene Situationen durchzumappen, merkt man auch ohne neuen Renderer, dass es noch hier und dort kneift und die Textwüste noche einer Änderung bedarf. Z.B. kann jemand hier ein Beispiel hinterlassen, wo es eben kneift und den anderen dort zeigen. Ich denke mal, dass es unmöglich ist, auf der Originalkarte dafür einen verlassenes Plätzchen zu bekommen, oder? Das würde nämlich Einiges vereinfachen. >Meiner Ansicht nach wuerde ein "Miniplanet" die Gefahr mit sich bringen, >dass Leute ausprobieren, wie bestimmte Sachen im Rendering aussehen, und >dann ihre Tagging-Entscheidungen danach richten... Wenn es um Tagging Entscheidungen geht, dann geht es auch um etwas real Existierendes. Und das künnte man auch in normalen Karte mappen und ausprobieren. Damit könnten also die Außerirdischen vom Miniplaneten die Erde nicht überfallen. ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Hallo, Tirkon wrote: Bloß ist das Vorausdenken etwas schwierig, wenn einem das notwendige gemeinsam nutzbare Reißbrett dazu fehlt. Textwüsten sind nicht immer hilfreich, wenn es hier um ein Projekt geht, dass seine Produkte im Wesentlichen grafisch editiert und darstellt. Daher würde ich mich freuen, wenn jemand meinen Vorschlag für das Online-Werkzeug "Miniplanet" http://wiki.openstreetmap.org/wiki/User:Tirkon/Miniplanet umsetzen könnte. Gute Idee, aber sehr viel Arbeit, das alles zu entwickeln und einzurichten - es muessem ja auch Editoren und Renderer dazu passen, dann hast Du das Permission-System, dann willst Du, dass es persistent ist, dann brauchst Du Import/Export-Tools (denn viele werden nicht auf der gruenen Wiese anfangen wollen, sondern eine bestehende Stadt importieren oder so), und was ist, wenn jemand tatsaechlich Aenderungen am API-Code braucht, um seine Sache zu demonstrieren? Ausserdem ist so ein "Miniplanet" beileibe kein Wundermittel - der Vorschlag, der hier von "steffterra" als, wie Du sagst, "Textwueste" unterbreitet wurde, wuerde mit oder ohne Miniplanet Wochen konzentrierter Arbeit brauchen, um ihn zur Demonstrationsreife zu bringen (Aenderungen an Renderern und Editoren!). Jemand, der *das* kann, der kann auch schnell noch eine Rails-API gemaess Wiki-Anleitung aufsetzen, der braucht keinen "Miniplanet". Meiner Ansicht nach wuerde ein "Miniplanet" die Gefahr mit sich bringen, dass Leute ausprobieren, wie bestimmte Sachen im Rendering aussehen, und dann ihre Tagging-Entscheidungen danach richten... 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] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Hallo, Tirkon wrote: Ein grosser Schritt vorwaerts waere es schonmal, nicht *unnoetig* richtungsabhaengige Informationen zu produzieren. Mir ist derzeit nicht klar, welche Du damit meinst. Könntest Du da konkrete Beispiele nennen? Die folgten doch direkt auf diesen Satz in meiner Mail. Nicht richtungsabhaengig ist fuer mich alles, was separat existiert und bei dem die Position mehr oder minder nur aus Bequemlichkeit im Verhaeltnis zur Strasse angegeben wird. Darunter fallen fuer mich fast alle left/right-Sachen. Wenn ich angeben will, auf welcher Seite einer Strasse sich eine Mauer oder eine Baumreihe oder ein Parkstreifen befindet, dann ist ein left/right dafuer nicht geeignet, genauso wie ich auch zu niemandem sagen wuerde: "Auf der linken Seite der Talstrasse ist ein Fahrradweg". Diese Information reicht nicht. Ich muss entweder sagen "wenn Du von X nach Y faehrst, ist auf der linken Seite der Talstrasse ein Fahrradweg", oder ich muss sagen "auf der Nordseite der Talstrasse ist ein Fahrradweg". Wenn man in OSM genauso verfahren wuerde, statt sich auf das Kunstgebilde der Way-Richtung zu verlassen, gaebe es 95% der Probleme mit backward, forward, left, right nicht. Die sind alle hausgemacht. 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] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Frederik Ramm wrote: >Ein grosser Schritt vorwaerts waere es schonmal, nicht *unnoetig* >richtungsabhaengige Informationen zu produzieren. Mir ist derzeit nicht klar, welche Du damit meinst. Könntest Du da konkrete Beispiele nennen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Frederik Ramm wrote: >Ich habe Deinen Vorschlag gelesen. Meine persoenliche Meinung ist, dass >es zu frueh ist, solche Komplexitaet in OSM einzubauen; die allermeisten >im Projekt sind noch lange nicht an dem Punkt, wo sie sich um solche >Dinge Sorgen machen. Andrerseits kann es natuerlich nie schaden, mal ein >bisschen vorauszudenken. Bloß ist das Vorausdenken etwas schwierig, wenn einem das notwendige gemeinsam nutzbare Reißbrett dazu fehlt. Textwüsten sind nicht immer hilfreich, wenn es hier um ein Projekt geht, dass seine Produkte im Wesentlichen grafisch editiert und darstellt. Daher würde ich mich freuen, wenn jemand meinen Vorschlag für das Online-Werkzeug "Miniplanet" http://wiki.openstreetmap.org/wiki/User:Tirkon/Miniplanet umsetzen könnte. Ich bin mir relativ sicher, dass das Werkzeug nach einiger Zeit des Bekanntwerdens zunehmend genutzt wird. Insbesondere denke ich, dass da bald viele Tüftler am Werk sein werden, die den von Dir genannten Punkt schon überschritten haben und neue Konzepte ausprobieren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 25.07.2010 um 23:39 schrieb Frederik Ramm: > Hallo, > > steffterra wrote: >> Wieso dann nicht die Argumente in einem neuen Datenmodell vereinen? >> Sicher bin ich nicht der erste, dem das einfällt. Ich habe hier schon >> des öfteren von "Linienbündeln" und "Fahrspurtagging" gelesen. > > Ich habe Deinen Vorschlag gelesen. Meine persoenliche Meinung ist, dass es zu > frueh ist, solche Komplexitaet in OSM einzubauen; die allermeisten im Projekt > sind noch lange nicht an dem Punkt, wo sie sich um solche Dinge Sorgen > machen. Andrerseits kann es natuerlich nie schaden, mal ein bisschen > vorauszudenken. > > Was ich nicht so recht verstehe, ist: Wieso meinst Du, dass eine neue Art von > Objekt erforderlich ist? Die Editoren muessen eh angepasst werden, um Dein > Konzept zu "verstehen", also koennte man sie auch derart anpassen, dass statt > Deiner "neuartigen Way-Gruppierung" eine ganz gewoehnliche Relation > eingesetzt werden kann - in einer fuer den Benutzer nicht unterscheidbaren > Art und Weise. Ich glaube zu verstehen, was Du meinst. Die Gruppierung in einer ID wäre wesentlich flexibler als vom User manuell zu setzende Relationen. Ich denke auch, dass Relationen ein guten Mittel für verschiedene Zwecke sein kann. Aber hier Relationen einzusetzen wäre overkill. Zumal auch mehr kb anfallen würden, als wenn jeder way, der zu einer Gruppe gehört die gleiche Gruppen-ID hätte. Es wäre schon deshalb felxibler, weil das im Hintergrund passieren könnte, also ohne dass sich der User darum kümmern muss, ausser die ways zu markieren und dann im Menü "Gruppieren" zu klicken. Dann schaltet JOSM die gemeinsame Hintergrundfarbe für diese Gruppe und es ist auch von der Wahrnehmung her zu einer Straße geworden. Im Hintergrund hat JOSM die ID vergeben und FRenderer können diese nutzen, um die ways entsprechend darzustellen. > Die Latte fuer "neuen Objekttyp in der zentralen Datenbank einfuehren" haengt > wesentlich hoeher als die fuer "neue Art von Relationsnutzung erfinden und > Editor-Support dafuer entwickeln". Fuer das erstgenannte musst Du wesentlich > mehr Leute davon ueberzeugen, dass das, was Du vorhast, gut ist. Das wiederum > fuehrt zu meiner einleitenden Anmerkung zurueck - solange 99% der Leute im > Projekt das Problem, das Du loesen moechtest, noch gar nicht selber hatten, > werden sie vermutlich mit einem gewissen Unverstaendnis reagieren. Vielleicht > ist das in 2-3 Jahren anders. das Problem mit foreward/backward besteht jetzt bereits. Dort wo kein Bedarf besteht, dass dies eingesetzt würde, muss man ja nicht gruppieren. Das ist ja der Vorteil des Konzepts. Es ist abwärtskompatibel, weil eben nciht alles darauf umgestellt werden muss. Man kann es nur dort einsetzen, wo es das taggen vereinfacht oder Fahrspurtagging sinnvoll wäre. > Ich sehe auch noch eine gewisse Schwaeche bei der Frage, wie man Ways > aufsplittet und verbindet - da muessen ja dann alle Teil-Ways immer > mitgesplittet werden, aber wo? Die Tags müssten natürlich genauso kopiert werden, wie bisher auch, alles die gleichen Regeln. Das Teilen/Splitten selbst kann durch mehrfachmarlkieren aller Nodes auf allen an der Gruppe beteiligten ways geschehen. So viele sind das ja meist nicht. Denn 8-spuriges Autobahntaggen ist ja nicht nötig ;-) Es kann ja auch jeder way einer Gruppe nach wie vor mit lanes=4 getaggt werden. Kein Problem. Das ist ja das schöne an der Felxibilität. Also einfach alle drei ways (beide Fahrrichtungsways und der datenway) mit nodes versehen, an denen man die Straße aufteilen möchte und den Befehl anwenden. Es sollte aber aus Sicherheitsgründen eine Nachfrage kommen, falls man einen node auf einem way nicht mitmarkiert hat. Könnte aber auch noch nachgeholt werden, falls man den way doch nicht abzweigen lassen möchte - z.B. als abzweigende Fahrspur. > Die Bearbeitung von Kreuzungen stelle ich mir sehr schwierig vor, aber > vielleicht ist das nur eine Frage des Benutzerinterfaces. Kreuzung werden sogar einfacher, das man nur die Schnittstellen mit gemeinsamen Nodes versieht, wo tatsächlich eine Kreuzung vorhanden ist. Abbiegespuren, die z.B. gar nicht kreuzen sidn so noch einfacher umzusetzen. Ansonsten gilt für jeden Richtugnsway/Abbiegespur die ganz normalen Abbiege-Relationen. Es bleiben ja ways mit nodes, auf diese man die Relationen anwenden kann. Absolut abwärtskompatibel. > Ausserdem muss man natuerlich immer damit rechnen, dass es Software und > Benutzer gibt, die das ganze nicht verstehen. Dazu könnte man eine sehr schöne Anleitung/HOWTO schreiben mit Bildbeispielen, wie ich sie mir auch für das Proposal vorstelle und für absolut nötig halte. In der heutigen Zeit könnte man auch einen Screencast erstellen, der erklärt, wie es funktioniert. > Wir haben in OSM keine Software-Zertifizierungsstelle, die entscheidet, > welche Software auf unsere Daten losgelassen werden darf und welche nicht > (und mit Benutzern ist es ebenso). Leute werden den Datenway a
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Hallo, steffterra wrote: Wieso dann nicht die Argumente in einem neuen Datenmodell vereinen? Sicher bin ich nicht der erste, dem das einfällt. Ich habe hier schon des öfteren von "Linienbündeln" und "Fahrspurtagging" gelesen. Ich habe Deinen Vorschlag gelesen. Meine persoenliche Meinung ist, dass es zu frueh ist, solche Komplexitaet in OSM einzubauen; die allermeisten im Projekt sind noch lange nicht an dem Punkt, wo sie sich um solche Dinge Sorgen machen. Andrerseits kann es natuerlich nie schaden, mal ein bisschen vorauszudenken. Was ich nicht so recht verstehe, ist: Wieso meinst Du, dass eine neue Art von Objekt erforderlich ist? Die Editoren muessen eh angepasst werden, um Dein Konzept zu "verstehen", also koennte man sie auch derart anpassen, dass statt Deiner "neuartigen Way-Gruppierung" eine ganz gewoehnliche Relation eingesetzt werden kann - in einer fuer den Benutzer nicht unterscheidbaren Art und Weise. Die Latte fuer "neuen Objekttyp in der zentralen Datenbank einfuehren" haengt wesentlich hoeher als die fuer "neue Art von Relationsnutzung erfinden und Editor-Support dafuer entwickeln". Fuer das erstgenannte musst Du wesentlich mehr Leute davon ueberzeugen, dass das, was Du vorhast, gut ist. Das wiederum fuehrt zu meiner einleitenden Anmerkung zurueck - solange 99% der Leute im Projekt das Problem, das Du loesen moechtest, noch gar nicht selber hatten, werden sie vermutlich mit einem gewissen Unverstaendnis reagieren. Vielleicht ist das in 2-3 Jahren anders. Ich sehe auch noch eine gewisse Schwaeche bei der Frage, wie man Ways aufsplittet und verbindet - da muessen ja dann alle Teil-Ways immer mitgesplittet werden, aber wo? Die Bearbeitung von Kreuzungen stelle ich mir sehr schwierig vor, aber vielleicht ist das nur eine Frage des Benutzerinterfaces. Ausserdem muss man natuerlich immer damit rechnen, dass es Software und Benutzer gibt, die das ganze nicht verstehen. Wir haben in OSM keine Software-Zertifizierungsstelle, die entscheidet, welche Software auf unsere Daten losgelassen werden darf und welche nicht (und mit Benutzern ist es ebenso). Leute werden den Datenway aufsplitten und die Spur-Ways unveraendert lassen, oder umgekehrt; Leute werden einen Name-Tag an einen Spur-Way anfuegen, sie werden Kreuzungen zwischen Objekten einbauen, die sich nicht kreuzen sollten, undsoweiter. Es ist extrem unwahrscheinlich, dass die API so geaendert wuerde, dass sie solche logisch "ungueltigen" Edits zurueckweist. Ich frage mich, ob unter solchen Bedingungen nicht manchmal mehr Redundanz besser ist; dann hat man wenigstens eine Chance, rauszufinden, wenn irgendwas nicht passt. 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] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Hallo, steffterra wrote: Bringt man richtungsabhängige Informationen in Relationen oder Tags am besten unter? Ein grosser Schritt vorwaerts waere es schonmal, nicht *unnoetig* richtungsabhaengige Informationen zu produzieren. Mal ganz platt gesagt, wenn auf einer Seite der Strasse ein Spielplatz ist, wird auch niemand auf die Idee kommen, sowas wie "playground=right" zu taggen. Ebenso waere eine Parkspur im Osten der Strasse nichts, was tatsaechlich irgendetwas mit der Richtung der Strasse zu tun hat - da gibt es eine Parkspur, aber in welcher Richtung der Verkehr auf der Strasse fliesst oder in welcher Richtung die Strasse in OSM eingezeichnet ist, hat mit der Parkspur nichts, aber auch gar nichts zu tun. Es waere also toericht, hier - egal, ob man nun Relationen oder Tags oder sonst was benutzt - in irgendeiner Form einen Bezug zur Richtung der Strasse herzustellen; man erzeugt damit voellig unnoetige Probleme. 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
[Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Hallo, Ich möchte nochmal ganz wertfrei und ohne Vorbehalte darüber schreiben, was bei diesem Thema zu beobachten ist: Das "Problem der drehenden Wege" bei Verwendung von backward-forward und left-right für die unterschiedlichsten Zwecke muss irgendwie grundlegend angepackt werden. Ich sehe da OSM einfach bei einer Grenze angekommen. - Ich verstehe, die Befürworter von Relationen für die Abbildung von Wegeigenschaften, die sich nur auf eine Straßenrichtung beziehen (z.B. maxspeed:forward, parking:lane:right, destination:forward, etc.), da mit Relationen eine Richtung festgelegt werden kann, egal wie der Weg gedreht ist. - Ich verstehe aber auch die Bedenken derer, die das lieber getaggt haben, um zu verhindern, dass irgendwann _alles_, was eine Straßenrichtung betrifft, in Relationen gefasst wird. Ich halte beide Version für unübersichtlich und aufgrund der Komplexität beider Varianten auch fehlerträchtig. - Manche versuchen das Problem zu umgehen, indem sie zwei ways für jede Fahrrichtung zeichnen, was aber nur bei baulicher Trennung korrekt wäre, und deshalb falsch ist. Wieso dann nicht die Argumente in einem neuen Datenmodell vereinen? Sicher bin ich nicht der erste, dem das einfällt. Ich habe hier schon des öfteren von "Linienbündeln" und "Fahrspurtagging" gelesen. Doch welche Konzepte gibt es bisher? Wie weit sind wir dahin? Steckt OSM da derzeit fest? Warum gehts nicht weiter? -- Ich meine, aufgrund dieser unbefriedigenden Situation gibt es eigentlich immer nur eine Diskussion: Bringt man richtungsabhängige Informationen in Relationen oder Tags am besten unter? Bei genauerem Hinsehen, kommt immer das gleiche heraus: Uneinigkeit, weil es natürlich für beide Varianten Vor- und Nachteile gibt. Sprich wir treten alle auf der Stelle. Doch die Anforderungen an OSM sind gestiegen und deshalb benötigen wir eine Erweiterung unseres bisherigen Datenmodells (so sagt man das doch?) - Mein Vorschlag ist sicher nicht neu und ich behaupte _nicht_, damit den Stein der Weisen gefunden zu haben! 1. Die bisherige Struktur von Nodes und Ways wird beibehalten und kann bei Bedarf an bestimmten Stellen (hier nur für Straßen!) erweitert werden. 2. Diese Erweiterung für Straßen sollte auf diese Weise einfach (von Anwenderseite gesehen) möglich sein: a) Einzeichnen zusätzlicher paralleler ways, die _nicht_ extra durch eine Relation oder einen Tag als zum gleichen way =ohne bauliche Trennung, gehörig verbunden werden müssen. Das sollte durch eine neue Datenart ermöglicht werden. Ich würde diese Funkion "Gruppierung" nennen und könnte durch eine gemeinsame abstrakte Signatur/ID erreicht werden, die von der DB (oder einem Algorithmus aus den way-id's jedes mal neu errechnet wird, wenn ein way dazukommt, oder abgezogen wird) vergeben wird. b) Diese way-Gruppe könnte in JOSM so dargestellt werden, dass jeder way beim Zeichnen automatisch parallel ausgerichtet wird und mit einer gemeinsamen Hintergrundfarbe hinterlegt ist. Das zeigt, das es sich um einen way im bisherigen Sinne ohne bauliche Trennung handelt. c) Festlegen der Richtung beider ways wie bisher auch und ein Schlosssymbol setzen, das verhindert, dass jemand diese Richtung ändern kann, ohne von JOSM rückgefragt zu werden. d) Taggen der entsprechenden Eigenschaften für die jeweilige Richtung. 3. Wenn man auf solch ein way-Gruppierung stößt, dann weiss man in DE, dass Rechtsverkehr herrscht und dann ist klar, in welcher Richtung -also auf welchem der beiden ways was getaggt weden muss, wenn man die Wirklichkeit abbilden möchte. 4. Es könnten mehrere ways für eine Fahrtrichtung in der Gruppe sein. Z.B. zwei zeigen in die eine Richtung, einer zeigt in die andere. Dadurch wäre auch Fahrspurtagging möglich und durch das Schlosssymbol in JOSM und Potlatch(?) wird man vorsichtig beim Ändern der Way-Richtung. 5. Nun muss noch was gegen die Redundanz gemacht werden: Anlegen eines "Datenways". a) Eine Straße, die z.B. je eine Fahrspur in jeder Richtung hat, wird mit _drei_ ways gezeichnet. b) Der mittlere way ist der Datenway, auf ihm werden alle Tags untergebracht, die für die _gesamte_ way-Gruppe gelten, wie z.B. highway= secondary, name=Bündelstraße, ref=B 19. als auch die Relationen-Teilnahme, die für alle ways des Bündel gelten. c) auf den ways links und rechts werden nur die tags untergebracht, die für die jeweilige Richtung gelten, z.B. maxspeed=50 und gegenüber auf dem anderen way maxspeed=40 d) Der mittlere way entspricht der derzeitigen Umsetzung für die mittlere Geographische Lage für ways. Er sollte möglichst die Mitte der Straße darstellen. e) was tun bei drei Fahrspuren? Der datenway wird zwischen beide Fahrtrichtungen gelegt und ist dann insgesamt gesehen der vierte way. 6. Nun zum Rendern und der Darstellung in JOSM: a) exisitert nur ein way, wird verfahren, wie bisher auch, um die Abwärtskompatibilität zum aktuellen Datenbestand zu erhalten b) _gleichzeitig mit der Einführung
