Re: [Talk-de] Nutzung von staedtischen Vermessungsdaten
On 08.05.13 19:57, Frank wrote: Am 08.05.2013 15:43, schrieb Andreas Labres: On 08.05.13 14:36, Sven Geggus wrote: im Gegensatz zu damals müsste man wohl in der Regel bestehende Daten entfernen Also das sollte grundsätzlich tabu sein! Nicht ganz, bei überschaubaren Strukturen kann man automatisiert abgleichen. Mglw. ein Mißverständnis: Mir ging es um das /Entfernen/. Abgleichen kann man immer (kommt halt ggf. drauf an, wie man es umsetzt). Nur das Werk des anderen, der da vielleicht mühsam Gebäude gezeichnet hat (oder auch nur POIs gesetzt hat), muss man respektieren. Also: korrigieren/ergänzen ja, löschen nein. /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stadtteilfuckup in Nominatim
Am 9. Mai 2013 03:22 schrieb Christian Müller cmu...@gmx.de: Am 09.05.2013 00:55, schrieb Ruben Kelevra: Nun, wie ich bereits sagte nimmt Nominatim den Stadtteil außerhalb des Stadtgebiets der definitiv NICHT zu einer Straße im Stadtgebiet gehört. Ich wüsste aber nicht wie ich den Stadtkern selbst taggen soll. Das ist das primäre Problem. Hat jemand dafür einen Vorschlag? Vorschlag: Schaue Dir die administrativen Stadt-/Ortsteilgrenzen von anderen Städten, wie z.B. Berlin oder Hamburg an. nur geht es ja nicht nur um administrative Grenzen sondern auch um Siedlungsgeografie, gerade z.B. in Großstädten wie Berlin und Hamburg, die nicht direkt vergleichbar sind mit einer Kleinstadt, wird das besonders deutlich. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spendenkampagne 2013 der OSMF für neue Hardware
Frederik Ramm frede...@remote.org wrote: Ich hoffe nicht, dass es bei uns zu einem Wikipedia-Effekt kommt und Euch irgendwann um die Adventszeit das Antlitz unseres Vorsitzenden (so fotogen, wie Simon auch sein mag!) von jeder OSM-Webseite entgegenlacht mit einem Spendenaufruf. Ich finde solch eine Spendenaktion (auch für OSM) in Ordnung, weil sie sich nicht an die Aktiven sondern vornehmlich an die Nutzer/Leser wendet. Dass die Spenden auch aus diesem Bereich kommen, lässt sich an den zahlreichen Spendenkommentaren ablesen. Es ist übrigens interessant, darin zu stöbern, weil man als Aktiver manche der Verwendungen niemals auf dem Schirm gehabt hätte. Die Zahl derjenigen, die proforma einen Euro spenden, um hier eine Kritik anzubringen, liegt gefühlt im Subpromillebereich. Insgesamt lässt sich resümieren, dass die Nutzer wirklich gerne spenden und froh sind, auf diese Möglichkeit aufmerksam gemacht worden zu sein. Und auch OSM hat ja schon davon profitiert, unter Anderem durch die Initiative von Marc. OSM wird bei Wikimedia Deutschland inzischen bezüglich der finanziellen Förderung mit Wikipedia gleichgestellt. OSMler sollten daher IMHO bei Bedarf diese Finanzquelle häufiger nutzen. Das hierfür abgestellte Budget wird unter dem Aspekt der Förderung freier Projekte und Software verteilt. Durch diese Spenden ist man beispielsweise auch bei den offiziell angesetzten Konferenzen nicht mehr auf Sponsoren angewiesen. Das gilt auch für die Räumlichkeiten. Womit nicht gesagt sei, dass man auf diese Sponsoren verzichten sollte. Denn dies erzeugt zumindest in Teilen auch einen Solidarisierungseffekt. Den Wikipedia Effekt, den ich als viel schlimmer empfinde, ist das Entwickeln des Eigenlebens unter der Angestelltenschaft sowohl der weltweiten Foundation als auch des deutschen Vereins. Da muss sich die Community jetzt Dinge erwehren, die sie nicht gutheißt. Da aber die Community nur nebenberuflich arbeitet, kann sie mitunter nicht gegen die Vollzeitler anstinken, die zudem eine bessere finanzielle Ausstattung haben und insgesamt am längeren Hebel sitzen. Das ist IMHO eine klare Schwächung und Demotivation für die Community. Das ist eine Entwicklung, die ich mir für OSM nicht wünsche. Nichtsdestotrotz finde ich es eine gute Idee, DEN Kernserver des Projektes durch die Aktiven zu finanzieren. Das Bewusstsein, das Projekt aus eigener Kraft am Laufen halten zu können, schafft sicherlich auch einen Solidarisierungseffekt. Nebenebei bemerkt ist es inzwischen nicht nur Jimmy Wales (nicht mehr Vorsitzender, sondern nur noch Gründer) sondern ein Konglomerat von Wikipedia/Wikimedia bezogenen Personen, mit deren Konterfei dort geworben wird. Übrigens: Man kann den Aufruf übrigens auch dauerhaft abschalten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stadtteilfuckup in Nominatim
On 09.05.2013 00:22, Martin Koppenhoefer wrote: sind das nodes oder Flächen? Flächen sind weil sie explizit das Gebiet definieren besser als nodes, bei Nodes kann Nominatim (und jeder andere) nur raten, wie groß das Gebiet ist. Ggf. kannst Du das hierarchisieren, indem Du das auf place=suburb und place=neighbourhood aufteilst. Frage mich ja ob Nominatim mit place nodes in boundary relationen umgehen kann. Wobei place ja auch recht schwierig sein kann. Kenne hier ein Neubaugebiet (Quatier), das sich auf beiden Seiten einer admin=6 Grenze befindet. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stadtteilfuckup in Nominatim
On 09/mag/2013, at 15:57, fly lowfligh...@googlemail.com wrote: Frage mich ja ob Nominatim mit place nodes in boundary relationen umgehen kann. M.E. ist das nicht unbedingt nötig bzw. sinnvoll, da es orthogonale Eigenschaften sind (solange wir von boundary=administrative reden), ein namematching bzw. räumliche Abfragen kann man ja auch so machen. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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
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] Stadtteilfuckup in Nominatim
Moin, Am 09.05.2013 00:55, schrieb Ruben Kelevra: Nun, wie ich bereits sagte nimmt Nominatim den Stadtteil außerhalb des Stadtgebiets der definitiv NICHT zu einer Straße im Stadtgebiet gehört. Ich wüsste aber nicht wie ich den Stadtkern selbst taggen soll. Das ist das primäre Problem. Hat jemand dafür einen Vorschlag? Ich kenne keine Gemeinde/Stadt, die aus Ortsteilen/Stadtteilen besteht, wo das Kerngebiet nicht auch ein Ortsteil/Stadtteil ist. Also wird es wohl auch dort für den 'Stadtkern' eine administrative Struktur samt Namen geben - ich tippe mal auf Wermelskirchen. ;-) Den Rest werde ich mal so probieren wie hier vorgeschlagen, entweder ein Shape oder nur die Straße selbst taggen. Shape / Grenze - selbst in geschätzter Lage - ist der bessere Weg. Selbst ein place-Node 'Stadtkern' hilft nicht weiter, wenn halt der äußere Stadtteil-Node immer noch dichter dran liegt ... Gruß Georg ___ 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
[Talk-de] OSM Stand auf der FROSCON
Hallo zusammen, ich war im letzen Jahr zum ersten mal auf der FROSCON um einen Vortrag über OSM Daten in PostGIS zu halten. Da mir die Konferenz recht gut gefallen hat (eigentlich so wie Linuxtag ganz früher) fand ich es etwas schade, dass OSM nicht wirklich vertreten war. Ich wäre bereit, das in diesem Jahr zu ändern und suche Mitstreiter für den Aufbau eines OSM Standes. Wenn sich noch 2-3 Leute bei mir melden würde ich einen Stand beantragen. Gruss Sven -- If you can spend five minutes on the Internet and do not run Linux, you're a genius. (Dirk Hohndel) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ 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
