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 lowfligh...@googlemail.com: 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
[Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.
Hallo, es gibt seit ein paar Wochen einen Beschreibungstag für Entsorgungsstationen für Campingfahrzeuge und Boote. http://wiki.openstreetmap.org/wiki/Proposed_features/Sanitary_Dump_Station Übersetzung und Erweiterung der Wikiseite ins Deutsche habe ich begonnen. http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dsanitary_dump_station 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. Ich kann zum Beispiel den Unterschied sanitary_dump_station:suction=yes und sanitary_dump_station:pump-out=yes nicht erkennen. http://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dsanitary_dump_station Es wäre schön wenn es noch andere Camper oder Bootsführer gäbe, die dort mit drüber schauen. Es gibt noch einen Franzosen, der die Seite übersetzt hat, aber der beteiligt sich nicht an der Diskussion. Gruß Gisbert ___ 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.
Auf English: The language barrier has been high here: help from someone fluent in both German and English is needed Each new proposal page so far has brought more confusion. -- In the USA/Canada/Mexico there are three main connection types for dumping a toilet holding tank: - Suction pump-outs for boats - A 3 inch round drain hose for grey and blackwater from mobile home holding tanks - A flush basin for dumping portable wheeled cassette holding tanks. In the UK the last item is sometimes called an Elsan Point. Often, a washing hose is available. Rarely, a septic leach field is in use and there are various restrictions on the type of chemical used in the holding tank. Worldwide, tags used for this feature have included: amenity=dumpstation, amenity=sanitary_station, amenity=pumpout, amenity=pump-out and amenity=pump out along with amenity=dump station, amenity=dump, and amenity=RV dump, amenity=recycling,waste=excrement, and finally tourism=caravan_site,note=RV Dump. Current tags in Germany include waste=excrement, recycling:excrement=yes, and waterway=pump_out, along with seamark:small_craft_facility:category=pump-out;other For UK canals it is tagged as follows: http://wiki.openstreetmap.org/wiki/WikiProject_United_Kingdom_Waterways#Further_tagging_information --- This feature is not rendered on any map I have found, at least in part because of the severe fragmentation of the tagging styles. ___ 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-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 lowfligh...@googlemail.com: 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: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. 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 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: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 ? 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 (railway=*) zu setzten gedacht, so wie wir das auch bei Straßen mit maxspeed, maxheight und ähnlichen Verkehrschildern machen ? Ciao fly
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Am 14.04.2015 um 21:13 schrieb Michael Reichert naka...@gmx.net: 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
