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 wrote:
>Es wird vermutlich eher selten
Am Thu, 16 May 2013 14:53:16 +0200
schrieb Michael Buege :
> > 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 nic
Zitat Wilhelm Spickermann:
> Am Thu, 16 May 2013 13:37:12 +0200
> 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, ab
Hi,
Am Thu, 16 May 2013 13:37:12 +0200
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
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 mac
Am 16. Mai 2013 13:26 schrieb Wilhelm Spickermann :
> 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 an
Hi,
Am Thu, 16 May 2013 12:43:30 +0200
schrieb Henning Scholland :
> 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 Zusatzta
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 zumi
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 Spickerm
Am 16. Mai 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
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/
Am 16. Mai 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 ric
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)
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 Tagname
Hi,
Am Thu, 16 May 2013 09:56:57 +0200
schrieb Simon Poole :
> 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
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
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
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
___
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
Hi,
Am Thu, 16 May 2013 09:56:57 +0200
schrieb Simon Poole :
> 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-d
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
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.co
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äc
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 (ka
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
ver
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
Am 14.05.2013 13:22 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
Am 14. Mai 2013 13:21 schrieb Wolfgang Hinsch :
> 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 u
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,
Hallo,
Am Dienstag, den 14.05.2013, 12:08 +0200 schrieb Martin Koppenhoefer:
> Am 14. Mai 2013 12:03 schrieb Florian Lohoff :
>
> > 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 cod
Am 14. Mai 2013 12:03 schrieb Florian Lohoff :
> 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 zuges
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.
Hi,
Am Tue, 14 May 2013 10:22:59 +0200
schrieb Henning Scholland :
> 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
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 :
Bspw. wenn ich einen Teil des
Umrisses eines Waldes parallel verschieben möchte, um
Hi,
Am Tue, 14 May 2013 08:42:42 +0200
schrieb Henning Scholland :
> 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 Erzeug
> Ü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
> Bearbeit
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.
Henni
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@ope
Am Fri, 10 May 2013 07:08:32 +0200
schrieb Wilhelm Spickermann :
> 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öhnl
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:4
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 i
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 ka
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, sc
Am 13.05.2013, 17:03 Uhr, schrieb Ruben Kelevra :
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 v
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 Info
Am 13. Mai 2013 15:45 schrieb Martin Koppenhoefer :
>
> 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
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üh
Fehlt nur noch eine Lösung für das kombinieren von Wegen.
Lg Ruben
Am 13.05.2013 16:59 schrieb "Martin Raifer" :
> Am 13.05.2013, 16:28 Uhr, schrieb Simon Poole :
>
> [...] lassen als Lösung nur zu dem Benutzer mitzuteilen: "Kannst du
>> nicht machen" oder "Wenn du das machst, machst du was kapu
Am 13.05.2013, 16:28 Uhr, schrieb Simon Poole :
[...] 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:
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
___
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 Cosdtline
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
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
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 onew
Am 13. Mai 2013 16:29 schrieb Martin Raifer :
>
>
> 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
Am 13.05.2013 14:10 schrieb "fly" :
> 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
___
Am 13.05.2013, 16:10 Uhr, schrieb Simon Poole :
natural=cliff
natural=coastline
barrier=retaining_wall
man_made=embankment
Am 13.05.2013, 16:18 Uhr, schrieb Martin Koppenhoefer
:
barrier=city_wall gehört z.B. auch dazu.
...aber nur wenn two_sided=yes nicht gesetzt ist. Außerdem können
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 ko
On 13/mag/2013, at 16:10, Simon Poole 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
__
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_
2013/5/13 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
>
> 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
> */
>
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 h
On 11.05.2013 07:02, Jo wrote:
> 2013/5/11 malenki
>
>> 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 Diskuss
Hi,
Am Sun, 12 May 2013 00:10:09 +0200
schrieb Eckhart Wörner :
> 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. Gen
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 :
> > 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:
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 beteilige
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 expon
Hi,
Am Sat, 11 May 2013 17:42:32 +0200
schrieb Eckhart Wörner :
> 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
Am Sat, May 11, 2013 at 5:42 PM schrieb Eckhart Wörner :
> 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
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 etabl
Am 11.05.2013 17:14 schrieb "fx99" :
> 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
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:
Hallo Eckhart,
Am Sat, 11 May 2013 15:40:32 +0200
schrieb Eckhart Wörner :
> 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,
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
> Sond
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 Be
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 mache
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. I
2013/5/11 malenki
> 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 e
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 un
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 nic
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 au
Hi,
Am Fri, 10 May 2013 07:08:32 +0200
schrieb Wilhelm Spickermann :
> 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 unte
Hi,
Am Thu, 09 May 2013 23:12:36 +0200
schrieb Tirkon :
> 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.
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" :
> Wilhelm Spickermann wrote:
>
> >Na ja, wenn der Weg nicht mehr da ist, dann ist in der Route auch in
> >der Realität ein Loch ..
Wilhelm Spickermann 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
exis
Vielen Dank für Eure Reaktionen. Damit ist einer der Punkte erledigt.
Im Einzelnen:
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
Hi,
Am Thu, 9 May 2013 17:52:36 +0200
schrieb Jo :
> 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
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 Ale
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 tu
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!
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
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 fin
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 Pr
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 OS
95 matches
Mail list logo
