Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 31.07.2010 um 21:14 schrieb steffterra: Am 31.07.2010 um 13:59 schrieb Guenther Meyer: Am Samstag 31 Juli 2010, 09:38:45 schrieb steffterra: der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. durch grafische Eingabe!? Der User sieht die Abbildung der Strasse, und darauf in Form eines Pfeils oder einer anderen Art der Darstellung, in welcher Richtung oder auf welcher Seite die Eigenschaft gueltig ist. Eingabefelder fuer die eigentlichen Tags zeigt man am besten gar nicht mehr an. Durch die Eingabe der Daten in einem aufpoppenden Fenster mit Pfeil auf den way, den es betrifft hätte man es einfach visualisert, an welchem way man soeben taggt. Das wäre die beste Lösung, stimmt! Super Vorschlag, wie ich finde. forward/backward/left/right könnte der intelligente Editor so wirklich automatisch vergeben. Ich muss mich selbst korrigieren: Natürlich ist es quatsch, durch den Editor noch forward/backward am Richtungsway zu taggen. Da hast Du mcih jetzt echt aufs Glatteis geführt. Nochmal zum Versatändnis: du schlägst einerseits vor, dass der Editor per popup-Fenster und Pfeil zum betroffenen way, an dem man das Tagging durchführt einfach die Keys einträgt, die für diesen richtugnsway gelten. Das geht aber auch so wie jetzt auch, da ja an so einem Richtugsway _keine_ richtungsabhängigen Tags nötig sind! Wenn Du Dein vorgehen an normalen ways machen möchtest, ist es dem Editor eben nicht möglich selbst zu entscheiden, was der user gerade eingibt, da eben nciht klar ist, wie er forward/backward/left/right vergeben soll, da es ja nur ein way ist. Bei senkrechten und waagrechten ways könnte man diese automatische Vergabe der richtungsanhängigen Tags noch ermöglichen, doch bei ways, die in 45° Winkel verlaufen, weiss der Renderer nicht von was Du ausgehst. Ist links jetzt die westliche Fahrbahnteil gemeint, oder der nördlich gelegene? 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 =?iso-8859-1?q?_forward/backward?=)
Am Sonntag 01 August 2010, 10:22:14 schrieb steffterra: Wer baut die grafische Tagging-Funktion in JOSM und Potlatch? (hier sind doch ein paar Entwickler unterwegs, oder?) Nicht dass für die Gruppierung keine Entwickler nötig wären... ;-) Beim Konzept kann ich durchaus behilflich sein, aber von Java und Flash halt ich mich fern. Ich hatte eher gehofft, falls das noch jemand ausser Dir mitliest gleich mal hier schreit ;-) Naja so ähnlich halt. Oder jemand kennt halt die Namen. Entwicklerkapazitaet ist bei OSM leider ein rares Gut. Wenn jemand nicht wirklich von einem neuen Konzept ueberzeugt wird, passiert da erst mal nicht viel - ausser man macht es selbst... 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Sonntag 01 August 2010, 11:22:38 schrieb steffterra: Am 31.07.2010 um 21:14 schrieb steffterra: Am 31.07.2010 um 13:59 schrieb Guenther Meyer: Am Samstag 31 Juli 2010, 09:38:45 schrieb steffterra: der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. durch grafische Eingabe!? Der User sieht die Abbildung der Strasse, und darauf in Form eines Pfeils oder einer anderen Art der Darstellung, in welcher Richtung oder auf welcher Seite die Eigenschaft gueltig ist. Eingabefelder fuer die eigentlichen Tags zeigt man am besten gar nicht mehr an. Durch die Eingabe der Daten in einem aufpoppenden Fenster mit Pfeil auf den way, den es betrifft hätte man es einfach visualisert, an welchem way man soeben taggt. Das wäre die beste Lösung, stimmt! Super Vorschlag, wie ich finde. forward/backward/left/right könnte der intelligente Editor so wirklich automatisch vergeben. Ich muss mich selbst korrigieren: Natürlich ist es quatsch, durch den Editor noch forward/backward am Richtungsway zu taggen. Da hast Du mcih jetzt echt aufs Glatteis geführt. Nochmal zum Versatändnis: du schlägst einerseits vor, dass der Editor per popup-Fenster und Pfeil zum betroffenen way, an dem man das Tagging durchführt einfach die Keys einträgt, die für diesen richtugnsway gelten. Das geht aber auch so wie jetzt auch, da ja an so einem Richtugsway _keine_ richtungsabhängigen Tags nötig sind! das Popup kam von dir ;-) konkret muss man schauen, was die beste Methode ist, das darzustellen. Ich gehe einen Schritt weiter. Ich will nicht, dass der User (ausser er arbeitet in einem speziellen Expertmode) ueberhaupt mit Tags zu tun hat. Wenn Du Dein vorgehen an normalen ways machen möchtest, ist es dem Editor eben nicht möglich selbst zu entscheiden, was der user gerade eingibt, da eben nciht klar ist, wie er forward/backward/left/right vergeben soll, da es ja nur ein way ist. das wuerde ganz genau so funktionieren, denn auch ein way hat eine Richtung. 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Sonntag 01 August 2010, 23:20:32 schrieb steffterra: 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. wir reden wohl manchmal aneinander vorbei ;-) Ich habe die Erfahrung gemacht, dass sich solche Dinge am effektivsten bei persoenlichen Treffen entwickeln lassen. Du bist nicht zufaellig aus der Muenchner Gegend? Ansonsten waere es vielleicht mal wieder interessant, einen OSM-Workshop wie damals im Linuxhotel zu veranstalten. 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. dazu braucht's kein Proposal, sondern simple Entwicklungs- bzw. Programmierarbeit. Fuer beides hab ich in dieser Richtung praktisch keine Zeit, hab noch genug andere offene Baustellen. Und Leute dafuer zu finden, hab ich aufgegeben. Wenn sich jemand darum kuemmern will, steuere ich gerne ein paar Ideen bei. Was wird aus deinem Konzept? Waere schade, wenn das wie viele andere Dinge einfach verschwinden wuerde... 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 30.07.2010 um 08:17 schrieb Guenther Meyer: Am Donnerstag 29 Juli 2010, 23:44:33 schrieb steffterra: 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? inklusive Fahrspurtagging. tagging ja - zeichnen nein. Nur die Fahrbahnen der beiden Richtungen (die je aus mind. 2 Fahrspuren bestehen können) werden einzeln gezeichnet, da es ja eine bauliche Trennung für die Fahrbahnen der beiden Richtungen gibt. Einzelne Fahrspuren einer Fahrbahn sind darin nicht umgesetzt worden, da sie nicht baulich getrennt sind. Das Prinzip möchte ich ja in meinem Modell beibehalten, nur dass dann angepassten Editoren die ways als zu einer Fahrbahn gehörig dargestellen können (durch die gleiche Hintergrundfarbe). Insofern wird zwar aufgehoben: ein way pro Fahrbahn, doch das gilt immernoch ausserhalb der gemeinsamen Hintergrundfarbe. Alte Editoren zeigen es halt wie jetzt auch an, mit den einzelnen ways pro Fahrspur, die aber nicht als baulich verbunden gezeigt werden (da die gemeinsame Hintergrundfarbe fehlt.) Ausserdem sind die ways ohne Straßenklassifizierung, weil das ja am datenway liegt. Beim Renderer ist es so: der alte Renderer zeigt nur den datenway, da dieser eine Straßenklassifizierung hat. Die Richtungsways werden gar nicht gerendert, da der highway-tag fehlt. Ein neuer Renderer erkennt aber, dass das Fahrspuren sind und zeichnet es entsprechend. Da Konzept sollte wohl auch fuer andere Strassen erweitert werden, leider kamm dann erstmal nix mehr... weil die bauliche Nicht-Trennung dagegen stand. 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. Es sind halt zwei verschiedene Ansaetze. Du haengst dich zu sehr an der Richtung auf. Ich versuche normalerweise erst mal, Probleme schnell und einfach am Ursprung zu loesen, bevor ich alles neu schreibe. Ich hänge mich nicht zu sehr an der Richtung auf, sondern ich versuche mit meinem Modell das Problem mit der Richtung zu beheben. 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? Das hat nichts miteinander zu tun. Eine Relation ist ein Basisobjekt genau wie ein Node oder ein Way. Wie du die nutzt, steht dir im Prinzip total frei. Es geht hier nur um die technische Abbildung deiner Gruppierung bzw. ID. Ja eben, wie errechnet sich denn die ID einer Relation? 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? Ich glaube, da liegt ein Verstaendnisproblem vor: Das einzige, wozu ich eine Relation benutzt haette, waere die Abbildung des Objekts Gruppe selbst. Nein ;-) Ich meinte, Du solltest bitte mal zeigen, wie Du die Spezialfälle der Gruppierung mittels Relationen darstellst. Also die Gruppierungen selbst, nicht das ganze Modell. Du sagtest ja, dass die Gruppierung ncihts anderes als eine Relation wäre. da warte ich noch auf dein versprochenes Beispiel (realisiert z.B. mit josm). Ich schau's mir an, und versuche dann mal, dasselbe auf meine Weise zu relaisieren... Da müsst Ihr Euch leider noch etwas gedulden. Aus beruflichen Gründen bin ich massiver eingespannt, als ich dachte und bin froh, diesem Thread weiter verfolgen zu können. mir geht's da leider aehnlich... Aber hey, wenn am Ende was brauchbares rauskommt, kommt's auf ein paar Tage mehr auch nicht an ;-) Sorry, muss weiter vertrösten. Aber ich stehe hinter meinem Modell und werde es hoffentlich bald mal machen können. Bis denn und danke, 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 =?iso-8859-1?q?_forward/backward?=)
Am 30.07.2010 um 08:27 schrieb Guenther Meyer: Für die Umsetzung müssen natürlich alle an einem Strang ziehen. +1 Abwärtskompatibilität bleibt ja dennoch erhalten. lassen wir uns ueberraschen. ich denke das koennte bei deinem Modell interessant werden. Man muesste mal ausprobieren, was ein heutiger Renderer aus deinem Modell machen wuerde (kann ich gerne machen, sobald was getaggtes vorliegt)... Das wäre cool. Leider habe ich dazu jetzt in der anderen mail geantwortet... :-/ wie das gerendert würde. Aber visualisiert ist es natürlich noch einfacher zu verstehen. Besonders der Richtugnsway, der nach meinem Modell keinen eigenen highway-tag hat, sollte eigentlich nicht gerendert werden, der datenway schon. Da die richtungsabhängigen Tags dann auf den ways liegen wird man diese Trennung auch bei der Software berücksichtigen müssen. Doch da helfen nur note-tags, dass das nicht zerlegt wird und stattdessen die Software das neue Modell unterstützt. (z.B. Navi-software, etc.) Letztendlich bleibt es dann doch wieder am Frontend haengen. Der User sollte nicht wissen muessen, ob er left, right, forward, backward taggen muss, oder ob er jetzt lieber ein Tag oder einen neuen way dranbasteln soll... doch woher soll das frontend wissen, wo backward usw. in der Realität ist? ist das so schwer?! ja schon. Wenn das automatisch gehen soll schon. der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. Wenn man mit Himmelsrichtungen für die Straßenseite arbeitest, dann hast Du das Problem, dassw man bei schräg verlaufenden Straßen nicht weiss, ob das nun nördlich ist (wie bei einer horizontalen Straße), oder schon westlich (wie bei einer senkrechten Straße) ... verstehst Du? Da müssten dann wieder Regeln eingeführt werden, ab wieviel ° was gilt. Aber es wäre durch Regeln umsetzbar. 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 =?iso-8859-1?q?_forward/backward?=)
Am Samstag 31 Juli 2010, 09:25:54 schrieb steffterra: Beim Renderer ist es so: der alte Renderer zeigt nur den datenway, da dieser eine Straßenklassifizierung hat. Die Richtungsways werden gar nicht gerendert, da der highway-tag fehlt. wenn ich dich richtig verstehe, koennen die zusaetzlichen ways u.a. auch Rad- und Fussgaengerwege sein, getrennte Ein/Ausfaedel- und Abbiegespuren sind genau so moeglich. Bisher werden diese ueber ein Highway-Tag gekennzeichnet, willst du dieses auch verwerfen und was neues einfuehren? Ein neuer Renderer erkennt aber, dass das Fahrspuren sind und zeichnet es entsprechend. klar. Es sind halt zwei verschiedene Ansaetze. Du haengst dich zu sehr an der Richtung auf. Ich versuche normalerweise erst mal, Probleme schnell und einfach am Ursprung zu loesen, bevor ich alles neu schreibe. Ich hänge mich nicht zu sehr an der Richtung auf, dafuer erwaehnst du das Thema zu oft ;-) sondern ich versuche mit meinem Modell das Problem mit der Richtung zu beheben. das sei dir ja gegoennt. Alles weitere dazu hatte ich bereits geschrieben. 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? Das hat nichts miteinander zu tun. Eine Relation ist ein Basisobjekt genau wie ein Node oder ein Way. Wie du die nutzt, steht dir im Prinzip total frei. Es geht hier nur um die technische Abbildung deiner Gruppierung bzw. ID. Ja eben, wie errechnet sich denn die ID einer Relation? keine Ahnung. Ich wuerde vermuten, dass die erst von der API beim comitten vergeben wird. Der lokale Editor kann ja nicht wissen, welche IDs frei sind. 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? Ich glaube, da liegt ein Verstaendnisproblem vor: Das einzige, wozu ich eine Relation benutzt haette, waere die Abbildung des Objekts Gruppe selbst. Nein ;-) Ich meinte, Du solltest bitte mal zeigen, wie Du die Spezialfälle der Gruppierung mittels Relationen darstellst. Also die Gruppierungen selbst, nicht das ganze Modell. Du sagtest ja, dass die Gruppierung ncihts anderes als eine Relation wäre. im Sinne von zusammenfassen von Objekten, also in diesem Falle der Ways. Konkret: Relation XY sagt aus, dass Way 12, Way 34 und Way 56 zusammengehoeren und eine 'Gruppe' bilden. Verstaendnisproblem. 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Samstag 31 Juli 2010, 09:38:45 schrieb steffterra: der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. durch grafische Eingabe!? Der User sieht die Abbildung der Strasse, und darauf in Form eines Pfeils oder einer anderen Art der Darstellung, in welcher Richtung oder auf welcher Seite die Eigenschaft gueltig ist. Eingabefelder fuer die eigentlichen Tags zeigt man am besten gar nicht mehr an. 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 31.07.2010 um 13:53 schrieb Guenther Meyer: Am Samstag 31 Juli 2010, 09:25:54 schrieb steffterra: Beim Renderer ist es so: der alte Renderer zeigt nur den datenway, da dieser eine Straßenklassifizierung hat. Die Richtungsways werden gar nicht gerendert, da der highway-tag fehlt. wenn ich dich richtig verstehe, koennen die zusaetzlichen ways u.a. auch Rad- und Fussgaengerwege sein, getrennte Ein/Ausfaedel- und Abbiegespuren sind genau so moeglich. Bisher werden diese ueber ein Highway-Tag gekennzeichnet, willst du dieses auch verwerfen und was neues einfuehren? Wenn Du mein Eingangsposting noch einmal in Ruhe liest, wird Dir auffallen, dass Radwege, etc. keine eigenen ways bekommen. sie werden einfach am richtigen Richtigungsway getaggt. Das ist einer der Unterscheide zum Linienbündel, das alles aufgedröselt hat. Ich möchte _nur_ die richtugnsabhängigen Tags in eigene ways packen und Fahrspuren auch _nicht generell_ sondern nur da, wo es der Plausibilität und besseren Abbildung der Wirklichkeit _nötig_ ist. Ein neuer Renderer erkennt aber, dass das Fahrspuren sind und zeichnet es entsprechend. eben, deshalb halte ich das Radwegtagging am auf der Seite des entsprechenden Richtungsway völlig ausreichend. In einem anderen Posting (es dürften 8-10 Postings/Mails vor diesem gewesen sein, schau mal ein wenig durch) habe ich 5 Beispiele verglichen, wie es nach dem jetzigen System und wie nach meinem Modell getaggt würde. Da siehst du den Radweg und andere Dinge entsprechend im Vergleich getaggt. Es sind halt zwei verschiedene Ansaetze. Du haengst dich zu sehr an der Richtung auf. Ich versuche normalerweise erst mal, Probleme schnell und einfach am Ursprung zu loesen, bevor ich alles neu schreibe. Ich hänge mich nicht zu sehr an der Richtung auf, dafuer erwaehnst du das Thema zu oft ;-) Es _ist_ das Thema ;-) Siehe Betreff. sondern ich versuche mit meinem Modell das Problem mit der Richtung zu beheben. das sei dir ja gegoennt. Alles weitere dazu hatte ich bereits geschrieben. Das war nur die Antwort darauf, warum ich es von richtungsabhängigen Tag abhängig mache. Es ist das Thema, es ist der Hauptgrund (mit allen positiven Nebeneffekten die ich gerne mitnehmen), dass ich mir das Modell überhaupt überlegt habe. Also ist klar, dass ich darauf auch besonders eingehe, oder? Dass ich deshalb die Nebeneffekte (positive und negative gleichermaßen) deshalb noch lange nicht ausser Acht lasse, kann man in meinen Mails dieses Threads nachlesen. 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? Das hat nichts miteinander zu tun. Eine Relation ist ein Basisobjekt genau wie ein Node oder ein Way. Wie du die nutzt, steht dir im Prinzip total frei. Es geht hier nur um die technische Abbildung deiner Gruppierung bzw. ID. Ja eben, wie errechnet sich denn die ID einer Relation? keine Ahnung. Ich wuerde vermuten, dass die erst von der API beim comitten vergeben wird. Der lokale Editor kann ja nicht wissen, welche IDs frei sind. 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? Ich glaube, da liegt ein Verstaendnisproblem vor: Das einzige, wozu ich eine Relation benutzt haette, waere die Abbildung des Objekts Gruppe selbst. Nein ;-) Ich meinte, Du solltest bitte mal zeigen, wie Du die Spezialfälle der Gruppierung mittels Relationen darstellst. Also die Gruppierungen selbst, nicht das ganze Modell. Du sagtest ja, dass die Gruppierung ncihts anderes als eine Relation wäre. im Sinne von zusammenfassen von Objekten, also in diesem Falle der Ways. Konkret: Relation XY sagt aus, dass Way 12, Way 34 und Way 56 zusammengehoeren und eine 'Gruppe' bilden. Verstaendnisproblem. Müsste sie auch noch aussagen, welcher way welche Rolle hat, oder ergibt sich das aus dem tagging? Dann könnte man auch sehr einfach eine Brücke in einer Relation zusammenfassen, schließlich ist das ja auch eine Fahrbahn mit unterscheidlichen Elementen. Hmm das ist eine interessante Geschichte. Denn sobald man richtugnsways, datenway, tram und anderes mit auf einer Brücke hat müsste man zunächst die Fahrbahnen ohne Tram zu einer Gruppe zusammenfassen und dann diese Gruppe und die Tram-Line in eine Relation für die Brücke zusammenfassen. Da bin ich aber eher dagegen, da es das unnötig verkomplizieren würde. Trams sind oft Fahrbahnbegleitend oder sogar gemeinschaftlich
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 31.07.2010 um 13:59 schrieb Guenther Meyer: Am Samstag 31 Juli 2010, 09:38:45 schrieb steffterra: der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. durch grafische Eingabe!? Der User sieht die Abbildung der Strasse, und darauf in Form eines Pfeils oder einer anderen Art der Darstellung, in welcher Richtung oder auf welcher Seite die Eigenschaft gueltig ist. Eingabefelder fuer die eigentlichen Tags zeigt man am besten gar nicht mehr an. Durch die Eingabe der Daten in einem aufpoppenden Fenster mit Pfeil auf den way, den es betrifft hätte man es einfach visualisert, an welchem way man soeben taggt. Das wäre die beste Lösung, stimmt! Super Vorschlag, wie ich finde. forward/backward/left/right könnte der intelligente Editor so wirklich automatisch vergeben. Gut, also keine Gruppierung mehr nötig? Hätte ich kein Problem, mit wenn man das vermeiden könnte. Wer baut die grafische Tagging-Funktion in JOSM und Potlatch? (hier sind doch ein paar Entwickler unterwegs, oder?) Nicht dass für die Gruppierung keine Entwickler nötig wären... ;-) 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 =?iso-8859-1?q?_forward/backward?=)
Am Samstag 31 Juli 2010, 21:10:38 schrieb steffterra: Wenn Du mein Eingangsposting noch einmal in Ruhe liest, wird Dir auffallen, dass Radwege, etc. keine eigenen ways bekommen. sie werden einfach am richtigen Richtigungsway getaggt. verstehe... Das ist einer der Unterscheide zum Linienbündel, das alles aufgedröselt hat. Ich möchte _nur_ die richtugnsabhängigen Tags in eigene ways packen und Fahrspuren auch _nicht generell_ sondern nur da, wo es der Plausibilität und besseren Abbildung der Wirklichkeit _nötig_ ist. d.h. also die von mir beschriebene Situation kann durchaus vorkommen. Ein neuer Renderer erkennt aber, dass das Fahrspuren sind und zeichnet es entsprechend. eben, deshalb halte ich das Radwegtagging am auf der Seite des entsprechenden Richtungsway völlig ausreichend. In einem anderen Posting (es dürften 8-10 Postings/Mails vor diesem gewesen sein, schau mal ein wenig durch) habe ich 5 Beispiele verglichen, wie es nach dem jetzigen System und wie nach meinem Modell getaggt würde. Da siehst du den Radweg und andere Dinge entsprechend im Vergleich getaggt. Es sind halt zwei verschiedene Ansaetze. Du haengst dich zu sehr an der Richtung auf. Ich versuche normalerweise erst mal, Probleme schnell und einfach am Ursprung zu loesen, bevor ich alles neu schreibe. Ich hänge mich nicht zu sehr an der Richtung auf, dafuer erwaehnst du das Thema zu oft ;-) Es _ist_ das Thema ;-) Siehe Betreff. lassen wir diese Diskussion, bringt ja eh nix ;-) Nein ;-) Ich meinte, Du solltest bitte mal zeigen, wie Du die Spezialfälle der Gruppierung mittels Relationen darstellst. Also die Gruppierungen selbst, nicht das ganze Modell. Du sagtest ja, dass die Gruppierung ncihts anderes als eine Relation wäre. im Sinne von zusammenfassen von Objekten, also in diesem Falle der Ways. Konkret: Relation XY sagt aus, dass Way 12, Way 34 und Way 56 zusammengehoeren und eine 'Gruppe' bilden. Verstaendnisproblem. Müsste sie auch noch aussagen, welcher way welche Rolle hat, oder ergibt sich das aus dem tagging? Waere wahrscheinlich sinnvoll, wenn man diesen Weg geht. Dann könnte man auch sehr einfach eine Brücke in einer Relation zusammenfassen, schließlich ist das ja auch eine Fahrbahn mit unterscheidlichen Elementen. Hmm das ist eine interessante Geschichte. Denn sobald man richtugnsways, datenway, tram und anderes mit auf einer Brücke hat müsste man zunächst die Fahrbahnen ohne Tram zu einer Gruppe zusammenfassen und dann diese Gruppe und die Tram-Line in eine Relation für die Brücke zusammenfassen. z.B. Da bin ich aber eher dagegen, da es das unnötig verkomplizieren würde. Trams sind oft Fahrbahnbegleitend oder sogar gemeinschaftlich mit einer Fahrspur genutzt. Aus diesem Grund würde ich eine tram-line wie eine Fahrspur in die Gruppe mit aufnehmen. ja. Man kann sie ja auch nciht an einem highway drantaggen, da sie einen eigenen way besitzen muss. warum? grade wenn das Gleis auf der Fahrbahn verlaeuft, gibt es dafuer keinen Grund. Also gerne entweder mit gemeinsamen Knoten einer Fahrspur (wenn sie in der Fahrspur eingelassen ist) ist nein. oder bei baulicher Trennung eben normal neben den highway-spuren. ja. Sorry für den kleinen Abstecher, aber damit haben wir auch den Spezialfall mit aufgenommen und sogar die Brücke mit reingebracht, die auch wunderbar vom Renderer genutzt werden könnte, dass man nicht immer diese durchsichten Brücken hat, wenn sie in einer Brückenrelation erfasst wurden. Diese Brückenrelation ersetzt dann die vorher und danach bestehende Gruppierungs-Relation, falls dort sonst richtungsabhängie Tags nötig wären. (sonst ist ja eine Gruppierung auch nicht nötig) eins nach dem anderen, das klingt mir schon wieder viel zu kompliziert ;-) 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Samstag 31 Juli 2010, 21:14:54 schrieb steffterra: Durch die Eingabe der Daten in einem aufpoppenden Fenster mit Pfeil auf den way, den es betrifft hätte man es einfach visualisert, an welchem way man soeben taggt. Das wäre die beste Lösung, stimmt! Super Vorschlag, wie ich finde. forward/backward/left/right könnte der intelligente Editor so wirklich automatisch vergeben. eben :-) Gut, also keine Gruppierung mehr nötig? Hätte ich kein Problem, mit wenn man das vermeiden könnte. auf Datenebene ist das schon noetig, wie soll der Editor sonst wissen, was zusammengehoert? Wer baut die grafische Tagging-Funktion in JOSM und Potlatch? (hier sind doch ein paar Entwickler unterwegs, oder?) Nicht dass für die Gruppierung keine Entwickler nötig wären... ;-) Beim Konzept kann ich durchaus behilflich sein, aber von Java und Flash halt ich mich fern. 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Donnerstag 29 Juli 2010, 23:44:33 schrieb steffterra: 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? inklusive Fahrspurtagging. Da Konzept sollte wohl auch fuer andere Strassen erweitert werden, leider kamm dann erstmal nix mehr... 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. Gut das das geklaert ist. Wenn alles perfekt waere, wuerde ich sicher nicht hier schreiben ;-) 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. Es sind halt zwei verschiedene Ansaetze. Du haengst dich zu sehr an der Richtung auf. Ich versuche normalerweise erst mal, Probleme schnell und einfach am Ursprung zu loesen, bevor ich alles neu schreibe. 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? Das hat nichts miteinander zu tun. Eine Relation ist ein Basisobjekt genau wie ein Node oder ein Way. Wie du die nutzt, steht dir im Prinzip total frei. Es geht hier nur um die technische Abbildung deiner Gruppierung bzw. ID. 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? Ich glaube, da liegt ein Verstaendnisproblem vor: Das einzige, wozu ich eine Relation benutzt haette, waere die Abbildung des Objekts Gruppe selbst. da warte ich noch auf dein versprochenes Beispiel (realisiert z.B. mit josm). Ich schau's mir an, und versuche dann mal, dasselbe auf meine Weise zu relaisieren... Da müsst Ihr Euch leider noch etwas gedulden. Aus beruflichen Gründen bin ich massiver eingespannt, als ich dachte und bin froh, diesem Thread weiter verfolgen zu können. mir geht's da leider aehnlich... Aber hey, wenn am Ende was brauchbares rauskommt, kommt's auf ein paar Tage mehr auch nicht an ;-) richtig, das Frontend ist das wichtige. Ob sich dahinter drei ways mit ein paar Tags oder nur ein Way mit vielen Tags verbergen, ist doch eigentlich egal. Nein, da man schon möglichst einfach durchblicken sollte! wie ich schon an anderer Stelle schrieb, ist mein Modell einfacher zu verstehen, da an dem way getaggt wird, den es betrifft. also auf dem way der Straßenseite, die es betrifft und nicht abstrakt am backward-attribut klebt, der noch von der wayrichtugn abhängig ist und da noch die gefahr besteht, dass falsch gedreht wurde udn zwischenzeitlich richtig nachgetaggt wurde und dann wieder gedreht wird, weil man slebst aus versehen alles danach falschherum eingetragen hat. Direkt am way der Straßenseite ist es halt einfach einfacher. Und viel einfacher nachzuvollziehen - auch für nachfolgende Mapper, da die visuelle Lage auf der Karte schon vieles klärt. abwarten. kann sein, muss aber nicht. email iust grausam. Ich mag Mailinglisten nicht besonders, auch wenn ich mit UUCP-Newsgroups und 9600er Modem groß wurde. foren finde ich praktischer, wenn gescheit moderiert und offtopics in eigene Threads getrennt werden. Ausserdem sind Diskussionstränge leichter nochmal durchzulesen, da es keine mehrfachabzweigungen gibt und man auch von frühereren Postings nochmal zitieren kann. Aber das ist ja jetzt auch offtopic. sorry. das mit den Threads haengt rein von der Disziplin der User ab. Prinzipiell finde ich ML ein sehr gutes Medium fuer Diskussionen. Nur bei der Eroerterung von komplexeren Themen, die am besten grafisch visualisiert werden sollten, mag es vielleicht bessere Medien geben. Aber ja, wir schweifen ab... 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Donnerstag 29 Juli 2010, 23:49:45 schrieb steffterra: Am 29.07.2010 um 23:34 schrieb Guenther Meyer: Am Donnerstag 29 Juli 2010, 23:15:07 schrieb steffterra: Er kann es aber leichter entscheiden, wenn er davon ausgehen kann, dass die Richtigkeit der Tags nicht von einem potentiell falsch gedrehten way wieder zunichte gemacht werden könnte. Er kann sich einfach sicher sein, dass auf der richtigen Seite getaggt wurde. Also eine Minimierung der Unsicherheitsfaktoren. einen Unsicherheitsfaktor hast du immer. Nachher kommt ein Mapper, sieht deine drei ways und denkt sich so ein Schmarrn, das ist doch nur ein Strasse, und zerlegt dir das Ganze wieder... ;-) Dafür gibts wikis und den Editro, der das ganze entsprechend rüberbringt. Note-tags gibts auch noch. leider keine 100%ige Loesung, aber die einzige, die wir im Moment haben. Für die Umsetzung müssen natürlich alle an einem Strang ziehen. +1 Abwärtskompatibilität bleibt ja dennoch erhalten. lassen wir uns ueberraschen. ich denke das koennte bei deinem Modell interessant werden. Man muesste mal ausprobieren, was ein heutiger Renderer aus deinem Modell machen wuerde (kann ich gerne machen, sobald was getaggtes vorliegt)... Letztendlich bleibt es dann doch wieder am Frontend haengen. Der User sollte nicht wissen muessen, ob er left, right, forward, backward taggen muss, oder ob er jetzt lieber ein Tag oder einen neuen way dranbasteln soll... doch woher soll das frontend wissen, wo backward usw. in der Realität ist? ist das so schwer?! der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Donnerstag 29 Juli 2010, 23:15:07 schrieb steffterra: Er kann es aber leichter entscheiden, wenn er davon ausgehen kann, dass die Richtigkeit der Tags nicht von einem potentiell falsch gedrehten way wieder zunichte gemacht werden könnte. Er kann sich einfach sicher sein, dass auf der richtigen Seite getaggt wurde. Also eine Minimierung der Unsicherheitsfaktoren. einen Unsicherheitsfaktor hast du immer. Nachher kommt ein Mapper, sieht deine drei ways und denkt sich so ein Schmarrn, das ist doch nur ein Strasse, und zerlegt dir das Ganze wieder... ;-) Eben: Die Fälle, wo der Mapper in deinem Modell bei Vereinigungen selber entscheiden muss, gibt es auch jetzt schon. Aber das gilt auch umgekehrt: Was in deinem Modell automatisch möglich wäre, ginge auch jetzt schon automatisch. Nein, da die unsicherheit besteht, dass der way zwischenzeitlich einmal aus Versehen gedreht wurde und die JOSM-Warnmeldung mangels Kenntnis missachtet wurde. Die Unsicherheit im generellen Umgang mit left/right und forward/backward erlebt man ja schon, wenn man die Argumente hier teilweise (nicht Deine) hier liest. Teilweise wurde nicht verstanden, dass backward/forward nicht das gleiche wie links/rechts ist, etc... Das zeigt, dasss das System im Grunde schon recht schwierig für manche ist. Dann kommt noch die Komponente dazu, dass der way aus den verschiedensten Gründen auch durch andere Editoren gedreht werden könnte, die keine Warnung oder ein automatischen Drehen der Tags ermöglichen. Wenn man aber einen way für jede Richtung einer Straße hat, dann passiert das erst gar nicht. Letztendlich bleibt es dann doch wieder am Frontend haengen. Der User sollte nicht wissen muessen, ob er left, right, forward, backward taggen muss, oder ob er jetzt lieber ein Tag oder einen neuen way dranbasteln soll... 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 29.07.2010 um 23:34 schrieb Guenther Meyer: Am Donnerstag 29 Juli 2010, 23:15:07 schrieb steffterra: Er kann es aber leichter entscheiden, wenn er davon ausgehen kann, dass die Richtigkeit der Tags nicht von einem potentiell falsch gedrehten way wieder zunichte gemacht werden könnte. Er kann sich einfach sicher sein, dass auf der richtigen Seite getaggt wurde. Also eine Minimierung der Unsicherheitsfaktoren. einen Unsicherheitsfaktor hast du immer. Nachher kommt ein Mapper, sieht deine drei ways und denkt sich so ein Schmarrn, das ist doch nur ein Strasse, und zerlegt dir das Ganze wieder... ;-) Dafür gibts wikis und den Editro, der das ganze entsprechend rüberbringt. Note-tags gibts auch noch. Für die Umsetzung müssen natürlich alle an einem Strang ziehen. Abwärtskompatibilität bleibt ja dennoch erhalten. Letztendlich bleibt es dann doch wieder am Frontend haengen. Der User sollte nicht wissen muessen, ob er left, right, forward, backward taggen muss, oder ob er jetzt lieber ein Tag oder einen neuen way dranbasteln soll... doch woher soll das frontend wissen, wo backward usw. in der Realität ist? 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 =?iso-8859-1?q?_forward/backward?=)
Am Mittwoch 28 Juli 2010, 00:11:03 schrieb steffterra: Am 27.07.2010 um 23:27 schrieb Guenther Meyer: [..viele Beispiele...] ich muss mir das Ganze nochmal genauer anschauen, aber abgesehen von der Losloesung von der Richtungsabhaengigkeit was aus meiner Sicht ein rieeesen Vorteil ist. Die anderen sind die Abwärtskompatibilität und vor allem die Ermöglichung von Fahrspurtagging, was für kommende OSM-Anwendungen enorm wichtig werden wird, wenn man zu den großen und kommerziellen konkurrenzfähig sein möchte. Vor allem im Navigationsbereich wären diese Vorteile sehr wünschenswert und eine sicherere Methode mit weniger Fehlerquellen. 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. sehe ich im Moment nicht wirklich Vorteile - und wesentlich einfacher wird's auch nicht. Wenn man alle Aspektev mit einbezieht eben schon. Vergleiche einfach mal die nötigen Tags in den Beispielen. Ist doch wesentlich klarer als die Latte an einem way, der dann ncoh die Gefahr birgt durch ein einfaches Drehen des way komplett über den Haufen geschmissen zu werden. Aber das wurde auch alles schon einmal besprochen. die Drehproblematik ist wirklich hinreichend behandelt; ebenso dass es keines neuen Schemas bedarf, um *diese* in den Griff zu kriegen. 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. Und woher weiss JOSM, dass die drei ways eigentlich ein Objekt bilden? Relation? Es steht doch da: sie werden zu einer Gruppe zusammengefasst. Diese Gruppierungsfunktion durch eine gemeinsame ID (_ähnlich_ wie bei Relationen, ist aber bei weitem nicht so aufwändig, da automatisiert durch den Editor) die sich aus den beteiligten ways durch einen einfachen Algorithmus errechnen liese, habe ich auch schon ausführlich in meinem Startposting beschrieben. Auch wenn du es Gruppe nennst, ist es nichts anderes als eine einfache Relation. Die automatische Erstellung durch den Editor aendert daran genau nichts. Warum willst du was neues erfinden, wenn es genau das, was du brauchst, bereits gibt? 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Hallo, Am Dienstag 27 Juli 2010 schrieb steffterra: [viele Beispieldetails] Hast du das schon irgendwo mal in die Tat umgesetzt? Ein Link zur Karte wäre in diesem Fall toll. Gruß, Carsten ___ 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 =?iso-8859-1?q?_forward/backward?=)
Am Dienstag 27 Juli 2010, 17:56:26 schrieb steffterra: 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. nicht nur. es gibt werden sowohl explizit Geh- und Radwege eingezeichnet (Linienbuendel), als auch Mischformen. [..viele Beispiele...] ich muss mir das Ganze nochmal genauer anschauen, aber abgesehen von der Losloesung von der Richtungsabhaengigkeit sehe ich im Moment nicht wirklich Vorteile - und wesentlich einfacher wird's auch nicht. 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. Und woher weiss JOSM, dass die drei ways eigentlich ein Objekt bilden? Relation? 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 27.07.2010 um 23:27 schrieb Guenther Meyer: [..viele Beispiele...] ich muss mir das Ganze nochmal genauer anschauen, aber abgesehen von der Losloesung von der Richtungsabhaengigkeit was aus meiner Sicht ein rieeesen Vorteil ist. Die anderen sind die Abwärtskompatibilität und vor allem die Ermöglichung von Fahrspurtagging, was für kommende OSM-Anwendungen enorm wichtig werden wird, wenn man zu den großen und kommerziellen konkurrenzfähig sein möchte. Vor allem im Navigationsbereich wären diese Vorteile sehr wünschenswert und eine sicherere Methode mit weniger Fehlerquellen. sehe ich im Moment nicht wirklich Vorteile - und wesentlich einfacher wird's auch nicht. Wenn man alle Aspektev mit einbezieht eben schon. Vergleiche einfach mal die nötigen Tags in den Beispielen. Ist doch wesentlich klarer als die Latte an einem way, der dann ncoh die Gefahr birgt durch ein einfaches Drehen des way komplett über den Haufen geschmissen zu werden. Aber das wurde auch alles schon einmal besprochen. 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. Und woher weiss JOSM, dass die drei ways eigentlich ein Objekt bilden? Relation? Es steht doch da: sie werden zu einer Gruppe zusammengefasst. Diese Gruppierungsfunktion durch eine gemeinsame ID (_ähnlich_ wie bei Relationen, ist aber bei weitem nicht so aufwändig, da automatisiert durch den Editor) die sich aus den beteiligten ways durch einen einfachen Algorithmus errechnen liese, habe ich auch schon ausführlich in meinem Startposting beschrieben. 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 =?iso-8859-1?q?_forward/backward?=)
Am Montag 26 Juli 2010, 00:39:36 schrieb steffterra: Am 25.07.2010 um 23:47 schrieb Guenther Meyer: Am Sonntag 25 Juli 2010, 23:08:21 schrieb Frederik Ramm: Doch die Parkspur ist ein Attribut eines Teils der Strasse (wenn man mal so ein Modell vorraussetzt), und damit muss irgendwie bezeichnet werden, auf welcher Seite sie sich befindet. +1 Die Fahrspur könnte z.b. nur in einer Fahrtrichtung vorhanden sein. Doch auf welcher? Das tagt man halt auf dem way der Richtugnsfahrspur, zwischen den nodes wo er vorhanden ist: parking:lane capacity:disabled:2 Dafuer braucht man nunmal irgendeine Art der Richtungsangabe. Nur sehe ich die hierfuer notwendige Richtung als total abstrakt an, z.B. angelegt wie die Strasse gezeichnet wurde. Die Richtung wohin die Fahrspur führt, ist tatsächlich egal für die Parkpsur. Doch man legt am way der Seite der Straße den tag an, wo die Parkspur tatsächlich vorhanden ist. Das erfordert aber wieder dieses Linienchaos, das doch so unuebersichtlich ist... 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. Genau diese Probleme will die Gruppierung ja verhindern, weil so genau festgelegt wird, an welchem way, also auf welcher Straßenseite welche Dinge vorhanden sind. Wie z.b. Radweg, usw. (Das ist übrigens der Unterschied zum wesentlich komplizierter zu zeichnenden Linienbündel, da wir ausreichend tags haben, um alle Arten von Radwegen, Parkständen, etc. am way zu taggen. Das einzige Problem hierbei ist aber durch die Gruppierung nicht mehr vorhanden und damit das Ziel derer errreicht: die richtugnsabhängigen Unterschiede liegen nun auf den einzelnen ways der Straßenseite, wo in Wirklichkeit vorhanden sind. was genau willst du eigentlich? So wie ich das verstehe, willst du, dass jeder Teil (Strasse, Fussweg, Fahrradweg) separat als way eingezeichnet wird, um diese dann irgendwie zusammenzufassen. Ich praeferiere eher den Ansatz, dass eine Strasse prinzipiell nur aus einem way besteht, der die zusaetzlichen Wege - genauso wie die Anzahl der Fahrspuren - als Attribute bekommt. Gemeinsam ist beiden Ansaetzen, dass die komplette Strasse inkl. Zubehoer in einem Objekt vereint wird. 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Montag 26 Juli 2010, 03:51:55 schrieb Frederik Ramm: 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. eben nicht. Das Problem ist, dass die Richtung je nach Geschmack gedreht wird, egal, ob davon noch andere Dinge abhaengen. Die Richtung sollte ein Hilfsmittel rein zur Beschreibung von richtungsabhaengigen Tags sein, nicht mehr und nicht weniger. Sobald ein Weg erstellt wurde, hat dieser eine Richtung, die so fix bleibt (und wie gesagt, dem User im besten Fall gar nicht erst gezeigt wird). 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Sonntag 25 Juli 2010, 23:08:21 schrieb Frederik Ramm: 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. ein Spielplatz ist auch von der Strasse total unabhaengig. 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. richtig, die Fahrtrichtung hat nichts mit der Parkspur zu tun. Doch die Parkspur ist ein Attribut eines Teils der Strasse (wenn man mal so ein Modell vorraussetzt), und damit muss irgendwie bezeichnet werden, auf welcher Seite sie sich befindet. Dafuer braucht man nunmal irgendeine Art der Richtungsangabe. Nur sehe ich die hierfuer notwendige Richtung als total abstrakt an, z.B. angelegt wie die Strasse gezeichnet wurde. Danach hat diese Richtung den User nicht mehr zu interessieren, sie braucht auch gar nicht mehr angezeigt werden. Benoetigt wird sie nur, damit der Editor bzw. die entsprechende Software die Attribute zuordnen und entsprechend auswerten kann. Deshalb gibt es auch keinen Grund, diese Richtung irgendwann zu aendern. 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 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Sonntag 25 Juli 2010, 23:39:29 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. sorry, wenn ich dir da widersprechen muss. Wenn ich mir anschaue, was heutzutage schon mit Relationen veranstaltet wird, dann ist die Komplexitaet fuer viele bereits zu hoch. Was her muss (ganz egal welches Modell darunterliegt) ist eine Abstraktion der Userebene. Als Anwender (der der gemeine Mapper ebenso ist) will ich mich nicht mit Tags und Relationen rumschlagen muessen. Die Presets sind hier ein guter Anfang, aber das muss noch viel weiter gehen... 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. +1 ob jetzt darunter neue Objekte liegen oder nicht ist relativ egal, hauptsache das ganze ist konsistent und einigermassen klar definiert. 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 25.07.2010 um 23:47 schrieb Guenther Meyer: Am Sonntag 25 Juli 2010, 23:08:21 schrieb Frederik Ramm: 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. ein Spielplatz ist auch von der Strasse total unabhaengig. +1 Die Lage ergibt sich aus den Koordinaten, diese zusätzliche Angabe komplett unnötig. 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. richtig, die Fahrtrichtung hat nichts mit der Parkspur zu tun. - sondern mit der Seite auf der sie vorhanden ist. Und das gilt es ja anzugeben (bisher mit forward/backward/right) Doch die Parkspur ist ein Attribut eines Teils der Strasse (wenn man mal so ein Modell vorraussetzt), und damit muss irgendwie bezeichnet werden, auf welcher Seite sie sich befindet. +1 Die Fahrspur könnte z.b. nur in einer Fahrtrichtung vorhanden sein. Doch auf welcher? Das tagt man halt auf dem way der Richtugnsfahrspur, zwischen den nodes wo er vorhanden ist: parking:lane capacity:disabled:2 Dafuer braucht man nunmal irgendeine Art der Richtungsangabe. Nur sehe ich die hierfuer notwendige Richtung als total abstrakt an, z.B. angelegt wie die Strasse gezeichnet wurde. Die Richtung wohin die Fahrspur führt, ist tatsächlich egal für die Parkpsur. Doch man legt am way der Seite der Straße den tag an, wo die Parkspur tatsächlich vorhanden ist. Danach hat diese Richtung den User nicht mehr zu interessieren, sie braucht auch gar nicht mehr angezeigt werden. Benoetigt wird sie nur, damit der Editor bzw. die entsprechende Software die Attribute zuordnen und entsprechend auswerten kann. Deshalb gibt es auch keinen Grund, diese Richtung irgendwann zu aendern. Mit der Einführung der Gruppierung sind sie bis auf oneway obsolet fürs tagging. Da man dort hin-taggen kann, wo es ist: an dem way der Straßenseite, wo es in Wirklichkeit vorhanden ist. 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. Genau diese Probleme will die Gruppierung ja verhindern, weil so genau festgelegt wird, an welchem way, also auf welcher Straßenseite welche Dinge vorhanden sind. Wie z.b. Radweg, usw. (Das ist übrigens der Unterschied zum wesentlich komplizierter zu zeichnenden Linienbündel, da wir ausreichend tags haben, um alle Arten von Radwegen, Parkständen, etc. am way zu taggen. Das einzige Problem hierbei ist aber durch die Gruppierung nicht mehr vorhanden und damit das Ziel derer errreicht: die richtugnsabhängigen Unterschiede liegen nun auf den einzelnen ways der Straßenseite, wo in Wirklichkeit vorhanden sind. Danke fürs Feedback, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
