Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.
Hallo Martin, vielen Dank für das Einmischen. Am 15.04.2015 um 12:14 schrieb Martin Koppenhoefer: Am 14. April 2015 um 17:33 schrieb gmbo g...@kilometerfresser.eu: Leider führe ich die Diskussion mit einem Amerikaner allein und auf jede Frage oder Anregung die ich stelle kommen mindestens 3 unerklärte neue Zusatztaggingvorschläge, die nichts mit der vorherigen Frage zu tun hat und für mich dann noch verwirrender ist, da mein Englisch nicht so gut ist. Manchmal habe ich den Eindruck, dass in den Staaten völlig andere Systeme benutzt werden. soweit ich Bryce verstehe scheint es unterschiedliche Grundkonzepte zu geben, sein Tagging geht um die Anbindungsart (welche Art Verbindung / Anschluss um Flüssigkeit Feststoffe zu transferieren), während Gisbert, soweit es Bryce versteht, wohl gerne die Verbindungsart und die Stoffe die man entsorgen kann, in einem tag verquicken würde. Es gibt warscheinlich gar nicht so große Unterschiede, deshalb gehe ich davon aus, dass es auch ein gemeinsames Tagging gibt. Im Proposel gibt es nur amenity=sanitary_dump_station. Dann das ganze zum Anhängen an eine bestehende Einrichtung also Camping- Wohnmobilstellplatz und Häfen. sanitary_dump_station=yes Beides sagt aus, daß es eine Entsorgungsstation gibt. Da es aber verschiedene Arten der Entsorgung gibt sind noch 2 Zusatztags dazugenommen worden. sanitary_dump_station:suction=yes sanitary_dump_station:gravity=yes diese beiden Tags sagen für mich nur aus, daß in dem ersten Fall abgesaugt wird und im 2. Fall die Entsorgung durch ablassen der Flüssigkeit geschieht. Also für mich nur die Beschreibung der Technik bei der Entsorgung. Deshalb habe ich die Bilder die ich im letzten Jahr von solchen Stationen gemacht habe hochgeladen und eine Tabelle in seine Diskussionsseite geladen mit der Bitte diese so zu beschreiben wie er sie sieht um Differenzen zu finden. Bilder fand er nicht gut und stellte 3 Videos vor. Dabei gab es dann den Tag sanitary_dump_station:pumpout=yes der auf meine Frage warum er jetzt dies benutzt wurde daraus dann pump_out. Als ich ihm dann erklärte, dass ich für die Suche nach neuen Begriffen Taginfo benutze und da in dem Fall dann einzig Habor:pump-out gefunden hätte hat er es dann mit Bindestrich geschrieben. Ich habe dann versucht die englische Wikiseite zu überseztzen , die aber täglich ein bisschen geändert wird. Dann habe ich ein paar Prinzipbilder , natürlich aus meiner Sicht erstellt. Die sollten aber eigentlich auch zwischen hier und den Staaten übereinstimmen, denn die Videos zeigen eigentlich die selbe Art von Fahrzeugen. Und ob es drüben ein Bajonet am Entsorgungsschlauch gibt oder ob der Schlauch mit einer anderen Art an das Fahrzeug angebracht wird sollte fürs taggen egal sein. Die für mich wichtige Frage, ob man die in den neueren Fahrzeugen verwendeten Kassettentanks auch über das gleiche Loch in welches der Adapter für das Auslassende passt, entsorgt werden kann hat er noch nicht beantwortet. Natürlich ist unstrittig, dass die Entsorgungseinlässe, die ca. 1 m hoch liegen nicht für die Schlauchentsorgung funktionieren, und man diess anders beschreiben muß. Da es sich dabei aber nicht nur um hochgelegte Auslassbecken oder spezielle Toiletten handelt sondern auch um extra hochgezogene Rohre ist der von ihm kurzerhand erstellte Tag sanitary_dump_station:basin=yes irreführend. Anscheinend gibt es da eben das Problem, dass man nicht das Becken , welches wenn es in den Boden eingelassen ist andere Entsorgungsmöglichkeiten bietet als wenn es In einem Gebäude 1m hoch an der Wand hängt, beschreiben darf sondern das was dort entsorgt wird. Ausserdem gefällt ihm der tag sanitary_dump_station:chemical_toilet nicht so gut, weil er da Verwechslungsgefahr mit chemischen Toiletten zur Benutzung durch Menschen sieht. chemical_toilet ist der zur Zeit am häufigsten benutzte Tag bei der Entsorgung Sieser wurde bisher mit amenity=waste_disposal waste=chemical_toilet getagt. Daher hatte ich diesen vorgeschlagen. Ich habe aber auch vorgeschlagen ganz auf den Tag zu verzichten da eigentlich 90% der hiesigen Entsorgungsstationen chemische Zusätze in den Fäkalien zulassen. Es gibt in Europa auf Länderebene Unterschiede welche Gifte enthalten sein dürfen, Aber das weiß man recht schnell wenn man in ein anderes Land reist. Da es aber bei uns Biologische Klärwerke gibt, die durch die Zugelassenen Chemikalien ihre Funktion verlieren bat ich um ein Tagg wie chemicals_ban oder forbit. Er führte daraufhin den Tag chemicals_restrictet ein und meite in den USA gäbe es nur Beschränkungen aber keine Verbote, außer in einigen Staaten, dort aber dann komplett. Das wäre aber ja maximal ein Tag der dann hier anders wäre als drüben. Sie könnten ja auch nebeneinander existieren. Gruß Gisbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
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:TYP: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
[Talk-de] Schreibfehler in deutschem Copyright-Text
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Im deutschsprachigen Text von http://www.openstreetmap.org/copyright ist ein blöder Schreibfehler, es wird nämlich als zu verlinkende Seite www.openstretmap.org/copyright (ein e zuwenig in der street) angegeben. Vielleicht liest ja einer der Macher hier mit - ansonsten und allgemein: Wo kann man einen solchen Fehler melden oder direkt korrigieren? Gruß, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJVLpnQAAoJEBrjxFVQEkD/Q+YP/0gKbjq8Vu8QN1261ijsguRf KA8LSpm79mjjFv+usqjfDg+bJuzQpOFnX4TwnHHLXo0tZBL9j+mLY7COYaCcY6mK Z4o58vUSp+19jYHWRsNWoGAKh0DZ2J5nKpXiA9PlcOC77AYQs2UAmFCeM8pl9weB 0DzINg+bKTp87Wf1nAWlxJDtTiPqWKIUhs6Aev3fwTkStnpOClT8O8vTdse2t179 GENAQiTeVNQYxTH/HCW5bhtcvVt6aORcvkbV1F/2TXBADOlmkMfDQ8joo0y6Jw/P WZW4eCyccqoSGJmG9QxyazwMCnO8wuT97R0LQZDRKQL6fAHj1a2Thd4L6mlXApvN BA9u9Z+GO3kNX6sYOnEt1ZxvxSzMx//gcOKf+gi9efCKewx+iEzCqmMtfPvBIuQt vsS+Q/AiYHRew6Clj/56T5Yda/0f5CZyOJ7Q+AlerKkHoDf8E2mfuQFazoGFbTwS CLah/srevKWej7mmik/zWczOYnsPIzsiqN+pq5qlhinQes7CKdAf3PuXjSfGCBya OpB4sZZ6YZk2iim7L1gRe7lF7NkXCSkCCkNMfUrRc77ubn6fTTglxNw59amX28jn FICvyiOWD1xtaYYhL2YtRlxf+bD/JP7TLiKcNfkWq7fZs5w1aea9+iLiNAtj8gqV IAYdXXF7thBp//wR4bOV =2VNC -END PGP 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 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:TYP: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 ? railway=signal signal:main=* state=* height=* ref=* direction=95 -es sollte IMHO tatsächlich states und nicht state sein, denn es gibt die Gesamtmenge der
Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.
You can also see how others are tagging Sanitary Dumps: http://www.sanidumps.com/maps/index.php?id=18 --- The top level tags sanitary_dump_station are enough for rendering. However someone with a given style of boat or motorhome can use use only some of the sites. They may have boat holding tank needing a pumpout, a boat or motorhome with a cassette, or a motorhome with a gravity fed hose. These are incompatible systems. A given site may accept one, two or three of the systems. A given site may restrict or even ban tank holding chemicals, but these rules are complex and hard to tag. I prefer just a warning that a given site may have a restriction that needs to be checked locally. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibfehler in deutschem Copyright-Text
Der Fehler hat sich auch schön verbreitet: auf Anhieb 275 Ergebnisse bei Google. Auf welcher Seite ist der Original-Fehler? (Du hast die Ziel-Seite angegeben, nicht die mit dem fehlerhaften link) Volker 2015-04-15 19:03 GMT+02:00 Mark Obrembalski m...@obrembalski.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Im deutschsprachigen Text von http://www.openstreetmap.org/copyright ist ein blöder Schreibfehler, es wird nämlich als zu verlinkende Seite www.openstretmap.org/copyright (ein e zuwenig in der street) angegeben. Vielleicht liest ja einer der Macher hier mit - ansonsten und allgemein: Wo kann man einen solchen Fehler melden oder direkt korrigieren? Gruß, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJVLpnQAAoJEBrjxFVQEkD/Q+YP/0gKbjq8Vu8QN1261ijsguRf KA8LSpm79mjjFv+usqjfDg+bJuzQpOFnX4TwnHHLXo0tZBL9j+mLY7COYaCcY6mK Z4o58vUSp+19jYHWRsNWoGAKh0DZ2J5nKpXiA9PlcOC77AYQs2UAmFCeM8pl9weB 0DzINg+bKTp87Wf1nAWlxJDtTiPqWKIUhs6Aev3fwTkStnpOClT8O8vTdse2t179 GENAQiTeVNQYxTH/HCW5bhtcvVt6aORcvkbV1F/2TXBADOlmkMfDQ8joo0y6Jw/P WZW4eCyccqoSGJmG9QxyazwMCnO8wuT97R0LQZDRKQL6fAHj1a2Thd4L6mlXApvN BA9u9Z+GO3kNX6sYOnEt1ZxvxSzMx//gcOKf+gi9efCKewx+iEzCqmMtfPvBIuQt vsS+Q/AiYHRew6Clj/56T5Yda/0f5CZyOJ7Q+AlerKkHoDf8E2mfuQFazoGFbTwS CLah/srevKWej7mmik/zWczOYnsPIzsiqN+pq5qlhinQes7CKdAf3PuXjSfGCBya OpB4sZZ6YZk2iim7L1gRe7lF7NkXCSkCCkNMfUrRc77ubn6fTTglxNw59amX28jn FICvyiOWD1xtaYYhL2YtRlxf+bD/JP7TLiKcNfkWq7fZs5w1aea9+iLiNAtj8gqV IAYdXXF7thBp//wR4bOV =2VNC -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibfehler in deutschem Copyright-Text
Am 15.04.2015 um 19:24 schrieb Volker Schmidt: Der Fehler hat sich auch schön verbreitet: auf Anhieb 275 Ergebnisse bei Google. Auf welcher Seite ist der Original-Fehler? (Du hast die Ziel-Seite angegeben, nicht die mit dem fehlerhaften link) Wie Mark es korrekt schreibt: Die Zielseite enthält den Schreibfehler im _Text_ : Zitat: Du kannst dies tun, indem du auf www.openstretmap.org/copyright http://www.openstreetmap.org/copyright verlinkst. Der dahinterliegende Link ist allerdings korrekt. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.
Dass in den USA die Sani Statiionen so wenig beschrieben sind ist kein Grund alles darauf zu reduzieren. Schau dir die Portale der Camping- und Wohnmobilkataloge in Deutschland an dann siehst du was dort alles angegeben wird. Die Toplevel Tags reichen für ein einfaches Rendering, aber was gibt dir das Recht, deshalb zu einem frühen Zeitpunkt weltweit einen Automatischen Edit anzustoßen wo du dich noch nicht einmal ausreichend mit dem Thema beschäftigt hast. Du stellt mir die lapidare Frage Können wir mit dem Editieren mit den Grundtags beginnen, auch wenn den Zusatztags noch im Unklaren sind und hast schon längst einen automatischen Edit angestoßen, der mehrere vorher gebrauchte Tags umschreibt. Dabei werden auch Zusatztags benutzt die du vorgestern anscheinend gewürfelt hast. Ich finde das schade, da du dich ja anscheinend noch nicht einmal ausreichend mit dem Thema beschäftigt hast. Sonst hättest du wenigstens auf die Bilder auf der englischen Talkseite beschreiben können. Wenn du meinst die Toplevel reichen, aber gleichzeitig meinst, dass es zu Kompliziert ist Die Unterschiede darzustellen, dann könnte ich behaupten warum taggen wir die Entsorgungsstationen überhaupt. Jeder gute Campingplatz hat eine und wenn man ankommt wird man schon erkennen ob das mit meinem Campingfahrzeug geht. Ich habe versucht mit dir über Grundlagen zu diskutieren, aber darauf bekomme ich dann die Antwort, dass es zwischen uns keine vernünftige Diskussionsbasis gibt, weil es die Sprachbariere gibt und das Thema Abwasser ja erheblich stinkt und man deshalb manches lieber nicht beschreibt, Wie taggst du eigentlich waste=excremente um,welches ja genauso oft vorkommt wie waste=gray_water oder waste=chemical_toilet? Im Moment fühle ich mich deshalb ziemlich hintergangen. Wie ich schon in der Diskussionsseite des Wikis auf die Frage geantwortet habe bin ich auf keinen Fall für einen automatischen Edit. Aber anscheinend muß man das System OSM und die Lücken kennen um weltweit etwas ändern zu können. Warum bist du daran interressiert, diesen Tag so schnell in eine dir genehme Form zu bringen. Dann bemühe dich darum dies zu erklären. Mit welchem Kreis ist der Edit besprochen? Wo ist dokumentiert was durch was ersetzt wird? Ich bin wie ich mehrfach erwähnte für ein einheitliches Taggen. Aber dann sollte es vernünftig und verständlich beschrieben sein. Nach Möglichkeit nicht nur Englisch(oder US - Amerikanisch) Auch bei heiklen Themen sollte auf Hintergründe eingegangen werden um auch Mappern, die sich nur wenig mit dem Thema beschäftigt haben, die Möglichkeit des Mappens zu geben. Gisbert Am 15.04.2015 um 19:37 schrieb Bryce Nesbitt: You can also see how others are tagging Sanitary Dumps: http://www.sanidumps.com/maps/index.php?id=18 --- The top level tags sanitary_dump_station are enough for rendering. However someone with a given style of boat or motorhome can use use only some of the sites. They may have boat holding tank needing a pumpout, a boat or motorhome with a cassette, or a motorhome with a gravity fed hose. These are incompatible systems. A given site may accept one, two or three of the systems. A given site may restrict or even ban tank holding chemicals, but these rules are complex and hard to tag. I prefer just a warning that a given site may have a restriction that needs to be checked locally. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description
2015-04-14 23:09 GMT+02:00: deren tags scheinen keinen sinn zu machen. tags löschen? Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben undokumentierte Tags. C'est la vie! Unschön da nicht dokumentiert, aber irgendwas wird sich derjenige, der sie eingetragen hat, schon dabei gedacht haben. Ob die Tags Sinn machen? Keine Ahnung, ist auch irrelevant. Any tags you like! Nur weil ich einen Tag nicht verstehe, lösche ich ihn nicht! * Warum Plural? Weil die Unsitte in weiten Bereichen OSMs einzieht, dass jedes Tag unbedingt sofort überall diskutiert, abgesegnet und dokumentiert werden muss. Dem ist nicht so! Es ist von Vorteil, etwas zu diskutieren (mit Leute die Ahnung von dem Thema haben und nicht den lautesten Schreiern in irgendeinem Forum oder einer tollen Mailingliste). Es ist von großem Vorteil, Tags zu dokumentieren (ist aber nicht verpflichtend - NICHTS ist in OSM verpflichtend, oder bezahlt mich jemand dafür?). Es war nie, ist nicht und wird - solange ich dabei bin - nicht erforderlich sein, von irgendjemanden irgendeine Zustimmung zu irgendeinem Tag einzuholen. Solange man die Arbeit anderer nicht zunichte macht, darf man eintragen was man will (der erste der mir jetzt mit Datensparsamkeit kommt, bekommt das hier: http://i.imgur.com/iWKad22.jpg). ___ 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:TYP: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 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
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] [Talk-at] wpt_symbol, wpt_description
Am 15.04.2015 um 10:34 schrieb Jo: Sind das nicht die tags die man im GPX XML findet? +1 Deswegen auch mit Tendenz zum löschen, vermutlich versehentlich hereingekommen. Kann man mal den Original-Autor fragen was das Tag soll? Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.
Am 14. April 2015 um 17:33 schrieb gmbo g...@kilometerfresser.eu: http://wiki.openstreetmap.org/wiki/Proposed_features/Sanitary_Dump_Station Ich kann zum Beispiel den Unterschied sanitary_dump_station:suction=yes und sanitary_dump_station:pump-out=yes nicht erkennen. da scheint es auch gar keinen zu geben. suction (Absaugen) steht hier: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dsanitary_dump_station#Tagging_the_Facility_Type als Erklärung für pump-out (auspumpen), auf der Wikiseite kommt das Wort sonst nicht vor. Laut taginfo kommt der tag sanitary_dump_station:suction weltweit 6 mal vor (pump-out 9x) Es wäre schön wenn es noch andere Camper oder Bootsführer gäbe, die dort mit drüber schauen. +1 ich kenne mich da leider gar nicht aus, melde mich hier nur zu Wort, weil Bryce mich um Hilfe gebeten hatte, die Sprachbarrieren zu überwinden, er kann wohl etwas Deutsch, es reicht aber nicht, um die Diskussion auf Deutsch zu führen. Soweit ich das verstanden habe will er gerne das tagging vereinheitlichen und dokumentieren, weil es wohl derzeit sehr fragmentiert ist. Er versucht daher ein allgemeingültiges Schema zu etablieren, das man weltweit einsetzen kann. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.
Am 14. April 2015 um 17:33 schrieb gmbo g...@kilometerfresser.eu: Leider führe ich die Diskussion mit einem Amerikaner allein und auf jede Frage oder Anregung die ich stelle kommen mindestens 3 unerklärte neue Zusatztaggingvorschläge, die nichts mit der vorherigen Frage zu tun hat und für mich dann noch verwirrender ist, da mein Englisch nicht so gut ist. Manchmal habe ich den Eindruck, dass in den Staaten völlig andere Systeme benutzt werden. soweit ich Bryce verstehe scheint es unterschiedliche Grundkonzepte zu geben, sein Tagging geht um die Anbindungsart (welche Art Verbindung / Anschluss um Flüssigkeit Feststoffe zu transferieren), während Gisbert, soweit es Bryce versteht, wohl gerne die Verbindungsart und die Stoffe die man entsorgen kann, in einem tag verquicken würde. Ausserdem gefällt ihm der tag sanitary_dump_station:chemical_toilet nicht so gut, weil er da Verwechslungsgefahr mit chemischen Toiletten zur Benutzung durch Menschen sieht. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description
Hallo, Martin Vonwald schrieb: Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben undokumentierte Tags. C'est la vie! [...] sry Martin, aber dem kann ich mich nicht anschließen da die Tags offensichtlicher Schwachsinn sind und die im Betreff genannten wohl auch etwas zu kurz greifen: ele=0. mitten im Ösiland? name=nXY? Die beiden zumindest sind dokumentiert und wie gesagt offensichtlicher Schwachsinn. Und ganz ehrlich, bei nem Tag-namen *_symbol hört sich das schon nach Tagging für irgendeinen Renderer an. Wenn dann ein City (Small) an einem Wald klebt .. Gruß, Peda ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description
Sind das nicht die tags die man im GPX XML findet? Die haben tatsächlich nichts verloren in OSM. Polyglot 2015-04-15 9:40 GMT+02:00 Peter Barth osm-p...@won2.de: Hallo, Martin Vonwald schrieb: Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben undokumentierte Tags. C'est la vie! [...] sry Martin, aber dem kann ich mich nicht anschließen da die Tags offensichtlicher Schwachsinn sind und die im Betreff genannten wohl auch etwas zu kurz greifen: ele=0. mitten im Ösiland? name=nXY? Die beiden zumindest sind dokumentiert und wie gesagt offensichtlicher Schwachsinn. Und ganz ehrlich, bei nem Tag-namen *_symbol hört sich das schon nach Tagging für irgendeinen Renderer an. Wenn dann ein City (Small) an einem Wald klebt .. Gruß, Peda ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description
Am 15. April 2015 um 08:56 schrieb Martin Vonwald imagic@gmail.com: Weil die Unsitte in weiten Bereichen OSMs einzieht, dass jedes Tag unbedingt sofort überall diskutiert, abgesegnet und dokumentiert werden muss. Dem ist nicht so! Es ist von Vorteil, etwas zu diskutieren (mit Leute die Ahnung von dem Thema haben und nicht den lautesten Schreiern in irgendeinem Forum oder einer tollen Mailingliste). Es ist von großem Vorteil, Tags zu dokumentieren (ist aber nicht verpflichtend - NICHTS ist in OSM verpflichtend, oder bezahlt mich jemand dafür?). Es war nie, ist nicht und wird - solange ich dabei bin - nicht erforderlich sein, von irgendjemanden irgendeine Zustimmung zu irgendeinem Tag einzuholen. jein. Ich fände es ehrlich gesagt schon ein Problem, wenn die Offenheit des Projektes dadurch gefährdet würde, dass (hypothetisch) absichtlich undokumentierte Codes zur Anwendung kämen, um den Inhalt der tags zu verschleiern, z.B. proprietarymaps:123:12=Q34F5 (rein fiktives Beispiel). Deshalb kann ich Deine Ausführungen nicht pauschal unterschreiben, finde im konkreten Fall aber die Schwelle noch nicht überschritten. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ankündigung: Aufzeichnung Radio-OSM Folge 042 am Montag 20.4.2015
FYI: wir planen im Moment die aktuelle Folge 042 mit der Antwort auf alle Fragen in OSM ;-) am Montag Abend 20.04.2015 aufzuzeichnen. http://podcast.openstreetmap.de/ueber/ Dieses Mal ist wieder ein Streaming via Xenim vorgesehen (http://streams.xenim.de/osm/) so dass ein live zuhören möglich sein sollte. Wer via Mumble aktiv teilnehmen will findet die Info hierzu unter http://podcast.openstreetmap.de/mitmachen/ . Die geplanten Themen findet Ihr wie immer im Trello (ist noch nicht abgeschlossen und entwickelt sich gerade noch): https://trello.com/b/YvlitJTs/radioosm-contentplanung. Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
