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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
Ü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
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
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
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
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
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
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
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
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
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
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 finde auch, dass unnötige Warnungen für Anfänger eher abschreckend
sind, aber beim Löschen von Elementen, die Teil einer Relation sind, MUSS
es meiner Meinung nach eine Warnmeldung geben. Gerade weil Anfänger (öfters
als erfahrene Mapper) etwas löschen und dann neuzeichnen anstatt es nur zu
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
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:
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
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
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
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
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
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
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
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
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
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
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
___
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
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
___
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.
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
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.
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
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
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
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,
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,
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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!
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
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
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
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
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
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
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
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
95 matches
Mail list logo
