Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Hallo, On Di, 2015-04-21 at 17:16 +0200, Frederik Ramm wrote: > Hallo, > >schade, dass diese Diskussion von allen Seiten ein bisschen überhitzt > geführt wird. > > Ich finde, dass solche grossflächigen Edits - ob mechanisch oder nicht - > mit sehr grosser Sorgfalt angegangen werden sollten. Dazu zählt, dass > man sich gut überlegt, was man machen will, aber auch, dass man mit > Einwänden vernünftig umgeht. die Änderungen wurden detailliert geplant und dokumentiert: http://forum.openstreetmap.org/viewtopic.php?id=30676 Die Einwände von fly bezogen sich allerdings nicht auf die geplanten Änderungen, sondern auf das Taggingschema allgemein. Fly hat die Diskussion um den mechanischen Edit zum Anlass genommen, viele grundsätzliche Dinge des Taggingschemas in Frage zu stellen. > Von vorn herein nur im Forum zu posten und auf Nachfrage zu erklären, > die Mailingliste sei ja eh am Sterben, ist "asking for trouble" - einen > breiten Konsens erreicht man nicht, indem man die (nach eigenem Befinden > kleinere) Hälfte der Community ignoriert. Das ist zugegebenermaßen nicht gut gelaufen. Ich selbst hätte es auch auf der Mailingliste gepostet. Die Begründung, dass die Mailingliste am Sterben sei, finde ich auch nicht wirklich passend. > Ausserdem sehe ich hier eine gefährliche Tendenz von "das ist > OpenRailwayMap-Sache, wir haben uns das überlegt, und warum sollten wir > auf jemanden hören, der nicht mal zu uns gehört". Folgerichtig hat > Michael (Nakaner) seine Aktion auch nicht "zur Diskussion gestellt" > (denn er war sich ja schon sicher, dass er alles richtig macht und sich > nicht reinreden lassen wird), sondern nur "angekündigt". Die geplanten Änderungen wurden ausgiebig auf unseren Treffen diskutiert (zu denen auf diversen Kanälen eingeladen wurde, aber kaum jemand gekommen ist). Nach den Treffen wurden diese Änderungsvorschläge auch nochmal auf der ORM-Mailingliste, im Forum und auf ein paar anderen Kanälen bekanntgegeben, ohne dass noch irgendwelche Einwände kamen. Deshalb darf man ja spätestens dann davon ausgehen, dass niemand mehr einen Einwand hat. Dazu sind die Änderungen wie bereits beschrieben sehr unspektakulär, da nur Fehler aus der Anfangszeit des Schemas behoben wurden. Es ändert sich ja praktisch nichts durch den Edit. Warum sollten wir also plötzlich ein funktionierendes Taggingschema auf den Kopf stellen, weil ein einziger Mapper Kritik übt, aber selbst keine brauchbaren Verbesserungen aufzeigen kann? > Es ist etwas ungeschickt, dass fly selbst nicht auf der > OpenRailwayMap-Mailingliste ist und sich zugleich gern an der weiteren > Diskussion bezüglich Tagging von Eisenbahnanlagen beteiligen will. Wäre > er auf dieser Liste gewesen, hätte er vermutlich im Vorfeld an der > Diskussion teilnehmen können, statt Verbesserungsvorschläge erst > einzubringen, als der Edit "angekündigt" wurde. Nicht nur das. Was ich fly vorwerfe ist, dass es jetzt auf einmal anfängt, nicht nur Details, sondern grundsätzliche Dinge eines Taggingschemas in Frage zu stellen, das seit Jahren etabliert und in breiter Verwendung ist. Vor allem hat seine Kritik überhaupt nichts mit dem eigentlichen Edit zu tun: * Erfassung von Signalen mit railway:signal:direction=* und railway:signal:position=* ist "kaputt" * Tags sind zu lang * Signaltypen sollten nicht abgekürzt, sondern ausgeschrieben werden * die Signalvorschriften sind zu kompliziert Wenn jemand begründete Einwände hat, bin ich gerne bereit, mir diese Kritik anzuhören und gegebenenfalls das Tagging zu verbessern. Voraussetzung dafür ist jedoch, dass derjenige konstruktive Vorschläge hat, wie es seiner Meinung besser gemacht werden könnte. > (Dann wieder - OpenRailwayMap ist eine private Mailingliste auf einer > privaten Domain, > wo der private Betreiber jeden rauswerfen kann, der ihm nicht passt - > insofern stellt sich die Frage, ob eine Meinungsbildung auf der > OpenRailwayMap-Liste für OSM überhaupt eine Bedeutung haben sollte.) Auf sämtlichen anderen "offiziellen" Mailinglisten kann man doch auch jederzeit rausgeworfen werden?! > Ich habe jetzt keine Lust, die hier diskutierten Edits zu reverten, aber > ich erwarte künftig vom OpenRailwayMap-Team, dass sie den Rest des > Projekts nicht wie Idioten behandeln, die ja eh nichts zu sagen haben, > sondern dass man sie und ihre Bedenken ernst nimmt. Dazu zählt, dass man > seine Edits nicht bloss "ankündigt", sondern tatsächlich innerlich zu > Kompromissen bereit ist, und dazu zählt auch, dass man auf talk-de nicht > bloss auftaucht, um Leuten mitzuteilen, dass man mit ihnen jetzt nicht > mehr spricht. Wir haben niemanden wie Idioten behandelt, allerdings sollte man Kritik auch zurückweisen dürfen. Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Hallo, schade, dass diese Diskussion von allen Seiten ein bisschen überhitzt geführt wird. Ich finde, dass solche grossflächigen Edits - ob mechanisch oder nicht - mit sehr grosser Sorgfalt angegangen werden sollten. Dazu zählt, dass man sich gut überlegt, was man machen will, aber auch, dass man mit Einwänden vernünftig umgeht. Von vorn herein nur im Forum zu posten und auf Nachfrage zu erklären, die Mailingliste sei ja eh am Sterben, ist "asking for trouble" - einen breiten Konsens erreicht man nicht, indem man die (nach eigenem Befinden kleinere) Hälfte der Community ignoriert. Ausserdem sehe ich hier eine gefährliche Tendenz von "das ist OpenRailwayMap-Sache, wir haben uns das überlegt, und warum sollten wir auf jemanden hören, der nicht mal zu uns gehört". Folgerichtig hat Michael (Nakaner) seine Aktion auch nicht "zur Diskussion gestellt" (denn er war sich ja schon sicher, dass er alles richtig macht und sich nicht reinreden lassen wird), sondern nur "angekündigt". Ich finde, dass das insgesamt einen unnötig arroganten Eindruck macht, und Nakaner hat ja auch "Erfolg" gehabt, indem fly auf die Barrikaden gegangen ist. Ich bin sicher, das OpenRailwayMap-Team wird tolerant und freundlich bleiben, wenn "fly" demnächst sein neues Signaltaggingschema auf talk-de (und nicht im Forum) ankündigt dann anfängt (sorgsam und manuell natürlich) alle deutschen Signale umzustellen ;) Das ist alles in allem ziemlich schlecht gelaufen, und künftige ähnliche Aktionen sollten mit mehr Respekt gegenüber der Community, auch gegenüber der "Minderheit auf talk-de" und den "Aussenseitern ausserhalb OpenRailwayMap" durchgeführt werden, oder eben gar nicht. Es ist etwas ungeschickt, dass fly selbst nicht auf der OpenRailwayMap-Mailingliste ist und sich zugleich gern an der weiteren Diskussion bezüglich Tagging von Eisenbahnanlagen beteiligen will. Wäre er auf dieser Liste gewesen, hätte er vermutlich im Vorfeld an der Diskussion teilnehmen können, statt Verbesserungsvorschläge erst einzubringen, als der Edit "angekündigt" wurde. (Dann wieder - OpenRailwayMap ist eine private Mailingliste auf einer privaten Domain, wo der private Betreiber jeden rauswerfen kann, der ihm nicht passt - insofern stellt sich die Frage, ob eine Meinungsbildung auf der OpenRailwayMap-Liste für OSM überhaupt eine Bedeutung haben sollte.) Ich habe jetzt keine Lust, die hier diskutierten Edits zu reverten, aber ich erwarte künftig vom OpenRailwayMap-Team, dass sie den Rest des Projekts nicht wie Idioten behandeln, die ja eh nichts zu sagen haben, sondern dass man sie und ihre Bedenken ernst nimmt. Dazu zählt, dass man seine Edits nicht bloss "ankündigt", sondern tatsächlich innerlich zu Kompromissen bereit ist, und dazu zählt auch, dass man auf talk-de nicht bloss auftaucht, um Leuten mitzuteilen, dass man mit ihnen jetzt nicht mehr spricht. Ich sehe nicht ein, wieso die Data Working Group extra Arbeit haben soll, bloss weil jemand einen Edit mit dem gerade noch akzeptablen Minimum an Respekt durchziehen will, wenn es nun wirklich nicht schwer gewesen wäre, Konflikte zu vermeiden. Klar ist die Reaktion von fly überhitzt, aber er wurde auch provoziert, und das war unnötig. Die Data Working Group braucht ihre Zeit für Fälle, in denen sich Idioten die Köpfe einschlagen, und nicht für Fälle, bei denen an sich vernünftige und intelligente Mapper mal austesten, wie weit sie gehen können. Das bitte ich künftig zu beachten, *besonders* bei künftigen großflächigen Eisenbahn-Edits, aber eigentlich sowieso immer. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
On Fr, 2015-04-17 at 15:58 +0200, fly wrote: > Wenn schon so viele Objekte angefasst werden, können wir doch vorher uns > auf geschicktes Tagging verständigen und ich sehe dieses Vorgehen immer > noch als mechanischen Edit. > > z.B. könnten wir auch das völlig kaputte System um > railway:signal:direction und railway:signal:position verbessern und dann > alles auf einmal korrigieren. Du bezeichnest das etablierte Tagging als "völlig kaputt", hast aber selbst bislang auch kein besseres Konzept vorgestellt. Zwar hast du immer mal wieder direction=* oder Relationen ins Spiel gebracht, aber mehr als vage Ideen waren das nicht. Erstelle doch mal eine Wikiseite, auf der du deine Ideen detailliert beschreibst, mit ein paar Taggingbeispielen anreicherst und dir Gedanken über die Praxistauglichkeit machst. Danach können wir weiter reden... > Am meisten kotzt mich hier die Art und Weise des Vorgehens und die > mangelnde Bereitschaft sich auf eine konstruktive Diskussion > einzulassen, an. Da stimme ich dir zu. Von deiner Seite fehlen mir bislang konstruktive und durchdachte Vorschläge. > Wie es scheint fehlen hier ein paar grundsätzlichen Verständnisse einer > Gemeinschaft und ich müss jetzt halt doch die DWG einschalten. Habe ich > bisher fast immer erfolgreich vermeiden können. Und was willst du der DWG sagen? Dass die Leute von der OpenRailwayMap ihr Taggingschema nicht nach deinen Vorstellungen ändern wollen? Und was soll die DWG dann dazu sagen? Gruß Alex, der nun ebenfalls keine Lust mehr auf diese Diskussion hat signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Am 17.04.2015 um 10:08 schrieb Martin Koppenhoefer: > Am 17. April 2015 um 09:44 schrieb Michael Reichert : > >> Du scheinst ja noch >> nicht einmal irgendetwas gemappt zu haben, bist also auch nicht für mich >> ernst zu nehmen. >> https://www.openstreetmap.org/user/fly >> > > > das ist wohl Quatsch, wahrscheinlich editiert er unter einem anderen > Namen... Oder zwei, drei ??? Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Am 17.04.2015 um 09:44 schrieb Michael Reichert: > Am 2015-04-16 um 23:24 schrieb fly: >> Und desshalb wird jetzt auch einfach angefangen ohne nochmal Bescheid zu >> sagen. Ohne Zahlem im Wiki. > > Den letzten Satz kann ich nicht unkommentiert stehen lassen. Es handelt > sich schlicht und einfach um eine Lüge/Falschaussage von dir. Im Wiki > steht drin, wie viele Objekte betroffen sind. > > https://wiki.openstreetmap.org/wiki/User:Nakaner/Mechanical_Edit_German_on_Railway_Signals#What_will_be_touched.3F_Which_edits_have_been_done_yet.3F > > (ist eine Weiterleitung von > https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Nakaner-repair) Entschuldige bitte, Michael. Das mit den Zahlen nehme ich zurück. Das habe ich wohl heute Nacht in der Aufregung überlesen. Tut mir Leid. > Kann es sein, dass du einfach nur irgendeinen Quark schreibst, damit du > jeden Tag irgendeinene Mail an Talk-de schreibst? Du scheinst ja noch > nicht einmal irgendetwas gemappt zu haben, bist also auch nicht für mich > ernst zu nehmen. > https://www.openstreetmap.org/user/fly Wer hat denn behauptet, dass dies mein Account ist ? Den Rest spare ich mir hier lieber zu kommentieren. >> Sofort einstellen und zur Diskussion finden ! > > Es handelt sich nicht um einen richtigen mechanischen Edit, da ich von > Anfang an die Signale anschaue und gefundene Taggingfehler (z.B. > Kombinationen, die es in der Realität nicht gibt) entweder korrigiere > (wenn Ortskenntnis vorhanden) oder den User per Änderungssatz-Kommentar > anschreibe. Wenn schon so viele Objekte angefasst werden, können wir doch vorher uns auf geschicktes Tagging verständigen und ich sehe dieses Vorgehen immer noch als mechanischen Edit. z.B. könnten wir auch das völlig kaputte System um railway:signal:direction und railway:signal:position verbessern und dann alles auf einmal korrigieren. Warum müsste das jetzt so schnell über die Bühne gebracht werden. Eine Woche ist ja wohl keine Zeitspanne die ausreicht. Bei emails an user spechen wir doch auch von drei Wochen. Am meisten kotzt mich hier die Art und Weise des Vorgehens und die mangelnde Bereitschaft sich auf eine konstruktive Diskussion einzulassen, an. Wie es scheint fehlen hier ein paar grundsätzlichen Verständnisse einer Gemeinschaft und ich müss jetzt halt doch die DWG einschalten. Habe ich bisher fast immer erfolgreich vermeiden können. fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Hi Michael, alle, Am 17. April 2015 um 09:44 schrieb Michael Reichert : > Hallo fly, > [...] > Es handelt > sich schlicht und einfach um eine Lüge/Falschaussage von dir. > [...] > Kann es sein, dass du einfach nur irgendeinen Quark schreibst, damit du > jeden Tag irgendeinene Mail an Talk-de schreibst? > [...] > Michael, > der mit dir nicht weiter diskutieren wird > kannst Du Dich nicht ein wenig mäßigen? Musst Du Dich so ausdrücken? Ich finden Deinen Stil arrogant, anmaßend und beleidigend! So wollen wir hier nicht miteinander umgehen! ... und was Martin schreibt solltest Du Dir vielleicht auch mal auf einen Zettel schreiben! -- ## Manfred ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Am 17. April 2015 um 09:44 schrieb Michael Reichert : > Du scheinst ja noch > nicht einmal irgendetwas gemappt zu haben, bist also auch nicht für mich > ernst zu nehmen. > https://www.openstreetmap.org/user/fly > das ist wohl Quatsch, wahrscheinlich editiert er unter einem anderen Namen... Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Hallo fly, Am 2015-04-16 um 23:24 schrieb fly: > Und desshalb wird jetzt auch einfach angefangen ohne nochmal Bescheid zu > sagen. Ohne Zahlem im Wiki. Den letzten Satz kann ich nicht unkommentiert stehen lassen. Es handelt sich schlicht und einfach um eine Lüge/Falschaussage von dir. Im Wiki steht drin, wie viele Objekte betroffen sind. https://wiki.openstreetmap.org/wiki/User:Nakaner/Mechanical_Edit_German_on_Railway_Signals#What_will_be_touched.3F_Which_edits_have_been_done_yet.3F (ist eine Weiterleitung von https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Nakaner-repair) Kann es sein, dass du einfach nur irgendeinen Quark schreibst, damit du jeden Tag irgendeinene Mail an Talk-de schreibst? Du scheinst ja noch nicht einmal irgendetwas gemappt zu haben, bist also auch nicht für mich ernst zu nehmen. https://www.openstreetmap.org/user/fly > Sofort einstellen und zur Diskussion finden ! Es handelt sich nicht um einen richtigen mechanischen Edit, da ich von Anfang an die Signale anschaue und gefundene Taggingfehler (z.B. Kombinationen, die es in der Realität nicht gibt) entweder korrigiere (wenn Ortskenntnis vorhanden) oder den User per Änderungssatz-Kommentar anschreibe. Viele Grüße Michael, der mit dir nicht weiter diskutieren wird -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Am 13.04.2015 um 17:24 schrieb fly: > Sorry, vielleicht habe ich den falschen Ton angeschlagen. Anscheinend hatte ich den Kommentar im Forum schon richtig verstanden ! > Danke für die Wochennotiz. > > Macht meiner Meinung trotzdem wenig Sinn nur indirekt beteiligt zu sein. > >> Ist dir noch nicht aufgefallen, dass diese Liste ihre besten Tage hinter >> sich hat? :-) >> https://www.openstreetmap.org/user/Nakaner/diary/34713 Und desshalb wird jetzt auch einfach angefangen ohne nochmal Bescheid zu sagen. Ohne Zahlem im Wiki. Sofort einstellen und zur Diskussion finden ! Ciao fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Am Mittwoch, 15. April 2015, 15:00:40 schrieb fly: > Fände es ja schön wenn auch alle meine Fragen beantwortet werden. > > Insgesamt scheint ja leider kaum Diskussionsbereitschaft vorhanden zu > sein und auf meine Vorschläge wird sich gar nicht erst eingelassen Wie es in den Wald schallt… Für meinen Geschmack nehmt ihr euch da beide nichts. Es sind diverse Gegenargumente gekommen, auf die auch nicht wirklich eingegangen wurde. Ich persönlich bin da eher leidenschaftslos, und am Tagging-Schema auch nicht beteiligt gewesen, also versuche ich es jetzt nochmal von "neutraler" Seite aus. Wenn hier beiden Seiten die Lust am Diskutieren vergeht kann ich es aber vollkommen verstehen, als wirklich konstruktiv habe ich nur wenige Teile der ganzen Diskussion empfunden. > Am 15.04.2015 um 09:27 schrieb Alexander Matheisen: > > On Di, 2015-04-14 at 22:34 +0200, fly wrote: > >> Am 14.04.2015 um 21:13 schrieb Michael Reichert: > >>> Am 2015-04-14 um 19:43 schrieb fly: > railway:signal:main:state:forward=* > >>> > >>> Lass mich raten, das Signal stammt von rayquaza und ist – für > >>> OpenRailwayMap-Verhältnisse – schon ewig gemappt? > >> > >> Nein, nur meiner Logik entsprungen. > > > > du denkst dir ein Tag selbst aus und kritisierst dann, dass es zu lang > > sei, oder wie soll ich das jetzt verstehen? > > Naja, war ja ein Volltreffer und wie willst Du es denn anders > interpretieren ohne die fehlenden Information der Sonderbehandlung ? Ich kann mich Michaels Verwunderung hier nur anschließen. Warum soll man virtuelle Probleme diskutieren, wenn du doch genug echte Probleme ausgemacht haben willst? Lasst uns dann doch auch bitte realitätsnahe Probleme diskutieren, Streitpunkte gibt es ja scheinbar genug, das man nicht noch unnötig neue erfinden muss. > >>> Das sind Versuche, > >>> Signale zu mappen, die für verschiedene Richtungen gelten und am selben > >>> Mast hängen. Es hat sich nie durchgesetzt (das > >>> railway:signal::state:forward/backward=* werten wir nicht aus und > >>> wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz > >>> nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung, > >>> der andere für die andere Richtung. > >> > >> Habe ich das im Wiki überlesen ? > >> Welche Gründe sprechen denn dafür ? > > > > Das Tagging so zu gestalten, dass Signale an einem Mast für verschiedene > > Richtungen eingetragen werden können, würde die Tags noch komplizierter > > machen. Da es nur wenige Signale gibt, wo das vorkommt, haben wir uns > > entschieden, in diesen Fällen zwei Nodes zu taggen und dafür insgesamt > > kürzere Tags zu schaffen. Das ist doch in deinem Sinne, oder? > > Wie kürzere Tags. Mir geht es um die nutzlose Wiederholung. In > Sonderfällen wird dann erweitert. Das heißt doch noch lange nicht, dass > immer die Richtung im Tag benötigt wird. Die Richtung würde nur dann nicht benötigt, wenn in beide Richtungen das gleiche Signalbild gezeigt würde. Das ist so unwahrscheinlich, das man es völlig ignorieren kann. Also braucht es immer die Richtung. > >> Mapped Ihr dann auch noch den Masten ? > >> > >> Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher > >> komplizierter. > > > > Ich finde es deutlich komplizierter, als zwei Nodes zu mappen. > > Wenn es nicht dokumentiert ist, verwirren zwei Punkte. Selbst wenn es > dokumentiert ist, müß es erst gefunden und gelesen werden. Sonst schlägt > Ihr ja auch vor alle Signale auf einen Pubkt zu mappen, nur bei der > Richtung soll dann Schluß sein ? Es gibt zwei Möglichkeiten: 1) beides an einem Node, dann heißt das jeweil eine Tag-Ebene mehr. Fände ich prinzipiell auch gut, weil es z.B. Schneepflug-Signale gibt, die quasi ausschließlich im Doppel auftreten: ein Mast, an einer Seite steht "hoch", an der anderen Seite "runter". Wenn man das sinnvoll vereinheitlichen kann: gerne, immer her damit. Wie würdest du denn so ein Signal eintragen? Hier siehst du sowas bildlich: http://walter-klan.de/signale/08)_ne-signale.html#Ne_7 2) 2 Nodes wie gehabt. Kürzere Tags, dafür liegt das halt nicht direkt übereinander. [Signalrelationen] > Zumindest Links wären dann wohl angebracht. Kann ich mir nichts drunter vorstellen, insofern würde ich das auch lesen. Nach meiner Erfahrung ist aber alles, was man ohne Relation erschlagen kann, ein Gewinn. associatedStreet ist schon schlimm genug, da muss man nicht noch mehr von dem Zeug erfinden. > >> Was war denn jetzt an meinen Vorschlägen jetzt falsch ? > >> > >> state:main:forward=* resp. state:main=* > >> height[:TYPE][:DIRECTION] resp. height[:TYPE] > >> > >> Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ? > >> (railway:signal:main:state=*) > > > > Wie soll man denn so etwas auswerten? Oder JOSM-Vorlagen für so ein > > Tagging erstellen? Denke erstmal etwas über deine Vorschläge nach, bevor > > du solchen Unsinn schreibst. > > Siehe zB :lanes-Tagging > > Was ist bitte an folgendem Beispiel Unsinn ? > > railw
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Fände es ja schön wenn auch alle meine Fragen beantwortet werden. Insgesamt scheint ja leider kaum Diskussionsbereitschaft vorhanden zu sein und auf meine Vorschläge wird sich gar nicht erst eingelassen Am 15.04.2015 um 09:27 schrieb Alexander Matheisen: > On Di, 2015-04-14 at 22:34 +0200, fly wrote: >> Am 14.04.2015 um 21:13 schrieb Michael Reichert: >>> Am 2015-04-14 um 19:43 schrieb fly: >>> railway:signal:main:state:forward=* >>> >>> Lass mich raten, das Signal stammt von rayquaza und ist – für >>> OpenRailwayMap-Verhältnisse – schon ewig gemappt? >> >> Nein, nur meiner Logik entsprungen. > > du denkst dir ein Tag selbst aus und kritisierst dann, dass es zu lang > sei, oder wie soll ich das jetzt verstehen? Naja, war ja ein Volltreffer und wie willst Du es denn anders interpretieren ohne die fehlenden Information der Sonderbehandlung ? >>> Das sind Versuche, >>> Signale zu mappen, die für verschiedene Richtungen gelten und am selben >>> Mast hängen. Es hat sich nie durchgesetzt (das >>> railway:signal::state:forward/backward=* werten wir nicht aus und >>> wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz >>> nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung, >>> der andere für die andere Richtung. >> >> Habe ich das im Wiki überlesen ? >> Welche Gründe sprechen denn dafür ? > > Das Tagging so zu gestalten, dass Signale an einem Mast für verschiedene > Richtungen eingetragen werden können, würde die Tags noch komplizierter > machen. Da es nur wenige Signale gibt, wo das vorkommt, haben wir uns > entschieden, in diesen Fällen zwei Nodes zu taggen und dafür insgesamt > kürzere Tags zu schaffen. Das ist doch in deinem Sinne, oder? Wie kürzere Tags. Mir geht es um die nutzlose Wiederholung. In Sonderfällen wird dann erweitert. Das heißt doch noch lange nicht, dass immer die Richtung im Tag benötigt wird. >> Mapped Ihr dann auch noch den Masten ? >> >> Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher >> komplizierter. > > Ich finde es deutlich komplizierter, als zwei Nodes zu mappen. Wenn es nicht dokumentiert ist, verwirren zwei Punkte. Selbst wenn es dokumentiert ist, müß es erst gefunden und gelesen werden. Sonst schlägt Ihr ja auch vor alle Signale auf einen Pubkt zu mappen, nur bei der Richtung soll dann Schluß sein ? >> Warum nicht gleich eine type=node Relation oder ähnliches, dann ist auch >> die Verknüpfung mit der eigentlichen Position (Masten) möglich und wir >> können jedes Signal einzeln eintragen. > > Das Thema Signalrelationen haben wir in der Vergangenheit schon öfter > auf diversen Kanälen diskutiert und sowohl für Mapper als auch die > Auswerter für nicht praktikabel befunden. Deshalb habe ich keine Lust, > dieses Thema hier wieder neu auszudiskutieren, nur weil du jetzt > plötzlich meinst, das Taggingschema der Signale in Frage zu stellen. Zumindest Links wären dann wohl angebracht. >> >> Was war denn jetzt an meinen Vorschlägen jetzt falsch ? >> >> state:main:forward=* resp. state:main=* >> height[:TYPE][:DIRECTION] resp. height[:TYPE] >> >> Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ? >> (railway:signal:main:state=*) > > Wie soll man denn so etwas auswerten? Oder JOSM-Vorlagen für so ein > Tagging erstellen? Denke erstmal etwas über deine Vorschläge nach, bevor > du solchen Unsinn schreibst. Siehe zB :lanes-Tagging Was ist bitte an folgendem Beispiel Unsinn ? railway=signal signal:main=* state=* height=* ref=* direction=95 >>> Lektüreempfehlung: >>> http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-JlU0vWcI/8332992/data/rw_301_aktualisierung_8.pdf >>> :-) Ein gleichzeitiger Aufenthalt auf einem Bahnhof ist empfehlenswert >>> für Nicht-Bahnaffine. >> >> Nein danke, wenn die Zeit reicht, mache ich mal einige Fotos und >> versuche dann mein Glück >> >> Solch ein Regelwerk ist nicht zumutbar und sollte übersetzt werden, Lese >> ja auch nicht die gesamte STVO um eine Ampel bzw Verkehrsschild einzutragen. > > Wenn du ein wenig im Internet recherchieren würdest, würdest du recht > schnell auf einfachere Erklärungen stoßen. Wikipedia ist ein guter > Anfang, ebenso die auf den ORM-Wikiseiten bei jedem Signal vorhandenen > Links zu weiterführenden Informationen. Wenn du dennoch damit > überfordert bist, dann lass es doch einfach. Es zwingt dich doch > niemand, Bahnsignale einzutragen. Genau, es sind alles Links zu externen Seiten, und auch dort nur Fachabkürzungen und weitere Links. Zu den Beispielen am Ende habe ich schon Kommentare abgegeben. Das ist mir alles doch recht dürftig und absolut nicht für eine größere Gemeinschaft geeignet. Unter solchen Voraussetzungen frage ich mich halt warum das alles in OSM soll. TMC wurde ja schon erwähnt als abschreckendes Beispiel. fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Am 15. April 2015 um 09:27 schrieb Alexander Matheisen < alexandermathei...@ish.de>: > Das Thema Signalrelationen haben wir in der Vergangenheit schon öfter > auf diversen Kanälen diskutiert und sowohl für Mapper als auch die > Auswerter für nicht praktikabel befunden. Deshalb habe ich keine Lust, > dieses Thema hier wieder neu auszudiskutieren, nur weil du jetzt > plötzlich meinst, das Taggingschema der Signale in Frage zu stellen. > für Mapper ist das m.E. einfacher als 2 und mehr genau übereinander liegende Nodes, die man einerseits nicht so einfach erstellen kann (manuelle Koordinateneingabe erforderlich), und wo man später leicht die weiteren Nodes übersieht. Wenn man hingegen nebeneinanderliegende Nodes mappt, stimmt es topologisch nicht (sind ja nicht mehrere Positionen sondern dieselbe). Für Auswerter könnte man es banal so machen: jede Node-relation wird zu einem eigenen Node an derselben Stelle umgewandelt (wobei man dann an dieser Stelle topologisch wieder ein Problem einführt, aber als Resultat nichts schlechteres erhält als bei genau übereinanderliegenden Nodes, und einen Vorteil hat gegenüber "dicht" beieinanderliegenden Nodes) --- oder man müsste sich was eigenes überlegen ;-). Praktikabel ist das in jedem Fall. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
On Di, 2015-04-14 at 22:34 +0200, fly wrote: > Am 14.04.2015 um 21:13 schrieb Michael Reichert: > > Am 2015-04-14 um 19:43 schrieb fly: > >> Am 09.04.2015 um 08:25 schrieb Rolf Eike Beer: > >>> Wenn ich das mit dem Tagging vergleiche, bei dem mir auch regelmäßig > >>> namespace-Tags begegnen, dann ist es doch leicht anders: > >>> > >>> emergency=fire_hydrant > >>> fire_hydrant:type=underground > >>> > >>> railway=signal > >>> railway:signal:... > >> > >> railway:signal:main:state:forward=* > > > > Lass mich raten, das Signal stammt von rayquaza und ist – für > > OpenRailwayMap-Verhältnisse – schon ewig gemappt? > > Nein, nur meiner Logik entsprungen. du denkst dir ein Tag selbst aus und kritisierst dann, dass es zu lang sei, oder wie soll ich das jetzt verstehen? > > Das sind Versuche, > > Signale zu mappen, die für verschiedene Richtungen gelten und am selben > > Mast hängen. Es hat sich nie durchgesetzt (das > > railway:signal::state:forward/backward=* werten wir nicht aus und > > wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz > > nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung, > > der andere für die andere Richtung. > > Habe ich das im Wiki überlesen ? > Welche Gründe sprechen denn dafür ? Das Tagging so zu gestalten, dass Signale an einem Mast für verschiedene Richtungen eingetragen werden können, würde die Tags noch komplizierter machen. Da es nur wenige Signale gibt, wo das vorkommt, haben wir uns entschieden, in diesen Fällen zwei Nodes zu taggen und dafür insgesamt kürzere Tags zu schaffen. Das ist doch in deinem Sinne, oder? > Mapped Ihr dann auch noch den Masten ? > > Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher > komplizierter. Ich finde es deutlich komplizierter, als zwei Nodes zu mappen. > Warum nicht gleich eine type=node Relation oder ähnliches, dann ist auch > die Verknüpfung mit der eigentlichen Position (Masten) möglich und wir > können jedes Signal einzeln eintragen. Das Thema Signalrelationen haben wir in der Vergangenheit schon öfter auf diversen Kanälen diskutiert und sowohl für Mapper als auch die Auswerter für nicht praktikabel befunden. Deshalb habe ich keine Lust, dieses Thema hier wieder neu auszudiskutieren, nur weil du jetzt plötzlich meinst, das Taggingschema der Signale in Frage zu stellen. > >> Wenn möglich sollte doch der ein oder andere Tag auch mit weniger > >> Pre-/Postfixen auskommen (siehe auch :lanes-Tagging). > >> > >> state:main:forward=* > >> > >> bzw wenn möglich sogar nur > >> > >> state=* > >> height[:TYPE][:DIRECTION] > >> Eindeutig ist das ganze doch schon durch railway=signal > >> > >>> Das macht die Zuordnung "interessiert mich der key" für den Benutzer > >>> etwas > >>> einfacher, aber andere Dinge wir "ref" fallen da trotzdem aus der > >>> Reihe[1]. > >> > >> Welche Benutzer*innen meinst Du ? > >> > >> Bei Vorlagen ist es erstmal egal aber aufgelistet füllen solche langen > >> Schlüssel schon eine Menge Platz aus und die wichtige Information steht > >> am Ende. > >> > >>> Ich sehe nicht, dass der Verzicht auf "railway:" bei den key-Namen eine > >>> große > >>> Verwirrung stiften würde, da der Rest der Keys, zumindest so weit ich das > >>> überblicken kann, zu Kollisionen mit anderen Taggings führen würde. > >> > >> Wolltest wohl "zu keinen Kollisionen" schreiben > >> > >> Kann mir auch nicht richtig Probleme vorstellen in Bezug auf railway=signal > > > > An einem Hauptsignalmasten hängen oft (Signaltyp laut Taggingschema in > > eckigen Klammern): > > - ein Vorsignal (v.a. in Bahnhöfen und auf stark befahrenen Strecken) > > [distant] > > - ein Geschwindigkeitsanzeiger [speed] und/oder > > Geschwindigkeitsvoranzeiger [speed_limit] > > - ein Gegengleisanzeiger (bei Ausfahrsignalen) [wrong_road] > > - ein Richtungsvoranzeiger [route_distant] und/oder Richtungsanzeiger > > [route](bei Streckenverzweigungen und mancherorts auch bei > > Gleiswechseln) > > - eine Haltetafel [stop] (die mit dem H) > > - Ein Hauptsignal hat oft auch noch die Funktion eines Rangiersignals > > [minor]. > > Was war denn jetzt an meinen Vorschlägen jetzt falsch ? > > state:main:forward=* resp. state:main=* > height[:TYPE][:DIRECTION] resp. height[:TYPE] > > Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ? > (railway:signal:main:state=*) Wie soll man denn so etwas auswerten? Oder JOSM-Vorlagen für so ein Tagging erstellen? Denke erstmal etwas über deine Vorschläge nach, bevor du solchen Unsinn schreibst. > > Lektüreempfehlung: > > http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-JlU0vWcI/8332992/data/rw_301_aktualisierung_8.pdf > > :-) Ein gleichzeitiger Aufenthalt auf einem Bahnhof ist empfehlenswert > > für Nicht-Bahnaffine. > > Nein danke, wenn die Zeit reicht, mache ich mal einige Fotos und > versuche dann mein Glück > > Solch ein Regelwerk ist nicht zumutbar und sollte übersetzt werden, Lese > ja auch nicht die gesamte STVO um eine Amp
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
> Am 14.04.2015 um 21:13 schrieb Michael Reichert : > > An einem Hauptsignalmasten hängen oft (Signaltyp laut Taggingschema in > eckigen Klammern): > - ein Vorsignal (v.a. in Bahnhöfen und auf stark befahrenen Strecken) > [distant] > - ein Geschwindigkeitsanzeiger [speed] und/oder > Geschwindigkeitsvoranzeiger [speed_limit] > - ein Gegengleisanzeiger (bei Ausfahrsignalen) [wrong_road] > - ein Richtungsvoranzeiger [route_distant] und/oder Richtungsanzeiger > [route](bei Streckenverzweigungen und mancherorts auch bei > Gleiswechseln) > - eine Haltetafel [stop] (die mit dem H) > - Ein Hauptsignal hat oft auch noch die Funktion eines Rangiersignals > [minor]. evtl ein Fall für die Node-Relation? Oder die provides Feature Relation? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Am 14.04.2015 um 21:13 schrieb Michael Reichert: > Am 2015-04-14 um 19:43 schrieb fly: >> Am 09.04.2015 um 08:25 schrieb Rolf Eike Beer: >>> Wenn ich das mit dem Tagging vergleiche, bei dem mir auch regelmäßig >>> namespace-Tags begegnen, dann ist es doch leicht anders: >>> >>> emergency=fire_hydrant >>> fire_hydrant:type=underground >>> >>> railway=signal >>> railway:signal:... >> >> railway:signal:main:state:forward=* > > Lass mich raten, das Signal stammt von rayquaza und ist – für > OpenRailwayMap-Verhältnisse – schon ewig gemappt? Nein, nur meiner Logik entsprungen. > Das sind Versuche, > Signale zu mappen, die für verschiedene Richtungen gelten und am selben > Mast hängen. Es hat sich nie durchgesetzt (das > railway:signal::state:forward/backward=* werten wir nicht aus und > wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz > nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung, > der andere für die andere Richtung. Habe ich das im Wiki überlesen ? Welche Gründe sprechen denn dafür ? Mapped Ihr dann auch noch den Masten ? Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher komplizierter. Warum nicht gleich eine type=node Relation oder ähnliches, dann ist auch die Verknüpfung mit der eigentlichen Position (Masten) möglich und wir können jedes Signal einzeln eintragen. Sehe ähnliche Probleme auch beim Mirkromappen von traffic_sign und traffic_signal, wo es wohl über kurz oder lang auch Relationen bedarf, wenn ich zB mehre Zeichen übereinander an einer Straßenlaterne befinden und ich die Höhe (height) eintragen will. >> Wenn möglich sollte doch der ein oder andere Tag auch mit weniger >> Pre-/Postfixen auskommen (siehe auch :lanes-Tagging). >> >> state:main:forward=* >> >> bzw wenn möglich sogar nur >> >> state=* >> height[:TYPE][:DIRECTION] >> Eindeutig ist das ganze doch schon durch railway=signal >> >>> Das macht die Zuordnung "interessiert mich der key" für den Benutzer etwas >>> einfacher, aber andere Dinge wir "ref" fallen da trotzdem aus der Reihe[1]. >> >> Welche Benutzer*innen meinst Du ? >> >> Bei Vorlagen ist es erstmal egal aber aufgelistet füllen solche langen >> Schlüssel schon eine Menge Platz aus und die wichtige Information steht >> am Ende. >> >>> Ich sehe nicht, dass der Verzicht auf "railway:" bei den key-Namen eine >>> große >>> Verwirrung stiften würde, da der Rest der Keys, zumindest so weit ich das >>> überblicken kann, zu Kollisionen mit anderen Taggings führen würde. >> >> Wolltest wohl "zu keinen Kollisionen" schreiben >> >> Kann mir auch nicht richtig Probleme vorstellen in Bezug auf railway=signal > > An einem Hauptsignalmasten hängen oft (Signaltyp laut Taggingschema in > eckigen Klammern): > - ein Vorsignal (v.a. in Bahnhöfen und auf stark befahrenen Strecken) > [distant] > - ein Geschwindigkeitsanzeiger [speed] und/oder > Geschwindigkeitsvoranzeiger [speed_limit] > - ein Gegengleisanzeiger (bei Ausfahrsignalen) [wrong_road] > - ein Richtungsvoranzeiger [route_distant] und/oder Richtungsanzeiger > [route](bei Streckenverzweigungen und mancherorts auch bei > Gleiswechseln) > - eine Haltetafel [stop] (die mit dem H) > - Ein Hauptsignal hat oft auch noch die Funktion eines Rangiersignals > [minor]. Was war denn jetzt an meinen Vorschlägen jetzt falsch ? state:main:forward=* resp. state:main=* height[:TYPE][:DIRECTION] resp. height[:TYPE] Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ? (railway:signal:main:state=*) > Für eine vernünftige Erfassung muss man von jedem Signal nicht nur > erfassen, was es ist (z.B. Geschwindigkeitsvoranzeiger Zs 3v), sondern > auch die Signalisierungsart (Schild, Formsignal, Lichtsignal), die > möglichen Signalbilder bzw. anzeigbaren Kennziffern/-buchstaben usw. > > Das railway:*-Präfix zeigt dem Nicht-Eisenbahnmapper, dass das Tag mit > Bahn zu tun hat. Und genau da frage ich, welche anderen Tags sollten den an so einem Punkt noch vorhanden sein, welche sich nicht auf railway=signal beziehen ? Mir fällt da nur so was wie man_made=mast/pole ein, aber wir taggen ja nicht die exakte Position. > Funktioniert bei TMC ja auch (ok, ich lese auch > jedesmal die Doku, bevor ich da etwas ändere, tue das aber auch bloß > einmal pro Jahr). TMC ist ja wohl ein Beispiel, das ich lieber nicht erwähnen würde. Das neue Schema sieht da schon besser aus, allerdings bin ich auch noch nicht dazu gekommen es richtig auszuprobieren. > Lektüreempfehlung: > http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-JlU0vWcI/8332992/data/rw_301_aktualisierung_8.pdf > :-) Ein gleichzeitiger Aufenthalt auf einem Bahnhof ist empfehlenswert > für Nicht-Bahnaffine. Nein danke, wenn die Zeit reicht, mache ich mal einige Fotos und versuche dann mein Glück Solch ein Regelwerk ist nicht zumutbar und sollte übersetzt werden, Lese ja auch nicht die gesamte STVO um eine Ampel bzw Verkehrsschild einzutragen. Habt Ihr mal die Möglichkeit Tags an die Linien (railw
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Hallo, Am 2015-04-14 um 19:43 schrieb fly: > Am 09.04.2015 um 08:25 schrieb Rolf Eike Beer: >> Am Mittwoch, 8. April 2015, 20:36:13 schrieb Martin Koppenhoefer: Am 08.04.2015 um 15:17 schrieb fly : Warum eigentlich railway: als "name space" ? >>> >>> ich finde so einen namespace dort nicht schlecht, wo es um Spezialistentags >>> geht. Hauptsignale und Ähnliches wird wohl nicht jeder eintragen, und durch >>> den Präfix wird auch demjenigen, der diese Spezialtags nicht alle kennt, >>> schonmal ungefähr ein Kontext vermittelt (Eisenbahn in diesem Fall), ohne >>> dass er gleich die genaue Bedeutung im Wiki recherchieren müsste >> >> Wenn ich das mit dem Tagging vergleiche, bei dem mir auch regelmäßig >> namespace-Tags begegnen, dann ist es doch leicht anders: >> >> emergency=fire_hydrant >> fire_hydrant:type=underground >> >> railway=signal >> railway:signal:... > > railway:signal:main:state:forward=* Lass mich raten, das Signal stammt von rayquaza und ist – für OpenRailwayMap-Verhältnisse – schon ewig gemappt? Das sind Versuche, Signale zu mappen, die für verschiedene Richtungen gelten und am selben Mast hängen. Es hat sich nie durchgesetzt (das railway:signal::state:forward/backward=* werten wir nicht aus und wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung, der andere für die andere Richtung. > Wenn möglich sollte doch der ein oder andere Tag auch mit weniger > Pre-/Postfixen auskommen (siehe auch :lanes-Tagging). > > state:main:forward=* > > bzw wenn möglich sogar nur > > state=* > height[:TYPE][:DIRECTION] > Eindeutig ist das ganze doch schon durch railway=signal > >> Das macht die Zuordnung "interessiert mich der key" für den Benutzer etwas >> einfacher, aber andere Dinge wir "ref" fallen da trotzdem aus der Reihe[1]. > > Welche Benutzer*innen meinst Du ? > > Bei Vorlagen ist es erstmal egal aber aufgelistet füllen solche langen > Schlüssel schon eine Menge Platz aus und die wichtige Information steht > am Ende. > >> Ich sehe nicht, dass der Verzicht auf "railway:" bei den key-Namen eine >> große >> Verwirrung stiften würde, da der Rest der Keys, zumindest so weit ich das >> überblicken kann, zu Kollisionen mit anderen Taggings führen würde. > > Wolltest wohl "zu keinen Kollisionen" schreiben > > Kann mir auch nicht richtig Probleme vorstellen in Bezug auf railway=signal An einem Hauptsignalmasten hängen oft (Signaltyp laut Taggingschema in eckigen Klammern): - ein Vorsignal (v.a. in Bahnhöfen und auf stark befahrenen Strecken) [distant] - ein Geschwindigkeitsanzeiger [speed] und/oder Geschwindigkeitsvoranzeiger [speed_limit] - ein Gegengleisanzeiger (bei Ausfahrsignalen) [wrong_road] - ein Richtungsvoranzeiger [route_distant] und/oder Richtungsanzeiger [route](bei Streckenverzweigungen und mancherorts auch bei Gleiswechseln) - eine Haltetafel [stop] (die mit dem H) - Ein Hauptsignal hat oft auch noch die Funktion eines Rangiersignals [minor]. Für eine vernünftige Erfassung muss man von jedem Signal nicht nur erfassen, was es ist (z.B. Geschwindigkeitsvoranzeiger Zs 3v), sondern auch die Signalisierungsart (Schild, Formsignal, Lichtsignal), die möglichen Signalbilder bzw. anzeigbaren Kennziffern/-buchstaben usw. Das railway:*-Präfix zeigt dem Nicht-Eisenbahnmapper, dass das Tag mit Bahn zu tun hat. Funktioniert bei TMC ja auch (ok, ich lese auch jedesmal die Doku, bevor ich da etwas ändere, tue das aber auch bloß einmal pro Jahr). Viele Grüße Michael Lektüreempfehlung: http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-JlU0vWcI/8332992/data/rw_301_aktualisierung_8.pdf :-) Ein gleichzeitiger Aufenthalt auf einem Bahnhof ist empfehlenswert für Nicht-Bahnaffine. -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Am 09.04.2015 um 08:25 schrieb Rolf Eike Beer: > Am Mittwoch, 8. April 2015, 20:36:13 schrieb Martin Koppenhoefer: >>> Am 08.04.2015 um 15:17 schrieb fly : >>> >>> Warum eigentlich railway: als "name space" ? >> >> ich finde so einen namespace dort nicht schlecht, wo es um Spezialistentags >> geht. Hauptsignale und Ähnliches wird wohl nicht jeder eintragen, und durch >> den Präfix wird auch demjenigen, der diese Spezialtags nicht alle kennt, >> schonmal ungefähr ein Kontext vermittelt (Eisenbahn in diesem Fall), ohne >> dass er gleich die genaue Bedeutung im Wiki recherchieren müsste > > Wenn ich das mit dem Tagging vergleiche, bei dem mir auch regelmäßig > namespace-Tags begegnen, dann ist es doch leicht anders: > > emergency=fire_hydrant > fire_hydrant:type=underground > > railway=signal > railway:signal:... railway:signal:main:state:forward=* Ohne auf direction=* einzugehen, halte ich vier Pre- bzw Postfixe selbst mit Muttersprache Deutsch doch viel. Wenn möglich sollte doch der ein oder andere Tag auch mit weniger Pre-/Postfixen auskommen (siehe auch :lanes-Tagging). state:main:forward=* bzw wenn möglich sogar nur state=* height[:TYPE][:DIRECTION] Eindeutig ist das ganze doch schon durch railway=signal > Das macht die Zuordnung "interessiert mich der key" für den Benutzer etwas > einfacher, aber andere Dinge wir "ref" fallen da trotzdem aus der Reihe[1]. Welche Benutzer*innen meinst Du ? Bei Vorlagen ist es erstmal egal aber aufgelistet füllen solche langen Schlüssel schon eine Menge Platz aus und die wichtige Information steht am Ende. > Ich sehe nicht, dass der Verzicht auf "railway:" bei den key-Namen eine große > Verwirrung stiften würde, da der Rest der Keys, zumindest so weit ich das > überblicken kann, zu Kollisionen mit anderen Taggings führen würde. Wolltest wohl "zu keinen Kollisionen" schreiben Kann mir auch nicht richtig Probleme vorstellen in Bezug auf railway=signal Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Sorry, vielleicht habe ich den falschen Ton angeschlagen. Am 08.04.2015 um 21:15 schrieb Michael Reichert: > Am 2015-04-07 um 15:09 schrieb fly: >> Grundsätzlich spricht nichts gegen eine Anpassung, allerdings sollten >> solche Änderungen möglichst breit diskutiert werden und dann bringt es >> nichts wenn der Autor hier nicht einmal persönlich einen Link >> veröffentlicht und dann auch mitdiskutiert ! > > Der Autor ist Teil des Wochennotiz-Teams und hat selbst dafür gesorgt, > dass in der in wenigen Stunden erscheinenden Wochennotiz die Diskussion > im Forum verlinkt ist. Da er eh anschließend noch ein paar Tage gewartet > hätte, war das in seinen Augen kein Ausschluss derjenigen, die nicht im > Forum aktiv sind. Danke für die Wochennotiz. Macht meiner Meinung trotzdem wenig Sinn nur indirekt beteiligt zu sein. > Ist dir noch nicht aufgefallen, dass diese Liste ihre besten Tage hinter > sich hat? :-) > https://www.openstreetmap.org/user/Nakaner/diary/34713 Das ist wohl eine getrennte Diskussion wert. Siehe unter anderem tagging@ >> Gibt es Proposals ? > > "You can tag what you want" habe ich mal gelernt. Wenn das nicht mehr > gelten sollte, dann ist OSM ja fast so schlimm wie das > Crowdsourcing-Projekt mit dem W. Hey wir sprechen von einem Mechanical Edit. Habe kein Problem damit wenn vor Ort besichtigt und dann entsprechend getaggt wird. > Das Signaltagging wird auf einer Liste mit öffentlichem Archiv > diskutiert und ist sauber dokumentiert. Zwar lief ein Teil der > Diskussion der vergangen zwölf Monate nicht auf einer Mailingliste, > sondern im Real-Life, aber zu den Veranstaltungen wurde eingeladen. Die > Tagesordnungen waren vorab öffentlich im Wiki, die Protokolle sind es > (sogar ins Englische übersetzt!) auch. Auch an Links in der Wochennotiz > hat es nicht gemangelt. Wenn du die Wochennotiz nicht liest, dann kann > ich dir nicht weiterhelfen. > > http://lists.openrailwaymap.org/archives/openrailwaymap/ > https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Mappingwochenende_2014_1 > https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Aktiventreffen_2014_2 Sorry, aber die Seiten bietet nur ein Anfang. Proposals für die einzelnen Abschnitte wären dann der nächste Schritt. Sollte nach dieser intensiven Beschäftigung mit dem Thema ja auch kein Problem sein und dann wären auch so Fragen wie nach dem Namensraum oder der Länderspezifizierung schon geklärt. Wenn ich mir die Wikiseite zu railway=signal anschaue [1] finde ich schon den ersten fürchterlichen Redirekt (english -> deutsch) und dann einen einzigen Link. Inhalt fehlt, zB Vergleich mit traffic_sign, andere Länder, häufige Kombinationen bzw Zusatztags. Die beiden am häufigsten verwendeten Kombination haben Wikiseiten, allerdings sind das auch nur wieder Redirekts. Zu railway:signal:main:states finde ich im Wiki überhaupt keine Info. Grüße fly P.S.: support=* vermisse ich komplett, habt Ihr das übersehen ? [1] https://wiki.openstreetmap.org/wiki/Tag:railway%3Dsignal ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Am Mittwoch, 8. April 2015, 20:36:13 schrieb Martin Koppenhoefer: > > Am 08.04.2015 um 15:17 schrieb fly : > > > > Warum eigentlich railway: als "name space" ? > > ich finde so einen namespace dort nicht schlecht, wo es um Spezialistentags > geht. Hauptsignale und Ähnliches wird wohl nicht jeder eintragen, und durch > den Präfix wird auch demjenigen, der diese Spezialtags nicht alle kennt, > schonmal ungefähr ein Kontext vermittelt (Eisenbahn in diesem Fall), ohne > dass er gleich die genaue Bedeutung im Wiki recherchieren müsste Wenn ich das mit dem Tagging vergleiche, bei dem mir auch regelmäßig namespace-Tags begegnen, dann ist es doch leicht anders: emergency=fire_hydrant fire_hydrant:type=underground railway=signal railway:signal:... Das macht die Zuordnung "interessiert mich der key" für den Benutzer etwas einfacher, aber andere Dinge wir "ref" fallen da trotzdem aus der Reihe[1]. Ich sehe nicht, dass der Verzicht auf "railway:" bei den key-Namen eine große Verwirrung stiften würde, da der Rest der Keys, zumindest so weit ich das überblicken kann, zu Kollisionen mit anderen Taggings führen würde. tl;dr: der Namespace ist nett, aber ich sehe keinen zwingenden Grund dafür (oder ihn zu entfernen). Eike signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Hallo, Am 2015-04-07 um 15:09 schrieb fly: > Grundsätzlich spricht nichts gegen eine Anpassung, allerdings sollten > solche Änderungen möglichst breit diskutiert werden und dann bringt es > nichts wenn der Autor hier nicht einmal persönlich einen Link > veröffentlicht und dann auch mitdiskutiert ! Der Autor ist Teil des Wochennotiz-Teams und hat selbst dafür gesorgt, dass in der in wenigen Stunden erscheinenden Wochennotiz die Diskussion im Forum verlinkt ist. Da er eh anschließend noch ein paar Tage gewartet hätte, war das in seinen Augen kein Ausschluss derjenigen, die nicht im Forum aktiv sind. Ist dir noch nicht aufgefallen, dass diese Liste ihre besten Tage hinter sich hat? :-) https://www.openstreetmap.org/user/Nakaner/diary/34713 > Gibt es Proposals ? "You can tag what you want" habe ich mal gelernt. Wenn das nicht mehr gelten sollte, dann ist OSM ja fast so schlimm wie das Crowdsourcing-Projekt mit dem W. Das Signaltagging wird auf einer Liste mit öffentlichem Archiv diskutiert und ist sauber dokumentiert. Zwar lief ein Teil der Diskussion der vergangen zwölf Monate nicht auf einer Mailingliste, sondern im Real-Life, aber zu den Veranstaltungen wurde eingeladen. Die Tagesordnungen waren vorab öffentlich im Wiki, die Protokolle sind es (sogar ins Englische übersetzt!) auch. Auch an Links in der Wochennotiz hat es nicht gemangelt. Wenn du die Wochennotiz nicht liest, dann kann ich dir nicht weiterhelfen. http://lists.openrailwaymap.org/archives/openrailwaymap/ https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Mappingwochenende_2014_1 https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Aktiventreffen_2014_2 Viele Grüße Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
> Am 08.04.2015 um 15:17 schrieb fly : > > Warum eigentlich railway: als "name space" ? ich finde so einen namespace dort nicht schlecht, wo es um Spezialistentags geht. Hauptsignale und Ähnliches wird wohl nicht jeder eintragen, und durch den Präfix wird auch demjenigen, der diese Spezialtags nicht alle kennt, schonmal ungefähr ein Kontext vermittelt (Eisenbahn in diesem Fall), ohne dass er gleich die genaue Bedeutung im Wiki recherchieren müsste Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
> >> * Warum werden den die Werte als Abkürzungen definiert ? Was spricht > >> gegen zB Hauptsignal statt hp ? > > > > Es handelt sich dabei um offizielle Abkürzungen, die durch das > > Signalbuch festgelegt sind (so wie die Verkehrszeichen in der StVO). > > Unter Eisenbahnern sind diese Abkürzungen auch gebräuchlicher als die > > Langnamen. > > > > Ausgeschriebene Bezeichnungen werden z.B. bei den österreichischen > > Signalen verwendet, da dort die Signale keine offiziellen Abkürzungen > > tragen. > > Im Sinne der allgemeinen Benutzerfreundlichkeit wären dann immer noch > Werte ohne Abkürzungen besser. Das Unterscheidet sich nicht von Verkehrszeichen, auch da wird mit den entsprechenden Abkürzungen getaggt (http://wiki.openstreetmap.org/wiki/Traffic_sign#Traffic_sign_IDs) Außerdem sehe ich nicht, was einem Benutzer da groß hilft. Die Funktion wird bereits über den key beschrieben, z.B. railway:signal:main, damit ist bereits gesagt, dass es ein Hauptsignal ist. Über den key wird dann nur noch die genaue Art festgelegt, ähnlich dem Verkehrszeichen. Außerdem sind insbesondere im Bereich der DB-ESO die Begriffe wie "Hauptsignale" nicht eindeutig: es gibt mindestens 5 in Deutschland von der DB verwendete Signalsysteme, und alle haben ein Hauptsignal. railway:signal:main=DE-ESO:Hauptsignal sagt also in key und value das gleiche und lässt die interessanten Details letztlich aus. > > Ansonsten verstehe ich nicht so genau, was du eigentlich kritisierst... > > Taginfo zeigt ja schon zehntausende Treffer für railway:signal* [2] > jedoch hat kein einziger Schlüssel eine Wiki-Seite. http://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Tagging_in_Germany Vielleicht sollte man von mal ein paar (Dutzend) redirects einbauen ;) Eike signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Am 07.04.2015 um 16:08 schrieb Alexander Matheisen: > Hallo, > > On Di, 2015-04-07 at 15:09 +0200, fly wrote: >> Grundsätzlich spricht nichts gegen eine Anpassung, allerdings sollten >> solche Änderungen möglichst breit diskutiert werden und dann bringt es >> nichts wenn der Autor hier nicht einmal persönlich einen Link >> veröffentlicht und dann auch mitdiskutiert ! > > ich nehme an, dass Nakaner das schlicht vergessen hat. Nein siehe Forum [1]. >> * Warum werden den die Werte als Abkürzungen definiert ? Was spricht >> gegen zB Hauptsignal statt hp ? > > Es handelt sich dabei um offizielle Abkürzungen, die durch das > Signalbuch festgelegt sind (so wie die Verkehrszeichen in der StVO). > Unter Eisenbahnern sind diese Abkürzungen auch gebräuchlicher als die > Langnamen. > > Ausgeschriebene Bezeichnungen werden z.B. bei den österreichischen > Signalen verwendet, da dort die Signale keine offiziellen Abkürzungen > tragen. Im Sinne der allgemeinen Benutzerfreundlichkeit wären dann immer noch Werte ohne Abkürzungen besser. >> Die Beispiele am Ende hängen in der Luft und genau die Unterschiede sind >> nicht herausgearbeitet, da nur jeweils ein Beispiel für jeden Haupttag >> vorhanden ist. Noch sind die Tags railway:signal:main=*, >> railway:signal:combined=*, railway:signal:*:states=* und was da noch so >> herumschwirrt gut dokumentiert. Das Hauptsignal und das stillgelegte >> Signal verwenden exakt das gleiche Bild ! > > Es könnten definitiv noch ein paar mehr Beispiele auf der Seite stehen. > Mit der Zeit werden sicherlich auch noch einige dazukommen. > > Ansonsten verstehe ich nicht so genau, was du eigentlich kritisierst... Taginfo zeigt ja schon zehntausende Treffer für railway:signal* [2] jedoch hat kein einziger Schlüssel eine Wiki-Seite. Ich habe mich jetzt bemüht aber die einzelnen Schlüssel sind nirgends im Wiki mit ein paar klaren Sätzen beschrieben. Wie soll ich dann wissen was zB. railway:signal:*:states=* oder railway:signal:main:height=normal überhaupt bedeutet ? >> Gibt es Proposals ? Habe ein altes gefunden [3]. > Nein. Schade, denn das ist ein guter Ansatz für die Dokumentation. >> Insgesamt ist die Situation eher unbefriedigend, da es sich hier wohl >> eher um einen kleineren Kreis von Profis handelt und interessierte Laien >> schon Probleme bekommen. > > Mit der Verwendung der JOSM-Vorlagen kann man sich das Eintragen der > Signale schonmal deutlich vereinfachen. Etwas Bahnwissen gehört aber > dennoch dazu, das gebe ich zu. Das hebt zwar die Einstiegshürde und > schreckt die große Masse ab, sichert aber auch eine gewisse Qualität der > Daten. Mit diesem Argument kannst Du auch gleich iD abschaffen ! Wie soll ich denn etwas bewerten, wenn ich mich erst einmal kreuz und quer durchlesen will. >> Auch wird, nach wie vor, an forward/backward und left/right an Punkten >> festgehalten, was so von keinem einzigen Editor unterstützt wird. > > Das ist momentan eben die beste Möglichkeit, um einerseits die Daten > einfach eintragen zu können, andererseits auch gut auswerten zu können. > Wenn du eine bessere Idee hast, kannst du uns die gerne vorstellen. Schon mal über direction=* [4] nachgedacht ? Im Zweifel würde ich halt nur N, S, W, E und im Zweifel auch noch NW, NE, SW und SE verwenden. Dann könnte left/right sogar funktionieren. Aber vorsichtig, direction=* ist die Richtung, in die das Signal zeigt und somit entgegengesetzt zur Fahrtrichtung. Warum eigentlich railway: als "name space" ? Wenn möglich sollten doch allgemein gültige Tags auch funktionieren. >> Somit komme ich zu dem Schluss, dass es wohl immer noch an einer >> gelungen Ausarbeitung des Tagging-Schemas und der entsprechenden auch >> für "normale" User verständlichen Wikiseiten fehlt und ein mechanischer >> Edit zur Zeit zu wenig Verbesserung mit sich bringt. > > Hast du konkrete Verbesserungsvorschläge für die Wikiseiten? s.o. Insgesamt wäre es schön, wenn die Openrailway-Fraktion aus ihren separaten Gruppen heraustritt und mehr mit der gesamten Gemeinschaft diskutiert. (tagging@, talk-de@ und warum nicht sogar talk@) IM sehe ich hier einige Parallelen zu Openseamap und auch dort haben sich Ungereimtheiten eingeschlichen. > Der mechanische Edit bringt deutliche Verbesserungen. Er vereinheitlicht > das Tagging und korrigiert "Design-Fehler", die wir beim Entwurf des > Taggingschemas gemacht haben, nämlich die fehlende internationale > Eindeutigkeit der Tags. Grundsätzlich habe ich nichts dagegen und warte dann mal auf die entsprechende Wiki-Seite über den Edit. Genau Angaben über die Anzahl der Objekte sind immer hilfreich. Allerdings hilft es uns auch nicht wenn Fehler mit anderen Ungereimtheiten korrigiert werden und dann in naher Zukunft der nächste mechanische Edit bevor steht. Grüße fly [1] http://forum.openstreetmap.org/viewtopic.php?pid=495894#p495894 [2] https://taginfo.openstreetmap.org/search?q=railway%3Asignal [3] https://wiki.openstreetmap.org/wiki/Proposed_features/Railway_Signals [4] htt
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Hallo, On Di, 2015-04-07 at 15:09 +0200, fly wrote: > Grundsätzlich spricht nichts gegen eine Anpassung, allerdings sollten > solche Änderungen möglichst breit diskutiert werden und dann bringt es > nichts wenn der Autor hier nicht einmal persönlich einen Link > veröffentlicht und dann auch mitdiskutiert ! ich nehme an, dass Nakaner das schlicht vergessen hat. > * Wie sieht das denn im Ausland aus ? Wurde auch über den Tellerrand > (Europa) hinausgeschaut ? Andere Länder sind nicht betroffen (Ausnahme: Österreich), da es anfangs nur ein Taggingschema für Deutschland gab. Somit gibt es im Ausland im Grunde keine Signale, da ja bisher ein Taggingschema dafür fehlte. Beim Entwurf des Schemas für Österreich wurde das Problem der fehlenden Eindeutigkeit erkannt und von Anfang an das Länderkürzel AT: verwendet. Da wir ja mittlerweile ein Länder-Betreiber-Präfix verwenden, ist das auch nicht mehr ganz korrekt. Da es aber nicht viele Signale mit dem alten Schema gibt und ein Großteil davon auch von mir erfasst wurden, sehe ich hier erstmal keinen Bedarf für größere Umtagaktionen. Das Taggingschema für die Schweiz, das vor wenigen Tagen fertiggestellt wurde, verwendet von Anfang an das neue Länder-Betreiber-Präfix. > * Können wir kein internationales Schema entwickeln und nur > länderspezifische Signale mit LC erweitern. Alle Signale sind länderspezifisch! Das Taggingschema ist ja schon weitgehend international ausgelegt, sodass die Art und Bedeutung des Signals mit einem generischen Schema abgebildet wird. Nur muss eben trotzdem bei jedem Signal der konkrete länderspezifische Typ mitgetaggt werden, weil sonst wichtige Informationen fehlen. > * Warum werden den die Werte als Abkürzungen definiert ? Was spricht > gegen zB Hauptsignal statt hp ? Es handelt sich dabei um offizielle Abkürzungen, die durch das Signalbuch festgelegt sind (so wie die Verkehrszeichen in der StVO). Unter Eisenbahnern sind diese Abkürzungen auch gebräuchlicher als die Langnamen. Ausgeschriebene Bezeichnungen werden z.B. bei den österreichischen Signalen verwendet, da dort die Signale keine offiziellen Abkürzungen tragen. > * Wie wäre es mit operator=* anstatt der Präfixe der Werte ? Das ist nicht praktikabel. Um etwa auf einer Karte das richtige Signalicon zu zeichnen, müsste man nämlich die externe Information haben, welche Signale und welches Regelwerk bei einem bestimmten Betreiber verwendet werden. Außerdem können an einem Signalmast auch Signale verschiedener Signalordnungen hängen. > Die Beispiele am Ende hängen in der Luft und genau die Unterschiede sind > nicht herausgearbeitet, da nur jeweils ein Beispiel für jeden Haupttag > vorhanden ist. Noch sind die Tags railway:signal:main=*, > railway:signal:combined=*, railway:signal:*:states=* und was da noch so > herumschwirrt gut dokumentiert. Das Hauptsignal und das stillgelegte > Signal verwenden exakt das gleiche Bild ! Es könnten definitiv noch ein paar mehr Beispiele auf der Seite stehen. Mit der Zeit werden sicherlich auch noch einige dazukommen. Ansonsten verstehe ich nicht so genau, was du eigentlich kritisierst... > Gibt es Proposals ? Nein. > Insgesamt ist die Situation eher unbefriedigend, da es sich hier wohl > eher um einen kleineren Kreis von Profis handelt und interessierte Laien > schon Probleme bekommen. Mit der Verwendung der JOSM-Vorlagen kann man sich das Eintragen der Signale schonmal deutlich vereinfachen. Etwas Bahnwissen gehört aber dennoch dazu, das gebe ich zu. Das hebt zwar die Einstiegshürde und schreckt die große Masse ab, sichert aber auch eine gewisse Qualität der Daten. > Auch wird, nach wie vor, an forward/backward und left/right an Punkten > festgehalten, was so von keinem einzigen Editor unterstützt wird. Das ist momentan eben die beste Möglichkeit, um einerseits die Daten einfach eintragen zu können, andererseits auch gut auswerten zu können. Wenn du eine bessere Idee hast, kannst du uns die gerne vorstellen. > Somit komme ich zu dem Schluss, dass es wohl immer noch an einer > gelungen Ausarbeitung des Tagging-Schemas und der entsprechenden auch > für "normale" User verständlichen Wikiseiten fehlt und ein mechanischer > Edit zur Zeit zu wenig Verbesserung mit sich bringt. Hast du konkrete Verbesserungsvorschläge für die Wikiseiten? Der mechanische Edit bringt deutliche Verbesserungen. Er vereinheitlicht das Tagging und korrigiert "Design-Fehler", die wir beim Entwurf des Taggingschemas gemacht haben, nämlich die fehlende internationale Eindeutigkeit der Tags. Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Grundsätzlich spricht nichts gegen eine Anpassung, allerdings sollten solche Änderungen möglichst breit diskutiert werden und dann bringt es nichts wenn der Autor hier nicht einmal persönlich einen Link veröffentlicht und dann auch mitdiskutiert ! * Wie sieht das denn im Ausland aus ? Wurde auch über den Tellerrand (Europa) hinausgeschaut ? * Können wir kein internationales Schema entwickeln und nur länderspezifische Signale mit LC erweitern. * Warum werden den die Werte als Abkürzungen definiert ? Was spricht gegen zB Hauptsignal statt hp ? * Wie wäre es mit operator=* anstatt der Präfixe der Werte ? Die Beispiele am Ende hängen in der Luft und genau die Unterschiede sind nicht herausgearbeitet, da nur jeweils ein Beispiel für jeden Haupttag vorhanden ist. Noch sind die Tags railway:signal:main=*, railway:signal:combined=*, railway:signal:*:states=* und was da noch so herumschwirrt gut dokumentiert. Das Hauptsignal und das stillgelegte Signal verwenden exakt das gleiche Bild ! Gibt es Proposals ? Insgesamt ist die Situation eher unbefriedigend, da es sich hier wohl eher um einen kleineren Kreis von Profis handelt und interessierte Laien schon Probleme bekommen. Auch wird, nach wie vor, an forward/backward und left/right an Punkten festgehalten, was so von keinem einzigen Editor unterstützt wird. Somit komme ich zu dem Schluss, dass es wohl immer noch an einer gelungen Ausarbeitung des Tagging-Schemas und der entsprechenden auch für "normale" User verständlichen Wikiseiten fehlt und ein mechanischer Edit zur Zeit zu wenig Verbesserung mit sich bringt. Grüße fly Am 07.04.2015 um 13:37 schrieb chris66: > Hi, > User Nakaner plant alle Signalanlagen in Deutschland umzutaggen. > > Hier der entsprechende Beitrag im OSM Forum: > > http://forum.openstreetmap.org/viewtopic.php?id=30676 > > Einwände bitte dort oder hier posten. :-) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Hi, User Nakaner plant alle Signalanlagen in Deutschland umzutaggen. Hier der entsprechende Beitrag im OSM Forum: http://forum.openstreetmap.org/viewtopic.php?id=30676 Einwände bitte dort oder hier posten. :-) Viele Grüße Christian ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
