Re: [Talk-de] Fußgänger-Diskriminierung?
Am 21.04.2015 um 21:15 schrieb Hubert: Am 21. April 2015 um 15:19 schrieb fly lowfligh...@googlemail.com Am 21.04.2015 um 12:08 schrieb Martin Koppenhoefer: Am 21. April 2015 um 11:14 schrieb Roland Olbricht olbri...@mentzdv.de: Kurze Nachfrage. In wie fern hängen footway/path=sidewalk und sidewalk=detached zusammen, bzw unterschieden die sich? Weil die Frage auf kam: Ich verwende path=sidewalk, da ich mich an kein explizit gemappten highway=cycleway;cycleway=track errinnern kann. Aber was spricht gegen cycleway=sidewalk ? Irgentwo habe ich mal gelesen, dass highway=cycleway;cycleway=track sinnfrei wäre, da highway=cycleway sowieso cycleway=track impliziere. Außerdem wird cycleway=track schon an der Straße (highway=track) verwendet, und könnte daher zu Problemen mit Renderern führen, die man vermeiden kann. Das war missverstandlich und bitte nicht als tagging-Vorschlag interpretieren. Meinte ich kenne keinen separat eingetragenen Fahrradweg entlang der straße, der nicht auch gemischt oder separiert für Füßgänger*innen erlaubt ist. Gegen cycleway=sidewalk sprich meiner Meinung nach nicht viel, außer einem komischen Gefühl durch das walk im sidewalk. Im Moment wäre sideway wohl das beste. Haben jetzt auch schon sidepath und sidewalk. sidewalk=detached ist doch eher sowas wie footway=track, d.h. ein von der Straße unabhängiger bzw. baulich getrennter Fußweg in Nähe der Straße, im Gegensatz zu einem klar zur Straße gehörenden, nur durch einen Bordstein abgetrennten Gehweg. Ich hätte es jetzt an den Straße (highway=*) analog zu sidewalk=both/left/right/no verwendet. Aah. Das macht tatsächlich am meinsten Sinn. Danke. Moment, das war meine Interpretation ohne mir die Daten anzuschauen. m.E. wäre es von vornherein sinnvoll gewesen, Gehwege mit einem anderen tag als völlig unabhängige, eigenständige Fußwege zu taggen, und vielleicht ginge das auch jetzt noch einzuführen. +1 highway=sidepath oder sideway=footway/path/cycleway highway=sidepath finde ich recht nett. Da könnte man dann die gleichen tagging Regeln anwenden, wie bei highway=path. Außerdem verlinken dann sowohl cycleway/sidewalk=sidepath und bicycle/foot=use_sidepath auf eben diesen Weg. Allerdings müsste man auch hier irgentwie zwischen Wegen unterscheiden, welche nur durch einen Bordstein bzw. mittels Grünstreifen, Graben, Gitter, (Parkbuchten) von der Fahrbahn getrennt sind. Vielleicht auch highway=sideway. Verstehe nicht, warum wir zwischen nur Bordstein und zB nur Grünfläche unterscheiden müssen. Das kann doch alles separat eingetragen werden, aber wenn Du jetzt noch einen Zusatztag brauchst, dann erfinde doch etwas. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fußgänger-Diskriminierung?
Am 22.04.2015 um 12:39 schrieb Martin Koppenhoefer: Vielleicht sollte man nochmal klären, worum es hier überhaupt geht: 1. Radwege / Gehwege, die direkt an der Straße liegen (d.h. Bordstein oder ggf. Parkstreifen (s. auch 2.) als Trennung) 2. selbige, die in Abstand und baulich getrennt (z.B. Grünstreifen, Absperrgitter, Leitplanken, Parkstreifen, etc.) ungefähr entlang der Straße und nicht zu weit entfernt verlaufen. Die ursprünglichen Beispiele von Roland waren aus der 2. Kategorie, hier in der Diskussion ging es aber scheinbar auch um Fälle der 1. Kategorie. Ist da wirklich so ein großer Unterschied ? Kenne 1. und 2. selbst mit offiziellem Radweg und beides bezieht sich immer noch auf die Straße. Sobald der Bordstein oder Grünstreifen bzw andere Barriere gemappt ist, bekommen wir halt Problem mit nur einer Linie für die gesamte Straße. Wie stellen wir also den Bezug zwischen den einzelnen Linien da, damit sowohl Router wie Renderer es gut auswerten können. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fußgänger-Diskriminierung?
Am 21.04.2015 um 12:08 schrieb Martin Koppenhoefer: Am 21. April 2015 um 11:14 schrieb Roland Olbricht olbri...@mentzdv.de: Kurze Nachfrage. In wie fern hängen footway/path=sidewalk und sidewalk=detached zusammen, bzw unterschieden die sich? Weil die Frage auf kam: Ich verwende path=sidewalk, da ich mich an kein explizit gemappten highway=cycleway;cycleway=track errinnern kann. Aber was spricht gegen cycleway=sidewalk ? Danke für den Hinweis. Das ist (für Fußwege) ziemlich genau das, was ich gesucht habe und zu Jochens Vorschlag passt. Dass es zusätzlich sidwalk=detached gibt, liegt vermutlich daran, dass der russische Nutzer ebenfalls das Tag footway=sidewalk nicht gefunden hat. sidewalk=detached ist doch eher sowas wie footway=track, d.h. ein von der Straße unabhängiger bzw. baulich getrennter Fußweg in Nähe der Straße, im Gegensatz zu einem klar zur Straße gehörenden, nur durch einen Bordstein abgetrennten Gehweg. Ich hätte es jetzt an den Straße (highway=*) analog zu sidewalk=both/left/right/no verwendet. Es sollte mit in die Wiki-Dokumentation zu highway=footway aufgenommen werden: http://wiki.osm.org/wiki/DE:Tag:highway%3Dfootway In diesem Fall reicht es sogar, das nur in der deutschen Version nachzuziehen. m.E. wäre es von vornherein sinnvoll gewesen, Gehwege mit einem anderen tag als völlig unabhängige, eigenständige Fußwege zu taggen, und vielleicht ginge das auch jetzt noch einzuführen. +1 highway=sidepath oder sideway=footway/path/cycleway 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 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
Am 17.04.2015 um 10:08 schrieb Martin Koppenhoefer: Am 17. April 2015 um 09:44 schrieb Michael Reichert naka...@gmx.net: 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 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
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
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
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] Öffnungszeiten Unstrutschleusen
Am 13.04.2015 um 13:30 schrieb Robin `ypid` Schneider: Ich hatte in der dritten Regel ein open vergessen und habe bei der Gelegenheit noch weiter getunet und das Kommentar für die Jahre nach 2015 etwas verständlicher gemacht. Apr 2-Oct 10: Th-Mo,PH 09:00-12:00,13:00-18:00 open letzte Schleusung 17:45; May 14-25,Jul 10-31 Tu,We 09:00-12:00,13:00-18:00 open letzte Schleusung 17:45; May 14-25,Jul 10-31: Fr-Su,PH 18:00-20:00 open letzte Schleusung 19:45; 2016+ NurGültig 15 Wieso denn open ? Auch scheint da doch mit dem letzten Wert etwas falsch zu sein oder lese ich das jetz falsch ? Für mich heißt das 14-25 Mai und 10-31 Juli Fr-So + Feiertags nur 18-20 h und nicht vorher Ist es nicht schlauer die letzte Schleusung direkt anzugeben ? Beim Gottesdienst wird doch auch nur der Beginn und nicht das Ende angegeben. service_time=2015 Apr 2-Oct 10: Th-Mo,PH 09:00-12:00,13:00-17:45; 2015 May 14-25,Jul 10-31 Tu,We 09:00-12:00,13:00-17:45; 2015 May 14-25,Jul 10-31: Fr-Su,PH 09:00-12:00,13:00-19:45 Eventuell noch operating_time=* oder operating_hours=* operating_hours=2015 Apr 2-Oct 10: Th-Mo,PH 09:00-12:00,13:00-18:00; 2015 May 14-25,Jul 10-31 Tu,We 09:00-12:00,13:00-18:00; 2015 May 14-25,Jul 10-31: Fr-Su,PH 09:00-12:00,13:00-20:00 cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Öffnungszeiten Unstrutschleusen
Am 13.04.2015 um 16:34 schrieb Martin Koppenhoefer: Am 13.04.2015 um 15:02 schrieb fly lowfligh...@googlemail.com: Beim Gottesdienst wird doch auch nur der Beginn und nicht das Ende angegeben. kann man schon auch tun, es steht zwar meist nur der Beginn dran, aber manchmal wird auch eine Dauer angegeben (z.B. Mittagsandacht 15Minuten), oder man weiß, wie lange es ungefähr geht... Wenn ich bei der Schleuse bleib, interessiert mich wohl in erster Linie die Abfahrten und dann noch die Dauer. Erinnere mich an so manchen Tag mit Gegenwind auf dem Rad und Zeitpunkt für die Querung eines Flusses. cu 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 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] https://wiki.openstreetmap.org/wiki/Key:direction
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
Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht
Am 07.04.2015 um 23:39 schrieb Wolfgang Hinsch: Am Sonntag, 5. April 2015, 16:51:16 schrieb fly: Hast Du nicht den Datensatz runtergeladen ? War da eine Lizenz dabei ? Falls nicht, hast Du den Satz als CC0 runtergeladen und der bleibt auch CC0, selbst wenn die Lizenz jetzt geändert ist. Du meinst wahrscheinlich, ob eine von der auf der Seite zu dem Zeitpunkt angegebenen CC0-Lizenz abweichende Angabe im Datensatz war. (Ganz ohne Lizenz CC0) Grundsätzlich ist das erst mal richtig, aber: Es geht hier erstmal nicht um OSM sondern nur um den Fall, dass die Daten einmal als CC0 veröffentlicht auch so weiter verbreitet werden dürfen und dann auch in OSM verwendet werden dürfen. Die Stadt Hamburg hat da keine Möglichkeiten zu handeln wenn jetzt die Daten zB auf archieve.org unter CC0 zur Verfügung gestellt werden. Ob wir das jetzt ausspielen wollen ist eine andere Frage, aber letzten endlich ist so ein Fehler halt schwerwiegend und kann teuer werden (weiss jetzt nicht ob da andere Rechteinhaber dahinter stecken). So etwas sollte in der Verwaltung zumindest gegengecheckt werden vor der Veröffentlichung. cu Es handelt sich sehr wahrscheinlich um einen Irrtum. Dies ist von uns bemerkt worden. Ob wir die Beute trotzdem einfach behalten und verwerten dürfen, ist fraglich. Bei der sehr zurückhaltenden OSM-Politik in diesen Bereichen zumindest im Projekt eher nein. Außerdem halte ich es im Sinne eines Miteinanders mit der Verwaltung, bei der sich jetzt endlich etwas ändert, für kontraproduktiv, jeden Brocken, der mal versehentlich etwas daneben geworfen wurde, sofort mit Zähnen und Klauen zu schnappen und festzuhalten. Es gibt mit Sicherheit innerhalb der Verwaltung unterschiedliche Positionen und wir würden nur die Fraktion stärken, die sowieso der Meinung ist, die Piraten von OSM klauen sofort alles, was nicht niet- und nagelfest ist. Im übrigen ist uns die Verwaltung schon sehr weit entgegen gekommen. Der in der Lizenz geforderte Quellenverweis muss nur angegeben werden, wenn er vom Datenanbieter bereitgestellt wird, und der schreibt ausdrücklich Namensnennung nicht erforderlich. Siehe auch Mail vom 2.4.15 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht
Hast Du nicht den Datensatz runtergeladen ? War da eine Lizenz dabei ? Falls nicht, hast Du den Satz als CC0 runtergeladen und der bleibt auch CC0, selbst wenn die Lizenz jetzt geändert ist. cu fly Am 31.03.2015 um 20:27 schrieb Johannes Kröger: Ich habe zwar noch keine Antwort von irgendwem offiziellen bekommen, aber der Datensatz (und die anderen CC0er) ist jetzt wie alles andere unter der Deutschlandlizenz. Da hätte ich wohl abwarten sollen, bevor ich es geschrieben habe, sorry! http://suche.transparenz.hamburg.de/dataset/hamburger-strasseninformationsbank-hh-sib ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 244 17.3.–23.3.2015
JOSM portable gibt es doch schon lange, nur eine Anleitung auf Deutsch fehlt [1][2]. Mit vorinstallierter Java-Laufzeitumgebung reicht häufig schon eine .jar-Datei und ein Platz für das Profil. cu fly [1] https://josm.openstreetmap.de/wiki/USB_Stick [2] https://wiki.openstreetmap.org/wiki/JOSM/HOWTO/Run_from_flash_disk_with_Java Am 25.03.2015 um 18:56 schrieb wn reader: die Wochennotiz Nr. 244 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2015/03/wochennotiz-nr-244/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen auf amenitys= / tourism= flächen
Am 24.03.2015 um 11:39 schrieb Martin Koppenhoefer: Am 24. März 2015 um 08:27 schrieb Florian Lohoff f...@zz.de: mir ist eine camp_site untergekommen deren gesamte Fläche addr: informationen trägt. Erst war ich mir ziemlich sicher das das ja quatsch ist - Wenn ich das zu einer Koordinate wandle zur Navigation kommt da der Mittelpunkt der Fläche bei raus zu der ich navigiere. Führt im zweifelsfalle dazu das ich am Hintereingang vor dem Zaun lande. das kommt ein bisschen darauf an, wie man die Logik implementiert. Man koennte es ja auch so sehen: alle Punkte innerhalb der Addr.-Flaeche haben diese Adresse. Wenn man nun zu der Adresse will, muss man nur den entsprechenden entrance-node (ggf. auch barrier=entrance) am Rand oder evtl. auch innerhalb dieser Flaeche finden, wenn man den Haupteingang sucht z.B. entrance=main. Der sollte normalerweise keine Extra-addr.-tags benoetigen, weil die ja schon auf der Flaeche sind. +1 Bei größeren Flächen braucht es halt auch eher ein besseres Ziel als nur die Adresse. Willst Du zum Direktorat, zu der Bibliothek zu den Sportanlagen oder zum Hausmeister, zudem ist es ja wohl auch noch entscheidend mit welchem Verkehrsmittel Du unterwegs bist, da ja zB. Parkplätze das Zwischenziel sein können. Kenne durchaus Schulgebäude mit mehreren Haupteingängen, welche in dem einzigen Gebäude mehrere unabhängige Schulen beherbergen. Alle mit der selben Adresse. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zum Mappen von Gemüsefeldern - Praktikabilität bedenken
Am 22.03.2015 um 12:12 schrieb tshrub: Martin Koppenhoefer schrieb: Am 19. März 2015 um 11:55 schrieb goegeo goe...@gmx.de: 1. Dauergrünland (Tag: landuse=meadow) 2. Ackerbauflächen (Tag: landuse=farmland) nach meinem Verständnis ist das bereits so, dazuhin gibt es dann noch orchard für Baumplantagen, z.B. Oliven, Äpfel, Orangen etc. und vineyard für Weinberge. Was Du aufzählst (Spargel, Erdbeeren, Getreide, Kartoffeln und mehr) ist alles farmland. es gibt auch für nur ein Jahr eingesätes Grünland. Neben den oben genannten, nutze ich ebenso die Tag: landuse=meadow für Grünland, ergo mehrjährige Wiesen Weiden Tag: landuse=farmland für offenen Boden, Land, das über mehrere Jahre hinweg gepflügt wird, also auch so kurzfristige Futterwieseneinsaat (sofern erkennbar bzw. wäre das zu beobachten). +1 Es gibt auch weitständige Oliven- oder seltener Apfelkulturen (da in anderem Klima), die ackerähnlich aussehen, da regelmäßig umgebrochen. Die zähle ich auch zu orchard. Bisschen unsicher bin ich mir dabei aber manchmal. Streuobstwiesen und -acker sind wohl weder farmland, meadow noch orchard und sollten eher einen eigenen (Sub-)Tag bekommen. Gemüsearten würden dann in Untertags benannt - und die müsste der Tagger dann aktuell halten, da sie ja öfter wechseln? Beständig und leider zunehmend muss ich dieses verwenden landuse=farmland species:Zea mays Luftbilder sind meist nicht aktuell und was nützt es mir zu wissen, dass vor drei Jahren dort eine bestimmte Spezies oder auch nur Wiese war. Eigentlich bleibt Dir nichts anderes übrig als die Menschen welche dort anbauen dazuzubringen, dass selber einzutragen. Ciao fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] information=guidepost auf eine kreuzungsnode
Am 20.03.2015 um 12:22 schrieb André Riedel: hiking - Wandern foot - innerstädtische Wege foot ist doch erstmal alles auch hiking. Finde hier sollten wir zumindest einen Zusatztag wenn nicht gar eigene Werte für type=* für innerstädtische Routen finden. Wo genau ist der Unterschied. Bisher ist das mir alles zu unklar definiert, insbesondere der Übergang. Gab vor Jahren mal anhaltspunkte aber leider nichts draus entstanden. [1] Wie ist das bei Karten (information=map)? Sollte man da auch extra Keys einführen? map:hiking:yes ??? Solange es ein eigenes, isoliertes Objekt ist, besteht kein Änderungsbedarf. cu fly [1] https://lists.openstreetmap.org/pipermail/talk-de/2012-August/thread.html#97799 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] information=guidepost auf eine kreuzungsnode
Am 20.03.2015 um 11:32 schrieb Florian Lohoff: On Fri, Mar 20, 2015 at 10:59:27AM +0100, Alexander Heinlein wrote: Gesendet: Freitag, 20. März 2015 um 10:01 Uhr Von: chris66 chris66...@gmx.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] information=guidepost auf eine kreuzungsnode Am 19.03.2015 um 22:08 schrieb Kurt Waldhans: Generell aber noch: ich habe noch keinen Router gefunden, der von einer Informations--Tafel gestoppt wurde. Solange man nicht bicycle=no für Wanderwegweiser (hiking=yes) mappt, ist das kein Problem. Leider macht beispielsweise das JOSM-Preset genau das. Klickt man dort zwei mal auf cycling, dann landet ein bicycle=no am Wegweiser. Das ist ja bei allen Preset-Checkboxen so üblich, führt in diesem Fall aber zu Routing-Problemen. JOSM can mittlerweile das no auch unterdrücken. Kannst ja nach einem enchancement fragen. bicycle ist hier einfach ungünstig gewählt, idealerweise sollte man es durch ein anderes Tag ersetzen. Leider ist so ein ersetzen bei OSM sowohl in der Datenbank als auch bei Editoren und Auswertern nicht so einfach möglich :\ Und dass ein bicycle=no an einem information=guidepost von Routern eine Spezialbehandlung bekommt, kann auch schlecht verlangt werden. OSM hat leider keine eindeutige nomenklatur zu hierarchischen tags - Dann wäre ein guidepost:bicycle=yes So sollte eigentlich nicht nötig sein. s.u. angebracht. Ein reines bicycle=yes ist kaputt. Aber wie gesagt - Wenn man die Topologie repariert ist das Problem ja schon aus der Welt weil die tags auf separaten Objekten sind. Eben, solange jedes reale Objekt auch sein Objekt in OSM erhält ist das kein Problem. Bei Linien-Punkten ist das ein bisschen komplizierter und es sind entweder Prefixe ala crossing:*=* oder halt Relationen nötig. Martins Vorschlage type=node z.B. brauche ich hier öfters, da die Wegweiser halt an Straßenlaternen angebracht sind und ich spätestens bei height=*, network=* und operator=* Probleme bekomme. Ciao fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 18.03.2015 um 07:48 schrieb Martin Koppenhoefer: Am 17.03.2015 um 22:53 schrieb Bernhard Weiskopf bweisk...@gmx.de: Feldwege, die man mit Kfz befahren darf, trage ich schon lange als service statt track ein. ob man Feldwege befahren darf hängt davon ab, wo man sich befindet und was ausgeschildert ist, in vielen Teilen der Welt _darf_ man praktisch alle Wege befahren sofern sie nicht privat sind. Mit Deiner Regel gäbe es kaum noch tracks. Ich finde es schon wichtig, dass man sich beim Tagging an die Definitionen hält, auf die man sich gemeinsam geeinigt hat, damit die Daten ausgewertet werden können. +1 Dachte immer, dass die offizielle Zugangsstraße bis zur Lokalität highway=unclassified ist und erst danach die Feldwege beginnen. Dass heißt jetzt nicht das Feldwege vom Routen ausgeschlossen werden sollen. highway=service ist nur die private Zufahrt. Habe in meiner Gegend einige Stellen, wo der von der Straße getrennte Rad-/Gehweg mit Zusatz Zufahrt zu den privaten Stellplätzen frei versehen ist: highway=path bicycle=designated foot=designated motor_vehicle=private cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Import of bicycle repair stations / Import Fahrrad Reparatur-Stationen
Dann wundere ich mich nur darüber, warum diese Mailing-Liste informiert wurde. Am 01.03.2015 um 21:10 schrieb Andreas Schmidt: right, there are „offshore countries“ :-) I had the Central European Syndrome... Anyway, appears not to affect countries with German vernacular language. Am 01.03.2015 um 17:02 schrieb fly: Am 01.03.2015 um 16:55 schrieb Andreas Schmidt: it appears there are two stations in Europe only, both at TU of Delft, The Netherlands. Europe includes some island so do not forget the origin of OSM. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Error render on OSM.org
Welches Format hast Du denn gewählt ? Bei .svg macht der Server sehr schnell schlapp. Versuche es doch mal mit einem minimalen Auschnitt, wenn es dann dauerhaft fehlschlägt gibt es wohl wirkliche Probleme. Grüße fly Am 01.03.2015 um 16:34 schrieb Johannes Silly: Hallo liebe Kollegen ich bin mir ja meiner Sache nicht sicher deshalb frag ich mal nach: Ich hab die letzten Tage mal seit langen wieder mal die Export funktion auf OSM.org nutzen wollen um schnell mal ein Bild zum ausdrucken und herzeigen zu haben. Da stellte ich fest das der Server überlastet ist oder sein sollte, naja dachte ich kein Problem hab ja erst was geändert und deshalb ist er überlastet, deshalb später (einen Tag) nochmal probiert wieder gleiche Problem! Deshalb mal an anderen stellen getestet aber immer das gleiche. Fehlerseite Siehe Auszug: Meine fragen nun: Ist das Standard oder nur diese Woche so? Und kann man das fixen? Gibt es bereits eine Lösung? Wird daran gearbeitet? Ich glaub auch als nicht OSM Begeisteter kann das abschreckend wirken (im Weitesten Sinne) Meine Alternative war halt dann mal wieder ein Bildschirmfoto. Auszug beginn Adress: http://render.openstreetmap.org/cgi-bin/export?bbox=15.123581886291504,47.048066225105806,15.131574869155884,47.0510606129168scale=42000format=pdf Site: Error The load average on the server is too high at the moment. Please wait a few minutes before trying again. Auszug ende Wer Rechtschreibung und Formatierungsfehler findet darf sie behalten. mit freundlichen Grüsen Johannes ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Import of bicycle repair stations / Import Fahrrad Reparatur-Stationen
Am 01.03.2015 um 16:55 schrieb Andreas Schmidt: it appears there are two stations in Europe only, both at TU of Delft, The Netherlands. Europe includes some island so do not forget the origin of OSM. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Import of bicycle repair stations / Import Fahrrad Reparatur-Stationen
Am 01.03.2015 um 00:56 schrieb Bryce Nesbitt: This is a request for comments on a proposed import of bicycle repair stations: http://wiki.openstreetmap.org/wiki/Import/Dero_Bike_Repair These locations are open 24/7. The locations came from press releases. The locations need local mapping to get the location perfect. -- Dies ist eine RFC zu einem Vorschlag Import von Fahrrad Reparatur-Stationen: http://wiki.openstreetmap.org/wiki/Import/Dero_Bike_Repair Die Standorte kamen von Pressemitteilungen. Die Standorte müssen lokale Zuordnung, die Lage ist perfekt erhalten. Die Standorte sind 24/7 goffnet. Is there any import in Germany or German speaking region ? Did not find any [1]. By the way, the page does not work with firefox on my system and the render order of city names needs quite some improvements. cu fly [1] http://www.dero.com/fixitmap/fixitmap.html ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Positionsgenauigkeit der Daten (war: admin schläft)
Am 26.02.2015 um 22:39 schrieb Joachim: Nicht spekulieren, ins Wiki schauen! :) Habe in den letzten Wochen da kräftig dokumentiert und im Forum darüber diskutiert. Hat zwar keine hübschen Bilder sollte aber relativ komplett sein. http://wiki.openstreetmap.org/wiki/Stuttgart/Transportation An den Haltestellen solltes es train=yes anstatt rail=yes sein [1]. cu fly [1] https://wiki.openstreetmap.org/wiki/Key:public_transport#Values ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 20.02.2015 um 13:39 schrieb Martin Koppenhoefer: Am 20. Februar 2015 um 10:42 schrieb Holger Jeromin mailgm...@katur.de: Du sagst das, aber die Daten nicht. Sind dann nicht die Daten falsch? Ich will bei einem ein Meter breiten Trampelpfad nicht mit dem Auto geführt werden. das ist aber kein Problem, zumindest nicht so, evtl. tritt ein Problem bei sehr langen Fahrzeugen wie z.B. LKW auf. Prinzipiell ist doch aus unseren Daten klar, ob ein PKW von der Breite her durchkommt (highway path vs. track/service, im Zweifel kann man noch width angeben oder entsprechende legale Beschränkungen). track/service vs path funktioniert nur in eine Richtung. Ein highway=path kann auch 10 Meter breit sein und vehicle=private ist durch aus möglich. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieder einmal lcn Sammelrelationen
Genau, es existieren keine Knoten, von daher ist es sehr unübersichtlich und wenn dann werden zumindest Routen mit dem Hauptrichtungen benötigt. Ein Gitternetzwerk hilft nicht wirklich, vorallem wenn es einige innerer Äste gibt, welche plötzlich enden. Fürs Routen sind solche Netze eher unbrauchbar, vorallem wenn erst einmal noch eine Relation abgefragt werden muss, wo doch alle relevanten Daten an den Linien zu finden sind. Mit lokaler Ortskenntnis finde ich oft bessere Routen als auf dem Fahrradweg and der Hauptstraße entlang zu fahren In meiner Gegend sind das alles lcn denn die Ortsnamen sind maximal die nächste Gemeinde im angrenzenden Kreis an sonsten alles innerhalb des Landkreises. Nach wie vor halte ich es für die einfachste Lösung ein simples lcn=yes an die Linien und den operator an die Wegweiser. Das gleiche trifft auch auf lwn zu (in D gelbe, liegende Raute). cu fly Am 06.02.2015 um 10:23 schrieb Jo: Das sind wohl etwas mehr als Wegweiser. Diese Routen sind doch etwas angenämer fürs Radfahren. Hier (Belgien, Niederlände, kleine Teile auch in Deutschland) würden wir die als rcn eintragen, nur haben die Knoten des Netzwerks hier Nummer. 2015-02-06 10:09 GMT+01:00 Manuel Reimer manuel.s...@nurfuerspam.de: Jo winfixit at gmail.com writes: Könntest du mal einige fotos von diese Schilder hochladen, vielleicht auf Mapillary.com? Dann können wir die auch sehen und eine Aussage drüber machen, ob sie in OSM gehören als Wanderrouten oder nur als Wegweiser. Hier gibt es einige Fotos: https://wiki.openstreetmap.org/wiki/User:Snoopy88/Radwegenetz Sieht eben in Etwa so aus als würde man an eine X-beliebige Straßenkreuzung kommen. Gut gemeinter Hinweis aber eine Route wird erst draus wenn man geplant hat wo man hinwill und welche Zwischenstationen man dabei durchqueren muss. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mehrere Häuser mit gemeinsamen Dach
Am 04.02.2015 um 14:58 schrieb Tobias Knerr: Am 03.02.2015 23:49, schrieb Holger Jeromin: Jetzt habe ich doch noch roof:shape=side_hipped [1] entdeckt. Scheint für einfachere Fälle zu funktionieren. Oder eine Linie als roof:ridge quer rüber eintragen. Es müssten 3 Linien mit gemeinsamen Knoten mit den Gebäuderändern sein. Gemeinsame Firstlinien für mehrere Gebäude sind meines Wissens nirgends definiert. Übrigens ist auch side_hipped keine standardisierte Dachform (wobei man argumentieren könnte, dass entweder ein neuer roof:shape-Wert oder ein Subtag für das normale hipped für so etwas sinnvoll wäre). Das Problem ist, dass bei den standardisierten Dachformen nur von einzeln stehenden Häusern ausgegangen wird. Ich brauche aber einen Tag der angibt, dass an den Hausübergängen das Dach nicht abgeflacht ist. Eventuell ist es auch sinnvoll eine Himmelsrichtung mit anzugeben oder ist es nachvollziehbar, dass die jeweils freistehende Seite abgeflacht ist ? cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] mehrere Häuser mit gemeinsamen Dach
Hi Habe folgendes Problem: Habe hier drei and der Querseite verbundene Häuser mit einem gemeinsamen Dach.Bisher sind sie als ein Objekt eingetragen mit roof:shape=hipped. Wie passe ich roof:shape am besten an, wenn ich die Häuser als einzelne Objekte eintragen will ohne Informationen zu verlieren. Das mittlere Haus sollte kein Problem sein (roof:shape=gabled) aber wie kennzeichne ich dass, die äusseren Häuser nur zu drei Seiten hin ein abfallendes Dach haben ? Hat hier mir jemand einen Tipp ? Wie geht hier in solchen Situationen vor ? Die Häuser mit building:part=* zu taggen ist wohl nicht passend. Danke fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] mehrere Häuser mit gemeinsamen Dach
Hi Habe folgendes Problem: Habe hier drei and der Querseite verbundene Häuser mit einem gemeinsamen Dach.Bisher sind sie als ein Objekt eingetragen mit roof:shape=hipped. Wie passe ich roof:shape am besten an, wenn ich die Häuser als einzelne Objekte eintragen will ohne Informationen zu verlieren. Das mittlere Haus sollte kein Problem sein (roof:shape=gabled) aber wie kennzeichne ich dass, die äusseren Häuser nur zu drei Seiten hin ein abfallendes Dach haben ? Hat hier mir jemand einen Tipp ? Wie geht hier in solchen Situationen vor ? Die Häuser mit building:part=* zu taggen ist wohl nicht passend. Danke fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mehrere Häuser mit gemeinsamen Dach
Am 03.02.2015 um 18:47 schrieb fly: Hi Habe folgendes Problem: Habe hier drei and der Querseite verbundene Häuser mit einem gemeinsamen Dach.Bisher sind sie als ein Objekt eingetragen mit roof:shape=hipped. Wie passe ich roof:shape am besten an, wenn ich die Häuser als einzelne Objekte eintragen will ohne Informationen zu verlieren. Das mittlere Haus sollte kein Problem sein (roof:shape=gabled) aber wie kennzeichne ich dass, die äusseren Häuser nur zu drei Seiten hin ein abfallendes Dach haben ? Hat hier mir jemand einen Tipp ? Wie geht hier in solchen Situationen vor ? Die Häuser mit building:part=* zu taggen ist wohl nicht passend. Jetzt habe ich doch noch roof:shape=side_hipped [1] entdeckt. Scheint für einfachere Fälle zu funktionieren. Ciao fly [1] https://wiki.openstreetmap.org/wiki/DE:OSM-4D/Roof_table#Dächer_mit_2_Ebenen ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mehrere Häuser mit gemeinsamen Dach
Am 03.02.2015 um 19:06 schrieb Morray: Hi, Am 03.02.2015 um 18:47 schrieb fly: Die Häuser mit building:part=* zu taggen ist wohl nicht passend. doch, genau das müsste man imho machen, wenn man das wirklich so erfassen will. Vielleicht habe ich mich undeutlich ausgedrückt. Laut Katasteramt sind das mehrere Häuser mit unterschiedlichen Hausnummern, aber auf dem Luftbild erkennt man eben nur ein Dach. Jetzt brauche ich die passenden Tags danit am Ende die drei Häuser zusammen wieder die Form ergeben. cu ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieder einmal lcn Sammelrelationen
Am 01.02.2015 um 19:26 schrieb Volker Schmidt: Das ist eindeutig nicht im Sinne der ueblichen Interpretation der Radrouten-Relationen Das ist ein zusätzliches Problem, mir geht es eher um die unnötigen Sammelrelationen [2]. Der user Snoopy88 hat die Bedeutung des tags network anders interpretiert als ich das bisher gekannt habe: network=ncn bedeutet das die der Relation entsprechende Route Teil nationalen Netzwerks des Landes ist. Fuer Snoopy88 bedeutet es, dass die Relation ein Netzwerk darstellt. Dafür gibt es wohl eher type=network aber das schreit ja auch schon wieder nach Sammelrelation. Ich habe auch keine Diskussion ueber eine Umwidmung des network tags mitbekommen. Ich auch nicht und ich bin nur durch Zufall auf folgende Seite [1] gestoßen. cu fly [2] https://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories 2015-02-01 17:53 GMT+01:00 fly lowfligh...@googlemail.com: Zumindest im Südwesten werden mal wieder alle Linien die einem lcn-Netzwerk angehören in Sammelrelationen gesteckt und diese wiederum sogar in Elternrelationen [1]. Hat sich da eine andere Philosophie durchgesetzt und sind solche Sammelrelationen mittlerweile akzeptiert ? [1] https://wiki.openstreetmap.org/wiki/User:Snoopy88/Radwegenetz ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wieder einmal lcn Sammelrelationen
Hey Zumindest im Südwesten werden mal wieder alle Linien die einem lcn-Netzwerk angehören in Sammelrelationen gesteckt und diese wiederum sogar in Elternrelationen [1]. Hat sich da eine andere Philosophie durchgesetzt und sind solche Sammelrelationen mittlerweile akzeptiert ? Grüße fly [1] https://wiki.openstreetmap.org/wiki/User:Snoopy88/Radwegenetz ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mühlgraben
Am 24.01.2015 um 07:50 schrieb malenki: On Wed, 21 Jan 2015 14:00:17 +0100, André Riedel wrote: wie trägt man einen Mühlgraben ein? Fragt man Overpass findet man ganze verschiedene Interpretationen von Wasserwegen mit dem Name Mühlgraben: waterway = 491 stream 181 ditch 132 canal 68 drain 62 river Damit es nicht zu langweilig wird, gebe ich noch Kunstgräben in die Diskussion. Um Wikipedia zu zitieren: | Als Kunstgraben werden Wassergräben bezeichnet, über die Bergwerke | mit Wasser zum Antrieb von Wasserrädern versorgt wurden. Sie dienten also dem gleichen Zweck wie Mühlgräben: Wasser zu energetischen Zwecken bereitstellen: http://de.wikipedia.org/wiki/Kunstgraben Im Siehe auch des Artikels sind drei Kunstgrabensysteme verlinkt: lesenswert. Ich habe die Kunstgräben meiner Region mit waterway=stream man_made=yes getaggt Mühlgräben iirc auch - soweit ich sie selbst eingetragen habe. man_made=yes finde ich jetzt nicht gut gewählt, eher doch artificial=yes. Auch cutting=both könnte passen. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Start-/Landebahn
Am 25.01.2015 um 21:02 schrieb kelvan bugmenot: Am 14. Januar 2015 um 08:02 schrieb Frederik Ramm frede...@remote.org: Es gibt ja Flugzeuge in der Luft - deren Routen wollen wir bei OSM nicht - und Flugzeuge am Boden; die Rollwege an einem grossen Flughafen können ein ganz schönes Dickicht sein, und darauf zu routen, wäre mit OSM-Daten schon möglich. In der Praxis ist es nicht relevant, weil der Tower den Fliegern schon sagt, wo sie langrollen sollen, aber wer weiss, im Flugsimulatorspiel ist es vielleicht nützlich ;) Es sind nicht nur Flugzeuge auf den Rollwegen unterwegs ;) Wie mir mein Besuch beim VIE gezeigt hat sollte man nicht vorschnell annehmen ein Flughafen würde nicht auch ggf. OSM Kartendaten nutzen. uU etwas OT: Was mir auch klar wurde bei dem Gespräch ist, dass die aktuellen aeroway tags etwas nunja rudimentär und teilweise unpräzise sind. Eine Sache scheint für Flughäfen (zumindest für den Bereich mit dem ich gesprochen habe) essentiell zu sein, die Unterscheidung zwischen taxiway und taxilane. Der Unterschied hier ist ca wie zwischen einer Landstrasse und einer Strasse am Parkplatz. +1 Wobei wir analog auch über :lanes zusammen mit aeroway=* sprechen sollten. Habe dazu ein Proposal im Wiki angelegt: https://wiki.openstreetmap.org/wiki/Proposed_features/taxilane Kannst Du das bitte auch auf tagging@ posten. Insgesamt bleibt das Problem, dass wir zur Zeit wohl nicht ohne ein zusätzliches Objekt für die Fläche auskommen. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deprecation von associatedStreet-Relationen
Am 22.01.2015 um 00:16 schrieb Michael Reichert: Hallo, aufgeweckt durch einen Newbie-Frage im Forum, bin ich (entdeckt hat's eigentlich Swen Wacker [1]) auf einen veralteten Inhalt im Wiki-Artikel DE:Relatio:associatedStreet gestoßen. https://wiki.openstreetmap.org/wiki/DE:Relation:associatedStreet In dem Artikel wird die associated-Street-Relation beschrieben, die verwendet wurde/wird, wenn der Mapper nicht an jedem Gebäude/Hausnummernnode addr:street=* usw. taggen wollte. Entworfen wurde sie im Rahmen des Karlsruher Schemas als Redundanzvermeidung. Von Datennutzern, die OSM-Adressdaten nutzen, habe ich gehört, dass diese Relationen aufwendiger in der Auswertung seien als das addr:street=*-Tag an jedem Adressnode/Gebäude auszuwerten. Weis ja nicht wen Du gefragt hast, aber von nominatim weiß ich, dass die Relation ausgewertet werden und auch funktionieren, während bei Straßen mit vielen Hausnummern ohne Relation Probleme auftreten. Mittlerweile beträgt der Anteil an den gesamten Adressen in OSM nur noch 7 Prozent. Auf was beziehst Du Dich da ? Zeitraum ? Ich habe das zum Anlass genommen, frecherweise diese Relation als deprecated (veraltet) zu markieren. [3] Das ist ja wohl dreist und damit greifst Du schon jeder Abstimmung vorraus. Bitter schleunigst rückgängig machen. Im Forum [2] wird das schon diskutiert. Ich bitte euch, wie schon diverse Forumsuser tun, im Wiki darüber abzustimmen. https://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet Sauber ? Wo ist da die Diskussion auf tagging@ davor und dann eine erneute Ankündigung der Abstimmung ? Anmerkung: Auf der deutschen Diskussionsseite schrieb tyr_asd im Oktober 2012, dass diese Relationen für mehrsprachige Gebiete eine Anwendung hätten. Ein Blick in seine Mappingregion Südtirol zeigt jedoch, dass dort mittlerweile eine name-Tag-ähnliche Lösung ohne Relationen angewendet wird. Beispiel: addr:street = Unterrainer Straße - Strada Riva di Sotto addr:housenumber = 10 addr:city = Eppan a.d. Weinstr. - Appiano s.s.d.v. addr:postcode = 39057 addr:hamlet = St. Pauls - S. Paolo addr:street:de = Unterrainer Staße addr:street:it = Strada Riva di Sotto addr:city:de = Eppan a.d. Weinstr. addr:city:it = Appiano s.s.d.v. Hatte es sich nicht rausgestellt, dass die unterschiedlichen Sprachen nicht von der Straße her abzuleiten sind und damit unnötig. Warum schaffen wir nicht gleich alle redundanten addr:* Tags ab ? * addr:street wird nur benötigt wenn es nicht die nächste Straße ist. * addr:country/city/postcode/suburb und noch viele mehr sind redundant und können aus den Grenz-Relationen gewonnen werden. cu fly [1] http://forum.openstreetmap.org/viewtopic.php?pid=478904#p478904 [2] http://forum.openstreetmap.org/viewtopic.php?pid=479346#p479346 [3] Teils haben es andere User, teils ich selbst, wieder auf in use zurückgesetzt. Mal schauen, was das Ergebnis der Abstimmung ist. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mühlgraben
Super, ich hätte jetzt ditch bzw stream benutzt und eben nicht canal. cu fly Am 21.01.2015 um 16:13 schrieb Bernd Wurst: Am 21.01.2015 um 14:00 schrieb André Riedel: wie trägt man einen Mühlgraben ein? Je nach dem wie er aussieht bzw. genutzt wird. Fragt man Overpass findet man ganze verschiedene Interpretationen von Wasserwegen mit dem Name Mühlgraben: waterway = 491 stream Das würde ich normalerweise nicht dafür nehmen, außer wenn es von einem natürlichen Bachlauf nicht mehr zu unterscheiden ist (also stillgelegter und renaturierter Mühlgraben). 181 ditch Habe ich selbst noch nie benutzt, geht aber laut Wiki schon für künstlich angelegte Wasserläufe. 132 canal So habe ich das immer getagged. Schließlich ist es genau das: Ein künstlicher Kanal. Wir haben bei Wasserwegen die schöne Situation, dass schon immer die Breite nicht am Tag sondern an der Außenlinie erkennbar ist, sofern es sich um ein nennenswert breites Gewässer handelt. Man kann also IMHO schon den kleinen Mühlkanal von der stillgelegten Mühle von nebenan gleich taggen wie den Nord-Ostsee-Kanal. Letzterer hat halt dann ein flächig gemapptes Objekt. 68 drain Das ist wörtlich genommen eher der Ablauf nach der Mühle. Wobei ich das dafür nicht nehmen würde da ich bei drain eher an einen Ablauf im Sinne einer Entsorgung denke. 62 river Siehe stream. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mühlgraben
Am 23.01.2015 um 02:36 schrieb Stephan Wolff: Am 21.01.2015 um 14:00 schrieb André Riedel: wie trägt man einen Mühlgraben ein? Falls es sich nur um den Graben ohne Wasser handelt wohl eher barrier=ditch. Ich nehme an, du meinst den Zufluss zu einer historischen Wassermühle. Wassermühlen sind dort entstanden, wo man einen Bach aufstauen konnte und genügend Gefälle für ein Wasserrad hatte. Bei hinreichender Wassermenge kam man auch ohne Mühlenteich aus. bzw ist das mit unter auch nur ein kleiner Teil des Baches vorallem bei Oberlaufkonstruktionen, da kann das durchaus nur ditch sein. Bäche werden als waterway=stream getaggt, auch die Abschnitte, die ein künstliches Gewässerbett haben (was in Deutschland auf einen großen Teil der Flüsse und Bäche zutrifft). canal ist laut englischem Wiki auf Schifffahrtkanäle und sehr große Bewässerungskanäle beschränkt: Use waterway=canal for man-made waterways used for transportation or also for the largest waterways created for irrigation purposes. Im deutschen Wiki fehlt leider die Größenangabe. Dafür wird ausdrücklich gesagt Kanalisierte Flüsse werden mit waterway=river bezeichnet. Das sollte entsprechend auch für kanalisierte Bäche gelten. +1 Es erscheint mir sinnlos, Schifffahrtkanäle und Mühlgräben mit demselben Tag zu bezeichnen. Man kann ein solches Tag nicht sinnvoll auswerten. Jede Darstellung durch den Renderer wäre für eines der Beispiele völlig unangemessen. +1 cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deprecation von associatedStreet-Relationen
Hey Sarah Am 22.01.2015 um 20:54 schrieb Sarah Hoffmann: On Thu, Jan 22, 2015 at 07:29:37PM +0100, fly wrote: Von Datennutzern, die OSM-Adressdaten nutzen, habe ich gehört, dass diese Relationen aufwendiger in der Auswertung seien als das addr:street=*-Tag an jedem Adressnode/Gebäude auszuwerten. Weis ja nicht wen Du gefragt hast, aber von nominatim weiß ich, dass die Relation ausgewertet werden und auch funktionieren, während bei Straßen mit vielen Hausnummern ohne Relation Probleme auftreten. Da hast du einen falschen Eindruck bekommen. Ja, nominatim wertet die Relationen aus, aber das ist alles ein wackeliges Konstrukt und es gibt immer wieder Probleme. Die Auswertung der Addressen mit addr:street/addr:place hingegen funktioniert anstandslos. Na,ja ich bezog mich auf #5025 [1], wo zumindest das zweite Beispiel bei mir immer noch kein eindeutiges Ergebnis liefert (springt hin und her). Einige andere Beispiele scheinen mittlerweile zu funktionieren. Nebenbei, scheint das Highlighting kaputt zu sein. Jedenfalls mit iceweasel 35 sehe keine Veränderungen wenn ich die Checkbox ändere. Als Entwickler würde ich sofort für die Abschaffung der associatedStreet- Relationen stimmen, denn das würde die Software um einiges schneller machen. Allerdings ist die Diskussion meiner Meinung nach müssig, wenn man diese Relation abschafft und dann dafür die street-Relation gross bewirbt, die sich ja nur dadurch unterscheidet, dass man ausser Addressen noch beliebige andere Objekte reintun darf. Ja, das wäre wohl der einzige akzeptable Grund. cu fly [1] https://trac.openstreetmap.org/ticket/5025 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deprecation von associatedStreet-Relationen
Am 22.01.2015 um 19:54 schrieb Michael Reichert: Am 2015-01-22 um 19:29 schrieb fly: Am 22.01.2015 um 00:16 schrieb Michael Reichert: Mittlerweile beträgt der Anteil an den gesamten Adressen in OSM nur noch 7 Prozent. Auf was beziehst Du Dich da ? Zeitraum ? 3.573.027 Objekte sind mit der Rolle house Mitglied in einer associatedStreet-Relation. [1, 2] 49.260.005 Objekte in der OSM-Datenbank haben addr:housenumber=*. Somit beträgt der Anteil der mit Relationen gemappten Hausnummern an alle gemappten Hausnummern 7,2 Prozent. Und ist das nun mehr geworden oder weniger ? Wie sieht das mit der street-Relation aus ? 7,2 Prozent ist doch gar nicht so wenig. Sauber ? Wo ist da die Diskussion auf tagging@ davor und dann eine erneute Ankündigung der Abstimmung ? Ich glaube, du solltest vor dem Schreiben einer Mail nochmal nachschauen, ob alles noch so ist, wie du glaubst. :-) https://lists.openstreetmap.org/pipermail/tagging/2015-January/021277.html https://lists.openstreetmap.org/pipermail/tagging/2015-January/021281.html Ja, ich kann die Zeiten der Emails lesen, somit ist das keine Antwort geschweige denn eine Diskussion im Vorraus. Anmerkung: Auf der deutschen Diskussionsseite schrieb tyr_asd im Oktober 2012, dass diese Relationen für mehrsprachige Gebiete eine Anwendung hätten. Ein Blick in seine Mappingregion Südtirol zeigt jedoch, dass dort mittlerweile eine name-Tag-ähnliche Lösung ohne Relationen angewendet wird. Beispiel: addr:street = Unterrainer Straße - Strada Riva di Sotto addr:housenumber = 10 addr:city = Eppan a.d. Weinstr. - Appiano s.s.d.v. addr:postcode = 39057 addr:hamlet = St. Pauls - S. Paolo addr:street:de = Unterrainer Staße addr:street:it = Strada Riva di Sotto addr:city:de = Eppan a.d. Weinstr. addr:city:it = Appiano s.s.d.v. Hatte es sich nicht rausgestellt, dass die unterschiedlichen Sprachen nicht von der Straße her abzuleiten sind und damit unnötig. Die Straße neben dem Gebäude hat sowohl name:de=Unterrainer Straße als auch name:it=Strada Riva di Sotto als auch name=Deutsch - Italienisch Dann ist doch eher der name=* das Problem, bzw. die Software welche in mehrsprachigen Gebieten nicht nach der dem entsprechenden name:*=* sucht. Zugegebener Maßen kann ich in mehrsprachigen Gebieten auch mit allen offiziellen Namen leben, allerdings lieber nur einmal in der Relation. Folgendes war dann doch nicht so ernst gemeint: Warum schaffen wir nicht gleich alle redundanten addr:* Tags ab ? * addr:street wird nur benötigt wenn es nicht die nächste Straße ist. Das gibt aber eine wackelige Konstruktion. Da hast du dann noch viel mehr noch viel stärker fragilere Konstrukute als die heutige Referenzierung von Adressen (als Ersatz von addr:country, addr:city und addr:postcode) als heute. Wenn einer die Straße verschiebt verlegt, dann gehören die Häuser plötzlich zur anderen Straße. :) Bezüglich Redundanzvermeidung sind die Erfahrungen aus der Mappingpraxis alles andere als ermutigend. Im Forum gibt es genug Berichte, dass das Konzept möglichst wenig Redundanz in OSM nicht funktioniert. Wir sind halt keine Geodatenbank aus dem Lehrbuch. http://forum.openstreetmap.org/viewtopic.php?pid=479367#p479367 und die folgenden Posts Ein weiterer Grund weder addr:street an den Objekten noch die Relation zu löschen. Ein Hauptproblem in OSM ist wohl die häufig fehlende Unterstützung der Editoren was Relationen angeht. Darum ist es auch nicht verwunderlich, wenn gerade Adressen häufig zuerst ohne Relation gemappt werden. Ciao fly [1] https://taginfo.openstreetmap.org/relations/associatedStreet [2] Es gibt noch 7114 Objekte mit der Rolle address. Das sind aber vernachlässigbar wenige (nur 2 Promille). ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Start-/Landebahn
Am 14.01.2015 um 09:14 schrieb Garry: Am 14.01.2015 um 01:13 schrieb Martin Koppenhoefer: fürs Flugzeugrouten fehlen in OSM AFAIK die relevanten Daten, die Frage Fläche oder way für die Startbahn ist vor diesem Hintergrund komplett unwichtig hinsichtlich Routing. Für z.B. potentielle Immobilienkäufer/Mieter in Flugplatznähe ist es aber vielleicht schon eine relevante Information wenn es solche beschränkte Nutzungen (nur Starts, nur eine Richt_ung_...) gibt. Das klingt mir dann eher nach einer Lösung analog zu area:highway z.B area:aeroway und aeroway=* nur für Linien benutzen. Alternative sollten mal ein paar Renderer width=* unterstützen sonst wird es schwierig beim Überzeugen, das es als Linie auch graphisch funktioniert. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie kann man Änderungen rückgängig machen?
Am 13.01.2015 um 23:27 schrieb Tom Pfeifer: malenki wrote on 2015-01-13 22:28: On Tue, 13 Jan 2015 21:47:12 +0100, Bernhard Weiskopf wrote: Mit dem JOSM Reverter Plugin habe ich keine Erfahrung. Dann wird es Zeit. :) Ich halte es nicht für einen Nachteil, wenn es mehr als nur eine Handvoll Leute gibt, die falsche Änderungen gewissenhaft ganz oder teilweise zurücksetzen können. +1 Wenn nicht mehr geändert wurde, als das, was mir direkt aufgefallen ist, kann ich dies auch einzeln editieren, denn ich kenne die Örtlichkeit und weiß wie es dort aussieht. Super, dann kannst Du ja auch das Ergebnis des Zurücksetzens gut beurteilen. Ich finde öfter Objekte, die jemand versehentlich gelöscht hat und die dann von ihm oder anderen neu gemalt wurden. Regelmäßig fehlen dann access, maxspeed und surface, von Relationen nicht zu reden. Gelegentlich fehlt auch der Name (oder er wurde falsch geschrieben). Wenn man ungute Änderungen mit dem Reverter-Plugin zurücksetzt, kann man solche Fehler vermeiden. Vorgestern erst beim Revertieren gleich eine zweite merkwürdige Änderung entdeckt. Schon interessant, wenn plötzlich Wege wieder auftauchen. Alles schön und gut, aber im konkreten Fall ging es um einen Anfängerfehler, beim Setzen eines PoI, der versehentlich auf dem Radweg landet. Wurden vermutlich beim Schreiben des Namens ein paar Tastaturkürzel aktiviert. (Ich empfinde den iD als extrem un-intuitiv.) Da kann man mit Pinsel und Schraubenzieher reparieren, und muss nicht gleich mit dem Bulldozer kommen und den gutgemeinten Erst-Edit wieder platt machen. Der Neuling soll ja vielleicht auch länger bleiben. Klar ist es möglich einfache Dinge auch direkt zu korrigieren. Bei gelöschten Objekten sieht das schon ganz anders aus. Was wir hier vermitteln wollten ist es doch bei einem einfachen Beispiel mal auszuprobieren und Erfahrungen zu sammeln. Dies geht auch wunderbar lokal in JOSM. Alles zurücksetzten kann oft sehr problematisch sein und es bedarf eine Analyse der Änderungen, häufig sind es nur ein paar Objekte und somit ein partieller Revert. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie kann man Änderungen rückgängig machen?
Am 11.01.2015 um 23:15 schrieb malenki: On Sun, 11 Jan 2015 16:03:51 +0100, Tom Pfeifer wrote: chris66 wrote on 2015-01-11 15:31: Am 11.01.2015 um 13:30 schrieb Bernhard Weiskopf: Weiß jemand, wie das geht? Das geht mit dem JOSM Reverter Plugin. Chris Halte ich für überzogen, insbesondere wenn Bernhard damit auch unerfahren ist. Wann ist der richtige Zeitpunkt, damit erste Erfahrungen zu sammeln? Zudem muss man nach dem lokalen Revert nicht zwangsweise hochladen. +1 Wobei spannender zum Üben sind da doch älter Changesets, damit auch einige Konflikte entstehen. Volker Schmidt wrote on 2015-01-11 15:01: Gib doch dem user Logge1456 ein paar Tage Zeit. Es ist sein erstes edit. Genau, und erst wenn das nicht passiert die kleinen Fehler korrigieren. +1 Nur einen Tag auf Antwort des Mappers warten zu wollen halte ich für etwas ungeduldig. Zwar dürften die meisten Leute auf dieser Liste täglich im Netz sein und ihr Mails abholen, aber es gibt auch Menschen mit anderen Tages- und Wochenabläufen. +1 Alternative gibt es noch die neue Kommentarfunktion der Änderungssätze. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Fehler
Am 01.01.2015 um 15:44 schrieb Markus: Schönes neues Jahr Die Hauptseite ist so gegliedert, dass zu erst OP-unabhängige Optionen aufgelistet werden. Grau sind Optionen mit Einschränkungen. Da du anscheinend viel mit Windows zu tun hast: nimm den Windows-Installer. Ja, es geht um die Installation auf Windows für Neue :-) Unter Linux gibt es meistens ein Paket im Distributions-Repository, aber benutzen würde ich die auch nicht. _josm-setup.exe_ Du empfiehlst dafür den Windows-Installer. Was sind die Vorzüge für den Neubenutzer? (im Wiki steht dazu nichts, und der Link-Hintergrund ist grau) Wäre damit auch die Fehlermeldung wegen dem Zertifikat erledigt? In josm.openseamap.org wird josm.jnlp empfohlen (grün und zuoberst). Da ändert sich immer mal wieder etwas, allerdings sollte .jnlp das einfachste sein, wobei java+browser ja auch schon problematisch sein kann. _josm.jnlp_ Wenn ich die Wikipedia-Seite zu jnlp richtig verstehe, wird damit eine XML runtergeladen, die vergleichbar mit einer BAT den Installationsprozess steuert? Jedesmal wenn josm.jnlp gestartet wird, wird geprüft, ob es eine neue JOSM-Version gibt (und die ggf. neu runtergeladen)? Ebenfalls wird geprüft, ob es neue Plugins oder Plugin-Versionen gibt? Auch MapPaint-Stile? und Objektvorlagen? Geprüft wird auch, ob ein JAVA existiert? und ob in aktueller Version? Das wäre ja schon ziemlich ideal für Anfänger...?! Eben, jedoch sind einige dieser Feature (zB. Pluginkontrolle) direkt in JOSM implementiert und somit unabhängig von der Installationsweise Aber als ich das auf einen JOSM-jungfräulichen Rechner versuchte, kammen alle die im der vorherigen Mail erwähnten Fehler. Das ist auf jeden Fall einen Bugreport wert, wenn andere .jnlp laufen bei JOSM ansonsten doch eher bei dem entsprechenden Java. _josm-tested.jar_ Auch hier wird dem Benutzer nicht erklärt, welchen Vorteil jar gegenüber den anderen Varianten hat. Aber dier link ist zumindest grün also irgendwie gut? Wenig Information wird gegeben. Vielleicht hilft Dir [1] bzw [2] weiter. Letzten Endes ist es ein Wiki. Ciao fly [1] https://josm.openstreetmap.de/wiki/Download [2] https://josm.openstreetmap.de/wiki/InstallNotes ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 17.12.2014 um 15:11 schrieb Martin Koppenhoefer: Am 17. Dezember 2014 um 02:24 schrieb 715371 osmu715...@gmx.de: Das Problem mit der Zuordnung der Fußwege zur Straße, bzw. umgekehrt empfinde ich als nicht so extrem. Über sidewalk=right/left/both bekommt man das schon hin. das kann man so aber nur raten, eine direkte Zuordnung gibt es nicht. Nur weil die in der Nähe liegende Straße einen Fußweg auf der Seite hat, wo auch ein Fußweg separat gezeichnet ist, bekommt man noch keine eindeutige Zuordnung in allen Fällen (z.B. schmale Straßen die parallel führen dazwischen eine Stützwand, eine Straße oben, eine unten). Man weiss bei OSM ja nie, ob die Stelle überhaupt schon zu Ende gemappt ist, oder evtl. noch wesentliche Teile fehlen. Stützwand ist jawohl eine Trennung oder ? Ala :lanes wäre: highway:ways:forward=highway|cycleway|parking|sidewalk vielleicht auch highway:ways:forward=highway|cycleway|kerb|parking|fence|sidewalk möglich. Noch nicht ganz ausgereift, gebe ich zu. Aber das ist doch doppelte Erfassung. Wobei es natürlich stimmt, dass man einen Tag an beiden Wegen benötigt. das ist so viel doppelte Erfassung, wie z.B. amenity=bank, atm=yes auf einem Objekt und amenity=atm auf einem anderen darinliegenden doppelte Erfassung ist. Das eine Tag an der Straße sagt: die Straße hat einen Gehweg, das andere Tag auf dem Fußweg sagt: ich bin ein Fußweg. Nicht ganz, bei der Straße geht genau der Unterschied zwischen doppelt gemappt oder doch zusätzlichen Weg verloren. da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsinseln und Mehrzweckspur in der Fahrbahnmitte
Hey Früher habe ich auch alles getrennt, mittlerweile versuche ich so viel wie möglich auf eine Linie zu reduzieren. Am 09.12.2014 um 09:01 schrieb Martin Vonwald: Einfachste Lösung wäre wohl: Bei Grüninseln: lanes=2 + traffic_calming=island +1 Leider wird traffic_calming and Linien nur selten unterstützt. eventuell auch noch ein Punkt mit highway=crossing. Bei Mehrzweckspur: lanes=3 + lanes:both_ways=1 + (optional falls irgendwie ersichtlich) turn:both_ways=left turn:both_ways=left;merge_to_right ? Nebenbei, ich verwende das :lanes*-Tagging auch für Bushaltebuchten. Funktioniert super. cu fly Am 9. Dezember 2014 um 00:44 schrieb Tirkon tirko...@yahoo.de: Moin, in einer Ortsdurchfahrt sind die beiden gegenläufigen Richtungsfahrspuren mehr oder weniger in der Mitte durch eine sogenannte Mehrzweckspur getrennt. Den Begriff hat die Verkehrsbehörde über die Presse verbreiten lassen. Diese mittlere Spur unterscheidet sich von den beiden Richtungsfahrbahnen durch einen leicht helleren Asphalt. Sie wird immer wieder durch bepflanzte Verkehrinseln unterbrochen, wobei teilweise eine Überquerungshilfe für Fu0gänger/Radfahrer eingebettet ist. Die Inseln sorgen dafür, dass die mittlere Mehrzweckspur - wie beabsichtigt - nicht vom fließenden Durchgangsverkehr befahren wird. Die Mehrzweckspur dient laut Presse zum Ein- und Ausfädeln von Linksabbiegern auf/von Grundstückseinfahrten und kleinen Nebenstraßen sowie zum gelegentlichen Überholen. Nur an wenigen Stellen ist die Mittelspur durch weiße Streifen von den durchgehenden Richtungsfahrspuren getrennt, nämlich wenn sie beampelt zur echten Linksabbiegespur auf größere Straßen mit Richtungspfeilen auf der Fahrbahn wird. Momentan ist die Straße bei OSM als zwei getrennte Richtungswege eingetragen, was dem funktionalen Charakter entspräche. Wollte man sie streng nach den Regeln mappen, müsste man sie suboptimalerweise wegen der vielen Inseln ständig verzweigen und zusammenführen. Gibt es da eine bessere Möglichkeit? ergänzende Info: Unmittelbar neben der Straße verläuft noch eine Güterzugstrecke mit zig Bahnübergängen durch den Ort. Bisweilen sind Bushaltestellen zwischen Bahn und Straße eingefügt. Dieses ganze Paket wird beidseitig von abgesetzen Fuß-/Radwegen eingerahmt, wobei einer keine entsprechende Beschilderung aufweist. Seit die Straße mit der Mehrzweckspur versehen wurde, läuft der Verkehr deutlich reibungsloser. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 08.12.2014 um 16:50 schrieb Hubert: Hallo, Am 8. Dezember 2014 12:05 schrieb 715371 osmu715...@gmx.de: Was, wenn der cycleway=track nur durch Bordstein von der Fahrbahn getrennt wäre? Zum Thema Bordstein-Trennung gab es Ende Oktober eine kleine Diskussuion hinsichtlich des Eintragens von Bürgersteigen (http://forum.openstreetmap.org/viewtopic.php?id=27488. Es ging darum ob und wann ja wie Bürgersteige und Überwege eingetragen werden sollen. Zusammengefasst (Ich hoffe ich erinnere mich richtig): Keine Einigung, entweder als sidewalk=right/left/both oder als highway=footway dann aber mit footway=sidewalk. Das wird bei einem Bordsteinradweg allerdings etwas schwieriger, da es (noch) keinen äquivalenten tag zu footway=sidewalk für Radwege gibt. Ich habe zumindest path=sidewalk/crossing schon öfter verwendet. Reinen cycleways begegne ich äußerst selten. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 07.12.2014 um 23:55 schrieb Tobias Knerr: Am 07.12.2014 19:19, schrieb Martin Vonwald: * Können auch Parkspuren und Gehsteige in die lane-Liste eingebaut werden? Wenn ja, wie? Parkspuren theoretisch ja, auch wenn ich kein Freund davon bin. Gehsteige würde ich nein sagen, da es ja keine Spuren für irgendwas sind. Bei Gehsteigen würde ich bei dem bewährten Konzept mit den sidewalk-Tags (inkl. Sub-Tags und ohne separate Wege) bleiben. Momentan haben wir Tags für die normalen lanes, für die cycleways, für die parking:lanes, und für die sidewalks. Das Problem, das ich lösen will: Wie kann ich angeben, in welcher Ordnung die sich zueinander befinden? Ich kann mir da zwei Lösungen vorstellen: * Alles in die *:lanes=* mit integrieren * Zusätzlich zu den genannten Tags noch eine Liste taggen, die die Reihenfolge der genannten Elemente angibt Und ich versuche gerade, etwas nachzufühlen, was wohl besser ankommt. Halte es für einfacher und verständlicher mit *:lanes*=*. Was mir an der ganzen Diskussion bisher auffällt sind die wenigen exakten Beispiele. Denke, dort sollten wir anfangen. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 05.12.2014 um 16:10 schrieb Tobias Knerr: Am 05.12.2014 13:19, schrieb Martin Vonwald: Vom Prinzip her ist bicycle:lanes=...|designated|... und cycleway:lanes=|lane| identisch. Welche Variante besser ist, kann ich sagen. Ich tendiere eher zu bicycle:lanes, da es konsistent mit der Angabe anderer access-Beschränkungen wäre, z.B. bus:lanes. Ich sehe hier einige Probleme: * Im Sinne unserer damaligen Diskussion, ob left/right nicht besser wäre als forward/backward: Wie mappe ich Radwege, die in beide Richtungen nutzbar sind? Entweder als separaten Weg und bicycle=use_sidepath oder mit einer Kombination aus left/right + forward/backward. * Können auch Parkspuren und Gehsteige in die lane-Liste eingebaut werden? Wenn ja, wie? Analog zu cycleway:lanes*=* kann ich mir auch sidewalk:lanes*=* und parking:lane:lanes*=* vorstellen Mein Problem ist hier nur der Umgang mit Barrieren álà kerb oder auch unterbrochene fence_type=railing * Zumindest, so lange es nicht ausdrücklich definiert ist, halte ich es nicht für selbstverständlich, dass die access-Angaben Auswirkungen auf die Breite etc. haben. Radspuren sind ja nicht dasselbe wie eine Spur mit voller Breite, die für Radfahrer ist (leider ;-)). Siehst du das anders? Für die Breite gibt es width:lanes*=* cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM - Fernsteuerung - Sicherheit
Am 24.11.2014 um 13:34 schrieb Markus: Liebe JOSM-Spezialisten, Beim Aktivieren der Fernsteuerung ist als Standard ein- bzw aus- geschaltet: HTTPS Unterstützung aktivieren x Daten über API laden x Daten von URL omportieren Lokale Dateien öffnen x Hintergrund-Ebenen laden x Auswahl ändern x Ansicht ändern x Neue Objekte erstellen x Protokollversion lesen Objekte in neue Ebene herunterladen Alle Fernsteuerungsaktionen manuell bestätigen Dazu habe ich folgende Fragen: - was bedeuten die einzelnen Optionen genau? (die Hilfe ist leider nur in Englisch verfügbar) - welche sollte man aus Sicherheitsgründen ausschalten? warum? * https hat noch Probleme ansonsten wäre es Standard. * lokale Dateien kannst Du auch anders öffnen. * Objekte in neue Ebene laden und alles manuell bestätigen sind Zusätz welche eher verwirren oder nervig sein können, aber definiert sicherheitsrelevant. Generell, solltest Du wohl nur die Optionen einschalten, welche Du brauchst. Ach so, die Hilfe ist ein Wiki. Grüße fly P.S.: Bei mir stellt sich immer noch NoScript in den Weg. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schwarzwald bei Ludwigsburg ?
Hey
Am 16.11.2014 um 15:27 schrieb Roland Olbricht:
http://overpass-turbo.eu/s/64G
findet den Teilstring Schwarzwald in allen Relationen.
http://overpass-turbo.eu/s/64H
läuft etwas schneller, weil es nur auf den String Schwarzwald anspricht.
Das ganze für Ways (nur die exakte Variante):
http://overpass-turbo.eu/s/64I
Achtung: zieht man die Bounding-Box größer, wird die Abfrage nicht
langsamer.
Da ist aber auch nichts plausibles bei. Es handelt sich also wohl um
einen Bug in der Rendering-Queue.
Eigentlich war ich ja auf der Suche nach *name*=Schwarzwald (oder welche
Varianten rendert Mapnik-Carto iM), damit wir endlich verstehen woher
der Schwarzwald unter Ludwigsburg herkommt.
relation[~name~Schwarzwald]({{bbox}});
liefert aber auch tausende von nodes.
cu fly
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schwarzwald bei Ludwigsburg ?
Am 15.11.2014 um 20:25 schrieb Peter Czaja: Vom Renderstil vermute ich auch ein Wald-Multipolygon, aber zumindest der Relation-Analyzer liefert mit ra.osmsurround.org/searchRelation?name=Schwarzwald kein Polygon, dessen Zentroid an dieser Stelle wäre. Grüsse, Peter On 15.11.2014 19:11, Lothar Beck wrote: Entschuldigung, ich bin da nicht so bewandert im Forum. Und auch nicht der Profi in Overpass. Ich bin nur ein normaler Mapper aus der Gegend von Ludwigsburg den es stört dass wie unten erwähnt auf Zoomstufe 11 Schwarzwald unter Ludwigsburg gerendert wird. Das passt da nicht hin, der Schwarzwald liegt ja ca. 100 km südwestlich. Auf Zoomstufe 10 steht dann nur noch Schwarzwald dort. Im deutschen Kartenstil gibt es kein Schwarzwald unter Ludwigsburg. Ich hab das tile dann mit /dirty auch mal zum neurendern angestossen, das hat aber auch nichts gebracht, denn mit /status habe ich gesehen dass es aktuell ist. Direkt in Ludwigsburg finde ich da nichts mit Schwarzwald und ein größeres Gebiet läßt mich JOSM nicht laden. Deshalb der Versuch mit der overpass turbo Abfrage, wo ich aber auch keinen Erfolg hatte (Ich fand zwar viele Schwarzwald, aber eben nur da wo sie hingehören nämlich im Schwarzwald und nicht bei Ludwigsburg) Ich vermute da gibt es irgendwo in der Datenbank eine große Relation oder Grenze oder was auch immer mit dem Namen Schwarzwald, was dann dazu führt dass der Name dort bei Ludwigsburg gerendert wird. Ich wäre glücklich wenn mir einer die ID und den Typ des Elementes dazu in der Datenbank findet. Dann kann ich weitersehen welchen Sinn das hat oder ob man das ändert / löscht. Gruss Loth -Ursprüngliche Nachricht- Von: christian.pietz...@googlemail.com [mailto:christian.pietz...@gmail.com] Gesendet: Samstag, 15. November 2014 00:24 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] (kein Betreff) bin nochmal schnell durch den Artikel und hab bei dem 3D Modell Links ergänzt und das mit F4 geändert (bei mir funktioniert es) Am 15. November 2014 00:12 schrieb christian.pietz...@googlemail.com christian.pietz...@gmail.com: bin durch..ein paar Kleinigkeite und 2 Links korrigiert Am 14. November 2014 23:51 schrieb christian.pietz...@googlemail.com christian.pietz...@gmail.com: ich schau gleich mal drüber Am 14. November 2014 22:42 schrieb Lothar Beck lothar.b...@t-online.de: Hallo, kurze Frage, weil ich etwas nicht verstehe / finde: Auf der Karte: http://www.openstreetmap.org/#map=11/48.8652/9.1599 Also nur Zoomstufe 11 sehe ich unter der Bezeichnung Ludwigsburg (also die Stadt) den grünen Test Schwarzwald. Das macht meiner Meinung nach dort wenig Sinn. Ich weiss aber nicht wo das herkommt, ich will mir auch nicht den gesamten Bereich in JOSM laden, das geht vermutlich auch nicht. Mit Overpass turbo habe ich nach dem Namen Schwarzwald gesucht, aber kein Ergebnis in way, node, oder relation bekommen. Hat mir jemand einen Hinweis / Erklärung ? Zuerst ist mir folgende Relation eingefallen: https://www.openstreetmap.org/relation/3255371 Die ist es aber nicht. Jedoch findet overpass-turbo sie auch nicht: http://overpass-turbo.eu/s/64d Alles sehr schleierhaft. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] priority=* an railway=*
Am 06.11.2014 um 11:40 schrieb Peter Czaja: On 05.11.2014 20:04, Alexander Matheisen wrote: On Mi, 2014-11-05 at 15:38 +0100, fly wrote: Am 04.11.2014 um 20:15 schrieb Michael Reichert: Hallo Fly, Am 2014-11-04 um 18:48 schrieb fly: Dachte, die wären doch zu Google gegangen. Mentz war noch nie sehr diskussionsfreudig von Doku ganz zu schweigen. Hier hat mal wieder eine Firma ihre Mitarbeiter*innen nicht unter Kontrolle. Am besten allen eine Mail schreiben und darauf hinweisen, dass so was im Vorhinein zu diskutieren ist. http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000157.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000159.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000164.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000165.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000166.html Danke, aber sowas gehört doch auch auf eine offizielle Mailingliste wie transit@ oder tagging@ Damit meinte ich in erster Linie eine internationale Liste (meist in englischer Sprache) Auch auf dieser Liste hätte ja zumindest ein Link zur Diskussion mitgeteilt werden können. Meine direkte Antwort auf unten. Bei wievielen Mailinglisten soll ich mich denn sonst noch überall anmelden ? Rückfrage: Auf wie vielen verschiedenen Kanälen soll denn nun über Eisenbahntagging diskutiert werden? Wer an Eisenbahnthemen in OSM interessiert ist, dürfte meist ohnehin bei der ORM-Mailingliste angemeldet sein. Der Sinn der ORM-Mailingliste ist es ja, Eisenbahnthemen unter interessierten Mappern zu diskutieren. transit und tagging sind für solche Themen nicht wirklich geeignet. s.o. Grundsätzlich sollte eine Erarbeitung eines Schema doch genau in ein Proposal enden und somit auf jeden Fall dokumentiert sein und foglich zumindest das Proposal und eventuelles Voting auch auf tagging@ angekündigt werden. Unabhängig davon sehe ich im vorliegenden Fall auch überhaupt keinen Grund, das Thema auf den genannten Mailinglisten anzusprechen. Statt eines etablierten und vieldiskutierten Taggingschemas hat Mentz - warum auch immer - ein veraltetes und ungeeignetes Taggingschema angewendet. Ich sehe bei dem Thema keinen Diskussionsbedarf mehr... Wenn man solch großräumige Edits am Datenbestand anbringt, ist es aber wirklich das Mindeste, das entsprechend leicht auffindbar im Wiki bei dem verwendeten Tag zu dokumentieren. Und wenn http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000169.html richtig verstehe, rudert die Firma Mentz nun zurück bezüglich der Verwendung des Tags 'priority'. Schaumama, Nicht das erste Mal und natürlich auch kein Wort darüber auf dieser Liste. cu fly cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Das alte Schema hat Schwächen und ist am Ende auch nur eine Sammlung, da der Streckenverlauf gerade bei Bussen nicht mehr nachvollziehbar ist. Unter anderem desshalb wurde das neue Schema erarbeitet. Leider wird dieses bis heute auf keiner der auf der Hauptseite angebotenen Karten unterstützt. Da alle Tram und Stadt-Buslinien auf das neue/aktuelle Schema umgestellt sind hatte ich mich entschlossen auch das alte Tagging an den Haltestellen zu entfernen. Pustekuchen, alle Haltestellen verschwanden, nur die deutsche Seite gab mir Hoffnung. Ich sehe das Problem eine Stufe höher angesiedelt, da hier noch nicht einmal beide System komplett unterstützt werden und somit keine gleichen Chancen existieren. Ob es nun an jeder Bushaltestelle eine stop_position geben muss, kann man gerne diskutieren, aber wir brauchen die stop_position auch bei Buslinien und das alte Schema hatte genau Problem mit der Unterscheidung/Positionierung welche nun gelöst sind. Eine Ausnahme für Busse einzuführen macht es auch nicht einfacher und die Komplexität steigt auch nicht damit, ob es nun jeweils ein Objekt mit einer Rolle oder zwei Objekte mit ihrer Rolle sind. Das Grundprinzip der Relation mit Rollen und sowohl platform wie stop_position müß verstanden werden. cu fly Am 05.11.2014 um 06:08 schrieb Tirkon: Michael Reichert naka...@gmx.net wrote: Wenn aber z.B. eine Linie mit kurzen Zügen und eine mit langen Zügen vor der selben Haltetafel halten, dann brauchen die beiden getrennte stop_positions. Würdest Du mir zustimmen, dass die stop_position nur in sehr wenigen Fällen nicht aus den Positionen der Haltestellenschilder bzw. der Positionsschilder ABCDEF z.B. durch Fällen des Lotes auf den Verlauf der Routenrelation hervorgeht? Falls ja, bitte ich Folgendes zu bedenken: Das Mappen des ÖPNV geschieht derzeit sehr uneinheitlich. Eine große Mehrheit von Mappern versteht das derzeitige ÖPNV Schema mit der Aufteilung einer Haltestelle in platform und stop_position nicht. Wenn schon OSM-Füchse wie die Moderatoren des Podcastes sich nicht damit auskennen, sollte man doch schon ins Grübeln kommen. Es nützt nichts, wenn die Diplomarbeit von Sebastian Schwarz-Versteher ein Schema beschließen, an deren Abstimmung die große Mehrheit der Mapper nicht teilnehmen kann, weil sie deren Diskussion nicht versteht. Folglich wird das Modell nicht oder nur fehlerhaft umgesetzt. Selbst richtig gemappte Busrouten-Relationen werden dann inkonsistent, wenn der Mapper vor Ort bei Verlegung einer Bushaltestelle nur die platform aber nicht die stop_position verschiebt. Vielleicht bemerkt er auch (sofern er nicht ID nutzt) die Routen-Relation, lässt aber wegen der Komplexität dann die Finger von der Wartung. Ergo müssen die Datenjunkies beim Entwurf ihrer Schemata für die große schweigende Mehrheit der Mapper mitdenken und das Teil ergonomisch und intuitiv gestalten. Und was ist intuitiver als die Realität, in der für den Mapper nachvollziehbar der ÖPNV am Schild bzw. Wartefläche hält? Abseits vom Verständnis der Datenkonstruktion kommt noch Folgendes hinzu: Wer über 20 km mit dem Auto zu einem Bahnhof fahren muss, um von dort aus nach über zwei Stunden Zugfahrt den nächsten ICE Bahnhof zu erreichen, der fährt lieber gleich mit dem Auto zum Endziel und wird die seltene Notwendigkeit einer stop_position niemals live erleben. Dennoch ist man in der Lage, ein verschobenes Bushaltestellenschild in seinem Ort auch in OSM zu verschieben. Ich selbst kann als Landei die Teilung von Bahnsteigen durch Buchstaben nur deswegen nachvollziehen, weil ich alle zwei Jahre in München in einen in Hannover geflügelnden ICE einsteige. Was nutzt ein Modell, das zugunsten weniger Spezialfälle so komplex wird, dass es nicht funktioniert? Es geht hier also nicht um das Deprecaten eines Tags, sondern um ein Modell, das nicht nur von einer kleinen Minderheit umgesetzt werden kann. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] priority=* an railway=*
Am 04.11.2014 um 20:15 schrieb Michael Reichert: Hallo Fly, Am 2014-11-04 um 18:48 schrieb fly: Dachte, die wären doch zu Google gegangen. Mentz war noch nie sehr diskussionsfreudig von Doku ganz zu schweigen. Hier hat mal wieder eine Firma ihre Mitarbeiter*innen nicht unter Kontrolle. Am besten allen eine Mail schreiben und darauf hinweisen, dass so was im Vorhinein zu diskutieren ist. http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000157.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000159.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000164.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000165.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000166.html Danke, aber sowas gehört doch auch auf eine offizielle Mailingliste wie transit@ oder tagging@ Auch auf dieser Liste hätte ja zumindest ein Link zur Diskussion mitgeteilt werden können. Bei wievielen Mailinglisten soll ich mich denn sonst noch überall anmelden ? Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Am 05.11.2014 um 12:53 schrieb Martin Koppenhoefer: Am 4. November 2014 18:18 schrieb fly lowfligh...@googlemail.com: Jain, forward/backward funktioniert nicht direction=* in Himmelrichtungen bzw Winkel geht sehr gut wenn man die tatsächlichen Werte dieses Keys betrachtet ist allerdings clockwise mit Abstand der häufigste Wert, danach kommen forward und backward ;-) https://taginfo.openstreetmap.org/keys/direction#values Wir reden wohl eher von Punkten: https://taginfo.openstreetmap.org/keys/direction?filter=nodes#values clockwise kommt durch junction=roundabout forward/backward wurde mal gehipt und wird immer noch von Vorlagen unterstützt. Auch steht es an mehreren Stellen im wiki (zb. traffic_sign). Im Moment wird es von openrailway-tagging verwendet macht aber auch da keinen Sinn und ist extrem Fehler anfällig, da weder die Richtung der Linie umgedreht werden darf noch die Linie an diesem Punkt geteilt werden darf. Alles in allem kannst Du bei absoluten Werten hier wohl eher nur die Werte von forward+backward mit allen Werten mit Grad + Himmelrichtungen vergleichen Alternativ vielleicht auch orientation? Fände ich sprachlich besser, kommt aber nur 350mal vor bisher, dafür mit augenscheinlich konsistenteren Werten: https://taginfo.openstreetmap.org/keys/orientation#values Wohl eher beim Luftverkehr verwendet. fast 90K mal gibt es die roof:orientation Variante, die dafür andere Werte hat: https://taginfo.openstreetmap.org/keys/roof%3Aorientation#values Hat auch 90% along bzw across als Wert. Sorry, überzeugen mich beide nicht so wirklich. Denke das Hauptproblem war die Wikiseite, wo viel zu lange forward/backward ganz oben stand. Zur Zeit fehlt immernoch ein Hinweis, dass diese Werte an Punkten von keiner Edit-Software unterstützt werden. Ciao fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Am 04.11.2014 um 14:20 schrieb Hubert: Am Di 04.11.2014 13:32 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Richtungsangaben auf nodes, die sich auf die Richtung des ways beziehen (und nicht z.B. auf Himmelsrichtungen) sind broken, nicht nur, weil nodes keine Richtung haben, sondern z.B. auch, weil es ways mit verschiedenen Richtungen geben kann, die durch denselben node laufen. Jain, forward/backward funktioniert nicht direction=* in Himmelrichtungen bzw Winkel geht sehr gut Laut wiki [1] ist die Richtung definiert als Richtung in die das Objekt zeigt. zumindest zumindest die Begründung weil nodes keine Richtung haben ist nachvollziehbar. Im Anderen Falle kann man ja die Ampel auf die Haltelinie setzten. Dann hat man keine sich kreuzende Nodes. Ich setzt die Ampel meistens an den Übergang bzw an die Haltelinie bei fehlendem Übergang und gebe direction=* an. Man müsste sich einmal mal überlegen, ob man einen Datenauswerter dabei unterstüzen kann, zu erkennen, wieviele Ampeln zusammengehören. Zum Thema Kreuzungen gab es gerade einige Diskussion auf tagging@ und es existieren mehrere Proposal diese als Fläche zu taggen. Weiß allerdings nicht welche Software sowas schon einsetzt und in Asien geht es primär darum Kreuzungen bzw Ampeln Namen zu geben. Grüße fly [1] https://wiki.openstreetmap.org/wiki/DE:Key:direction ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Am 04.11.2014 um 18:31 schrieb Hubert: Hey, On Di 04.11.2014 16:42 Florian Lohoff f...@zz.de wrote: Ich hatte mal überlegt ob man das durch eine relation lösen könnte. D.h. alle Signale die zu einer Kreuzung und einer Steuerung unterliegen zu einer Relation zusammenfassen. Damit wäre die zuordnung zu einer Kreuzung gegeben. Dann gäbe es auch die möglichkeit noch: - Ampelphasen (Wegen der statistischen 1/2 Ampelphase Wartezeit) - Laufzeiten z.b. 8-16:00 etc zu Dokumentieren. Nur so mal ins unreine gesprochen Das halte ich für einen gangbaren Weg. Meine Ideen dazu: Wenn dann die Relationen so eingesetzt werden, dass man zu einer Ampel kommt, alle anderen Ampeln der gleichen Relation auf dem Weg über die Kreuzung nicht mehr gezählt werden. Eine ähnliche Relation könnte man dann auch für Fußgänger/Radfahrer übergänge nutzen. (zweimal hintereinander highway=traffic_signals + crossing=signals oder highway=crossing + crossing=signals) Im Zweifelsfall hat man dann aber mehrere Relationen pro Kreuzung. Außerdem könnte man so auch eine Grüne Welle darstellen/simulieren. Dafür braucht es doch keine Relation, eine geschlossene Linie genügt vollkommen. Siehe [1],[2] und [3]. Weiß jemand ob die Ideen mit dem Junction-Proposal im Widerspruch stehen? http://wiki.openstreetmap.org/wiki/Proposed_features/Junction cu fly [1] https://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Djunction [2] https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named [3] https://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Djunction ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] priority=* an railway=*
Dachte, die wären doch zu Google gegangen. Mentz war noch nie sehr diskussionsfreudig von Doku ganz zu schweigen. Hier hat mal wieder eine Firma ihre Mitarbeiter*innen nicht unter Kontrolle. Am besten allen eine Mail schreiben und darauf hinweisen, dass so was im Vorhinein zu diskutieren ist. cu fly Am 04.11.2014 um 18:32 schrieb Peter Czaja: Moin, mir fallen gerade Änderungen am Schienennetz auf, in denen die Firma Mentz DV priority=(yard | primary | switch) an railway=*-Wege anbringt. Im Wiki http://wiki.openstreetmap.org/wiki/DE:Key:priority finde ich auch die nichts zu dem value 'primary'. Auch unter den Modellierungsvorschlägen unter http://wiki.openstreetmap.org/wiki/%C3%96V_Firma_Mentz_Datenverarbeitung_GmbH/Modellierungsvorschl%C3%A4ge nicht. Weiss jemand Näheres über das verwandte Tagging-Schema? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WMTS-Einbindung in JOSM
Am 10.10.2014 14:31, schrieb Blaßnig Emmanuel: Danke für deine Rückmeldung. Ich habe einen eigenen WMTS-Dienst gemacht, die Orthofotos wurden mit QGIS erzeugt. Ich verwende folgenden Link im JOSM http://webgis.linz.at/WMTS/1.0.0/getcapabilities.xml Die Fehlermeldung die ich dann bekomme lautet: !!! Konnte die Liste der WMS-Ebenen nicht einlesen. !!! Dann scheint es bisher nicht zu funktionieren. Kannst ja ein Ticket [1] eröffnen und darum bitten. Grüße fly [1] https://josm.openstreetmap.de/newticket ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vertrauen in OSM-Wochennotiz
Am 07.10.2014 13:54, schrieb Martin Koppenhoefer: Am 6. Oktober 2014 16:35 schrieb fly lowfligh...@googlemail.com: Es gibt wahrscheinlich nichts sichereres als ein eigenes Zertifikat, jein, weil wenn man das nicht prüft sondern einfach, weil sowieso selbstgemacht, immer abnickt, dann ist ein Man-in-the-middle problemlos möglich. Dafür haben die Lauscher keine Kopie des Server-Schlüssels. Bitte zitiere doch nicht einen halb Satz ! Ich habe geschrieben: Es gibt wahrscheinlich nichts sichereres als ein eigenes Zertifikat, wenn ich jetzt noch den Fingerprint über eine andere Quelle bekomme, aber wer vergleicht den heute noch Fingerprints oder Checksummen ? entscheidend ist der Fingerprint über eine andere Quelle/Medium, ob Telfon, Ausdruck, Chat etc. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verbesserung der attributiven Heterogenität (War: Was gibt es für unterschiedliche Tagging-Schemen?)
Am 05.10.2014 22:16, schrieb Stefan Keller: Ich habe kurz nachgeschaut: 1. Ablösung highway=ford durch ford=yes : Ist in der Wiki-Seite vermerkt: http://wiki.openstreetmap.org/wiki/Ford#Remarks Da gibt es noch 6'222 gegenüber 51'728. 2. Ablösung von landuse=reservoir durch natural=water + water=reservoir : Ist in der Wiki-Seite vermerkt: http://wiki.openstreetmap.org/wiki/DE:Tag:landuse%3Dreservoir Da gibt es noch 308'718 gegenüber 25'537. Fazit dieser (zugegebenermassen kleinen) Stichprobe: * Das Wiki scheint mind. für Tag-Beschreibungen aktueller als manche denken(?). * Für deprecated gibt es die Wiki-Seite Deprecated_features * Aber es gibt offenbar keine Formatvorlage (Hinweise: Manchmal ist auch nur ein Abschnittt deprecated - was dann?) * Deprecated_features scheint unvollständig (z.B. landuse=reservoir). Hinweis: Das ist m.E. keine Tag-Beschreibungsseite sondern eine Art Meta-Seite. * Einzelne Ablösungen sind offenbar noch lange nicht abgeschlossen (z.B. landuse=reservoir durch natural=water + water=reservoir) Und genau da hast Du wohl einen Fehler der deutschen Übersetzung gefunden. landuse=reservoir wurde nie als veraltet erklärt nur die Definition genauer. Es ist eben nicht nur der Wasserbereich sondern zumindest auch noch der Damm bzw Begrenzung häufig auch noch ne Wiese. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vertrauen in OSM-Wochennotiz
Richtig oder falsch ? Benutzt Ihr alle noch RC4 oder verzichtet Ihr auf YouTube ? Es gibt wahrscheinlich nichts sichereres als ein eigenes Zertifikat, wenn ich jetzt noch den Fingerprint über eine andere Quelle bekomme, aber wer vergleicht den heute noch Fingerprints oder Checksummen ? cu fly Am 05.10.2014 21:02, schrieb Hakuch: nein, find ich nicht, denn warum dieser CA-Mafia unnötig Geld in den Rachen schmeissen? Ok, ja es gibt noch kostenlose aber auch umständliche Möglichkeiten die evtl. auch einen Warndialog erzeugen. Statt *Entweder richtig machen oder sein lassen!* würd ich eher sagen *hauptsache verschlüsselt* PS, nochmal einen informativen Link zu der ganzen Diskussion (fefe muss man nicht mögen, diese Infos sind aber gut) http://blog.fefe.de/?ts=b25933c5 On 05.10.2014 20:49, Johann H. Addicks wrote: Dass auf die Frage warum passt das SSL-Zertifikat bei den Wochennotzizen nicht die Antwort zu bekommen das ganze CA-System ist sowieso broken by design und ausserdem zu teuer und man könne ja eine Ausnahmeregel setzen: Das kommt mir so vor als ob der Restaurantgast der ein kaltes, versalzenes Essen reklamiert als Antwort bekommt, dass Fastfood bei McDonalds noch ungesünder sei und ausserdem könne er ja Reis dazubestellen, der sei heiß und dann wäre es auch in Summe nimmer so salzig. TLDR Oder um mich den Vorrednern anzuschießen: *Entweder richtig machen oder sein lassen!* ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebiete bezeichnen - Archipel, Insel, Inselchen, Fels
Am 26.09.2014 12:09, schrieb Archer: _Archipel_ Beim Archipel werden vermutlich oft nur die Hauptinseln in die Relation eingebunden (manche mit vorgelagerten Kleininseln, manche ohne), Und kleinere Insern werden oft vergessen. Eine Bounding-Linie wäre zwar eindeutig, aber das wäre eine virtuelle Marke... Dann muss man halt die fehlenden Inseln in der Relation nachtragen, das ist kein Grund irgend eine Bounding-Box drumrum zu zeichnen um Zeit zu sparen. +1 auch gibt es häufig noch Seegrenzen somit erst Recht kein Grund für eine zusätzliche BBox. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Josm
Am 23.09.2014 13:37, schrieb Eifelhunde: Hey Steffen Bitte schreibe bei solchen Fragen doch zumindest dein Betriebsystem dazu. Da JOSM Java benötigt ist auch diese Versionnummer wichtig. Josm braucht ne Ewigkeit (mehrere Minuten) um sich überhaupt einzuloggen. Mein Frage, wie verbindet sich Josm überhaupt mit dem Netzt? wird da ein browser zur hilfe genommen oder macht das josm alleine? Ich kann mich nicht erinnern das ich irgendwas großes geändert hätte. Ich hab josm auch mehrfach installiert, mit allen nebenschauplätzen und wieder installiert, es ändert sich nichts. Wenn ichs über josm.exe probiere kommt ne Fehlermeldung das Java nicht gefunden wird. Grundsätzlich gibt es mehrere Möglichkeiten JOSM auf Windows zu installieren/betreiben wie auf der Homepage [1] beschrieben. Was Du auf jeden Fall aber benötigst ist eine Java 7 Laufzeitumgebung. Diese muss im Zweifel zuvor installiert werden. Grüße fly [1] https://josm.openstreetmap.de/wiki/De:WikiStart ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Josm
Am 23.09.2014 19:46, schrieb Frank J.: Am 23.09.2014 um 13:37 schrieb Eifelhunde: Josm braucht ne Ewigkeit (mehrere Minuten) um sich überhaupt einzuloggen. ... Grüße aus der Eifel Steffen Hallo, mein JOSM hat derzeit nach dem Start einen kleinen Hänger, weil er auf http://openptmap.de/favicon_pt.png wartet. Die URL gibt's nicht mehr. PT = Public Transport = ÖPNV Das wird bestimmt bald behoben. Im Zweifel mal die offline Funktion ausprobieren, dann sollte nichts mehr warten. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nutzung der IBGE Mapa de Setores Urbanos beim Mappen in Brasilien
Am 08.09.2014 21:26, schrieb Joao Porto: 2014-09-08 18:45 GMT+02:00 Andreas Schmidt schmidt-postf...@freenet.de: 1. Wie schreibe ich die in Majuskeln geschriebenen Namen richtig ab? Beispielsweise „RUA PERICLES VIEIRA“ wird das in portugiesischer Landessprache zu „Rua Pericles Vieira“ oder „Rua pericles Vieira“ oder „Rua pericles vieira“ oder gar zu „rua pericles vieira“? Rua Pericles Vieira wäre hier Richtig. 2. gehe ich recht in der Annahme, dass „RUA SEM DENOMINACAO“ bedeutet, dass die Straßen keinen Namen hat? Genau, die Strasse hat wenigstens keinen offiziellen Name. Wie sollte man es handhaben, diesen „Namen“ ins Namefeld in JOSM eintragen oder den Namen leer lassen? Bisher hat man meinstens das Feld leer gelassen. Ich glaube, das macht auch am meinsten Sinn. plus: noname=yes Auf deutsch noch nicht, aber auf Brasilianischem Portugiesisch gibt es auch die entsprechende Wikiseite [1] Hilft den Mapper_innen und der QA-Software. Falls jemand meine Fragen auf portugiesisch übersetzen kann, würde ich das gerne nehmen und mir einen lokale Mailingliste suchen. Man kann wie vom anderen Mapper vorgeschlägt auf jedem Fall bei unserem Talk-br auf Englisch schreiben, ja sogar auf Deutsch. Sie sind da willkommen und ich persönlich bin nur dankbar für jede Unterstützung, OSM in Brasilien voranzubrigen. +1, wenigstens versuchen, da finden sich bestimmt Moderator_innen, die gerne falls nötig auch übersetzen bzw entstehen persönlich Email Kontakte. Ciao fly [1] https://wiki.openstreetmap.org/wiki/Key:noname ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umweltzone Köln
Hey Roland und alle anderen Ich kenne durchaus Straßen die nur von einer Seite nicht aus der Umweltzone erreichbar sind und ja es muss gewendet werden ohne wirkliche Möglichkeit. Probleme mit den Schildern hatte ich bisher noch nicht habe aber auch noch nicht systematisch gesucht. Da die offiziellen Daten (Amtsblatt) nur sehr grob sind, ist auch das Abbild an etlichen Stellen noch sehr wage. Und zuletzt der problematischste Punkt: Auch bei mir gibt es keine Möglichkeit die Zone richtig darzustellen, da eine Straße in der Mitte komplett ausgelassen ist, jedoch die Brücken darüber eben nicht bzw verläuft ein Teil der oben genannten Straße im Tunnel. In meinem Fall bleibt also nur die Möglichkeit, es doch an alle Linien zu taggen oder einen eigenen Type von Relation zu definieren, welcher Multipolygon erweitert und bestimmte Objekte ausnimmt. Grüße fly Am 07.09.2014 12:31, schrieb Roland Olbricht: Liebe Mitmapper, Im Rahmen der Wochenaufgabe http://blog.openstreetmap.de/blog/2014/08/wochenaufgabe-umweltzonen-kw-3536-25-08-7-09-2014/ habe ich mir die Umweltzone Köln vorgenommen. Schließlich bringt man OpenStreetMap am besten voran und lernt auch am meisten über die Werkzeuge, wenn man mappt. Ein paar Beobachtungen dabei will ich daher festhalten. Für Köln habe ich mich entschieden, weil die Stadt mit OpenStreetMap durchaus wohlwollend umgeht (und bei mir um die Ecke liegt). Zum einen basiert der touristische Stadtplan http://stadtplan.koeln.de/ auf OSM-Daten, zum anderen haben wir von der Stadt Köln ein Adressverzeichnis bekommen, so dass zumindest theoretisch sogar alle Kölner Adressen in OSM verzeichnet werden könnten. In der Praxis würde ich dafür allerdings eher die amtliche Liegenschaftskarte von NRW nutzen. In NRW haben wir die Erlaubnis, Adressen aus dem ALK abzuschreiben, daher steht es als Hintergrundlayer in JOSM zur verfügung. Generell ist das gegenüber der Situation vorher eine deutliche Erleichtung. Zahlreiche Adressen hätte ich sonst nicht finden können. Denn nicht alle Hauseigentümer bringen ihre Hausnummern so an, dass man sie als Fußgänger oder vom Fahrrad aus sehen könnte. Vom Auto aus wird sogar noch schwieriger. Natürlich kann man die Frage stellen, welchen Nutzen eine Hausnummer hat, wenn ein Benutzer der Karte sie nicht finden kann. Einer ist eben, dass man die Angabe Die Umweltzone endet bei Hausnummer 1377 in eine zumindest auf 20 Meter genaue Geokoordinate umsetzen kann. In dieser Form hat die Stadt Köln nämlich ihre Umweltzone vorgelegt http://www.stadt-koeln.de/mediaasset/content/pdf57/strassen_und_adressen_in_der_umweltzone.pdf Wie hilfreich ist das? Generell würde ich zu einer Umweltzone wünschen, dass sie zumindest Kreuzungen auflöst, so dass man zu jeder einzelnen Straße entscheiden kann, ob sie drinnen oder draußen ist. Überraschenderweise reichen Hausnummern dafür nicht: Hier http://www.openstreetmap.org/#map=18/50.96584/7.02683 ist für die Bergisch Gladbacher Straße die Hausnummer 267 als Grenze angegeben, so dass man nicht weiß, ob man noch in die Gronauer Straße hineindarf oder nicht; die Gronauer Straße gehört überraschenderweise nicht nur Umweltzone. Hier http://www.openstreetmap.org/#map=18/50.97472/6.97126 gilt das gleiche für die Aral-Tankstelle (und die beiden Industriezufahrten) an der Friedrich-Karl-Straße; sie gehört bis zur nicht auffindbaren Hausnummer 270 zur Umweltzone. Es gibt auch gleich Straßen ganz ohne Hausnummern, z.B. Unterer Komarweg, Mülheimer Brücke und Niehler Gürtel, bei denen man aus dem Kontext rekonstruieren muss, ob sie zur Umweltzone gehören: wenn man an der einen Seite sowieso nur in die Umweltzone kommt, darf man vermuten, dass die Straße selbst auch zur Umweltzone gehört. Wobei eben auch Straßen ausgenommen sein können, selbst wenn sie nur Straßen innerhalb der Umweltzone miteinander verbinden. Das gilt z.B. für die Militärringstraße http://overpass-turbo.eu/s/4VS . Mit Ortskenntnis wäre es sehr überraschend gewesen, wenn die Straße zur Umweltzone gehörte. Es zeigt auch auf, dass die Modellierung als Polygon nicht ausreichend aussagekräftig ist: Hier http://www.openstreetmap.org/#map=17/50.93770/6.88473 kreuzt die Straße Aachener Straße (innerhalb der Umweltzone) besagte Militärringstraße (außerhalb der Umweltzone). Das gleiche Problem dürfte für 30-Zonen existieren; auch diese dürfen ja auf Brücken über Straßen außerhalb von 30-Zonen verlaufen. Andererseits ist es zumindest für die Umweltzone keine Option, sie als Relation oder Tag an Wegen zu notieren: Als Relation wäre sie mit mehreren tausend Wegen drinnen kaum handhabbar. Als Tag gäbe es Schwierigkeiten, absehbare Änderungen an den Bedingungen der Umweltzone nachzuziehen. Beide Konzepte wäre anfällig für Abgrenzungen: muss eine Busspur oder ein Radweg noch getaggt werden? Wer kontrolliert, ob neue Wege oder umgestufte Wege korrekt mit der Zone getaggt werden? Insgesamt wird man wohl über
Re: [Talk-de] Wie taggt man das LKW-Mautschild?
Am 05.09.2014 11:33, schrieb chris66: Am 05.09.2014 10:40, schrieb KWO: ich wollte nachfragen, wie man das LKW-Mautschild in OSM taggt? Oder sind schon welche in OSM getaggt? Es ist das Verkehrszeichnen 390 Mautpflicht nach dem Autobahnmautgesetz. traffic_sign=DE:390 Gab es nicht auch noch ein tag für die Linie (Straße) ? cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:state massen remove in DE
Am 03.09.2014 19:05, schrieb Jacob Bräutigam: Hallo Jacob Hallo an alle, als Verursacher der Diskussion möchte ich mich auch zu Wort melden. Super ! Vielleicht einmal kurz die Vorgeschichte: ich habe in den letzten Wochen in Berlin die Adressdaten mit den vom Geoportal zur Verfügung gestellten Daten ergänzt. Dabei ist mir der addr:state-Tag an einer der Adressen aufgefallen. Im Wiki zu den addr-Keys war er als Bundesland beschrieben, mir hats gefallen und ich habe begonnen, den Tag in den gerade ergänzten Gebieten Berlins mit einzusetzen. Das führte dazu (wie Dietmar schon richtig herausgefunden hat), dass Gehrke mich angeschrieben hat und mich gebeten hat, auf diesen Tag zu verzichten. Daraufhin habe ich mich etwas umgesehen und den Wiki-Artikel zum Karlsruher Schema gefunden. Darauf wird der Tag beschrieben als: The state for those countries like the US and Australia that have state abbreviations in their addresses. For other countries this is not used. Damit die Tags in Berlin einigermaßen konsistent benutzt werden, habe ich mich Montag daran gemacht, die addr:state-Tags in Berlin zu entfernen. Die waren fast ausschließlich von mir, dass sollte also kein allzu großes Problem gewesen sein. Sehe ich auch als OK an wenn die tags noch nicht lange vorhanden waren. Weil es in Deutschland nur wenige Gebiete gab, in denen die Tags auch benutzt wurden, habe ich diese dann am Dienstag ebenfalls entfernt. Das ich damit so große Wellen schlagen würde, habe ich nicht gedacht. Deshalb habe ich keine Diskussion in den Mailinglisten oder dem Forum angefangen. Da hättest Du zumindest mal die Personen befragen sollen, welche die Tags eingetragen haben. Für mein Vorgehen entschuldige ich mich. +1 Ich werde die losgetretene Diskussion verfolgen und falls es eine Einigung für einen Revert gibt, werde ich den natürlich machen. Dann würde ich aber vorschlagen, dass wir uns auf eine konstante Art der Bezeichnung einigen. (Gesehen: Abkürzung in 2 Buchstaben, ausgeschrieben in Deutsch, ausgeschrieben in Englisch, teilweise mit Ergänzungen wie Freistaat) Außerdem wäre eine konsistente Beschreibung im Wiki sicher wünschenswert, damit wir diese Diskussion nicht ganz so schnell wieder führen. (Zur Zeit: Karlsruhe Schema (en): for those countries that have state abbreviations in their addresses, Karlsruhe Schema (de): nichts, Key:addr (de): gestern ergänzt um Bundesstaat, in DE/AT/CH in Adressangaben unüblich) Das Wiki sollte imho als erstes angepasst werden, nach einer Diskussion. Ich finde es auch wichtig in der englischsprachigen Version auf die Begrenzung von einzelnen Ländern hinzuweisen. Am Ende bleibt mal wieder viel Theater um wenig Inhalt. Zugegebener Maßen, es war ein mechanical edit und das hat auch für den großen Wirbel gesorgt. Die Overpass-api macht es leider zu einfach, darum besprecht doch solche Änderungen bitte im Voraus in mehreren Medien. Auf ein paar Tage kommt es jawohl nicht an. Dann kann auch gleich das Wiki entsprechend angepasst werden und es muss nicht ein Bot laufen um diese Tags regelmäßig zu entfernen. Im Grunde ist ja alles OK aber die Art und Weise war es halt nicht. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Veröffentlichung OpenTopoMap Garmin-Edition
Am 27.08.2014 11:59, schrieb Sven Geggus: fly lowfligh...@googlemail.com wrote: Auf jeden Fall, wenn möglich auf der offiziellen Seite oder bin ich der einzige hier ? Na ja, Abnehmer würden sich sicher finden. Mal schaun. Das komplizierte am Buildprozess der alten AIO waren ja eigentlich die zuschaltbaren layer. Ich habe die für mich immer weggelassen. Wenn ich so schaue wäre der Addresslayer vielleicht noch sinnvoll. Der Vorteil der Layer ist die Flexibilität. Adressen und Maxspeed sind super. FIXME könnte vielleicht durch notes ersetzt werden. Leider hat die AIO meist an einer Person gehangen und ist aus mehreren Gründen immer wieder eingeschlafen. Somit sehe ich eine monatliche Aktualisierung der Basemap als Verbesserung. Ob wir je wieder zum Feature der selbstzusammengestellten Tiles wie vor drei Jahren kommen steht dann wohl eher in den Sternen. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Veröffentlichung OpenTopoMap Garmin-Edition
Am 19.08.2014 09:58, schrieb Sven Geggus: fly lowfligh...@googlemail.com wrote: Kannst Du die zur Verfügung stellen ? Ich mache ja keinen automatischen Build sondern nur alle paar Monate mal einen für mich selbst und eben halt wie gesagt auch nur den DACH+ Ausschnitt. Außerdem ist das nur der Baselayer, was ich da rechne. Wenn das trotzdem interessant ist könnte ich in der Tat mal einen cronjob aufsetzen, der so einmal im Monat läuft. Auf jeden Fall, wenn möglich auf der offiziellen Seite oder bin ich der einzige hier ? Nicht zu vergessen ist, dass optimal Routen durchaus auch mehrmals Grenzen überschreiten können. Jepp. Grade bei einer Routenplanuny mit cycle.travel am Hochrhein erlebt. Ja , Grenzflüsse aber auch die gesamte Westgrenze der BRD + Anrainer sind Beispiele, und nicht nur für Fahrrad sondern auch für motorisierte Fahrzeuge Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Veröffentlichung OpenTopoMap Garmin-Edition
Am 17.08.2014 15:31, schrieb Sven Geggus: Stefan Erhardt stefan_erha...@gmx.de wrote: http://garmin.opentopomap.org Gibt es ein Mini HOWTO, wie man das selber rechnet? Hintergrund: Ich rechne bisher für mich selbst immer noch eine Version der AIO mit einen Ausschnitt, den ich DACH+ nenne. Es handelt sich dabei um folgende bbox: 5.8,45.7 16.7,55.2 Das umfaßt den kompletten deutschsprachingen Raum sowie mehr oder weniger große Teile der Nachbarländer hört aber nicht künstlich an der Grenze auf. Grade hier am Oberrhein empfinde ich Karten bei denen linksrheinisch Drachen wohnen ziemlich ungeschickt. Kannst Du die zur Verfügung stellen ? Wäre interessiert, da die letzten offiziellen AIOs vom 14.1.2014 sind. Genau, das Abschneiden an den Grenzen ist fürchterlich. Jetzt muss ich erstmal drei Länder runterladen und warum denn so viel Nationalismus im vereinten Europa ? Nicht zu vergessen ist, dass optimal Routen durchaus auch mehrmals Grenzen überschreiten können. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Berlin Stadtbaumkampagne
Am 15.08.2014 00:51, schrieb Hefee: Eine Kleinigkeit nutzte für die Baumart nicht name sondern genus bzw. species. Also zum Beispiel so: genus=acer species=acer rubrum genus:de=Ahorn species:de=Rot Ahorn Bitte die Sprachzusätze nur verwenden, wenn der lateinische Begriff für Familie und Art nicht bekannt ist und mit species=* wird genus=* überflüssig. name wird verwendet, wenn der Baum einen bestimmten Namen hat wie zum Beispiel Fresseiche Dorflinde. +1 Das ganze findest du auch nochmal ausführlicher im Wiki: http://wiki.openstreetmap.org/wiki/DE:Tag:natural=tree cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gibt es einen Tag für Kasseler Sonderbords?
Am 22.07.2014 07:18, schrieb malenki: On Tue, 22 Jul 2014 02:34:38 +0200, Andreas Neumann wrote: Evtl. kennt jemand im selben Zug ein Tagging, dass die Bushaltestelle über Blindenleitlinien verfügt. http://wiki.openstreetmap.org/wiki/DE:Key:tactile_paving Und wo ich grad beim recherchieren war: Gibt es bereits ein Tagging, wo sich die Bushalteposition befindet (auf der Straße, dem Parkstreifen, halbe Bucht, schräge Bucht, ganze Bucht)? Evtl dies?: http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position Passt wohl nicht ganz. Habe schon bus_stop:type=bay bzw steet gesehen. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sichelförmige Treppe
Meintest Du vielleicht [1]. Wird vom wiki [2] direkt drauf verwiesen. Allerdings gibt es auch dort zuerst einen Link zum Area-Model. Halte das Area-Model als bestes Konzept und habe auch schon ein paar Treppen entsprechen gemappt, allerdings vermisse ich eine genauere Beschreibung, welche ich meine schon mal im wiki gesehen zu haben. Vielleich ein Fall ähnlich der Zusatztags für railways. Da war die Doku auch auf einer user-Seite und wurde einfach gelöscht. - Schade. cu fly [1] https://wiki.openstreetmap.org/wiki/User:Marek_kleciak/Stairs_modelling [2] https://wiki.openstreetmap.org/wiki/Steps Am 21.07.2014 17:20, schrieb christian.pietz...@googlemail.com: ich kenn noch die Variante am unteren ende eine Linie zu ziehen mit startline=yes und oben dann endline=yes und dann einen highway steps zwische unterer und oberer Linie. Hate mal irgendwo jemand vorgschlagen..die Seite dazu find ich ich mehr und es gibt bisher auch nur 5 Fälle wo es angewendet wurde. Mfg Christian Am 21. Juli 2014 15:33 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Jeweils einen way an der ersten und letzten Steigung (Stellstufe) eines Absatzes. Diese in die Relation einfügen mit den Rollen lower und upper, ggf. kann man auch den seitlichen Abschluss explizit zeichnen und mit der Rolle lateral einfügen, ist aber nur bei nicht-geraden (d.h. mit Absätzen/Sprüngen oder gekurvt) Seiten sinnvoll. tag an der Relation (minimum): type=area highway=steps empfohlen: step_count=* surface etc. s.hier: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area#Area-steps.2C_steps_which_are_wide_and.2For_irregular Damit das einfach zum Auswerten wird, sollte man die Richtung des oberen und unteren Wegs jeweils gleich haben, und möglichst auch dieselbe Anzahl nodes verwenden. Gruß, Martin ___ 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sichelförmige Treppe
Am 21.07.2014 18:44, schrieb Martin Koppenhoefer: Am 21. Juli 2014 15:33 schrieb Martin Koppenhoefer dieterdre...@gmail.com: tag an der Relation (minimum): type=area highway=steps empfohlen: step_count=* surface etc. s.hier: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area#Area-steps.2C_steps_which_are_wide_and.2For_irregular Damit das einfach zum Auswerten wird, sollte man die Richtung des oberen und unteren Wegs jeweils gleich haben, und möglichst auch dieselbe Anzahl nodes verwenden. evtl. kann man noch überlegen, ob man zusätzlich eine lineare (übliche) Treppe zeichnet und mit highway=steps incline=up etc. taggt für die Router. Falls man das tut sollte man diese Treppe evtl. mit einer entspr. Rolle auch in die area-Relation mit übernehmen, so dass man diese beim Rendern dann ausnehmen kann. (bin mir da nicht so ganz sicher, theoretisch könnte ein Router sich diese Linie auch selbst generieren, was sie aber wohl erst dann tun, wenn das Konzept sich verbreitet hat). Diese Linie könnte man entweder an den Rändern führen (so dass man sie mehrfach verwenden kann, also auch in der area-Relation als lateral-member) oder in der Mitte. Echt schade, dass ich die genauere Beschreibung nicht mehr finde. In der Mitte werden durchaus Linien benötigt, wenn die Treppe zB einen Knick macht oder auch sich die Stufenanzahl ändert und so schlimm sehen Treppen nebeneinander auch nicht aus, wenn der Rendere bzw Router nicht mit der Relation klarkommt. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gibt es einen Tag für Kasseler Sonderbords?
Am 22.07.2014 02:06, schrieb Andreas Neumann: Moin, wie taggt man am besten Kasseler Sonderbords (die hohen weißen, etwas angeschrägten Bordsteine an Bushaltestellen)? Laut alter Diskussion[0] ist ein wheelchair=yes unangebracht. Ich bin mir ziemlich sicher schon einmal ein entsprechendes Tagging an einer Haltestelle gesehen zu haben, finde aber nichts im Wiki dazu. Kann jemand helfen? Kling nach kerb=raised [1]. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Am 20.07.2014 18:27, schrieb Tirkon: Henning Scholland o...@aighes.de wrote: Ich stimme dir aber auch zu, dass es Kontraproduktiv sein kann, wenn man den Renderer vor vollendete Tatsachen stellt und ihm die Nodes weg löscht. Im Prinzip müsste es eine deadline geben ala: Renderer, wir haben uns entschieden, in Deutschland die überflüssigen place-nodes zu entfernen, bitte nutze doch die labels aus den Grenzrelationen. Am besten noch mit einem Zeitrahmen. Für die Sache eines orientierungsfördernden Renderns wäre das natürlich der beste Weg. Die Suche nach Bezeichnungen wie bei den Places für verschiedene Levels wäre obsolet. Im Admin Level findet alles seine Berücksichtung, z.B. kreisfreie Städte. Man könnte Kommunen, die Staats-, Landeshaupt-, Kreisstädte darstellen bzw. Stadtteile mit Rathausstandort (capital=yes), bei Konkurrenz im gleichen Admin Level immer verdrängend rendern und mit einem Sternchen versehen. Ansonsten geht es innerhalb des Admin Level nach Bevölkerungszahl. Es könnten auch beim Hereinzoomen die jetzt gähnend leeren ländlichen Gebiete mit Ortsnamen gefüllt werden. Wenn nach dem Abarbeiten eines Admin Levels noch Platz ist, nimmmt man eben den nächsten. Möglicherweise veröffentlicht man das Ergebnis auch als Dump. Ob das harte Vorgehen OSM-DB vs OSM-Renderer aus Community-Sicht so sinnvoll ist, ist da schon fraglicher. Wir wollen ja auch dort nicht demotivieren - zumal Andy Allen hier auf der SOTM-EU um Hilfe gebeten hat, nachdem ich das bevorzugte Rendern großer Kommunen thematisiert hatte. Möglicherweise wäre eine dringende Bitte ohne Termin im Vorfeld da günstiger. So wie Du es formulierst, soll sich dieses Anliegen von den üblichen Feature Requests abheben. Die Frage bleibt, wer mit der offiziellen Mitteilung/Bitte an die Renderer Commmunity von OSM Carto herantritt - die Data Working Group? Zumal ja auch darüber diskutiert wird, welchen Zweck diese offizielle Kartendarstellung hat. Vorsicht mit capital=yes: 1. Weder Standort der Legislative noch der der Exekutive muss Capital sein. 2. entweder hier oder auf tagging@ oder talk@ würde der capital=* tag vor kurzem diskutiert. Ergebnis waren die zusätzliche Rolle capital für den entsprechenden place Punkt, wenn dieser place nicht auch einziger admin_centre ist. Persönlich habe ich mit dem aktuellen Rendern schon meine Schwierigkeiten beider zu schwachen Unterscheidung im kleinsten Abschnitt (hamlet,isolated_dwelling,locality) und das der Renderer nur Punkte mit place=* ordentlich darstellt nicht aber Polygone. Ich finde auch immer wieder Täler als Ortsnamen oft unterhalb von village aber eben nicht zusammenhängende Ortschaft (hamlet). Wie tagge ich das korrekt ? place=valley ? cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Am 21.07.2014 00:58, schrieb Martin Koppenhoefer: Am 20/lug/2014 um 22:40 schrieb fly lowfligh...@googlemail.com: place=valley ? klingt vernünftig, wo taggst Du das dran? Bisher nur an Punkte, da ich sowas nicht so einfach als Flächen einzeichnen läßt und wohl eher subjektiv ist. Allerdings bin ich damit nicht zu frieden, da es ja eher auch Dorfteile bzw Quartiere sind, allerdings eben nicht zusammenhängend. Heute haben die einzelnen Höfe halt Hausnummern und eine zugeordnete Straße, früher waren die Täler auch Teil der Adresse. Nur auf die Topologie bezogen ist wohl eher natural=valley angesagt. Wobei bei island ja auch beides existiert. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier= e.g. bollard / ohne access
Am 13.07.2014 19:36, schrieb Volker Schmidt: Vorsicht mit barrier=cycle_barrier Dummerweise werden diese Hindernisse in verschiedenen Laendern verschieden gehandhabt (1) und muessen deshalb immer mit den expliziten tags versehen werden (wie's im Wiki empfohlen wird: https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcycle_barrier). (1) In IT werden diese Schikanen auf den Radweg gesetzt um zu verhindern, dass Motorraeder den Radweg benutzen. In DE werden identische Anordungen auf reine Fusswege gesetzt, um zu verhindern, dass Radfahrer durchfahren. Mir ist das uebel aufgestossen, als ich anfing diese Hindernisse hier in Italien ohne Zusatztags in die Karte einzutragen, und ploetzlich haben einige Router (erinner mich nicht mehr welche) Fahrraeder dort nicht mehr durchgelassen, nur noch Fussgaenger. Seitdem tagge ich immer explizit. In Deutschland gibt es beide Sorten, wobei meist Fahrräder verboten sind, allerdings kenne ich einige, wo es erlaubt und möglich ist durchzufahren ohne abzusteigen. 2014-07-13 19:08 GMT+02:00 715371 osmu715...@gmx.de: Moin Florian, Am 13.07.2014 18:54, schrieb Florian Lohoff: Irgendwie f�nd ich es ja schön wenn die regel w�re das ein barrier immer die Verkehrsarten listed die erlaubt sind/bzw physikalisch durch gehen. Ich würde davon ausgehen, dass folgendes immer gilt, wenn nicht näher spezifiziert: foot=yes bicycle=yes Im Wiki sagen die das auch so und anders. https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dbollard Auf jeden Fall müsste/könnte man dann motorcar=permissive taggen, wenn der Poller herausnehmbar ist, denke ich. Na ja, dass ich gerade einen Vierkant-Schlüssel dabei habe erlaubt es mir doch nicht auch dort entlang zu fahren. Grundsätzlich ist es in erster Linie eine Barriere, welche es einigen Fahrzeugen rein physikalisch verwehrt durchzufahren. Die Zugangsbeschränkungen sind durch entsprechende Zeichen separat geregelt. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] primary - trunk auf Bundesstraßen
Hey Woran macht Ihr den Unterschied zwischen highway=primary und trunk aus ? Ein konkretes Beispiel ist die B 31 zwischen Freiburg und Donaueschingen. Zur Zeit existiert ein ständiger Wechsel. Nur kleine Teilstücke haben getrennte Gegenrichtungen, jedoch gibt es auf der gesamten Strecke keine einzige Ampel. Die meisten Querstraßen sind über Ab- und Zufahrt angebunden, aber einige Kreuzungen sind noch geblieben und auch die Ortsdurchfahrt im Höllental. Teile der Strecke sind Schnellstraße (motorroad=yes) aber eben auch nicht konstant und die Spuranzahl wechselt von zwei bis vier (meistens drei mit zwei Berg aufwärts und einer Tal abwärts). Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] primary - trunk auf Bundesstraßen
Am 02.07.2014 00:12, schrieb christian.pietz...@googlemail.com: Ich würde es vllt versuchen anhand der Beschilderung und der fahrbaren Geschwindigkeit festzulegen, da ja die anderen autbahnähnlichen Merkmal mal mehr oder weniger zutreffen. https://de.wikipedia.org/wiki/Autobahn%C3%A4hnliche_Stra%C3%9Fe Super, dort lande ich auch eben wieder dazwischen. Seit 2013 wird das 2+1 System auch akzeptiert Am 1. Juli 2014 18:00 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 1. Juli 2014 17:54 schrieb fly lowfligh...@googlemail.com: Ein konkretes Beispiel ist die B 31 zwischen Freiburg und Donaueschingen. Zur Zeit existiert ein ständiger Wechsel. Nur kleine Teilstücke haben getrennte Gegenrichtungen, jedoch gibt es auf der gesamten Strecke keine einzige Ampel. Die meisten Querstraßen sind über Ab- und Zufahrt angebunden, aber einige Kreuzungen sind noch geblieben und auch die Ortsdurchfahrt im Höllental. trunk sind primaries, die autobahnähnlich ausgebaut sind, d.h. in der Regel baulich getrennt (Ausnahme Baustellen), keine Ampeln, kreuzungsfrei Wenn ich das 2+1 System jetzt dazu rechne habe ich bis auf ein paar Kreuzungen und dem unteren Höllental also ein trunk. Wie gestalte ich den Übergang ? Finde es recht merkwürdig, wenn dann 1 km dazwischen primary ist, wegen zwei Kreuzungen. So was dann eher doch trunk mit motorroad=no. Ja, das wechselt auch noch zwischen durch. Ciao fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlatch 2
Am 28.06.2014 12:43, schrieb Christoph (TheFive@OSM): Hi micha Photomapping in JOSM ist hier beschrieben: http://wiki.openstreetmap.org/wiki/DE:Photo_mapping (sollte sich JOSM mittlerweile zu stark weiterentwickelt haben, gib bescheid, dann muss ich das Wiki an dieser Stelle etwas updaten). ein paar (etwas ältere) Videos gibt es hier. http://wiki.openstreetmap.org/wiki/Video_tutorials#JOSM_video_collection Scheint beim stöbern ein generelles Problem zu sein, JOSM überholt einfach die ganzen Einführungsvideos und Anleitungen :-( Ja, es fehlt mal wieder an aktueller Dokumentation. Am 28.06.2014 um 12:31 schrieb Michael osm...@suesz.de: Am 28.06.2014 08:29, schrieb Christoph (TheFive@OSM): Ein Editor, mit dem man einen GPX Track mit Anmerkungen anzeigen kann, ist JOSM (ist der einzige der mir bekannt ist). Ich gebe zu, die Einsteigerhürde ist hoch, aber nicht unüberwindbar, und es lohnt sich. (So bietet JOSM z.B. Fotomapping, d.h. die Möglichkeit die Fotos mit Zeitstempel an einen GPX Track mit Zeitstemtempel anzupassen, und so an der aufgenommenen Stelle zu zeigen). Hallo Christoph, meine Erfahrungen mit Josm habe ich nicht gut in Erinnerung! Weshalb ? Was hast Du versucht ? Was hat Dich gestört ? Wobei, um ein paar Sachen anzupassen, sollte ich diesen Editor doch begreifen? Die Vorlagen sind vielleicht etwas versteckt. Erreichbar über das Hauptmenü bzw auch über den Link oben im Eigenschaften/Mitglieder Dialog. Gibt es ein Howto oder ähnlich für Josm um Fotomapping zu realisieren? Oder ist jemand bereit hier mal die 4 wichtigsten Schritte zu dokumentieren? Ich weiß ja nicht wie Du Deine Daten vorliegen hast. * Wenn es sich um Bilder handelt sind die ganz einfach mit JOSM zu öffnen (Dateimanager markieren + in JOSM-Fenster ziehen) * Für GPX mit Wegpunkten gilt das gleiche. Dies sollte jeweils eine eigene Ebene erzeugen mit den jeweiligen Objekten/Symbole erzeugen, welche selbst bei nicht aktiven Ebenen anklickbar sind. Der Rest ist Editieren mit JOSM. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] vending=photos - Fotoautomaten?!
Am 25.06.2014 20:50, schrieb Michael Kugelmann: Am 25.06.2014 18:25, schrieb Andreas Goss: Übersehe ich da etwas oder sind das fast alles diese Pass-Fotoautomaten, was ich in München, Stuttgart und Karlsruhe nachgesehen habe: stiimmt mit hoher Wahrscheinlichkeit. Teilweise steht auch FotoFix oder anderer eindeutiger Firmennamen dabei oder eine anderweitige eindeutige Beschreibung. Was es aber auch geben könnte (gab es zumindest in der Vergangenheit) sind Automaten zum Verkaufen von Negativ-/Diafilmen... = wenn es eindeutig ist würde ich es umtaggen. Für die anderen Objekte würde ich entweder ein Fixme dazumachen oder eine Note anbringen, jeweils mit der Aufforderung das zu prüfen. Da hast Du wohl eine wichtige Möglichkeit vergessen: Einfach mal den/die Ersteller_in anschreiben und nachfragen. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anfahrtsbeschreibung SOTM EU führt über gesperrte Straße
Am 10.06.2014 00:08, schrieb Frederik Ramm: Hi, On 06/09/2014 08:06 PM, Tirkon wrote: Könnte es sein, dass die Anfahrtsbeschreibung per Auto zur SOTM EU nicht funktioniert? *Pfeif* Danke, ist repariert. Ist aber auch der Wurm drin in Karlsruhe - für die Konferenz-Karte haben wir extra von Hand im JOSM die Bahnlinien so zurechtgefriemelt, wie sie jetzt gerade in diesen zwei Wochen ausnahmsweise fahren, mit lauter Umleitungen und Sonderlininen etc... Das sieht bei mir leider auch nicht besser aus. Dauernd Sonderlinien und Fahrplanänderungen. Und was mache ich denn jetzt, wenn es hoffentlich nur drei Wochen dauert, dadurch allerdings der zentrale Umsteigebahnhof betroffen ist ? Ist es OK hier alles umzumodeln und in drei Wochen wieder zurück ? cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rad-Wander-Skate-Routen
Am 25.05.2014 21:08, schrieb Sven Geggus: fly lowfligh...@googlemail.com wrote: Super, ich begegne immer wieder Situationen, wo das Semikolon die naheliegenste und einfachste Lösung ist und wundere mich immer warum sich dagegen so gesträubt wird. Lies mal den Blogpost von Jochen. Das Problem ist, dass es eben nicht immer so eindeutig ist was damit gemeint ist. http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html Die habe ich jetzt wiederholt gelesen und lese dort nur ein Problem mit der Definition. Josm wurde verbessert (ein Erfolg der letzten Diskussion), der Import war nicht nur in dieser Hinsicht grauenhaft und hätte nie so statt finden dürfen und die cadastre-Source geht auch mit Komma. Meine Punkte in der Hinsicht lauten dann eher: * Einigung auf ein Trennzeichen und Vermeidung dieses Zeichen bei anderen Bedeutungen (zB source) * Klare Definition bei Verwendung von Listen bzw. Verwendung eines eigenen Zeichen ala turn:lanes * Ausschluss bei Tags Diese Definitionen können alle diskutiert und dann im Wiki festgehalten werden. Einfach über das Problem hinweggehen und so tun als ob es nicht existiere verhindert Software-Unterstützung und wir werden dieses Thema in geraumen Abständen immer wieder diskutieren. Ciao fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage Abbiegebeschränkung Berlin
Am 27.05.2014 12:48, schrieb Martin Koppenhoefer: Am 27. Mai 2014 11:07 schrieb Volker Schmidt vosc...@gmail.com: Auserdem hat http://www.openstreetmap.org/way/24021332 einen falschen tag value: access=designated Der zweite Teil derselben Strasse http://www.openstreetmap.org/way/165333156hat mit access=destination wenigstens eine gueltige tag/value Kombibation. Mit access=destination auf way 24021332 wuerde die Abbiegebeschraenkung ueberfluessig. +1 kann man aber nur mutmaßen ohne vor Ort gewesen zu sein. Ich habe die Frage an die Berliner Liste weitergeleitet, da findet sich hoffentlich jemand, der die Stelle in ihrem aktuellen Zustand kennt. Eine Note an der Stelle anlegen ist auch ne Möglichkeit. fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rad-Wander-Skate-Routen
Am 22.05.2014 15:02, schrieb Sarah Hoffmann: Hi, On Thu, May 22, 2014 at 01:51:45PM +0200, C.Brause wrote: Mein Ansatz wäre jetzt, die Route als Relation mit route=bicycle;hiking;inline_skates zu bezeichnen und den mir bekannten Renderern (opencyclemap und waymarks) den Hinweis geben, dass solche Wege auch aufgenommen werden könnten/sollten. Ein Blick auf Taginfo zeigt mir, dass solche Kombinationen insgesamt ca. 110 mal vorkommen. Gefunden habe ich aber auch Radrouten, bei denen die Zusatzinfo, dass es sich auch um eine Ausgewiesene Rundstrecke für Skater und Wanderer handelt, in description=* befindet. Zum Auswerten ist das natürlich kaum geeignet. Ich vermute, dass das so gelöst wurde, damit es wenigstens irgendwo auch zu sehen ist. Im Wiki findet sich nichts zu Routen, die für mehr als ein Fortbewegungsmittel ausgeschildert sind. Was haltet ihr von dem Semicolonansatz und dem Anschreiben der Renderer? waymarkedtrails.org unterstützt den Semikolonansatz seit ein paar Wochen, weil ich gefunden habe, dass das a) die Wirklichkeit am genausten abbildet und b) für die Mapper so am einfachsten zu warten ist. Super, ich begegne immer wieder Situationen, wo das Semikolon die naheliegenste und einfachste Lösung ist und wundere mich immer warum sich dagegen so gesträubt wird. Alles mit yes/no abzubilden ala recycling ist auch keine Lösung und konkret ist das wohl eine Route und sollte als ein Objekt auch so gehandelt werden. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bounces
Am 21.05.2014 17:05, schrieb Walter Nordmann: Irgendwas ist zu Zeit komisch mit meinen Talk-de Zugang. Der wurde gestern wegen bouncing mails temporär gesperrt. Hab ihn wieder freigeschaltet, weiss aber noch nicht, ob der wieder funktioniert. Musste ich gestern auch. Eher serverseitiges Problem. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Tag-Template ??
Am 13.05.2014 07:58, schrieb Georg Feddern: Am 12.05.2014 23:01, schrieb Johannes: Keine Idee? keine, die Dir vermutlich wirklich weiterhelfen wird ... A) JOSM Sourcecode anpassen und compilieren - dann behält man die Vorbelegung mit den zuletzt eingegebenen Werten. B) Eigenes Preset schreiben - dann hat man aber keine Vorbelegung mit den zuletzt eingegebenen Werten. C) One-Click-Preset mit den verschiedenen leveln anlegen und in die Toolbar einhängen. Ja, diese Möglichkeiten gingen mir auch durch den Kopf. Zusätzlich hilft es vielleicht auch die Liste der zuletzt eingegebenen Tags im Add Value Dialog (glaube der heißt Eigenschaft hinzufügen auf Deutsch) auf 30 Einträge zu vergrößern.Allerdings weiß ich nicht wie gut die Tastaturkombinationen mit zweistelligen Zahlen funktioniert. Die ersten zehn sind auf jeden Fall belegt. [1] fly [1] https://josm.openstreetmap.de/wiki/Help/Dialog/AddValue ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XML von einem Objekt exportieren
Am 30.04.2014 23:50, schrieb Markus: - in JOSM einen Link zum ausgewählten Objekt Versuch mal Strg+i bzw Umschalt+Strg+i wenn Du ein Objekt ausgewählt hast. Super! man lernt nie aus... :-) Schön, wenn es möglich ist Wissen zu teilen. PS: Hatte früher mal aus Frust über fehlende JOSM-Doku eine Wiki-Doku geschrieben: http://wiki.openstreetmap.org/wiki/de:JOSM/Guide Dort habe ich Deine Tastaturkürzel eingetragen (bin aber nicht sicher mit der Sortierung). Naja, da hat sich doch so einiges getan, wobei es doch an Übersetzungen ins Deutsche noch fehlt. [1] Die beiden oben genannten Funktionen sind erklärt [2]+[3] und wer es ganz genau wissen will findet sogar eine automatisierte Liste der Tastaturkürzel [4]. cu fly [1] https://josm.openstreetmap.de/wiki/De:Help [2] https://josm.openstreetmap.de/wiki/Help/Action/InfoAboutElements [3] https://josm.openstreetmap.de/wiki/Help/Action/InfoAboutElementsWeb [4] https://josm.openstreetmap.de/wiki/DevelopersGuide/ShortcutsList ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XML von einem Objekt exportieren
Am 30.04.2014 12:56, schrieb Markus: Hallo Peter, Auf http://www.openstreetmap.org/way/24774635 und vgl. Seiten gibt's unten einen XML herunterladen-Link. Super - danke! (hatte zuwenig nach unten gescrollt) @Ralf: Deine Methode hat funktioniert. @Holger: sehr schön! Gruss, Markus Verbesserungsvorschläge: - XML herunterladen-Link nach oben +1 - in JOSM einen Link zum ausgewählten Objekt http://www.openstreetmap.org/way/# (z.B. in der History, oder dort wenigstens die Objekt-Nr kopierbar)) Versuch mal Strg+i bzw Umschalt+Strg+i wenn Du ein Objekt ausgewählt hast. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Tags = Schlagwörter
Am 27.04.2014 13:59, schrieb Frederik Ramm: Hallo, gerade ist mir aufgefallen, dass mein JOSM, wenn ich ihn auf Deutsch einstelle, die Tags neuerdings als Schlagwörter bezeichnet. Findet irgendjemand das gut (bzw. findet irgendjemand das besser als Eigenschaften)? Gibt es irgendwo, unabhängig vom konkreten Fall JOSM, einen Konsens oder zumindest eine Diskussion dazu? Gibt es andere Software oder Dokumentation im OSM-Umfeld, in der Tags als Schlagwörter bezeichnet werden? Dazu fallen mir mehrer Punkte ein: 1. Josm wird in Lauchpad übersetzt und mit einer Emailaddresse kann Mensch loslegen, was zu Fehlern und Ungereimtheiten führen kann. 2. Wichtige Begriffe sind, im Unterschied zu anderen Seiten/Software, bei Josm klar definiert und daran hat sich die letzten Jahre keine Person gestört. [1] 3. Wenn wir über den Toggle-Dialog sprechen, sind dort nicht nur Tags sondern auch Mitgliedschaften von Relationen aufgefüht, somit wesentlich mehr als nur Schlüssel-Wert-Paare. Zur generellen Softwareübersetzung habe ich auch ein gespaltenes Verhältnis und benutze selbst am liebsten Englisch und finde zB deutsche Manpages fürchterlich. Allerdings kenne ich doch etliche Menschen die in Englisch nicht so bewandert sind und doch lieber Deutsch/Französisch/Spanisch usw. benutzen. Gerrade im Bereich Fehlermeldungen wird es dann aber richtig spannend, da diese häufig kompliziert sind zu übersetzen und das richtige Maß an Verständlickeit und Einfachheit gefunden werden muss. Auch ist das auffinden dieser Meldungen im Internet mit der englischsprachigen Variante häufig einfacher, was allerdings auch nichts bringt, wenn der Rest auf dieser Seite dann auch nicht verstanden wird. Grundsätzlich würde ich ein offizielle Seite für wichtige Begriffe un deren Übersetzungen im Wiki begrüßen, denn dann wäre wenigstens ein Vereinheitlichung möglich und solche Schnitzer wie Schlagwörter würden noch unwahrscheinlicher. cu fly [1] https://josm.openstreetmap.de/wiki/De:Translations#SprachspezifischeÜbersetzungsnotizen ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Baum der Woche: Kastanie
Am 14.04.2014 05:41, schrieb malenki: On 13.04.2014 12:49, Ralf GESELLENSETTER wrote: Der milde März hat dazu geführt, dass bereits jetzt viele Kastanienbäume ihre fünffingrigen Blätterfächer entfalten und sogar ihre ersten Blütenkerzen entfachen... natural=tree species=Aesculus␣hippocastanum Dass die rot blühende Kastanien wohl species=Aesculus pavia (laut WP) sind, wäre imho auch noch erwähnenswert. Im Zweifel ist genus=Aesculus genus:de=Kastanie auf jeden Fall richtig. fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Mapnik-de: Schöneres Rendering von Sportplätzen
On 08.04.2014 12:14, Sven Geggus wrote: fly lowfligh...@googlemail.com wrote: Wenn Du Terracer meinst, dann ist das anwenden. Genau den meine ich. Wishlist an den Author wäre allerdings, dass man angeben kann ob man horizontal oder vertikal abteilen möchte. Doppel-Tennisplätze sind leider sehr quadratisch. Kannst gerne ein Ticket bei JOSM erstellen. Leider wird die Erweiterung nicht gepflegt und es gibt doch so den ein oder anderen Bug [1]. Und wie schon erwähnt funktioniert Split Geometry wunderbar, vielleicht noch ein q danach (rechtwinklig machen). fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Mapnik-de: Schöneres Rendering von Sportplätzen
On 08.04.2014 13:34, fly wrote: On 08.04.2014 12:14, Sven Geggus wrote: fly lowfligh...@googlemail.com wrote: Wenn Du Terracer meinst, dann ist das anwenden. Genau den meine ich. Wishlist an den Author wäre allerdings, dass man angeben kann ob man horizontal oder vertikal abteilen möchte. Doppel-Tennisplätze sind leider sehr quadratisch. Kannst gerne ein Ticket bei JOSM erstellen. Leider wird die Erweiterung nicht gepflegt und es gibt doch so den ein oder anderen Bug [1]. Und wie schon erwähnt funktioniert Split Geometry wunderbar, vielleicht noch ein q danach (rechtwinklig machen). Sorry, link vergessen. [1] https://josm.openstreetmap.de/query?status=assignedstatus=needinfostatus=newstatus=reopenedcomponent=Plugin+terracercol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=componentorder=priority ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
