Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 15.05.2013 16:53, schrieb fly: Und ich würde gerne Deine Alternativen wissen bevor Du sie als deprecated markieren willst. Wurde schon vorgeschlagen, aber halt nochmals: man könnte die (jetzt ohne waterway) 7 Tags mit :right und/oder :left Tags ergänzen. Wenn ich richtig gesehen habe wäre es sinnvoll: jeweils up, down, high,low oder inside, outside als Wertpaare zu verwenden. Natürlich ist eigentlich nur jeweils ein Zusatztag wirklich nötig. Beispiel Tagging: natural=cliff cliff:left=up (cliff:right=down) Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Thu, 16 May 2013 09:56:57 +0200 schrieb Simon Poole si...@poole.ch: cliff:left=up Sollte das nicht besser high/low sein? Mapper A: Von links gesehen ist es eine Aufwärtskante. Mapper B: Nach links geht es aufwärts. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi. Für eine generalisiertere Regel ist das trotzdem schwierig: Dein Beispiel: cliff:left=up wird beim Umdrehen des Weges ohne semantische Änderung zu cliff:right=up Beispiel von mir: highway=steps direction=up wird beim Umdrehen des Weges ohne semantische Änderung aber zu direction=down Wo inside/outside sinnvoll ist, weiß ich nicht - aber wenn wir dabei von Polygonen sprechen, dann ist deren Richtung bei uns nicht definiert (die Nodes können also sowohl im als auch gegen den Uhrzeigersinn angeordnet sein im geschlossenen way). Insofern ist inside/outside nichts, was sich in diesem Fall auf das Umkehren eines ways auswirken dürfte. Oder sehe ich hier die Tags nicht, die dir abei vorschweben? Gruß Peter Am 16.05.2013 09:56, schrieb Simon Poole: Am 15.05.2013 16:53, schrieb fly: Und ich würde gerne Deine Alternativen wissen bevor Du sie als deprecated markieren willst. Wurde schon vorgeschlagen, aber halt nochmals: man könnte die (jetzt ohne waterway) 7 Tags mit :right und/oder :left Tags ergänzen. Wenn ich richtig gesehen habe wäre es sinnvoll: jeweils up, down, high,low oder inside, outside als Wertpaare zu verwenden. Natürlich ist eigentlich nur jeweils ein Zusatztag wirklich nötig. Beispiel Tagging: natural=cliff cliff:left=up (cliff:right=down) Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 16.05.2013 10:19, schrieb Peter Wendorff: Oder sehe ich hier die Tags nicht, die dir abei vorschweben? barrier=city_wall http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcity_wall Aber vielleicht versteh ich da die Semantik nicht richtig. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Woher dichtest du dir da das inside/outside? Auf der von dir verlinkten englischsprachigen Seite jedenfalls steht davon nichts, da steht nur two_sided=yes. Und da dazu sonst nichts dokumentiert ist, sehe ich keinen Grund, warum nicht auch hier left/right genutzt werden sollte; zumal die wenigsten Stadtmauern heute noch so durchgängig sein dürften, dass sie als Polygone mit entrance-nodes gemappt werden könnten. Gruß Peter Am 16.05.2013 10:36, schrieb Simon Poole: Am 16.05.2013 10:19, schrieb Peter Wendorff: Oder sehe ich hier die Tags nicht, die dir abei vorschweben? barrier=city_wall http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcity_wall Aber vielleicht versteh ich da die Semantik nicht richtig. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Es gibt um den Tagwert, nicht ob links oder rechts im Tagnamen gebraucht wird (also barrier=city_wall, city_wall:left=inside). Die unterschiedliche Höhe im inneren vs ausserhalb der Mauer, scheint mir nur etwas schwierig zum bestimmen und im allgemeinen gibt es aber bei einer Stadtmauer ein klares innen und aussen, wäre also einfacher zum Taggen. Die Diskussion driftet aber jetzt doch -sehr- ab, die genaue Semantik der Tags im einzelnen ist ja auch nicht das Thema. Simon Am 16.05.2013 10:53, schrieb Peter Wendorff: Woher dichtest du dir da das inside/outside? Auf der von dir verlinkten englischsprachigen Seite jedenfalls steht davon nichts, da steht nur two_sided=yes. Und da dazu sonst nichts dokumentiert ist, sehe ich keinen Grund, warum nicht auch hier left/right genutzt werden sollte; zumal die wenigsten Stadtmauern heute noch so durchgängig sein dürften, dass sie als Polygone mit entrance-nodes gemappt werden könnten. Gruß Peter Am 16.05.2013 10:36, schrieb Simon Poole: Am 16.05.2013 10:19, schrieb Peter Wendorff: Oder sehe ich hier die Tags nicht, die dir abei vorschweben? barrier=city_wall http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcity_wall Aber vielleicht versteh ich da die Semantik nicht richtig. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Thu, 16 May 2013 09:56:57 +0200 schrieb Simon Poole si...@poole.ch: Wurde schon vorgeschlagen, aber halt nochmals: man könnte die (jetzt ohne waterway) 7 Tags mit :right und/oder :left Tags ergänzen. Wenn ich richtig gesehen habe wäre es sinnvoll: jeweils up, down, high,low oder inside, outside als Wertpaare zu verwenden. Natürlich ist eigentlich nur jeweils ein Zusatztag wirklich nötig. Mit Zusatztags, die die Bedeutung von Tags verändern, machen aber alte Programme Ärger, da sie die Richtungstags ignorieren werden. Das bringt die Mapper dazu, lustige Taggingideen auszuprobieren. Außerdem sollten die Zusatztags ja immer vorhanden sein, damit die Sache für die Mapper klarer wird. Aus Kompatibilitätsgründen müsste man aber den jetzigen Zustand zum Default erklären. Dann werden ihn aber viele weglassen. Das Problem könnte man aber mit einem Stichtag und einem Bot lösen. Auch wenn es hässlich ist: ein natural=cliff2 mit cliff2:left=high würde Probleme vermeiden. Na ja, vielleicht wäre natural=edge oder natural=slope oder noch was anderes besser. (Bei coastline hätte man die Gelegenheit, endlich das Wort ocean im Tag unterzubringen -- das würde viele Reparaturarbeiten in Seen und Flüssen einsparen.) Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Einverstanden, aber das inside/outside müsste ja in diesem Fall nicht angepasst werden: city_wall:left=inside wird beim umdrehen zu city_wall:right=inside und alles bleibt korrekt. Gruß Peter Am 16.05.2013 11:07, schrieb Simon Poole: Es gibt um den Tagwert, nicht ob links oder rechts im Tagnamen gebraucht wird (also barrier=city_wall, city_wall:left=inside). Die unterschiedliche Höhe im inneren vs ausserhalb der Mauer, scheint mir nur etwas schwierig zum bestimmen und im allgemeinen gibt es aber bei einer Stadtmauer ein klares innen und aussen, wäre also einfacher zum Taggen. Die Diskussion driftet aber jetzt doch -sehr- ab, die genaue Semantik der Tags im einzelnen ist ja auch nicht das Thema. Simon Am 16.05.2013 10:53, schrieb Peter Wendorff: Woher dichtest du dir da das inside/outside? Auf der von dir verlinkten englischsprachigen Seite jedenfalls steht davon nichts, da steht nur two_sided=yes. Und da dazu sonst nichts dokumentiert ist, sehe ich keinen Grund, warum nicht auch hier left/right genutzt werden sollte; zumal die wenigsten Stadtmauern heute noch so durchgängig sein dürften, dass sie als Polygone mit entrance-nodes gemappt werden könnten. Gruß Peter Am 16.05.2013 10:36, schrieb Simon Poole: Am 16.05.2013 10:19, schrieb Peter Wendorff: Oder sehe ich hier die Tags nicht, die dir abei vorschweben? barrier=city_wall http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcity_wall Aber vielleicht versteh ich da die Semantik nicht richtig. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 16.05.2013 09:56, schrieb Simon Poole: Beispiel Tagging: natural=cliff cliff:left=up (cliff:right=down) Meiner Meinung nach sollte bei so etwas left/right in den Wert. Also cliff:lower_side = left/right city_wall:inside = left/right oder auch flow = forward/backward/(alternating) Die Seiten- bzw. Richtungsangaben in den Schlüssel zu nehmen macht genau dann Sinn, wenn man beides gleichzeitig verwenden können soll (etwa bei zwei Gehsteigen links und rechts, die unterschiedliche surface-Werte bekommen). Das ist hier aber nicht gewollt - bestenfalls ist es redundant wie dein Tag in Klammern, eventuell sogar widersprüchlich. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 16. Mai 2013 10:36 schrieb Simon Poole si...@poole.ch: Am 16.05.2013 10:19, schrieb Peter Wendorff: Oder sehe ich hier die Tags nicht, die dir abei vorschweben? barrier=city_wall http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcity_wall Aber vielleicht versteh ich da die Semantik nicht richtig. in dem ursprünglichen Proposal zu barrier (wo city_wall enthalten war), waren Stadtmauern bereits als zweiseitig definiert, was ja auch Sinn macht. Das Innen wird wohl praktisch immer oder jedenfalls sehr oft anders ausfallen als die nach aussen gewandte Seite (innen hat man normalerweise Gänge und Räume, wo die Verteidiger sich bewegen, aussen hat man oft geneigte Mauern an der Basis, Schießscharten, etc.). Allerdings ist das ein relativ grobes Modell, wo die gesamte Stadtmauer als ein linearer Weg beschrieben ist, während bei genauerem Mapping ja auch die Wege in und hinter der Mauer, sowie die Türme etc. gemappt werden, woraus sich eigentlich ergibt, dass man die Stadtmauer eher als Fläche mappen sollte, wenn man Lust hat. Dieses two-sided=yes macht dagegen m.E. weniger Sinn , den könnte ich nur da erkennen, wo auf beiden Seiten innen ist (also bei einer Mauer, die quer durch die Stadt läuft, und daraus sozusagen 2 Städte oder Hälften macht). Nur an der Höhe eine Gleichheit der Innen- und Aussenseite zu postulieren ist ein bisschen kurz gesprungen (s.o.). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 16.05.2013 11:37, schrieb Tobias Knerr: Am 16.05.2013 09:56, schrieb Simon Poole: Beispiel Tagging: natural=cliff cliff:left=up (cliff:right=down) Meiner Meinung nach sollte bei so etwas left/right in den Wert. Also cliff:lower_side = left/right city_wall:inside = left/right oder auch flow = forward/backward/(alternating) Die Seiten- bzw. Richtungsangaben in den Schlüssel zu nehmen macht genau dann Sinn, wenn man beides gleichzeitig verwenden können soll (etwa bei zwei Gehsteigen links und rechts, die unterschiedliche surface-Werte bekommen). Das ist hier aber nicht gewollt - bestenfalls ist es redundant wie dein Tag in Klammern, eventuell sogar widersprüchlich. Der Vorteil von *:left und *:right im Tagnamen ist, dass es von den jetzigen Editoren schon unterstützt würde (Renderer müssten natürlich nachziehen). Jeder Tag mit solcher Semantik im Tagwert braucht einfach wieder ein Sonderbehandlung. Deine Beispiele lassen widersprüchliche Werte dann auch noch zu (cliff:lower_side=left, cliff:upper_side=left). Ich würde deshalb wenn schon dann eher etwas in der Art wie cliff=lower:left verwenden (auch dies würde aber von den Editoren Unterstützung verlangen). Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 16. Mai 2013 10:53 schrieb Peter Wendorff wendo...@uni-paderborn.de: Woher dichtest du dir da das inside/outside? Auf der von dir verlinkten englischsprachigen Seite jedenfalls steht davon nichts, da steht nur two_sided=yes. Und da dazu sonst nichts dokumentiert ist, sehe ich keinen Grund, warum nicht auch hier left/right genutzt werden sollte; zumal die wenigsten Stadtmauern heute noch so durchgängig sein dürften, dass sie als Polygone mit entrance-nodes gemappt werden könnten. es geht dabei z.B. darum, dass man auch bei einem Fragment erkennen kann, wo mal innen und aussen war. Ein Damm wie eine Stadtmauer hat üblicherweise 2 unterschiedliche Seiten, innen und aussen, von daher passt inside/outside prinzipiell gut finde ich. Das ist unabhängig davon, ob die Stadtmauer nun aktuell vor dem Eindringen von Feinden schützen soll, oder nur noch Relikt ist und keine Tore mehr geschlossen werden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hallo, für Objekte ohne Zusatztag werden die Auswerter und Editoren sich schon an dem bisherigen Default orientieren. Wenn dann in Zukunft ein solcher Weg ungedreht wird, wird der Editor also bspw. dann das entsprechende Zusatztag setzen. Henning Am 16.05.2013 11:09, schrieb Wilhelm Spickermann: Hi, Am Thu, 16 May 2013 09:56:57 +0200 Mit Zusatztags, die die Bedeutung von Tags verändern, machen aber alte Programme Ärger, da sie die Richtungstags ignorieren werden. Das bringt die Mapper dazu, lustige Taggingideen auszuprobieren. Außerdem sollten die Zusatztags ja immer vorhanden sein, damit die Sache für die Mapper klarer wird. Aus Kompatibilitätsgründen müsste man aber den jetzigen Zustand zum Default erklären. Dann werden ihn aber viele weglassen. Das Problem könnte man aber mit einem Stichtag und einem Bot lösen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 16.05.2013 12:01, schrieb Simon Poole: Der Vorteil von *:left und *:right im Tagnamen ist, dass es von den jetzigen Editoren schon unterstützt würde (Renderer müssten natürlich nachziehen). Jeder Tag mit solcher Semantik im Tagwert braucht einfach wieder ein Sonderbehandlung. Also zumindest bei JOSM wird beim Umdrehen aus irgendwas=forward ein irgendwas=backward, und aus irgendwas=left ein irgendwas=right. Das ist auch nötig, denn es gibt bereits solche Fälle, zB für Gehsteige sidewalk = left/right/both oder für Rolltreppen: conveying = forward/backward/reversible Deine Beispiele lassen widersprüchliche Werte dann auch noch zu (cliff:lower_side=left, cliff:upper_side=left). Nein, da es keinen Schlüssel cliff:upper_side geben soll. Ich würde deshalb wenn schon dann eher etwas in der Art wie cliff=lower:left verwenden (auch dies würde aber von den Editoren Unterstützung verlangen). Das wäre aber wieder was neues, wohingegen left/right/forward/backward als Werte bereits in Gebrauch sind, siehe oben. Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Thu, 16 May 2013 12:43:30 +0200 schrieb Henning Scholland o...@aighes.de: für Objekte ohne Zusatztag werden die Auswerter und Editoren sich schon an dem bisherigen Default orientieren. Wenn dann in Zukunft ein solcher Weg ungedreht wird, wird der Editor also bspw. dann das entsprechende Zusatztag setzen. Ich dachte mehr an die Probleme danach. Noch nicht umgestellte mkgmap Eingabedateien würden falsche Karten produzieren. Ein noch nicht umgestellter OSMI würde falsche Fehlermeldungen erzeugen. Noch nicht umgestellte Renderer würden Mapper zu unsinnigen Änderungen anregen. Die Probleme sind in diesem Fall nicht sooo gravierend. Aber sie sind ein Beispiel für die Probleme beim Umdefinieren von Tags. Jedes Umdefinieren von Tags entwertet die Tags oder bisher geleistete Arbeit in Programmen, Konfigurationsdateien oder beim Mappen. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 16. Mai 2013 13:26 schrieb Wilhelm Spickermann o...@spickermann-d.de: Ein noch nicht umgestellter OSMI würde falsche Fehlermeldungen erzeugen. Noch nicht umgestellte Renderer würden Mapper zu unsinnigen Änderungen anregen. Das ist der Preis der Flexibilität, wir könnten ja nichts mehr hinzufügen oder anpassen, wenn wir diesem Argument folgen würden. Ich sage nicht, dass das völlig von der Hand zu weisen ist, aber es ist eine Abwägung, der status quo hat halt auch Probleme, die man vorher nicht vorhergesehen hatte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hallo, so sehe ich das auch. Ich denke auch, dass die großen bekannten Tools da recht schnell drauf reagieren würden. Ich denke, dass alleine der Vorteil, dass vielen Mappern die Arbeit mit den Daten erleichtert den Nachteil relativiert. Erleichtert meint, dass man sich nicht mehr gedanken machen muss, ob der Weg eine Richtung hat oder nicht. Vorallem auch vor dem Hintergrund, dass immer mehr Mapper mitmachen wollen, die sich nicht unbedingt in den Tiefen des Wikis schauen wollen, ob nun Coastline gerichtet ist (und was die Richtung bedeutet). Henning Am 16.05.2013 13:37, schrieb Martin Koppenhoefer: Das ist der Preis der Flexibilität, wir könnten ja nichts mehr hinzufügen oder anpassen, wenn wir diesem Argument folgen würden. Ich sage nicht, dass das völlig von der Hand zu weisen ist, aber es ist eine Abwägung, der status quo hat halt auch Probleme, die man vorher nicht vorhergesehen hatte. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Thu, 16 May 2013 13:37:12 +0200 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Das ist der Preis der Flexibilität, wir könnten ja nichts mehr hinzufügen oder anpassen, wenn wir diesem Argument folgen würden. Ich sage nicht, dass das völlig von der Hand zu weisen ist, aber es ist eine Abwägung, der status quo hat halt auch Probleme, die man vorher nicht vorhergesehen hatte. Doch, sowas kann man machen. Dazu braucht man die Möglichkeit anzugeben, auf welche Definition sich das Tagging bezieht (Normen). Etwa so: Nach Abstimmung eines Proposals wird dieses eingefroren (unveränderlich gemacht) und ihm wird zentral eine Nummer gegeben. Der Mapper kann (nicht: muss!) mit z.B. OSM_NORM=4711 darauf Bezug nehmen. Wird später ein Nachfolger verabschiedet, so erhält er eine neue Nummer. Man kann nun den alten Datensätzen ihre Bedeutung noch vollständig ansehen und sie auf die neue Form umstellen (oder sie so lassen). Man könnte auch alte Normen als deprecated deklarieren und damit zur Umstellung durch Bots oder Mapper auffordern. Verarbeitende Programme wüssten dann, was sie verarbeiten können und was nicht. Für die Editoren/Inspektoren könnte das die Prüfung auf Fehler enorm verbessern, da sie einen ganze Sätze von Prüfungen anhand der Nummern in OSM_NORM=x;y;z aktivieren könnten und nicht auf die kleinsten gemeinsamen Eigenschaften beschränkt wären. Ich denke, dass solche Normen große Vorteile mit sich bringen würden. Allerdings auch die Möglichkeit, dass Verbesserungen immer nur als zusätzliche Möglichkeiten aufgefasst würden. Da müssten wir überlegen, mit welchen sozialverträglichen Vorgehensweisen man Ausufern verhindern kann. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Zitat Wilhelm Spickermann: Am Thu, 16 May 2013 13:37:12 +0200 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Das ist der Preis der Flexibilität, wir könnten ja nichts mehr hinzufügen oder anpassen, wenn wir diesem Argument folgen würden. Ich sage nicht, dass das völlig von der Hand zu weisen ist, aber es ist eine Abwägung, der status quo hat halt auch Probleme, die man vorher nicht vorhergesehen hatte. Doch, sowas kann man machen. Dazu braucht man die Möglichkeit anzugeben, auf welche Definition sich das Tagging bezieht (Normen). Etwa so: Nach Abstimmung eines Proposals wird dieses eingefroren (unveränderlich gemacht) und ihm wird zentral eine Nummer gegeben. [...] Abstimmungen über Proposals haben keine bindende Wirkung und werden diese auch nicht erlangen. -- Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am Thu, 16 May 2013 14:53:16 +0200 schrieb Michael Buege mich...@buegehome.de: Etwa so: Nach Abstimmung eines Proposals wird dieses eingefroren (unveränderlich gemacht) und ihm wird zentral eine Nummer gegeben. [...] Abstimmungen über Proposals haben keine bindende Wirkung und werden diese auch nicht erlangen. Daran würde sich durch den Vorschlag auch nichts ändern. Es würde nur eine Nummer vergeben, die sich dann verbindlich auf diesen Vorschlag bezieht ... nicht mehr. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Bei anderen Programmen habe ich eine gute Lösungsmöglichkeit gesehen: Da wird die Warnung zunächst jedesmal gezeigt, bis man sie abwählt. Dennoch erscheint die Meldung noch dreimal in größer werdenden Abständen, wobei man sie wieder aktivieren kann. malenki o...@malenki.ch wrote: Es wird vermutlich eher selten vorkommen, dass ein verantwortungsbewusster Anfänger Straßen(teile) löscht Ich hatte schon am 09.05.2013 23:12 Uhr ausführlich beschrieben, wie so etwas in gutem Glauben auch absichtlich passieren kann. (die Mitglieder von Relationen enthalten können) Dazu muss der Anfänger aber erst einmal von deren Existenz wissen. Und die ist in der Mapnik Standarddarstellung nicht zu sehen. Wenn dann auch der Editor nicht darauf hinweist ... Dazu kommt, dass auch in den Anleitungsvideos auf youtube von Steve Coast munter editiert wurde, ohne dass Relationen erwähnt wurden. Hätte er diese Edits mit Potlatch auf Wegen mit Relationen vorgenommen, dann wären diese anschließend zerstört gewesen. oder absichtlich die Richtung einer Einbahnstraße oder eines Wasserweges umkehrt. Aber unabsichtlich: Ich erinnere mich ganz dunkel: Zu Anfang habe ich weder Relationen noch Wege-Richtungen wahrgenommen und mich auf das massenweise Eintragen von Straßennamen beschränkt. Dazwischen begann ich, einige Icons zu probieren, wobei auch das erst später als Richtungsumkehr identifizierte Icon dabei war. Ich konnte aber keine Reaktion im Bild feststellen. Mag durchaus sein, dass bei der Probiererei eine Richtungsumkehr übrigblieb. Heute scheinen die Editoren Alles davon Abhängige selbstständig umzudrehen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
On 13.05.2013 16:10, Simon Poole wrote: Am 13.05.2013 14:43, schrieb Ronnie Soak: oneway gehört nicht zu den genannten (4 nach meine Zählung) Tags da sich mit oneway=-1 die Richtung umkehren lässt, was die meisten Editoren und Anwendungen auch unterstützen. Die 4 Tags sind übrigens (kann natürlich noch mehr geben) natural=cliff natural=coastline barrier=retaining_wall man_made=embankment Leider unvollständig und damit keiner sagt, dass er/sie es nicht gewußt hat. Hier die Doku. https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/corrector/ReverseWayNoTagCorrector.java?rev=5732#L27 https://josm.openstreetmap.de/ticket/4664 https://trac.openstreetmap.org/ticket/4787 Wobei man_made=embankment und barrier=city_wall mir auch neu sind. Ich zitiere aus einem bisschen JavaDoc das ich gerade geschrieben habe: /** * There is a set of tags which lead to a way not being reversable, this is EXTREMLY stupid and should be depreciated immediately. * @return true if somebody added the brain dead tags */ Deine non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. Und ich würde gerne Deine Alternativen wissen bevor Du sie als deprecated markieren willst. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Danke für input an alle. @jfirebaugh, mein Kollege und iD Programmierer hat soeben eine neue iD Roadmap für 1.1 gepostet [1]. Sie beinhaltet auch umfangreicheren relations support. Viele der Bedenken die hier aufkamen sollten also mit 1.1 befriedigt sein. Genaue release Daten werden sich in den nächsten Wochen ergeben. Alles beste, Alex https://github.com/systemed/iD/wiki/1.1-Roadmap 2013/5/15 fly lowfligh...@googlemail.com On 13.05.2013 16:10, Simon Poole wrote: Am 13.05.2013 14:43, schrieb Ronnie Soak: oneway gehört nicht zu den genannten (4 nach meine Zählung) Tags da sich mit oneway=-1 die Richtung umkehren lässt, was die meisten Editoren und Anwendungen auch unterstützen. Die 4 Tags sind übrigens (kann natürlich noch mehr geben) natural=cliff natural=coastline barrier=retaining_wall man_made=embankment Leider unvollständig und damit keiner sagt, dass er/sie es nicht gewußt hat. Hier die Doku. https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/corrector/ReverseWayNoTagCorrector.java?rev=5732#L27 https://josm.openstreetmap.de/ticket/4664 https://trac.openstreetmap.org/ticket/4787 Wobei man_made=embankment und barrier=city_wall mir auch neu sind. Ich zitiere aus einem bisschen JavaDoc das ich gerade geschrieben habe: /** * There is a set of tags which lead to a way not being reversable, this is EXTREMLY stupid and should be depreciated immediately. * @return true if somebody added the brain dead tags */ Deine non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. Und ich würde gerne Deine Alternativen wissen bevor Du sie als deprecated markieren willst. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Wie soeben auch auf [talk] gepostet: Ich bitte alle, die auf konkrete Bugs in iD stossen, diese auf der issue queue [1] mit einem neuen issue zu beschreiben. Das hilft den iD Programmierern den editor besser und robuster zu machen. Danke für die Mithilfe und alles Beste - Alex https://github.com/systemed/iD/issues 2013/5/15 Alex Barth a...@mapbox.com Danke für input an alle. @jfirebaugh, mein Kollege und iD Programmierer hat soeben eine neue iD Roadmap für 1.1 gepostet [1]. Sie beinhaltet auch umfangreicheren relations support. Viele der Bedenken die hier aufkamen sollten also mit 1.1 befriedigt sein. Genaue release Daten werden sich in den nächsten Wochen ergeben. Alles beste, Alex https://github.com/systemed/iD/wiki/1.1-Roadmap 2013/5/15 fly lowfligh...@googlemail.com On 13.05.2013 16:10, Simon Poole wrote: Am 13.05.2013 14:43, schrieb Ronnie Soak: oneway gehört nicht zu den genannten (4 nach meine Zählung) Tags da sich mit oneway=-1 die Richtung umkehren lässt, was die meisten Editoren und Anwendungen auch unterstützen. Die 4 Tags sind übrigens (kann natürlich noch mehr geben) natural=cliff natural=coastline barrier=retaining_wall man_made=embankment Leider unvollständig und damit keiner sagt, dass er/sie es nicht gewußt hat. Hier die Doku. https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/corrector/ReverseWayNoTagCorrector.java?rev=5732#L27 https://josm.openstreetmap.de/ticket/4664 https://trac.openstreetmap.org/ticket/4787 Wobei man_made=embankment und barrier=city_wall mir auch neu sind. Ich zitiere aus einem bisschen JavaDoc das ich gerade geschrieben habe: /** * There is a set of tags which lead to a way not being reversable, this is EXTREMLY stupid and should be depreciated immediately. * @return true if somebody added the brain dead tags */ Deine non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. Und ich würde gerne Deine Alternativen wissen bevor Du sie als deprecated markieren willst. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hallo Das würde ich nicht unbedingt sagen. Bspw. wenn ich einen Teil des Umrisses eines Waldes parallel verschieben möchte, um es als Fluss etc. zu nutzen. Dann trenne ich den Wald auf, mache die Operationen und dann schließe ich den Wald wieder. Da ist das Erzeugen des MP überflüssig. Henning Am 14.05.2013 07:38, schrieb Wilhelm Spickermann: Hi, Ergänzung: Beim Splitten in sich geschlossener Linien mit Flächentag wird beim Splitten völlig richtig ein Multipolygon erzeugt und die Fläche bleibt erhalten. Das ist deutlich besser als beim JOSM. Wow. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Übersetzung: Wir haben nicht vor, Warnungen für das Umkehren von Wegrichtungen anzeigen zu lassen. Warnungen mögen gut gemeint sein, laufen aber dem Ziel von iD zuwider, neue Nutzer zu Kartenbeiträgen zu ermutigen, weil sie [die Warnungen] die Nutzer verunsichern, auch wenn die Bearbeitungen zu 100% korrekt sind. Ich könnte etwas kaputt machen, deshalb fasse ich lieber nichts an. Nicht zu erwähnen die Verärgerung erfahrener Mapper, die denken natürlich möchte ich den Weg umkehren und weiter klicken, ohne die Warnung zu lesen. Glücklicherweise macht vorsichtiges Design Benutzer sicherer und es weniger wahrscheinlich, dass etwas kaputt geht. Der beste Weg dies zu erreichen ist ihnen zu zeigen - ohne dass sie sich ein tiefes Verständnis der Datenstrukturen von OSM aneignen müssen - was sich auf der Karte befindet und welche Änderungen die vornehmen. Wir planen für natural=coastline eine Darstellung, die die Wasser- und Landseite¹ eindeutig zeigt und können das Gleiche für Klippen, Böschungen und Barrieren machen. Wasserwege und Einbahnstraßen haben bereits eine eindeutige Richtungsanzeige. Diese Ansicht finde ich durchaus nachvollziehbar. Allerdings muss man halt doch bei gewissem Zerstoerungspotential eine Abwaegung zwischen Neunutzerverschreckung und Datensicherheit vornehmen. Wenn richtungsabhaengige Tags sehr deutlich als solche gerendert werden, mildert das die Gefahr tatsaechlich ab. Allerdings muss man dann konsequent sein und auf Warnungen zurueckgreifen solange dieses Rendering noch nicht inplementiert ist. Werden diese Tags denn schon entsprechend gerendert? Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Tue, 14 May 2013 08:42:42 +0200 schrieb Henning Scholland o...@aighes.de: Bspw. wenn ich einen Teil des Umrisses eines Waldes parallel verschieben möchte, um es als Fluss etc. zu nutzen. Dann trenne ich den Wald auf, mache die Operationen und dann schließe ich den Wald wieder. Da ist das Erzeugen des MP überflüssig. OK. Hmmm. Ist hab's nicht ausprobiert: vielleicht verschwindet das MP sogar automatisch wieder, wenn es nur noch ein Element hat? Ich finde aber, dass die Vorteile überwiegen. Vermutlich aber wohl deshalb, weil ich viele solche kaputtgesplitteten Flächen repariere. :-) Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hallo, das hört sich sinnvoll an. Hast du das den josm-devvs schon vorgeschlagen? Henning Am 14.05.2013 09:27, schrieb Wilhelm Spickermann: Hi, Am Tue, 14 May 2013 08:42:42 +0200 schrieb Henning Scholland o...@aighes.de: Bspw. wenn ich einen Teil des Umrisses eines Waldes parallel verschieben möchte, um es als Fluss etc. zu nutzen. Dann trenne ich den Wald auf, mache die Operationen und dann schließe ich den Wald wieder. Da ist das Erzeugen des MP überflüssig. OK. Hmmm. Ist hab's nicht ausprobiert: vielleicht verschwindet das MP sogar automatisch wieder, wenn es nur noch ein Element hat? Ich finde aber, dass die Vorteile überwiegen. Vermutlich aber wohl deshalb, weil ich viele solche kaputtgesplitteten Flächen repariere. :-) Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Tue, 14 May 2013 10:22:59 +0200 schrieb Henning Scholland o...@aighes.de: Hallo, das hört sich sinnvoll an. Hast du das den josm-devvs schon vorgeschlagen? Henning Nein. Ein Vollautomatik würde vielleicht auch nicht zum JOSM passen. Ich bin da unsicher. Vielleicht eher in Form von Rückfragen: beim Splitten: Der aufzutrennende Weg beschreibt eine Fläche. Was soll mit ihr geschehen? a) Fläche beibehalten durch Erzeugen eines Multipolygons. b) Fläche löschen c) nur die Linie auftrennen. und beim Combine: Die Fläche könnte jetzt auch ohne ein Multipolygon formuliert werden. a) Ja, die Fläche ohne Multipolygon formulieren. b) Nein. Nur die Linien verbinden. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, On Tue, May 14, 2013 at 01:18:10AM +0200, Henning Scholland wrote: Ob die Nutzer nun von Programmmeldungen verunsichert werden, oder von den empörten Mitmappern, die sich über die ganzen Zerstörungen aufregen läuft dann aber letztlich aufs gleiche hinaus. Dann aber lieber mit Warnung...dann gehen nicht die vorhandenen Daten kaputt. Ich würde preferieren wenn wir mal alle fälle sammeln die iD kaputt macht und warum. Und dann kann man die mal kategorisieren in - 1) Laesst sich technisch lösen 2) Muss man mit einem WARNING ausruesten. Ich denke das _viele_ dinge die hier genannt werden sich mit kleinigkeiten fixen lassen. Wegrichtungsumkehr ist eines davon - das ist wirklich Kindergeburtstag. Andere dinge lassen sich auch leicht fixen denke ich man muss sie nur mal versuchen exakt zu beschreiben und ein ticket dafuer aufmachen dann kann man ja code einbauen der das verhindert. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 14. Mai 2013 12:03 schrieb Florian Lohoff f...@zz.de: Andere dinge lassen sich auch leicht fixen denke ich man muss sie nur mal versuchen exakt zu beschreiben und ein ticket dafuer aufmachen dann kann man ja code einbauen der das verhindert. Sehe ich auch so, die Programmierer haben schon zugesichert, für die richtungsabhängigen Objekte eine entsprechende Darstellung einzubauen, so dass die Leute das nicht versehentlich sondern nur absichtlich ändern. Anderes aber ist problematischer (Nicht-Zeigen von Relationen und deren tags, Nicht-zeigen von tags, für die es einen Preset bzw. eine Übersetzung gibt). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hallo, Am Dienstag, den 14.05.2013, 12:08 +0200 schrieb Martin Koppenhoefer: Am 14. Mai 2013 12:03 schrieb Florian Lohoff f...@zz.de: Andere dinge lassen sich auch leicht fixen denke ich man muss sie nur mal versuchen exakt zu beschreiben und ein ticket dafuer aufmachen dann kann man ja code einbauen der das verhindert. Sehe ich auch so, die Programmierer haben schon zugesichert, für die richtungsabhängigen Objekte eine entsprechende Darstellung einzubauen, so dass die Leute das nicht versehentlich sondern nur absichtlich ändern. Anderes aber ist problematischer (Nicht-Zeigen von Relationen und deren tags, Nicht-zeigen von tags, für die es einen Preset bzw. eine Übersetzung gibt). Es stellt sich die Frage, ob richtungsgebundene tags überhaupt erforderlich (und sinnvoll) sind. Die Geschichte mit dem oneway ist historisch gewachsen, als es noch kaum Probleme gab. Dann/davor kamm die Coastline. Das könnte jetzt immer so weiter gehen, dann haben wir 10, 20, ... 1000 und mehr Ausnahmen. Wie wäre es denn, damit grundsätzlich aufzuräumen und alles auf die forward/backward oder left/right-Tags umzustellen. Dann wird einmal definiert, nach welcher Regel (Muster) die Begriffe umzustellen sind beim Umdrehen und gut ist. oneway=forward/backward coastline=yes sea=right/left Bestehende Software kann sehr leicht das neue Tagging einlesen und ggf. die Linie intern umdrehen, wenn das für die Verarbeitung nach dem bisherigen Tagging erforderlich ist. _NOCH_ sind es nur vier oder fünf tags. Mit dem Kliff könnte man auch downside=right oder so was machen. Auch für die anderen tags ginge das mit etwas gutem Willen. Für eine Übergangszeit gibt es dann beides, und danach werden alle tags selbsterklärend, ohne dass jeder Auswerter erst mal tausend Wiki-Beiträge durchackern muss, bis er versteht, was warum in welcher Richtung ausgewertet werden soll. Und beim mappen werden Fehler vermieden. Wäre auch die nonstupid-Alternative für oneway ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hallo Wolfgang, das klingt erstmal nach einer recht guten Idee. Vor allem auch, weil es dadurch für den Mapper einfacher zu verstehen wird welche Tags richtungsabhängig sind. Bei einer Klippe oder einer Küstenlinien ist sowas nicht gerade selbsterklärend. Einen weiteren Vorteil sehe ich darin, dass man auch angeben kann, dass man keine Ahnung hat, in welche Richtung das Objekt nun gerichtet ist. Bspw. bei einem Fluss, der auf dem Luftbild nur teilweise zu sehen ist. Viele Grüße Henning Am 14.05.2013 13:21, schrieb Wolfgang Hinsch: Es stellt sich die Frage, ob richtungsgebundene tags überhaupt erforderlich (und sinnvoll) sind. Die Geschichte mit dem oneway ist historisch gewachsen, als es noch kaum Probleme gab. Dann/davor kamm die Coastline. Das könnte jetzt immer so weiter gehen, dann haben wir 10, 20, ... 1000 und mehr Ausnahmen. Wie wäre es denn, damit grundsätzlich aufzuräumen und alles auf die forward/backward oder left/right-Tags umzustellen. Dann wird einmal definiert, nach welcher Regel (Muster) die Begriffe umzustellen sind beim Umdrehen und gut ist. oneway=forward/backward coastline=yes sea=right/left Bestehende Software kann sehr leicht das neue Tagging einlesen und ggf. die Linie intern umdrehen, wenn das für die Verarbeitung nach dem bisherigen Tagging erforderlich ist. _NOCH_ sind es nur vier oder fünf tags. Mit dem Kliff könnte man auch downside=right oder so was machen. Auch für die anderen tags ginge das mit etwas gutem Willen. Für eine Übergangszeit gibt es dann beides, und danach werden alle tags selbsterklärend, ohne dass jeder Auswerter erst mal tausend Wiki-Beiträge durchackern muss, bis er versteht, was warum in welcher Richtung ausgewertet werden soll. Und beim mappen werden Fehler vermieden. Wäre auch die nonstupid-Alternative für oneway ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 14. Mai 2013 13:21 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Dann wird einmal definiert, nach welcher Regel (Muster) die Begriffe umzustellen sind beim Umdrehen und gut ist. oneway=forward/backward coastline=yes sea=right/left Bestehende Software kann sehr leicht das neue Tagging einlesen und ggf. die Linie intern umdrehen, wenn das für die Verarbeitung nach dem bisherigen Tagging erforderlich ist. _NOCH_ sind es nur vier oder fünf tags. Mit dem Kliff könnte man auch downside=right oder so was machen. ja, das wäre im Prinzip eine gute Lösung, weil dann automatisch anpassbar bei Richtungsänderungen. So was hat man ja z.B. auch bei Treppen (highway=steps) schon gemacht mit dem incline-tag. Nachteil ist eigentlich nur, dass es schon viele anders getaggte Objekte gibt, und dass man zusätzliche tags braucht, für was bisher implizit war (dafür wird das dann auch explizit und springt daher eher ins Auge). Gruß Martin PS: Zur Liste der 5 tags kommt ggf. auch noch historic=citywalls (neben barrier gibt es auch dieses Tagging für Stadtmauern). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 14.05.2013 13:22 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Es stellt sich die Frage, ob richtungsgebundene tags überhaupt erforderlich (und sinnvoll) sind. Die Geschichte mit dem oneway ist historisch gewachsen, als es noch kaum Probleme gab. Dann/davor kamm die Coastline. Das könnte jetzt immer so weiter gehen, dann haben wir 10, 20, ... 1000 und mehr Ausnahmen. Wie wäre es denn, damit grundsätzlich aufzuräumen und alles auf die forward/backward oder left/right-Tags umzustellen. Dann wird einmal definiert, nach welcher Regel (Muster) die Begriffe umzustellen sind beim Umdrehen und gut ist. oneway=forward/backward coastline=yes sea=right/left +1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
On Tue, May 14, 2013 at 01:21:23PM +0200, Wolfgang Hinsch wrote: wäre es denn, damit grundsätzlich aufzuräumen und alles auf die forward/backward oder left/right-Tags umzustellen. Dann wird einmal definiert, nach welcher Regel (Muster) die Begriffe umzustellen sind beim Umdrehen und gut ist. Ich bin ja eher fuer im tag nicht in der value unterbringen - Aber das ist geschmacksfrage: oneway:forward=yes Wäre auch die nonstupid-Alternative für oneway ;-) Aber auch fuer 30 anwendungsfaelle ist das ja kein problem da eine zeile code einzufuegen ... Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
On 11.05.2013 07:02, Jo wrote: 2013/5/11 malenki o...@malenki.ch Tirkon schrieb: [keine Warnung beim Umkehren von Wegen, keine Warnung beim Löschen von Relationsmitgliedern...] Nach dem Lesen dieses Threads schrieb ich im IRC versehentlich in #osm statt in #osm-de, wodurch eine Diskussion zustande kam. Mit jfire war auch einer der Programmierer dabei. Er und auch iandees sind eher der Ansicht, dass Warnhinweise die User abschrecken und man solche Warnungen deshalb besser weglässt. Beim Umkehren von natural=coastline will jfire offenbar eine Schutzfunktion implementieren. Warnhinweise beim (versehentlichen) Umdrehen von Einbahnstraßen oder Wasserwegen scheinen dagegen nicht geplant oder erwünscht. Das Tastaturkürzel zum Umkehren der Wegrichtung ist V, das auf der Tastatur in der Regel neben B liegt - dem Kürzel für den Hintergrund - Luftbilder und Co. Relationen: Es ist geplant, Relationen gut sichtbar zu machen, damit die Nutzer sie wahrnehmen. Wenn dann ein Mitglied einer Abbiegebeschränkung gelöscht wird, soll die gesamte Relation entfernt werden. Was für ein Schwachsinn !! Hier haben wir nebenbei eine Relation, wo auch Punkte wichtig sind. Wer es genau nachlesen möchte, findet das IRC-Log hier: http://malenki.ch/OSM/irc_osm_-_id_reverse_ways_warn.txt hth Thomas Vielleicht werden die mehr fortgeschrittene Mapper ab jetzt alles doppeltredundant eintragen müssen. Eine Relation und dann noch welche Tags um an zu geben: hier gibt es eine Relation, wenn die Relation nicht mehr da ist, bitte neuerstellen. Schade das mit so wenig Respekt mit unsere Beitragen umgehen wird. +1 Gerade das Löschen und Revertieren ist sehr problematisch. Zusätzlich habe ich auch noch eine Aktion vergessen: Zusammenfügen und daraus entstehende Konflikte. Ich frage mich ja auch immer wieder warum solche Aktionen nicht verboten/verhindert werden, solange die Software zu doof dafür ist. Wie weit werden Newbies über die History von Objekten und die Richtungsbedeutungen aufgeklärt ? JOSM kann es und für Potlatsch gibt es einen Bug Report, aber warum halten die Entwickler von iD tags wie cliff oder retaining_wall für unwichtig und erlauben weiterhin das Umdrehen. Ich werde also in Zukunft die Entwickler anschreiben und sie bitten die Fehler in der Datenbank zu korrigieren und in Kontakt mit den Nutzern ihrer Software zu treten. Ich habe nämlich keine Lust mehr mich wie mit Fußengetreten zu fühlen. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 13.05.2013 14:09, schrieb fly: JOSM kann es und für Potlatsch gibt es einen Bug Report, aber warum halten die Entwickler von iD tags wie cliff oder retaining_wall für unwichtig und erlauben weiterhin das Umdrehen. Ich zitiere aus einem bisschen JavaDoc das ich gerade geschrieben habe: /** * There is a set of tags which lead to a way not being reversable, this is EXTREMLY stupid and should be depreciated immediately. * @return true if somebody added the brain dead tags */ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Ich zitiere aus einem bisschen JavaDoc das ich gerade geschrieben habe: /** * There is a set of tags which lead to a way not being reversable, this is EXTREMLY stupid and should be depreciated immediately. * @return true if somebody added the brain dead tags */ Deine non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
2013/5/13 Ronnie Soak chaoschaos0...@googlemail.com Ich zitiere aus einem bisschen JavaDoc das ich gerade geschrieben habe: /** * There is a set of tags which lead to a way not being reversable, this is EXTREMLY stupid and should be depreciated immediately. * @return true if somebody added the brain dead tags */ Deine non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. ich finde auch, mit einem abwertenden Kommentar in irgendeiner Software ist da nichts gewonnen. Es gibt nunmal einige tags, die richtungsabhängig sind, gerade weil in den letzten 10 Jahren noch niemand einen Alternativvorschlag bringen konnte, wie man es besser machen könnte (es gab ein paar Alternativvorschläge, die bisher als schlechter bewertet wurden). Neben den genannten oneway, retaining_wall und cliff sind das auch natural=coastline, alle forward- und backward-tags für Dinge, die nur in einer Richtung gelten, barrier=city_wall, left- und right-tags für Dinge, die einseitig vorkommen und implizit getaggt werden sollen (z.B. Fahrradwege), neuerdings wohl auch das lanes-Schema und vermutlich noch mehr. Diese tags führen keineswegs dazu, dass man die ways nicht umdrehen kann, man muss es nur mit Bedacht tun und ggf. weitere Dinge ändern, damit alles konsistent bleibt. Schwierig wird es m.E. vor allem dann, wenn nicht alle vorhandenen tags angezeigt werden, und div. Objekte (insb. Relationen) vor dem Nutzer versteckt werden. Das finde ich OK für einen einfachen POI-Editor, der dann aber auch nicht ermöglicht, diese Dinge kaputt zu machen. Wer Operationen erlaubt, die diese Dinge ggf. kaputtmachen können, der sollte auch soviel Vertrauen in die Fähigkeiten der Mapper haben, dass er ihnen eine Chance lässt, überhaupt zu erkennen, dass da noch mehr dran hängt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
oneway gehört nicht zu den genannten (4 nach meine Zählung) Tags da sich mit oneway=-1 die Richtung umkehren lässt, was die meisten Editoren und Anwendungen auch unterstützen. Die 4 Tags sind übrigens (kann natürlich noch mehr geben) natural=cliff natural=coastline barrier=retaining_wall man_made=embankment Simon Am 13.05.2013 14:43, schrieb Ronnie Soak: Ich zitiere aus einem bisschen JavaDoc das ich gerade geschrieben habe: /** * There is a set of tags which lead to a way not being reversable, this is EXTREMLY stupid and should be depreciated immediately. * @return true if somebody added the brain dead tags */ Deine non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
On 13/mag/2013, at 16:10, Simon Poole si...@poole.ch wrote: Die 4 Tags sind übrigens (kann natürlich noch mehr geben) natural=cliff natural=coastline barrier=retaining_wall man_made=embankment +1 barrier=city_wall gehört z.B. auch dazu. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 13.05.2013 15:45, schrieb Martin Koppenhoefer: ich finde auch, mit einem abwertenden Kommentar in irgendeiner Software ist da nichts gewonnen. Es gibt nunmal einige tags, die richtungsabhängig sind, gerade weil in den letzten 10 Jahren noch niemand einen Alternativvorschlag bringen konnte, wie man es besser machen könnte (es gab ein paar Alternativvorschläge, die bisher als schlechter bewertet wurden). Neben den genannten oneway, retaining_wall und cliff sind das auch natural=coastline, alle forward- und backward-tags für Dinge, die nur in einer Richtung gelten, barrier=city_wall, left- und right-tags für Dinge, die einseitig vorkommen und implizit getaggt werden sollen (z.B. Fahrradwege), neuerdings wohl auch das lanes-Schema und vermutlich noch mehr. oneway, *:right, *:left, *:backward, *:forward, incline, direction, Himmelsrichtungen, Steigungen in °, Steigungen in % etc. sind alles vernünftig, wenn auch mit Aufwand, handhabbar. Die (mittlerweilen) 5 Ausnahmen, lassen als Lösung nur zu dem Benutzer mitzuteilen: Kannst du nicht machen oder Wenn du das machst, machst du was kaputt, die Wege sind wirklich nicht umkehrbar. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 13.05.2013, 16:10 Uhr, schrieb Simon Poole si...@poole.ch: natural=cliff natural=coastline barrier=retaining_wall man_made=embankment Am 13.05.2013, 16:18 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: barrier=city_wall gehört z.B. auch dazu. ...aber nur wenn two_sided=yes nicht gesetzt ist. Außerdem können barrier=city_wall und natural=cliff auch auf Flächen benutzt werden, dann ist eine Richtungsumkehrung wieder uneingeschränkt erlaubt. Außerdem verstehe ich nicht, wieso man_made=embankment in dieser Liste auftaucht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 13.05.2013 14:10 schrieb fly lowfligh...@googlemail.com: Ich werde also in Zukunft die Entwickler anschreiben und sie bitten die Fehler in der Datenbank zu korrigieren und in Kontakt mit den Nutzern ihrer Software zu treten. Ich habe nämlich keine Lust mehr mich wie mit Fußengetreten zu fühlen. +1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 13. Mai 2013 16:29 schrieb Martin Raifer tyr@gmail.com: Außerdem verstehe ich nicht, wieso man_made=embankment in dieser Liste auftaucht. weil Dämme auch oft 2 unterschiedliche Seiten (innen und aussen) haben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Achos, es geht also nicht um wege, die sich nicht umdrehen lassen, sondern um tags, die sich nicht umdrehen lassen. Ok. Das kam bei mir bisher nicht so an. oneway=-1 war mir bis dato zudem unbekannt. Ist aber tatsaechlich im Wiki dokumentiert. (Wenn auch als deprecated mit dem dem Hinweis auf oneway=reverse) Gruss, Chaos Am 13. Mai 2013 16:10 schrieb Simon Poole si...@poole.ch: oneway gehört nicht zu den genannten (4 nach meine Zählung) Tags da sich mit oneway=-1 die Richtung umkehren lässt, was die meisten Editoren und Anwendungen auch unterstützen. Die 4 Tags sind übrigens (kann natürlich noch mehr geben) natural=cliff natural=coastline barrier=retaining_wall man_made=embankment Simon Am 13.05.2013 14:43, schrieb Ronnie Soak: Ich zitiere aus einem bisschen JavaDoc das ich gerade geschrieben habe: /** * There is a set of tags which lead to a way not being reversable, this is EXTREMLY stupid and should be depreciated immediately. * @return true if somebody added the brain dead tags */ Deine non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 13.05.2013 16:29, schrieb Martin Raifer: . ...aber nur wenn two_sided=yes nicht gesetzt ist. Außerdem können barrier=city_wall und natural=cliff auch auf Flächen benutzt werden, dann ist eine Richtungsumkehrung wieder uneingeschränkt erlaubt. Außerdem verstehe ich nicht, wieso man_made=embankment in dieser Liste auftaucht. Siehe http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dembankment unter Usage Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Die (mittlerweilen) 5 Ausnahmen, lassen als Lösung nur zu dem Benutzer mitzuteilen: Kannst du nicht machen oder Wenn du das machst, machst du was kaputt, die Wege sind wirklich nicht umkehrbar. Was spricht gegen diese Loesung? Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Ich seh immernoch den tieferen Sinn nicht überhaupt ein umdrehen von Wegen anzubieten. Kann mir jemand mal den Vorteil vom umdrehen erklären? Ich mach das immer nur VOR dem eintragen von Lanes-Tags, damit alle Wege zu der Kreuzung hin führen. Ich geh davon aus das kein Anfänger was an Cosdtlines fixen muss etc. was nur durch umdrehen möglich ist. Lg Ruben Am 13.05.2013 16:40 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 13. Mai 2013 16:29 schrieb Martin Raifer tyr@gmail.com: Außerdem verstehe ich nicht, wieso man_made=embankment in dieser Liste auftaucht. weil Dämme auch oft 2 unterschiedliche Seiten (innen und aussen) haben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 13.05.2013 16:45, schrieb Ruben Kelevra: Ich seh immernoch den tieferen Sinn nicht überhaupt ein umdrehen von Wegen anzubieten. Die üblichen expliziten Fälle sind Kreisverkehre und Einbahnstrassen. Implizit beim Verbinden von Wegen. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 13.05.2013, 16:28 Uhr, schrieb Simon Poole si...@poole.ch: [...] lassen als Lösung nur zu dem Benutzer mitzuteilen: Kannst du nicht machen oder Wenn du das machst, machst du was kaputt, die Wege sind wirklich nicht umkehrbar. https://github.com/systemed/iD/blob/master/js/id/actions/reverse.js#L2-L4: Order the nodes of a way in reverse order and reverse any direction dependent tags other than `oneway`. (We assume that correcting a backwards oneway is the primary reason for reversing a way.) Hm... Ich glaube hier gibt es zwei verschiedene Interpretationen von Weg umkehren. Du meinst: Reihenfolge der Nodes im OSM-Way umkehren bei gleichzeitiger Beibehaltung des abgebildeten Sachverhalts. iD meint: Drehe die abgebildete Information 'Einbahnstraße' um. Ich glaube was iD macht, ist auch das was ein Einsteiger (der noch kein Verständnis der zugrundeliegenden Datenstrukturen hat) sich unter der Funktion erwartet. Ah, diese Einbahn ist falsch eingetragen. Um das zu berichtigen, muss ich den Weg umdrehen. Um weitere Verwirrung zu verhindern sollte die Funktion aber auch Einbahn umdrehen (reverse oneway) heißen und nur auf Einbahnstraßen angeboten werden. Für das Korrigieren der Richtung von Klippen, Dämmen, usw. könnte es dann eine eigene Aktion Richtung der Klippe umdrehen geben. Grüße Martin / tyr_asd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Fehlt nur noch eine Lösung für das kombinieren von Wegen. Lg Ruben Am 13.05.2013 16:59 schrieb Martin Raifer tyr@gmail.com: Am 13.05.2013, 16:28 Uhr, schrieb Simon Poole si...@poole.ch: [...] lassen als Lösung nur zu dem Benutzer mitzuteilen: Kannst du nicht machen oder Wenn du das machst, machst du was kaputt, die Wege sind wirklich nicht umkehrbar. https://github.com/systemed/**iD/blob/master/js/id/actions/** reverse.js#L2-L4https://github.com/systemed/iD/blob/master/js/id/actions/reverse.js#L2-L4 : Order the nodes of a way in reverse order and reverse any direction dependent tags other than `oneway`. (We assume that correcting a backwards oneway is the primary reason for reversing a way.) Hm... Ich glaube hier gibt es zwei verschiedene Interpretationen von Weg umkehren. Du meinst: Reihenfolge der Nodes im OSM-Way umkehren bei gleichzeitiger Beibehaltung des abgebildeten Sachverhalts. iD meint: Drehe die abgebildete Information 'Einbahnstraße' um. Ich glaube was iD macht, ist auch das was ein Einsteiger (der noch kein Verständnis der zugrundeliegenden Datenstrukturen hat) sich unter der Funktion erwartet. Ah, diese Einbahn ist falsch eingetragen. Um das zu berichtigen, muss ich den Weg umdrehen. Um weitere Verwirrung zu verhindern sollte die Funktion aber auch Einbahn umdrehen (reverse oneway) heißen und nur auf Einbahnstraßen angeboten werden. Für das Korrigieren der Richtung von Klippen, Dämmen, usw. könnte es dann eine eigene Aktion Richtung der Klippe umdrehen geben. Grüße Martin / tyr_asd __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 13.05.2013 16:45, schrieb Ruben Kelevra: Ich seh immernoch den tieferen Sinn nicht überhaupt ein umdrehen von Wegen anzubieten. Kann mir jemand mal den Vorteil vom umdrehen erklären? Ich mach das immer nur VOR dem eintragen von Lanes-Tags, damit alle Wege zu der Kreuzung hin führen. Da hast du ja selbst dann schon einen Vorteil vom Umdrehen. Nehmen wir jetzt außerdem an, auf dem von dir deshalb umgedrehten Wegstück würde eine zusätzliche Kreuzung gebaut oder aus anderen Gründen einzutragen notwendig. Schon muss jemand den Weg aufsplitten und einen Teil davon wieder umdrehen. Zweites Beispiel: Du machst das genauso wie du es hier beschreibst - aber vorher hat jemand implizit die Bürgersteige (footway:left, footway:right) eingetragen - auf die du jetzt Rücksicht nehmen musst beim Umdrehen. Was mir bei der ganzen Diskussion hier Probleme bereitet ist der Widerspruch: Einerseits gibt es viele, die gegen das explizite Eintragen von Bürgersteigen als eigene ways sind, diese seien - wenn überhaupt - Attribute des Weges, andererseits sind dies genau deshalb notwendigerweise problematische Punkte beim Umdrehen von Wegen, weil ich eben einen linken Bürgersteig mit anderen Attributen beschreiben muss als den rechten, wenn diese sich unterscheiden. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 13. Mai 2013 15:45 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Schwierig wird es m.E. vor allem dann, wenn nicht alle vorhandenen tags angezeigt werden, und div. Objekte (insb. Relationen) vor dem Nutzer versteckt werden. Das finde ich OK für einen einfachen POI-Editor, der dann aber auch nicht ermöglicht, diese Dinge kaputt zu machen. Wer Operationen erlaubt, die diese Dinge ggf. kaputtmachen können, der sollte auch soviel Vertrauen in die Fähigkeiten der Mapper haben, dass er ihnen eine Chance lässt, überhaupt zu erkennen, dass da noch mehr dran hängt. Gruß Martin +1³ Das sagt alles! Das mindeste ist, dass man alle Tags anzeigt. Gerne auch ausgegraut/nicht änderbar. Denn nur so kann der Anwender erkennen, dass es in OSM noch viel mehr gibt. Gruß René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 13.05.2013 16:58, schrieb Martin Raifer: Hm... Ich glaube hier gibt es zwei verschiedene Interpretationen von Weg umkehren. Du meinst: Reihenfolge der Nodes im OSM-Way umkehren bei gleichzeitiger Beibehaltung des abgebildeten Sachverhalts. iD meint: Drehe die abgebildete Information 'Einbahnstraße' um. Ich glaube was iD macht, ist auch das was ein Einsteiger (der noch kein Verständnis der zugrundeliegenden Datenstrukturen hat) sich unter der Funktion erwartet. Ah, diese Einbahn ist falsch eingetragen. Um das zu berichtigen, muss ich den Weg umdrehen. Um weitere Verwirrung zu verhindern sollte die Funktion aber auch Einbahn umdrehen (reverse oneway) heißen und nur auf Einbahnstraßen angeboten werden. Für das Korrigieren der Richtung von Klippen, Dämmen, usw. könnte es dann eine eigene Aktion Richtung der Klippe umdrehen geben. Nein es gibt da kein Missverständnis (siehe auch https://github.com/systemed/iD/issues/299). Die Frage war nur was benutzerfreundlicher ist: anzunehmen, dass meistens der User die Bedeutung des oneway Tags umdrehen will wenn er ein Weg dreht oder nicht (ich hab in meinem Patch für vespucci die gleiche Annahme gemacht). In beiden Fällen muss man aber die anderen richtungsabhängigen Tags umdrehen, was iD ja auch macht. Ob man jetzt die Funktion nur für oneways anbieten soll würde ich offen lassen, mindestens für Kreisverkehre müsste man es dann auch zulassen, und wenns dann für andere normale Strassen nicht geht hat man wieder viel Erklärungsbedarf. Dreht man ein Weg um ihn mit einem anderen zu verbinden, kann man natürlich diese Annahme nicht machen und muss alle richtungsabhängigen Tags umdrehen (ob das iD auch so macht hab ich nicht überprüft). Ausser du willst nicht zulassen, dass man Wege verbindet, kommst du um die Komplexität nicht herum. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 13.05.2013, 17:03 Uhr, schrieb Ruben Kelevra cyr...@gmail.com: Fehlt nur noch eine Lösung für das kombinieren von Wegen. Ich glaube das Zusammenfügen sollte zumindest dann nicht angeboten werden, wenn für das Joinen implizit eine richtungsrelevante Eigenschaft umgedreht werden muss (z.B. 2 oneways in verschiedenen Richtungen). Vielleicht aber auch, wenn durch das Zusammenfügen so Konstrukte wie highway=residential;unclassified oder name=X-Straße;Y-Allee entstehen, die i.d.R. auch nicht mehr der Wirklichkeit entsprechen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Das sollte nicht möglich sein, solange sich die Eigenschaften unterscheiden und zu den Eigenschaften gehören auch die Relationen. Sprich entweder gleich ablehnen oder den Nutzer fragen: Gehören beide Wege zu der Radroute xyz?. Wenn nein, dann nicht verbinden. Henning Am 13.05.2013 17:03, schrieb Ruben Kelevra: Fehlt nur noch eine Lösung für das kombinieren von Wegen. Lg Ruben Am 13.05.2013 16:59 schrieb Martin Raifer tyr@gmail.com: Am 13.05.2013, 16:28 Uhr, schrieb Simon Poole si...@poole.ch: [...] lassen als Lösung nur zu dem Benutzer mitzuteilen: Kannst du nicht machen oder Wenn du das machst, machst du was kaputt, die Wege sind wirklich nicht umkehrbar. https://github.com/systemed/**iD/blob/master/js/id/actions/** reverse.js#L2-L4https://github.com/systemed/iD/blob/master/js/id/actions/reverse.js#L2-L4 : Order the nodes of a way in reverse order and reverse any direction dependent tags other than `oneway`. (We assume that correcting a backwards oneway is the primary reason for reversing a way.) Hm... Ich glaube hier gibt es zwei verschiedene Interpretationen von Weg umkehren. Du meinst: Reihenfolge der Nodes im OSM-Way umkehren bei gleichzeitiger Beibehaltung des abgebildeten Sachverhalts. iD meint: Drehe die abgebildete Information 'Einbahnstraße' um. Ich glaube was iD macht, ist auch das was ein Einsteiger (der noch kein Verständnis der zugrundeliegenden Datenstrukturen hat) sich unter der Funktion erwartet. Ah, diese Einbahn ist falsch eingetragen. Um das zu berichtigen, muss ich den Weg umdrehen. Um weitere Verwirrung zu verhindern sollte die Funktion aber auch Einbahn umdrehen (reverse oneway) heißen und nur auf Einbahnstraßen angeboten werden. Für das Korrigieren der Richtung von Klippen, Dämmen, usw. könnte es dann eine eigene Aktion Richtung der Klippe umdrehen geben. Grüße Martin / tyr_asd __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 13.05.2013 16:43, schrieb Ronnie Soak: Die (mittlerweilen) 5 Ausnahmen, lassen als Lösung nur zu dem Benutzer mitzuteilen: Kannst du nicht machen oder Wenn du das machst, machst du was kaputt, die Wege sind wirklich nicht umkehrbar. Was spricht gegen diese Loesung? +1 Ich denke kaum, dass die Zielgruppe von iD weiß, bzw. wissen möchte, ob die Richtung einer Klippe korrekt ist. Am sinnvollsten wäre eine Frage an den Anwender, in der auf das hingewiesen wird, was er gerade tut. Bspw. bei einem waterway=river: Du bist dabei beim Fluss name die Fließrichtung umzudrehen. Willst du das wirklich tun? Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Tirkon schrieb: In ID ist es durch die umringenden Icons jetzt für Anfänger noch einfacher als in Potlatch, versehentlich etwas zu löschen oder die Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich, um ein kilometerweites Netz abzufahren und maxspeed detailliert zu dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut abzufahren? Von dem Entwickler jfirebaugh gibt es jetzt auch eine wohl offizielle Antwort hinsichtlich richtungsabhängiger Tags/Wege: https://github.com/systemed/iD/issues/1475#issuecomment-17835596 | We're not planning to add any warnings for reversing ways. Warnings | may be well intentioned, but they run counter to iD's goal of | encouraging new users to contribute to the map because they make them | feel insecure, even when their edits are perfectly legitimate. I | might break something, I better not touch. Not to mention they are | an annoyance for experienced mappers, who think of course I want to | reverse it, and click through without reading. | Fortunately, careful design makes users feel MORE secure AND less | likely to break something. The best way to do it is show them, in a | way they can understand without a deep knowledge of OSM data | structures, what's on the map and what changes they are making to it. | We're planning to add styles for natural=coastline that indicate the | water/land sides (#1465), and we can do the same for cliffs, | embankments and barriers. Waterways and oneways already have a clear | direction indicator. Übersetzung: Wir haben nicht vor, Warnungen für das Umkehren von Wegrichtungen anzeigen zu lassen. Warnungen mögen gut gemeint sein, laufen aber dem Ziel von iD zuwider, neue Nutzer zu Kartenbeiträgen zu ermutigen, weil sie [die Warnungen] die Nutzer verunsichern, auch wenn die Bearbeitungen zu 100% korrekt sind. Ich könnte etwas kaputt machen, deshalb fasse ich lieber nichts an. Nicht zu erwähnen die Verärgerung erfahrener Mapper, die denken natürlich möchte ich den Weg umkehren und weiter klicken, ohne die Warnung zu lesen. Glücklicherweise macht vorsichtiges Design Benutzer sicherer und es weniger wahrscheinlich, dass etwas kaputt geht. Der beste Weg dies zu erreichen ist ihnen zu zeigen - ohne dass sie sich ein tiefes Verständnis der Datenstrukturen von OSM aneignen müssen - was sich auf der Karte befindet und welche Änderungen die vornehmen. Wir planen für natural=coastline eine Darstellung, die die Wasser- und Landseite¹ eindeutig zeigt und können das Gleiche für Klippen, Böschungen und Barrieren machen. Wasserwege und Einbahnstraßen haben bereits eine eindeutige Richtungsanzeige. ¹ https://github.com/systemed/iD/issues/1465 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Ob die Nutzer nun von Programmmeldungen verunsichert werden, oder von den empörten Mitmappern, die sich über die ganzen Zerstörungen aufregen läuft dann aber letztlich aufs gleiche hinaus. Dann aber lieber mit Warnung...dann gehen nicht die vorhandenen Daten kaputt. Henning Am 13.05.2013 22:46, schrieb malenki: Tirkon schrieb: In ID ist es durch die umringenden Icons jetzt für Anfänger noch einfacher als in Potlatch, versehentlich etwas zu löschen oder die Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich, um ein kilometerweites Netz abzufahren und maxspeed detailliert zu dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut abzufahren? Von dem Entwickler jfirebaugh gibt es jetzt auch eine wohl offizielle Antwort hinsichtlich richtungsabhängiger Tags/Wege: https://github.com/systemed/iD/issues/1475#issuecomment-17835596 | We're not planning to add any warnings for reversing ways. Warnings | may be well intentioned, but they run counter to iD's goal of | encouraging new users to contribute to the map because they make them | feel insecure, even when their edits are perfectly legitimate. I | might break something, I better not touch. Not to mention they are | an annoyance for experienced mappers, who think of course I want to | reverse it, and click through without reading. | Fortunately, careful design makes users feel MORE secure AND less | likely to break something. The best way to do it is show them, in a | way they can understand without a deep knowledge of OSM data | structures, what's on the map and what changes they are making to it. | We're planning to add styles for natural=coastline that indicate the | water/land sides (#1465), and we can do the same for cliffs, | embankments and barriers. Waterways and oneways already have a clear | direction indicator. Übersetzung: Wir haben nicht vor, Warnungen für das Umkehren von Wegrichtungen anzeigen zu lassen. Warnungen mögen gut gemeint sein, laufen aber dem Ziel von iD zuwider, neue Nutzer zu Kartenbeiträgen zu ermutigen, weil sie [die Warnungen] die Nutzer verunsichern, auch wenn die Bearbeitungen zu 100% korrekt sind. Ich könnte etwas kaputt machen, deshalb fasse ich lieber nichts an. Nicht zu erwähnen die Verärgerung erfahrener Mapper, die denken natürlich möchte ich den Weg umkehren und weiter klicken, ohne die Warnung zu lesen. Glücklicherweise macht vorsichtiges Design Benutzer sicherer und es weniger wahrscheinlich, dass etwas kaputt geht. Der beste Weg dies zu erreichen ist ihnen zu zeigen - ohne dass sie sich ein tiefes Verständnis der Datenstrukturen von OSM aneignen müssen - was sich auf der Karte befindet und welche Änderungen die vornehmen. Wir planen für natural=coastline eine Darstellung, die die Wasser- und Landseite¹ eindeutig zeigt und können das Gleiche für Klippen, Böschungen und Barrieren machen. Wasserwege und Einbahnstraßen haben bereits eine eindeutige Richtungsanzeige. ¹ https://github.com/systemed/iD/issues/1465 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am Fri, 10 May 2013 07:08:32 +0200 schrieb Wilhelm Spickermann o...@spickermann-d.de: Es gibt mehrere Splittingprobleme ... Ich habe den iD vorhin erstmalig benutzt und war von der Behandlung des Splittings angenehm überrascht. Anders als bei Potlatch und genauso wie im JOSM werden die Routen beim Splitten gewöhnlich nicht kaputt gemacht; das Einfügen der beiden Wegteile erfolgt gewöhnlich in der für die jeweilige Relation richtigen Reihenfolge an der richtigen Stelle: also insbesondere in den verschiedenen betroffenen Relationen mit i. A. verschiedener Reihenfolge. Wie beim JOSM funktioniert dies leider nicht, wenn die Vorgänger-/Nachfolgerwege nicht geladen sind. Beim JOSM kann man zur Vermeidung dieses Problems eine beliebig kleine Umgebung der Endpunkte vor dem Splitten laden. Vermutlich reicht es beim iD, die Endpunkte vor dem Splitten mal ins Bild zu bringen; das habe ich aber nicht ausprobiert. Zumindest in dieser Hinsicht ist der iD ein großer Fortschritt gegenüber Potlatch. Ich rechne da auf jeden Fall mit weniger Reparaturarbeiten an Relationen als bisher. Wilhelm PS: Eine zufällig betroffene Abbiegerelation sah bei den Tests auch gut aus. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Ergänzung: Beim Splitten in sich geschlossener Linien mit Flächentag wird beim Splitten völlig richtig ein Multipolygon erzeugt und die Fläche bleibt erhalten. Das ist deutlich besser als beim JOSM. Wow. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hallo Malenski, dem Argument der Programmierer kann ich folgen, Anfänger wollen nicht hundert Hinweise lesen bevor sie loslegen. Sondern einfach, sagen wir ein Café erstellen. Nur gibt es gewisse Dinge die geschützt werden müssen. Wege sollte man ganz allgemein nicht per Hotkey umdrehen können. Ich finde diese Funktion gehört einfach einen Menüpunkt Experten untergebracht, und dann ein genereller Warnhinweis davor. Was Relationen angeht seh ich kein Problem wenn Anfänger daran arbeiten. Viel wichtiger ist eine Prüfung des Datenbestands nach der Bearbeitung. Hier wird der Anfänger gewarnt wenn dir Daten inkonsistent sind. Das versteht selbst der absolute Neuling wenn am Ende eine Prüfung ausgeführt wird und er gewarnt wird. Es wäre hier sogar möglich wenn der Anfänger dies übergeht einen Bug zu erstellen, das den Experten das Suchen erleichtert und vielleicht jemand mit regionalem Bezug sich dem Anfänger annimmt. So würde eine Integration gefördert. Lg Ruben Am 11.05.2013 04:25 schrieb malenki o...@malenki.ch: Tirkon schrieb: [keine Warnung beim Umkehren von Wegen, keine Warnung beim Löschen von Relationsmitgliedern...] Nach dem Lesen dieses Threads schrieb ich im IRC versehentlich in #osm statt in #osm-de, wodurch eine Diskussion zustande kam. Mit jfire war auch einer der Programmierer dabei. Er und auch iandees sind eher der Ansicht, dass Warnhinweise die User abschrecken und man solche Warnungen deshalb besser weglässt. Beim Umkehren von natural=coastline will jfire offenbar eine Schutzfunktion implementieren. Warnhinweise beim (versehentlichen) Umdrehen von Einbahnstraßen oder Wasserwegen scheinen dagegen nicht geplant oder erwünscht. Das Tastaturkürzel zum Umkehren der Wegrichtung ist V, das auf der Tastatur in der Regel neben B liegt - dem Kürzel für den Hintergrund - Luftbilder und Co. Relationen: Es ist geplant, Relationen gut sichtbar zu machen, damit die Nutzer sie wahrnehmen. Wenn dann ein Mitglied einer Abbiegebeschränkung gelöscht wird, soll die gesamte Relation entfernt werden. Wer es genau nachlesen möchte, findet das IRC-Log hier: http://malenki.ch/OSM/irc_osm_-_id_reverse_ways_warn.txt hth Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Ruben Kelevra schrieb: Hallo Malenski, *hüstel* ;) dem Argument der Programmierer kann ich folgen, Anfänger wollen nicht hundert Hinweise lesen bevor sie loslegen. Sondern einfach, sagen wir ein Café erstellen. Ein Warnung sollte ja nur erfolgen, wenn sie (möglicherweise) etwas kaputt machen. Es wird vermutlich eher selten vorkommen, dass ein verantwortungsbewusster Anfänger Straßen(teile) löscht (die Mitglieder von Relationen enthalten können) oder absichtlich die Richtung einer Einbahnstraße oder eines Wasserweges umkehrt. Bei der (geschätzten) geringen Häufigkeit des tatsächlichen Auftretens solcher Edits sehe ich kein Problem, einen Warnhinweis zu zeigen. Nur gibt es gewisse Dinge die geschützt werden müssen. Wege sollte man ganz allgemein nicht per Hotkey umdrehen können. Ich finde diese Funktion gehört einfach einen Menüpunkt Experten untergebracht, und dann ein genereller Warnhinweis davor. +1 Was Relationen angeht seh ich kein Problem wenn Anfänger daran arbeiten. Derzeit sehen die Nutzer von iD nicht, dass es sowas wie Relationen überhaupt gibt. Ansonsten habe ich auch kein Problem, wenn Anfänger an Relationen arbeiten - solange die Daten nicht zerstört werden. Viel wichtiger ist eine Prüfung des Datenbestands nach der Bearbeitung. Hier wird der Anfänger gewarnt wenn dir Daten inkonsistent sind. Das versteht selbst der absolute Neuling wenn am Ende eine Prüfung ausgeführt wird und er gewarnt wird. Wenn erst beim Hochladen - möglicherweise nach umfangreichen Bearbeitungen - ein Hinweis gezeigt wird, dass xy kaputt gehen könnte, weiß der Mapper erst recht nicht, wie er den möglichen Schaden abwenden kann. Entweder er bricht frustriert ab oder lädt trotzdem hoch. Es wäre hier sogar möglich wenn der Anfänger dies übergeht einen Bug zu erstellen, das den Experten das Suchen erleichtert und vielleicht jemand mit regionalem Bezug sich dem Anfänger annimmt. So würde eine Integration gefördert. +1 Gruß Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Ich entschuldige mich, das war die Autokorrektur. Mit der umfangreichen Bearbeitung hast du recht, nur denke ich das die meisten Anfänger eher kleine Änderungen machen. Dies sollte auch in die Einführung geschrieben werden. Um so einfacher lassen sich Fehler ausbügeln. Man könnte außerdem dem Benutzer anbieten diese Datenprüfung jederzeit durchzuführen. Den aktuellen Zustand sehe ich dagegen als unhaltbar. Relationen fixen gehört mittlerweile zum täglich Brot, alles was diese Situation verschlechtert gehört der Schreibzugriff entzogen. Lg Ruben Am 11.05.2013 13:22 schrieb malenki o...@malenki.ch: Ruben Kelevra schrieb: Hallo Malenski, *hüstel* ;) dem Argument der Programmierer kann ich folgen, Anfänger wollen nicht hundert Hinweise lesen bevor sie loslegen. Sondern einfach, sagen wir ein Café erstellen. Ein Warnung sollte ja nur erfolgen, wenn sie (möglicherweise) etwas kaputt machen. Es wird vermutlich eher selten vorkommen, dass ein verantwortungsbewusster Anfänger Straßen(teile) löscht (die Mitglieder von Relationen enthalten können) oder absichtlich die Richtung einer Einbahnstraße oder eines Wasserweges umkehrt. Bei der (geschätzten) geringen Häufigkeit des tatsächlichen Auftretens solcher Edits sehe ich kein Problem, einen Warnhinweis zu zeigen. Nur gibt es gewisse Dinge die geschützt werden müssen. Wege sollte man ganz allgemein nicht per Hotkey umdrehen können. Ich finde diese Funktion gehört einfach einen Menüpunkt Experten untergebracht, und dann ein genereller Warnhinweis davor. +1 Was Relationen angeht seh ich kein Problem wenn Anfänger daran arbeiten. Derzeit sehen die Nutzer von iD nicht, dass es sowas wie Relationen überhaupt gibt. Ansonsten habe ich auch kein Problem, wenn Anfänger an Relationen arbeiten - solange die Daten nicht zerstört werden. Viel wichtiger ist eine Prüfung des Datenbestands nach der Bearbeitung. Hier wird der Anfänger gewarnt wenn dir Daten inkonsistent sind. Das versteht selbst der absolute Neuling wenn am Ende eine Prüfung ausgeführt wird und er gewarnt wird. Wenn erst beim Hochladen - möglicherweise nach umfangreichen Bearbeitungen - ein Hinweis gezeigt wird, dass xy kaputt gehen könnte, weiß der Mapper erst recht nicht, wie er den möglichen Schaden abwenden kann. Entweder er bricht frustriert ab oder lädt trotzdem hoch. Es wäre hier sogar möglich wenn der Anfänger dies übergeht einen Bug zu erstellen, das den Experten das Suchen erleichtert und vielleicht jemand mit regionalem Bezug sich dem Anfänger annimmt. So würde eine Integration gefördert. +1 Gruß Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hallo Wilhelm, Am Freitag, 10. Mai 2013, 07:08:32 schrieb Wilhelm Spickermann: Ein drittes Splittingproblem gibt es bei den Kreisverkehren. Wenn ein Kreisverkehr Element einer Route ist, dann ist damit nur benötigte Teil des Kreisverkehrs gemeint. Splittet man ihn auf, dann gilt diese Sonderregel nicht mehr und man muss nicht zugehörige Teile wegwerfen und die anderen Teile sinnvoll umsortieren. Noch schlimmer: man muss alle anderen betroffenen Relation ebenso laden, den Kreisverkehr ggf. weiter splitten und bei allen nachkorrigieren. Das unterstützt keiner der Editoren. (Ich halte es meist für Quatsch Kreisverkehre zu splitten, aber es gibt andere Ansichten/Situationen und wenn man da splittet, dann gibt es dieses Problem.) mit anderen Worten: der einzige Grund, weswegen Kreisverkehre ein Problem sind, ist *genau* diese Sonderregel. Wenn an Kreisverkehren von Anfang an für Routen richtig gesplittet wird, sind auch nachträgliche Splits kein Problem mehr. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hallo Eckhart, Am Sat, 11 May 2013 15:40:32 +0200 schrieb Eckhart Wörner ewoer...@kde.org: Wenn an Kreisverkehren von Anfang an für Routen richtig gesplittet wird, sind auch nachträgliche Splits kein Problem mehr. Ich glaube nicht, dass nur gesplittete Kreisverkehre richtig sind. Es ist etablierte Praxis, Kreisverkehre komplett anzugeben obwohl sie nicht komplett umlaufen werden und schon garnicht komplett vom Anfangs- zum Endpunkt. Wenn man das jetzt noch ändern wollte, dann müsste man eine große Abstimmung machen und dann einen Bot über die Welt laufen lassen wie beim Lizenzwechsel. Ich hatte nur einen einzigen Fall, in dem ich einen Kreisverkehr splitten musste. Da war in Frankreich eine Bushaltestelle so in den Kreisverkehr gelegt, dass der Bus eine zusätzliche Runde drehen musste. Soll man jetzt nur wegen exotischer Fälle alle Kreisverkehre splitten? Außerdem: wenn alle Kreisverkehre bereits gesplittet wären, dann wäre das Splitten dort immer noch ein Problem, nämlich das in Punkt zwei erwähnte. Nicht einmal JOSM macht das immer richtig. Es entfallen dann nur die zusätzlichen Splits -- die hat man dann schon vorher gemacht. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Ich denke, die entstehenden Probleme beim Editor beheben zu wollen, ist der falsche Ansatz. Meiner Meinung nach muss die Datenbank hochgeladenen Daten auf Konsistenz prüfen und ggf. zurückweisen. Dann erfasst man alle Editoren und auch direkte up-loads auf einen Schlag. Auch JOSM hat seine Tücken: Wenn man einen Weg oder eine Relation alleine runterlädt, und dann Punkte verschiebt, so kann man andere Wege und Relationen komplett unbrauchbar machen, ohne dass man etwas davon merkt oder dass JOSM meckert. -- View this message in context: http://gis.19327.n5.nabble.com/ID-Editor-zerstort-mit-einem-Klick-tagelange-Arbeit-tp5760346p5760581.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 11.05.2013 17:14 schrieb fx99 f...@vollbio.de: Auch JOSM hat seine Tücken: Wenn man einen Weg oder eine Relation alleine runterlädt, und dann Punkte verschiebt, so kann man andere Wege und Relationen komplett unbrauchbar machen, ohne dass man etwas davon merkt oder dass JOSM meckert. Das wirkt aber nicht gerade nach einem üblichen Fall... Lg Ruben ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hallo Wilhelm, Am Samstag, 11. Mai 2013, 17:03:16 schrieb Wilhelm Spickermann: Wenn an Kreisverkehren von Anfang an für Routen richtig gesplittet wird, sind auch nachträgliche Splits kein Problem mehr. Ich glaube nicht, dass nur gesplittete Kreisverkehre richtig sind. Es ist etablierte Praxis, Kreisverkehre komplett anzugeben obwohl sie nicht komplett umlaufen werden und schon garnicht komplett vom Anfangs- zum Endpunkt. Deine etablierte Praxis hat es noch nicht einmal ins Wiki geschafft? (Ich bestreite nicht, dass ein Mapper das so handhaben, aber sicher nicht die Mehrheit.) Wenn man das jetzt noch ändern wollte, dann müsste man eine große Abstimmung machen und dann einen Bot über die Welt laufen lassen wie beim Lizenzwechsel. S.o. Die Gründe, weswegen Kreisverkehre von vielen nicht gesplittet werden: a) JOSM hat dann früher Kreisverkehre als Flächen behandelt und ausgefüllt gezeichnet b) JOSM zeigt dann ein Kreisverkehr-Icon in Relationen an c) JOSM kann immer noch nicht mehrere Ways im Kreis anordnen Interessanterweise beginnen alle diese Punkte mit JOSM… (wahrscheinlich gibt es auch ein paar Punkte, die mit Potlatch… oder iD… beginnen). Es gibt keinen stichhaltigen Grund, warum Kreisverkehre so besonders sind. Ich hatte nur einen einzigen Fall, in dem ich einen Kreisverkehr splitten musste. Da war in Frankreich eine Bushaltestelle so in den Kreisverkehr gelegt, dass der Bus eine zusätzliche Runde drehen musste. Oh, es gibt genügend Gründe, warum Kreisverkehre gesplittet werden müssen: Turn Restrictions, Spuren, … Außerdem: wenn alle Kreisverkehre bereits gesplittet wären, dann wäre das Splitten dort immer noch ein Problem, nämlich das in Punkt zwei erwähnte. Nicht einmal JOSM macht das immer richtig. Es entfallen dann nur die zusätzlichen Splits -- die hat man dann schon vorher gemacht. Das in Punkt zwei erwähnte Problem hat erstmal gar nichts mit Kreisverkehren zu tun, sondern tritt überall auf. Ist aber auch ein lösbares Problem (Um den Weg korrekt zu splitten, müssen weitere Wege heruntergeladen werden. Jetzt herunterladen? o.ä.). Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am Sat, May 11, 2013 at 5:42 PM schrieb Eckhart Wörner ewoer...@kde.org: c) JOSM kann immer noch nicht mehrere Ways im Kreis anordnen Nicht ganz richtig, man muss blos manuell alle Nodes markieren, dann gehts. LG Ruben ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Sat, 11 May 2013 17:42:32 +0200 schrieb Eckhart Wörner ewoer...@kde.org: Ich bestreite nicht, dass ein Mapper das so handhaben, aber sicher nicht die Mehrheit. Ja. Manche machen es so und manche machen es anders. Wenn es dabei auf Mehrheiten ankommt, dann nur auf die Mehrheit bei einer Abstimmung zur Frage, ob man eine Praxis für falsch erklären soll. Wenn jemand einen Kreisverkehr splittet, dann füge ich ihn nicht wieder zusammen, sondern repariere statt dessen mühevoll die Relationen. Die Gründe, weswegen Kreisverkehre von vielen nicht gesplittet werden: a) JOSM hat dann früher Kreisverkehre als Flächen behandelt und ausgefüllt gezeichnet b) JOSM zeigt dann ein Kreisverkehr-Icon in Relationen an c) JOSM kann immer noch nicht mehrere Ways im Kreis anordnen Also für mich hat noch nie irgendeiner dieser Gründe eine Rolle gespielt. Interessanterweise beginnen alle diese Punkte mit JOSM… (wahrscheinlich gibt es auch ein paar Punkte, die mit Potlatch… oder iD… beginnen). Also an einem Editor-War möchte ich mich nicht beteiligen. Es gibt keinen stichhaltigen Grund, warum Kreisverkehre so besonders sind. Doch sicher. Bei Relationen, bei denen sich die Gebrauchsrichtung aus der Abfolge der Member ergibt, ist der benutzte Teil des Kreisverkehrs auch ohne Splitting eindeutig identifizierbar. Das ist eine Besonderheit. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Tirkon wrote In ID ist es durch die umringenden Icons jetzt für Anfänger noch einfacher als in Potlatch, versehentlich etwas zu löschen Die Kritik an den nahen gefährlichen Icons bleibt nach den bisherigen Rückmeldungen bestehen. Ich sehe da nur die Alternative, sie an weniger exponierter Stelle anzuordnen. +1 Ich finde es auch sehr ungeschickt, destruktive Operationen wie Löschen oder auch Rund machen auf oberster Ebene anzubieten. Ganz besonders bei einem Editor der sich an Anfänger richten soll. Allerdings dürfte es sich dabei um eine bewußte Designentscheidung handeln. :-( bye, Nop -- View this message in context: http://gis.19327.n5.nabble.com/ID-Editor-zerstort-mit-einem-Klick-tagelange-Arbeit-tp5760346p5760595.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hallo Wilhelm, Am Samstag, 11. Mai 2013, 18:46:24 schrieb Wilhelm Spickermann: Interessanterweise beginnen alle diese Punkte mit JOSM… (wahrscheinlich gibt es auch ein paar Punkte, die mit Potlatch… oder iD… beginnen). Also an einem Editor-War möchte ich mich nicht beteiligen. Ich mich auch nicht, ich wollte nur erklären, dass die Liste nicht vollständig war, sondern eher mein Nutzungsverhalten widerspiegelt. Es gibt keinen stichhaltigen Grund, warum Kreisverkehre so besonders sind. Doch sicher. Bei Relationen, bei denen sich die Gebrauchsrichtung aus der Abfolge der Member ergibt, ist der benutzte Teil des Kreisverkehrs auch ohne Splitting eindeutig identifizierbar. Das ist eine Besonderheit. Das Argument lässt sich genauso auf eine Route A - B - C anwenden, bei der nur eine Teilstrecke von B verwendet wird. Auch wenn ich weiß, welches Teilstück von B verwendet wird, sollte ich B trotzdem passend auftrennen. Genau die gleiche Situation. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hallo Ruben, Am Samstag, 11. Mai 2013, 18:26:38 schrieb Ruben Kelevra: Am Sat, May 11, 2013 at 5:42 PM schrieb Eckhart Wörner ewoer...@kde.org: c) JOSM kann immer noch nicht mehrere Ways im Kreis anordnen Nicht ganz richtig, man muss blos manuell alle Nodes markieren, dann gehts. sorry, ich wollte sagen: JOSM kann immer noch nicht *direkt* mehrere Ways im Kreis anordnen. (Alternative: Wege markieren, dann nach child (selected) suchen, und dann die Knoten anordnen.) Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Sun, 12 May 2013 00:10:09 +0200 schrieb Eckhart Wörner ewoer...@kde.org: Das Argument lässt sich genauso auf eine Route A - B - C anwenden, bei der nur eine Teilstrecke von B verwendet wird. Auch wenn ich weiß, welches Teilstück von B verwendet wird, sollte ich B trotzdem passend auftrennen. Genau die gleiche Situation. Ja, das sehe ich ein. Allerdings würde -- da man das Argument auch auf A und C anwenden könnte -- das Ganze hinterher sehr unübersichtlich und fehleranfällig. Aber ich muss Dir zustimmen, dass diese Praxis eher historisch gewachsen als gut begründet ist. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 10.05.2013 00:13, schrieb Tirkon: Auch ich habe anfänglich mit Potlatch Einiges unbeabichtigt zerstört. Hier selbiges. Dessen wurde ich aber erst gewahr, nachdem ich darauf hingewiesen wurde. Da ich hier im Ort praktisch nahezu alleine unterwegs bin, gibt es auch niemanden, der mich auf Fehler hinweist oder je hingewiesen hätte. Ok, es gibt einen Haufen Tools, die Fehler oder Unklarheiten anzeigen können, aber die muß man auch erstmal alle finden. Sowas wie ein Design Rule Check sollte in jedem Editor eingebaut sein. Es ist doch ein Witz, daß externe Tools nötig sind, um typische Fehler, wie z.B. dicht nebeneinanderliegende, aber nicht verbundene Wege zu finden oder unvollständige Abbiegerelationen. Erst nach dem empfohlenen Umstieg auf JOSM verstand ich und fand mich in der Historie als Verursacher von weiteren gefundenen Relationszerstörungen. Es wäre schön, wenn der Umstieg auf JOSM hierzu zukünftig nicht mehr zwingend erforderlich wäre. +1 Ich glaube, daß ich inzwischen als eingefleischter Potlatcher nicht mehr viel kaputtmache, aber daß es damit immer noch und jetzt mit dem ID erneut möglich ist, unbemerkt komplexere Strukturen zu zersemmeln, ist auf Dauer nicht tragbar. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 10.05.2013 07:08, schrieb Wilhelm Spickermann: Ein drittes Splittingproblem gibt es bei den Kreisverkehren. Wenn ein Kreisverkehr Element einer Route ist, dann ist damit nur benötigte Teil des Kreisverkehrs gemeint. Splittet man ihn auf, dann gilt diese Sonderregel nicht mehr und man muss nicht zugehörige Teile wegwerfen und die anderen Teile sinnvoll umsortieren. Noch schlimmer: man muss alle anderen betroffenen Relation ebenso laden, den Kreisverkehr ggf. weiter splitten und bei allen nachkorrigieren. Das unterstützt keiner der Editoren. Ich habe mich mal mit dem Potlatch an solch einen Kreisverkehr gewagt, über den mehrere Buslinien und Radwegrelationen gehen mit unterschiedlichen Ein- und Ausgängen und forward/backward usw. Daran kann man, wenn man keine Routine hat, anscheinend stundenlang sitzen, bis das alles plausibel zusammenpaßt... Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Tirkon schrieb: [keine Warnung beim Umkehren von Wegen, keine Warnung beim Löschen von Relationsmitgliedern...] Nach dem Lesen dieses Threads schrieb ich im IRC versehentlich in #osm statt in #osm-de, wodurch eine Diskussion zustande kam. Mit jfire war auch einer der Programmierer dabei. Er und auch iandees sind eher der Ansicht, dass Warnhinweise die User abschrecken und man solche Warnungen deshalb besser weglässt. Beim Umkehren von natural=coastline will jfire offenbar eine Schutzfunktion implementieren. Warnhinweise beim (versehentlichen) Umdrehen von Einbahnstraßen oder Wasserwegen scheinen dagegen nicht geplant oder erwünscht. Das Tastaturkürzel zum Umkehren der Wegrichtung ist V, das auf der Tastatur in der Regel neben B liegt - dem Kürzel für den Hintergrund - Luftbilder und Co. Relationen: Es ist geplant, Relationen gut sichtbar zu machen, damit die Nutzer sie wahrnehmen. Wenn dann ein Mitglied einer Abbiegebeschränkung gelöscht wird, soll die gesamte Relation entfernt werden. Wer es genau nachlesen möchte, findet das IRC-Log hier: http://malenki.ch/OSM/irc_osm_-_id_reverse_ways_warn.txt hth Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
2013/5/11 malenki o...@malenki.ch Tirkon schrieb: [keine Warnung beim Umkehren von Wegen, keine Warnung beim Löschen von Relationsmitgliedern...] Nach dem Lesen dieses Threads schrieb ich im IRC versehentlich in #osm statt in #osm-de, wodurch eine Diskussion zustande kam. Mit jfire war auch einer der Programmierer dabei. Er und auch iandees sind eher der Ansicht, dass Warnhinweise die User abschrecken und man solche Warnungen deshalb besser weglässt. Beim Umkehren von natural=coastline will jfire offenbar eine Schutzfunktion implementieren. Warnhinweise beim (versehentlichen) Umdrehen von Einbahnstraßen oder Wasserwegen scheinen dagegen nicht geplant oder erwünscht. Das Tastaturkürzel zum Umkehren der Wegrichtung ist V, das auf der Tastatur in der Regel neben B liegt - dem Kürzel für den Hintergrund - Luftbilder und Co. Relationen: Es ist geplant, Relationen gut sichtbar zu machen, damit die Nutzer sie wahrnehmen. Wenn dann ein Mitglied einer Abbiegebeschränkung gelöscht wird, soll die gesamte Relation entfernt werden. Wer es genau nachlesen möchte, findet das IRC-Log hier: http://malenki.ch/OSM/irc_osm_-_id_reverse_ways_warn.txt hth Thomas Vielleicht werden die mehr fortgeschrittene Mapper ab jetzt alles doppeltredundant eintragen müssen. Eine Relation und dann noch welche Tags um an zu geben: hier gibt es eine Relation, wenn die Relation nicht mehr da ist, bitte neuerstellen. Schade das mit so wenig Respekt mit unsere Beitragen umgehen wird. Polyglot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
On 09.05.2013 16:17, Tirkon wrote: Ersteinmal Danke für den neuen Editor. Ich habe wegen meiner Kritik an Potlatch schon vor einiger Zeit von Richard einen Rüffel einstecken müssen. Ich habe daher um des Friedens willen das Ganze auf sich beruhen lassen. Der ID-Editor verschärft dieses Problem IMHO jetzt nochmals. Eines vorab: Ich schätze Richards großen Einsatz für OSM. Aber was die Meinung über die Sicherheitsmaßnahmen in Editoren gegen unbeabsichtigte Zerstörungen an der Datenbank angeht, gehen die Meinungen auseinander. Daher bitte ich um Drittmeinungen: In ID ist es durch die umringenden Icons jetzt für Anfänger noch einfacher als in Potlatch, versehentlich etwas zu löschen oder die Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich, um ein kilometerweites Netz abzufahren und maxspeed detailliert zu dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut abzufahren? Auch bei Relationen kommt keinerlei Warnung bei Löschen eines Teilstückes. Auch hier: Es kostet große Mühen, eine lange Fahrradroute, Grenze oder gar Europastrasse in eine Relation zu bekommen. Hier wird stunden- oder tagelange Arbeit mit einem Klick kommentarlos zerstört. Auch diese Fehler sind für Andere kaum wahrnehmbar. Das Ganze wird mit dem Argument getan, dass man Anfängern entsprechende Fehlermeldungen nicht zumuten kann. So etwas demotiviert Mapper, die sich dem Maintaining eines Bereiches verschrieben haben - insbesondere dann, wenn sie auf mehrere zig Quadratkilometer die einzigen dauerhaften Mapper sind. +10 Ich warte auch schon lange auf Änderungen in potlatch(2), wenn jetzt auch noch iD mit ähnlichen Problemen auftaucht ist das um so frustrierender. Bitte keine Veränderung von Objekten ohne Korrektes Verhalten in Bezug auf Relationen. Dies gilt vorallem für Löschen und Richtungsänderungen aber auch Aufteilen ist problematisch. Im Zweifelsfall braucht man halt doch einen anständigen Relationseditor oder man darf solche Operation nicht erlauben. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi. Das Problem ist wohl noch niemandem bei iD aufgefallen vor dir - oder niemand - dich eingeschlossen - hat es als Fehler erkannt und den Entwicklern mitgeteilt. Ich hab das mal für dich (..., uns und alle anderen Mapper) gemacht: https://github.com/systemed/iD/issues/1458 Diese Fehler zu finden nachträglich, wenn sie durch irgendjemanden mal gemacht wurden, dürfte schwierig sein - wenn nicht jemand eine Auswertung darüber fährt (in Changesets erkennen, wenn die node-reihenfolge eines Weges umgekehrt worden ist). Was Relationen angeht: Multipolygone werden direkt unterstützt - allerdings gibt es keinen Hinweis darauf, wenn man nur auf den Umriss klickt, man muss auf die Fläche klicken. Wie das bei anderen Relationstypen aussieht, hab ich jetzt aber auch noch nicht ausprobiert. Gruß Peter Am 09.05.2013 16:17, schrieb Tirkon: Ich habe wegen meiner Kritik an Potlatch schon vor einiger Zeit von Richard einen Rüffel einstecken müssen. Ich habe daher um des Friedens willen das Ganze auf sich beruhen lassen. Der ID-Editor verschärft dieses Problem IMHO jetzt nochmals. Eines vorab: Ich schätze Richards großen Einsatz für OSM. Aber was die Meinung über die Sicherheitsmaßnahmen in Editoren gegen unbeabsichtigte Zerstörungen an der Datenbank angeht, gehen die Meinungen auseinander. Daher bitte ich um Drittmeinungen: In ID ist es durch die umringenden Icons jetzt für Anfänger noch einfacher als in Potlatch, versehentlich etwas zu löschen oder die Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich, um ein kilometerweites Netz abzufahren und maxspeed detailliert zu dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut abzufahren? Auch bei Relationen kommt keinerlei Warnung bei Löschen eines Teilstückes. Auch hier: Es kostet große Mühen, eine lange Fahrradroute, Grenze oder gar Europastrasse in eine Relation zu bekommen. Hier wird stunden- oder tagelange Arbeit mit einem Klick kommentarlos zerstört. Auch diese Fehler sind für Andere kaum wahrnehmbar. Das Ganze wird mit dem Argument getan, dass man Anfängern entsprechende Fehlermeldungen nicht zumuten kann. So etwas demotiviert Mapper, die sich dem Maintaining eines Bereiches verschrieben haben - insbesondere dann, wenn sie auf mehrere zig Quadratkilometer die einzigen dauerhaften Mapper sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Es gibt dazu schon einen uraltes Ticket von mir https://github.com/systemed/iD/issues/299 Das Problem war und ist also bekannt. Simon Am 09.05.2013 16:58, schrieb Peter Wendorff: Hi. Das Problem ist wohl noch niemandem bei iD aufgefallen vor dir - oder niemand - dich eingeschlossen - hat es als Fehler erkannt und den Entwicklern mitgeteilt. Ich hab das mal für dich (..., uns und alle anderen Mapper) gemacht: https://github.com/systemed/iD/issues/1458 Diese Fehler zu finden nachträglich, wenn sie durch irgendjemanden mal gemacht wurden, dürfte schwierig sein - wenn nicht jemand eine Auswertung darüber fährt (in Changesets erkennen, wenn die node-reihenfolge eines Weges umgekehrt worden ist). Was Relationen angeht: Multipolygone werden direkt unterstützt - allerdings gibt es keinen Hinweis darauf, wenn man nur auf den Umriss klickt, man muss auf die Fläche klicken. Wie das bei anderen Relationstypen aussieht, hab ich jetzt aber auch noch nicht ausprobiert. Gruß Peter Am 09.05.2013 16:17, schrieb Tirkon: Ich habe wegen meiner Kritik an Potlatch schon vor einiger Zeit von Richard einen Rüffel einstecken müssen. Ich habe daher um des Friedens willen das Ganze auf sich beruhen lassen. Der ID-Editor verschärft dieses Problem IMHO jetzt nochmals. Eines vorab: Ich schätze Richards großen Einsatz für OSM. Aber was die Meinung über die Sicherheitsmaßnahmen in Editoren gegen unbeabsichtigte Zerstörungen an der Datenbank angeht, gehen die Meinungen auseinander. Daher bitte ich um Drittmeinungen: In ID ist es durch die umringenden Icons jetzt für Anfänger noch einfacher als in Potlatch, versehentlich etwas zu löschen oder die Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich, um ein kilometerweites Netz abzufahren und maxspeed detailliert zu dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut abzufahren? Auch bei Relationen kommt keinerlei Warnung bei Löschen eines Teilstückes. Auch hier: Es kostet große Mühen, eine lange Fahrradroute, Grenze oder gar Europastrasse in eine Relation zu bekommen. Hier wird stunden- oder tagelange Arbeit mit einem Klick kommentarlos zerstört. Auch diese Fehler sind für Andere kaum wahrnehmbar. Das Ganze wird mit dem Argument getan, dass man Anfängern entsprechende Fehlermeldungen nicht zumuten kann. So etwas demotiviert Mapper, die sich dem Maintaining eines Bereiches verschrieben haben - insbesondere dann, wenn sie auf mehrere zig Quadratkilometer die einzigen dauerhaften Mapper sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Tirkon oder Simon - Könntet ihr dazu ein ticket auf iD verfassen? Offensichtlich wurde das Problem von John in dem ticket das Simon linkt nicht ganz verstanden oder es handelt sich hier einfach um ein anderes Problem. Jedenfalls wäre jeder input um iD robuster zu machen sehr willkommen. Danke! 2013/5/9 Simon Poole si...@poole.ch Es gibt dazu schon einen uraltes Ticket von mir https://github.com/systemed/iD/issues/299 Das Problem war und ist also bekannt. Simon Am 09.05.2013 16:58, schrieb Peter Wendorff: Hi. Das Problem ist wohl noch niemandem bei iD aufgefallen vor dir - oder niemand - dich eingeschlossen - hat es als Fehler erkannt und den Entwicklern mitgeteilt. Ich hab das mal für dich (..., uns und alle anderen Mapper) gemacht: https://github.com/systemed/iD/issues/1458 Diese Fehler zu finden nachträglich, wenn sie durch irgendjemanden mal gemacht wurden, dürfte schwierig sein - wenn nicht jemand eine Auswertung darüber fährt (in Changesets erkennen, wenn die node-reihenfolge eines Weges umgekehrt worden ist). Was Relationen angeht: Multipolygone werden direkt unterstützt - allerdings gibt es keinen Hinweis darauf, wenn man nur auf den Umriss klickt, man muss auf die Fläche klicken. Wie das bei anderen Relationstypen aussieht, hab ich jetzt aber auch noch nicht ausprobiert. Gruß Peter Am 09.05.2013 16:17, schrieb Tirkon: Ich habe wegen meiner Kritik an Potlatch schon vor einiger Zeit von Richard einen Rüffel einstecken müssen. Ich habe daher um des Friedens willen das Ganze auf sich beruhen lassen. Der ID-Editor verschärft dieses Problem IMHO jetzt nochmals. Eines vorab: Ich schätze Richards großen Einsatz für OSM. Aber was die Meinung über die Sicherheitsmaßnahmen in Editoren gegen unbeabsichtigte Zerstörungen an der Datenbank angeht, gehen die Meinungen auseinander. Daher bitte ich um Drittmeinungen: In ID ist es durch die umringenden Icons jetzt für Anfänger noch einfacher als in Potlatch, versehentlich etwas zu löschen oder die Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich, um ein kilometerweites Netz abzufahren und maxspeed detailliert zu dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut abzufahren? Auch bei Relationen kommt keinerlei Warnung bei Löschen eines Teilstückes. Auch hier: Es kostet große Mühen, eine lange Fahrradroute, Grenze oder gar Europastrasse in eine Relation zu bekommen. Hier wird stunden- oder tagelange Arbeit mit einem Klick kommentarlos zerstört. Auch diese Fehler sind für Andere kaum wahrnehmbar. Das Ganze wird mit dem Argument getan, dass man Anfängern entsprechende Fehlermeldungen nicht zumuten kann. So etwas demotiviert Mapper, die sich dem Maintaining eines Bereiches verschrieben haben - insbesondere dann, wenn sie auf mehrere zig Quadratkilometer die einzigen dauerhaften Mapper sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Ich hatte es damals mit ein paar Beispielen getestet und es schien OK, hab jetzt mal 1.0.0 mit cycleway:right getestet, iD ändert das korrekt in cycleway:left um. Die grundsätzliche Funktionalität scheint also da zu sein, vielleicht kann tirkon sonst ein Beispiel liefern das nicht wie erwartet tut. Simon Am 09.05.2013 17:28, schrieb Alex Barth: Tirkon oder Simon - Könntet ihr dazu ein ticket auf iD verfassen? Offensichtlich wurde das Problem von John in dem ticket das Simon linkt nicht ganz verstanden oder es handelt sich hier einfach um ein anderes Problem. Jedenfalls wäre jeder input um iD robuster zu machen sehr willkommen. Danke! 2013/5/9 Simon Poole si...@poole.ch Es gibt dazu schon einen uraltes Ticket von mir https://github.com/systemed/iD/issues/299 Das Problem war und ist also bekannt. Simon Am 09.05.2013 16:58, schrieb Peter Wendorff: Hi. Das Problem ist wohl noch niemandem bei iD aufgefallen vor dir - oder niemand - dich eingeschlossen - hat es als Fehler erkannt und den Entwicklern mitgeteilt. Ich hab das mal für dich (..., uns und alle anderen Mapper) gemacht: https://github.com/systemed/iD/issues/1458 Diese Fehler zu finden nachträglich, wenn sie durch irgendjemanden mal gemacht wurden, dürfte schwierig sein - wenn nicht jemand eine Auswertung darüber fährt (in Changesets erkennen, wenn die node-reihenfolge eines Weges umgekehrt worden ist). Was Relationen angeht: Multipolygone werden direkt unterstützt - allerdings gibt es keinen Hinweis darauf, wenn man nur auf den Umriss klickt, man muss auf die Fläche klicken. Wie das bei anderen Relationstypen aussieht, hab ich jetzt aber auch noch nicht ausprobiert. Gruß Peter Am 09.05.2013 16:17, schrieb Tirkon: Ich habe wegen meiner Kritik an Potlatch schon vor einiger Zeit von Richard einen Rüffel einstecken müssen. Ich habe daher um des Friedens willen das Ganze auf sich beruhen lassen. Der ID-Editor verschärft dieses Problem IMHO jetzt nochmals. Eines vorab: Ich schätze Richards großen Einsatz für OSM. Aber was die Meinung über die Sicherheitsmaßnahmen in Editoren gegen unbeabsichtigte Zerstörungen an der Datenbank angeht, gehen die Meinungen auseinander. Daher bitte ich um Drittmeinungen: In ID ist es durch die umringenden Icons jetzt für Anfänger noch einfacher als in Potlatch, versehentlich etwas zu löschen oder die Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich, um ein kilometerweites Netz abzufahren und maxspeed detailliert zu dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut abzufahren? Auch bei Relationen kommt keinerlei Warnung bei Löschen eines Teilstückes. Auch hier: Es kostet große Mühen, eine lange Fahrradroute, Grenze oder gar Europastrasse in eine Relation zu bekommen. Hier wird stunden- oder tagelange Arbeit mit einem Klick kommentarlos zerstört. Auch diese Fehler sind für Andere kaum wahrnehmbar. Das Ganze wird mit dem Argument getan, dass man Anfängern entsprechende Fehlermeldungen nicht zumuten kann. So etwas demotiviert Mapper, die sich dem Maintaining eines Bereiches verschrieben haben - insbesondere dann, wenn sie auf mehrere zig Quadratkilometer die einzigen dauerhaften Mapper sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Ich habe auch mal versucht ein Memberway der zu 2 route Relationen gehört zu löschen und das ist tatsäglich möglich, und sogar ohne Botschaft das etwas kaputgemacht wird. Dann auch mal mit PL2 versucht und der macht dasselbe Unglaublich. Sowas kann ich nicht verstehen. Polyglot 2013/5/9 Alex Barth a...@mapbox.com Tirkon oder Simon - Könntet ihr dazu ein ticket auf iD verfassen? Offensichtlich wurde das Problem von John in dem ticket das Simon linkt nicht ganz verstanden oder es handelt sich hier einfach um ein anderes Problem. Jedenfalls wäre jeder input um iD robuster zu machen sehr willkommen. Danke! 2013/5/9 Simon Poole si...@poole.ch Es gibt dazu schon einen uraltes Ticket von mir https://github.com/systemed/iD/issues/299 Das Problem war und ist also bekannt. Simon Am 09.05.2013 16:58, schrieb Peter Wendorff: Hi. Das Problem ist wohl noch niemandem bei iD aufgefallen vor dir - oder niemand - dich eingeschlossen - hat es als Fehler erkannt und den Entwicklern mitgeteilt. Ich hab das mal für dich (..., uns und alle anderen Mapper) gemacht: https://github.com/systemed/iD/issues/1458 Diese Fehler zu finden nachträglich, wenn sie durch irgendjemanden mal gemacht wurden, dürfte schwierig sein - wenn nicht jemand eine Auswertung darüber fährt (in Changesets erkennen, wenn die node-reihenfolge eines Weges umgekehrt worden ist). Was Relationen angeht: Multipolygone werden direkt unterstützt - allerdings gibt es keinen Hinweis darauf, wenn man nur auf den Umriss klickt, man muss auf die Fläche klicken. Wie das bei anderen Relationstypen aussieht, hab ich jetzt aber auch noch nicht ausprobiert. Gruß Peter Am 09.05.2013 16:17, schrieb Tirkon: Ich habe wegen meiner Kritik an Potlatch schon vor einiger Zeit von Richard einen Rüffel einstecken müssen. Ich habe daher um des Friedens willen das Ganze auf sich beruhen lassen. Der ID-Editor verschärft dieses Problem IMHO jetzt nochmals. Eines vorab: Ich schätze Richards großen Einsatz für OSM. Aber was die Meinung über die Sicherheitsmaßnahmen in Editoren gegen unbeabsichtigte Zerstörungen an der Datenbank angeht, gehen die Meinungen auseinander. Daher bitte ich um Drittmeinungen: In ID ist es durch die umringenden Icons jetzt für Anfänger noch einfacher als in Potlatch, versehentlich etwas zu löschen oder die Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward und backward Angaben. Diese Fehler sind zudem z.B. für maxspeed nur durch intensivste Analyse und eigentlich nur durch vor-Ort Recherche wahrnehmbar und korrigierbar. Da nimmt man Arbeit und Kosten auf sich, um ein kilometerweites Netz abzufahren und maxspeed detailliert zu dokumentieren - und dann so ein Editor. Wisst ihr einen anderen Weg für den Mapper, solche Umkehrfehler wahrzunehmen, ohne das Netz erneut abzufahren? Auch bei Relationen kommt keinerlei Warnung bei Löschen eines Teilstückes. Auch hier: Es kostet große Mühen, eine lange Fahrradroute, Grenze oder gar Europastrasse in eine Relation zu bekommen. Hier wird stunden- oder tagelange Arbeit mit einem Klick kommentarlos zerstört. Auch diese Fehler sind für Andere kaum wahrnehmbar. Das Ganze wird mit dem Argument getan, dass man Anfängern entsprechende Fehlermeldungen nicht zumuten kann. So etwas demotiviert Mapper, die sich dem Maintaining eines Bereiches verschrieben haben - insbesondere dann, wenn sie auf mehrere zig Quadratkilometer die einzigen dauerhaften Mapper sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Thu, 9 May 2013 17:52:36 +0200 schrieb Jo winfi...@gmail.com: Ich habe auch mal versucht ein Memberway der zu 2 route Relationen gehört zu löschen und das ist tatsäglich möglich, und sogar ohne Botschaft das etwas kaputgemacht wird. Dann auch mal mit PL2 versucht und der macht dasselbe Na ja, wenn der Weg nicht mehr da ist, dann ist in der Route auch in der Realität ein Loch ... darüber könnte man noch diskutieren. Klar wäre der Fall, wenn es nach dem Löschen eines Weges z.B. zweielementige Abbiegerelationen gäbe. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Vielen Dank für Eure Reaktionen. Damit ist einer der Punkte erledigt. Im Einzelnen: Tirkon tirko...@yahoo.de wrote: In ID ist es durch die umringenden Icons jetzt für Anfänger noch einfacher als in Potlatch, versehentlich etwas zu löschen Die Kritik an den nahen gefährlichen Icons bleibt nach den bisherigen Rückmeldungen bestehen. Ich sehe da nur die Alternative, sie an weniger exponierter Stelle anzuordnen. oder die Fahrtrichtung umzudrehen - mit entsprechenden Folgen für alle forward und backward Angaben. Das kann als erledigt angesehen werden. Offenbar werden hieraus resultierende Restfehler bei Eintrag in die Bugliste berücksichtigt. Auch bei Relationen kommt keinerlei Warnung bei Löschen eines Teilstückes. Hier scheint es den Reaktionen nach tatsächlich noch Nachholbedarf zu geben. Es muss noch einmal tiefergehend recherchiert werden, ob Relationen neben dem Löschen von Teilstücken auch durch andere Aktionen ohne Warnung zerstört werden. Zudem wurde hier noch das Splitting genannt. Wo da genau das Problem mit ID bzw. Potlatch liegt, habe ich allerdings noch nicht ergründet. Möglicherweise wäre eine Kontaktaufnahme der ID-Programmierer mit denen von JOSM sinnvoll. Denn Letztere haben die Juckelpunkte um Relationen schon erkannt und behoben bzw. sprechen entsprechende Warnungen aus. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Wilhelm Spickermann o...@spickermann-d.de wrote: Na ja, wenn der Weg nicht mehr da ist, dann ist in der Route auch in der Realität ein Loch ... darüber könnte man noch diskutieren. Häufig wird nicht deswegen gelöscht, weil etwas nicht mehr existiert, sondern beispielsweise eine Kreuzung auf die in der Realität existierende Richtungsfahrbahntrennung umgestellt wird. Es gibt viele Beispiele, wo das Bearbeiten durch Löschen eines Weges stattfinden kann, wo es eigentlich nicht erforderlich wäre. Es stört aber auch nicht, solange man Ortskenntnis hat und keine Relationen beteiligt sind. Anfänger löschen auch mal gerne einen ganzen Straßenzug, um ihn dann korrigiert neu zu erstellen. Dass dabei die Historie zum Teufel geht, ist wohl ein notwendiges Übel, eine Relationszerstörung hingegen nicht. Ohne Warnung vor Relationszerstörung kommt der Bearbeitende und insbesondere der Anfänger nicht auf die Idee, sich um andere Methoden des Editierens zu bemühen, die ein Löschen eines Weges nicht erfordern. Ohne Warnung kommt er nicht auf die Idee, dass da etwas nach Abschluss des beabsichtigten Editierens zu reparieren wäre. Auch ich habe anfänglich mit Potlatch Einiges unbeabichtigt zerstört. Dessen wurde ich aber erst gewahr, nachdem ich darauf hingewiesen wurde. Erst nach dem empfohlenen Umstieg auf JOSM verstand ich und fand mich in der Historie als Verursacher von weiteren gefundenen Relationszerstörungen. Es wäre schön, wenn der Umstieg auf JOSM hierzu zukünftig nicht mehr zwingend erforderlich wäre. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Ich sehe das ähnlich wie du, keiner der zerstörerischen Änderungen die ich je korrigiert hab wurde mit JOSM erstellt. Lg Ruben Am 10.05.2013 00:14 schrieb Tirkon tirko...@yahoo.de: Wilhelm Spickermann o...@spickermann-d.de wrote: Na ja, wenn der Weg nicht mehr da ist, dann ist in der Route auch in der Realität ein Loch ... darüber könnte man noch diskutieren. Häufig wird nicht deswegen gelöscht, weil etwas nicht mehr existiert, sondern beispielsweise eine Kreuzung auf die in der Realität existierende Richtungsfahrbahntrennung umgestellt wird. Es gibt viele Beispiele, wo das Bearbeiten durch Löschen eines Weges stattfinden kann, wo es eigentlich nicht erforderlich wäre. Es stört aber auch nicht, solange man Ortskenntnis hat und keine Relationen beteiligt sind. Anfänger löschen auch mal gerne einen ganzen Straßenzug, um ihn dann korrigiert neu zu erstellen. Dass dabei die Historie zum Teufel geht, ist wohl ein notwendiges Übel, eine Relationszerstörung hingegen nicht. Ohne Warnung vor Relationszerstörung kommt der Bearbeitende und insbesondere der Anfänger nicht auf die Idee, sich um andere Methoden des Editierens zu bemühen, die ein Löschen eines Weges nicht erfordern. Ohne Warnung kommt er nicht auf die Idee, dass da etwas nach Abschluss des beabsichtigten Editierens zu reparieren wäre. Auch ich habe anfänglich mit Potlatch Einiges unbeabichtigt zerstört. Dessen wurde ich aber erst gewahr, nachdem ich darauf hingewiesen wurde. Erst nach dem empfohlenen Umstieg auf JOSM verstand ich und fand mich in der Historie als Verursacher von weiteren gefundenen Relationszerstörungen. Es wäre schön, wenn der Umstieg auf JOSM hierzu zukünftig nicht mehr zwingend erforderlich wäre. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Thu, 09 May 2013 23:12:36 +0200 schrieb Tirkon tirko...@yahoo.de: Zudem wurde hier noch das Splitting genannt. Wo da genau das Problem mit ID bzw. Potlatch liegt, habe ich allerdings noch nicht ergründet. Möglicherweise wäre eine Kontaktaufnahme der ID-Programmierer mit denen von JOSM sinnvoll. Denn Letztere haben die Juckelpunkte um Relationen schon erkannt und behoben bzw. sprechen entsprechende Warnungen aus. Es gibt mehrere Splittingprobleme und man findet sie teilweise auch im JOSM. Ein im JOSM m.W. gelöstes Splittingproblem gibt es bei den Abbiegerelationen. Nur einer der beiden Teile des aufgeteilten Weges sollte in der Relation bleiben. Ein weiteres Splittingproblem haben wir bei den Relationen mit bedeutungsvoller Reihenfolge, also z.B. bei Routen nach dem Public Traffic Proposal. Hier wird die Durchfahrtrichtung nicht mit forward oder backward oder (=bidirektional) angegeben, sondern durch die Reihenfolge der Mitglieder in jeder Variante. Hier tritt z.B. in der einen Relation die Wegreihenfolge A,B,C auf und in einer anderen C,B,A. Spaltet man B auf, dann kann man es nicht einfach überall durch B1,B2 ersetzen, denn wenn A,B1,B2,C richtig ist, dann ist C,B1,B2,A falsch. Da muss dann C,B2,B1,A hin. Das macht der Potlatch falsch und der JOSM macht es nur dann richtig, wenn er die Elemente A und/oder C geladen hat. (Gewöhnt man sich als JOSM-Benutzer an, vor dem Splitten immer eine beliebig kleine Umgebung der Endpunkte des zu splittenden Weges zu laden, dann gibt es keine Probleme.) Ein drittes Splittingproblem gibt es bei den Kreisverkehren. Wenn ein Kreisverkehr Element einer Route ist, dann ist damit nur benötigte Teil des Kreisverkehrs gemeint. Splittet man ihn auf, dann gilt diese Sonderregel nicht mehr und man muss nicht zugehörige Teile wegwerfen und die anderen Teile sinnvoll umsortieren. Noch schlimmer: man muss alle anderen betroffenen Relation ebenso laden, den Kreisverkehr ggf. weiter splitten und bei allen nachkorrigieren. Das unterstützt keiner der Editoren. (Ich halte es meist für Quatsch Kreisverkehre zu splitten, aber es gibt andere Ansichten/Situationen und wenn man da splittet, dann gibt es dieses Problem.) Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Fri, 10 May 2013 07:08:32 +0200 schrieb Wilhelm Spickermann o...@spickermann-d.de: Ein drittes Splittingproblem... Ich hab noch eines vergessen: Ein viertes Splittingproblem haben wir bei in sich geschlossenen Wegen mit einem Flächentag. Wenn man hier hier aufspaltet, braucht man ein Multipolygon. Da unterstützt m.W. kein Editor. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
