OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

Announcement

A fix has been applied to the login system for the forums - if you have trouble logging in please contact support@openstreetmap.org with both your forum username and your OpenStreetMap username so we can make sure your accounts are properly linked.

#26 2017-04-02 15:24:44

Brainlessnick
Member
Registered: 2017-04-02
Posts: 3

Re: StreetComplete - die nächste suboptimale App

Bin einer der "bösen" Münchner User - hab mich auch schon gefragt warum keine Changesets gebaut wurden, mir waren die Implikationen für Qualitätsmanagement nicht so ganz klar - hab die Nutzung jetzt erstmal auf Eis gelegt.

@westnordost: Klasse app! m.M. nach die "bequemste" Art, OSM edits on-the-go zu machen und insb. auch für Nutzer ohne großen Buy-in nutzbar.

Offline

#27 2017-04-02 17:53:36

free_as_a_bird
Member
Registered: 2010-01-26
Posts: 171

Re: StreetComplete - die nächste suboptimale App

Brainlessnick wrote:

@westnordost: Klasse app! m.M. nach die "bequemste" Art, OSM edits on-the-go zu machen und insb. auch für Nutzer ohne großen Buy-in nutzbar.

Dem kann ich nur zustimmen! Ich halte StreetComplete nicht nur für die bequemste, sondern auch für die schönste App für die mobile Datenerfassung.

Kopf hoch @westnordost: bin gespannt auf Version 0.6, die das Problem mit den CS löst!

Offline

#28 2017-04-02 18:51:12

SammysHP
Member
From: Celle, Germany
Registered: 2012-02-27
Posts: 1,367
Website

Re: StreetComplete - die nächste suboptimale App

Anstatt den Oauth key zu widerrufen könnte man ja auch schauen, ob eine Sperrung von Versionen <= x möglich ist. Dann könnten Nutzer von einer neueren Version die App normal nutzen, andere mit einer veralteten Version hingegen nicht.

Ich bin auch der Meinung, dass der Zugriff über die aktuelle Version möglichst schnell gestoppt werden sollte. In meiner Region gab es zwar noch keine Changesets darüber, aber wenn jemand durch die Stadt geht und dutzende CS mit je einer Änderung erzeugt, würde mich das schon ziemlich stören.

Offline

#29 2017-04-02 20:58:43

Nakaner
Member
Registered: 2011-09-03
Posts: 1,724
Website

Re: StreetComplete - die nächste suboptimale App

SammysHP wrote:

Anstatt den Oauth key zu widerrufen könnte man ja auch schauen, ob eine Sperrung von Versionen <= x möglich ist. Dann könnten Nutzer von einer neueren Version die App normal nutzen, andere mit einer veralteten Version hingegen nicht.

westnordost müsste sich halt einen neuen OAuth-Schlüssel holen, bevor er die neue Version freigibt. Das ist nichts Bürokratisches, sondern erfordert nur das Ausfüllen eines Formulars. Das ist im Wiki beschrieben. Es ist einfach. Ich habe es selbst schon gemacht, als ich mit JOSM über die Dev-API editieren wollte (Änderungssätze für ein Revertskript erzeugen).


Bitte aussagekräftige Threadtitel verwenden und bei Änderungssätzen einen aussagekräftigen Kommentar eingeben.

Offline

#30 2017-04-02 22:43:32

freakyuser
Member
Registered: 2016-06-11
Posts: 7

Re: StreetComplete - die nächste suboptimale App

Ich hatte mit ihm schon Mailkontakt, bevor ich hier nachgelesen hatte. Es wurde zwar schon genug drüber diskutiert, aber ich geb jetzt doch noch meinen Senf dazu:

Wie man hier sehen kann: http://tyrasd.github.io/latest-changes/ … 298/8.3376

Hat er mit der App auch bei der Reaktivierung von einem in letzter Zeit inaktiven Nutzer geholfen wink


Finde den einfachen Ansatz wenn man unterwegs ist kurz was einzutragen echt super, mir fehlt ja oft die Kreativität zu checken, was in gut gemappten Regionen noch fehlt.


Edit: Krass, hab mal ein paar Städte angeschaut, z.B. Tübingen, da sind ja echt extrem viele im Lande mit der App unterwegs!
(Bzw. einige wenige recht fleißig)

Last edited by freakyuser (2017-04-02 22:47:00)

Offline

#31 2017-04-03 21:21:15

westnordost
Member
From: Hamburg
Registered: 2013-07-13
Posts: 84

Re: StreetComplete - die nächste suboptimale App

So, ich habe mir jetzt einmal auführlich überlegt, wie ich das implementieren würde. Nachdem ich im GitHub Ticket nicht allzu viel Feedback bekommen habe, hier einmal zusammengefasst. Wer große Bedenken dagegen hat, der möge jetzt sprechen oder für immer schweigen.

Grundsätzlich sind drei Modi zu unterscheiden: Automatisch (Online), Automatisch im Wifi und Manuell (Offline).

Für jeden Aufgabentyp wird ein eigenes Changeset erzeugt. Dieser Changeset hat je nach Aufgabentyp als Kommentar eine kurze Beschreibung, zum Beispiel "Added street surfaces" (also statt pro Aufgabe).
So ist nach wie vor am Kommentar des Changesets sofort die Natur der Änderungen zu erkennen, gleichzeitig reduziert sich die Anzahl der einzelnen Changesets deutlich.

Zunächst für den automatischen Modus: Gelöste Aufgaben werden sofort innerhalb ihres jeweiligen Changesets hochgeladen. Existiert noch keiner oder ist dieser schon geschlossen worden, wird dieser on-the-fly erstellt.
Der Changeset wächst also während der "survey" des Benutzers und wird schließlich von der App geschlossen, nachdem der Benutzer 10 Minuten keine Aufgaben dieses Typs mehr eingetragen hat. Diese Dauer kann nach Bedarf angepasst werden, wird aber nie über 1 Stunde betragen, da er nach einer Stunde automatisch vom OSM Server geschlossen wird. Tatsächlich wird dieser Fall recht häufig eintreten, denn es ist wahrscheinlich, dass nach dieser Wartezeit die App selbst garnicht mehr läuft.*
(Die App muss sich also persistent pro Aufgabentyp die zugehörige changeset id und die Zeit des letzten Lösen einer Aufgabe dieses Typs merken.)

Der "Automatisch im Wifi" Modus verhält sich wie der Name schon sagt im Wifi wie der automatische Modus und außerhalb des Wifis wie der manuelle. Das heißt, kommt man (zurück) in ein Wifi, werden die gelösten Aufgaben zwar sofort hochgeladen, aber die zugehörigen Changesets erst nach der Wartezeit geschlossen.

Manueller Modus: Der manuelle Modus ist ein bischen wie man es von einem klassischem Editor kennt. Es wird nichts automatisch hochgeladen und wenn der Benutzer den "Hochladen" Knopf drückt, wird sofort für jeden Aufgabentyp ein Changeset geöffnet, die Änderungen übertragen und der Changeset geschlossen. Das bedeutet, wenn ein Benutzer ständig auf diesen Knopf drückt, dann sind die Changesets eben auch klein. Das hat er da selbst in der Hand, wie bei jedem anderen Editor auch.
Es wäre natürlich möglich, auch im manuellen Modus die Changesets nicht sofort zu schließen sondern erst nach der Wartezeit, ich denke aber das läuft zuwider der Erwartung der Benutzer, dass nach Druck auf den Hochladen-Button wirklich alles abgeschlossen ist (würde aber natürlich zu weniger Changesets führen).

* technisch wäre es möglich, dies auch nach Ableben der App zu machen (Android AlarmManager). Das ist etwas komplexer und kann später implementiert werden.

Last edited by westnordost (2017-04-03 21:23:41)

Offline

#32 2017-04-03 21:34:04

Nakaner
Member
Registered: 2011-09-03
Posts: 1,724
Website

Re: StreetComplete - die nächste suboptimale App

Hallo,

westnordost wrote:

Grundsätzlich sind drei Modi zu unterscheiden: Automatisch (Online), Automatisch im Wifi und Manuell (Offline).

Für jeden Aufgabentyp wird ein eigenes Changeset erzeugt. Dieser Changeset hat je nach Aufgabentyp als Kommentar eine kurze Beschreibung, zum Beispiel "Added street surfaces" (also statt pro Aufgabe).
So ist nach wie vor am Kommentar des Changesets sofort die Natur der Änderungen zu erkennen, gleichzeitig reduziert sich die Anzahl der einzelnen Changesets deutlich.

Zunächst für den automatischen Modus: Gelöste Aufgaben werden sofort innerhalb ihres jeweiligen Changesets hochgeladen. Existiert noch keiner oder ist dieser schon geschlossen worden, wird dieser on-the-fly erstellt.
Der Changeset wächst also während der "survey" des Benutzers und wird schließlich von der App geschlossen, nachdem der Benutzer 10 Minuten keine Aufgaben dieses Typs mehr eingetragen hat. Diese Dauer kann nach Bedarf angepasst werden, wird aber nie über 1 Stunde betragen, da er nach einer Stunde automatisch vom OSM Server geschlossen wird. Tatsächlich wird dieser Fall recht häufig eintreten, denn es ist wahrscheinlich, dass nach dieser Wartezeit die App selbst garnicht mehr läuft.*
(Die App muss sich also persistent pro Aufgabentyp die zugehörige changeset id und die Zeit des letzten Lösen einer Aufgabe dieses Typs merken.)

Der "Automatisch im Wifi" Modus verhält sich wie der Name schon sagt im Wifi wie der automatische Modus und außerhalb des Wifis wie der manuelle. Das heißt, kommt man (zurück) in ein Wifi, werden die gelösten Aufgaben zwar sofort hochgeladen, aber die zugehörigen Changesets erst nach der Wartezeit geschlossen.

Manueller Modus: Der manuelle Modus ist ein bischen wie man es von einem klassischem Editor kennt. Es wird nichts automatisch hochgeladen und wenn der Benutzer den "Hochladen" Knopf drückt, wird sofort für jeden Aufgabentyp ein Changeset geöffnet, die Änderungen übertragen und der Changeset geschlossen. Das bedeutet, wenn ein Benutzer ständig auf diesen Knopf drückt, dann sind die Changesets eben auch klein. Das hat er da selbst in der Hand, wie bei jedem anderen Editor auch.
Es wäre natürlich möglich, auch im manuellen Modus die Changesets nicht sofort zu schließen sondern erst nach der Wartezeit, ich denke aber das läuft zuwider der Erwartung der Benutzer, dass nach Druck auf den Hochladen-Button wirklich alles abgeschlossen ist (würde aber natürlich zu weniger Changesets führen).

Welche Vorteile erhoffst du dir davon, dass es mehrere Modi gibt und nicht nur den manuellen? Das erhöht doch nur deinen Implementierungsaufwand? Der Nutzer weiß wahrscheinlich am besten, wann er ein stabileres Netz erwartet, um die Daten hochladen zu können.

Dumme Frage eines Nicht-Nutzers deiner App: Kann die App Objekte in OSM anlegen? Dann solltest du ein automatisches Hochladen über wackelige Netzwerverbindungen vermeiden. OSM kennt keine Transaktionen, sprich wenn die Transaktion abbricht, erfolgt kein Rollback, sondern das, was geschrieben wurde, bleibt persistent und der Rest ist weg. Was geschrieben wurde, kannst du nur umständlich herausfinden. Wenn man dann einfach ein zweites Mal blind hochlädt, erzeugt man Objekte doppelt.

Viele Grüße

Michael


Bitte aussagekräftige Threadtitel verwenden und bei Änderungssätzen einen aussagekräftigen Kommentar eingeben.

Offline

#33 2017-04-03 21:54:51

hsimpson
Member
Registered: 2015-07-21
Posts: 275

Re: StreetComplete - die nächste suboptimale App

BeKri wrote:

Hallo zusammen,

ich benutze natürlich einen provokanten Titel, damit darauf reagiert wird.

Hallo BeKri,

Ich bemühe mich bisher immer, Sachliche Titel zu verwenden (gut, ab und an gehen auch bei mir die Nerven mal durch) und ich fahre damit bisher immer ziemlich gut. Es gibt genug Leute hier im Forum, die alles zumindest überfliegen und wenn nötig ihren Senf dazu geben (danke dafür). Von daher hatte ich bisher nie ein Problem, dass meine Probleme nicht gehört wirden wären.

Es ist vielmehr so, dass reißerische Titel dem Niveau des Threads schaden und damit auch der Antwortqualität. Von daher schneidest du dir damit auch ein Stück weit ins eigene Fleisch.

Grüße

Online

#34 2017-04-03 22:14:39

westnordost
Member
From: Hamburg
Registered: 2013-07-13
Posts: 84

Re: StreetComplete - die nächste suboptimale App

Kann die App Objekte in OSM anlegen?

Nein

OSM kennt keine Transaktionen, sprich wenn die Transaktion abbricht, erfolgt kein Rollback, sondern das, was geschrieben wurde, bleibt persistent und der Rest ist weg.

Das ist nicht ganz richtig. Ein Changeset ist an sich keine atomare Transaktion, aber ein Diff upload innerhalb eines Changesets ist eine.

Last edited by westnordost (2017-04-03 22:14:55)

Offline

#35 2017-04-03 22:14:59

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 14,013
Website

Re: StreetComplete - die nächste suboptimale App

westnordost wrote:

So, ich habe mir jetzt einmal auführlich überlegt, wie ich das implementieren würde. Nachdem ich im GitHub Ticket nicht allzu viel Feedback bekommen habe, hier einmal zusammengefasst. Wer große Bedenken dagegen hat, der möge jetzt sprechen oder für immer schweigen.

Der erste Eindruck dieses Entwurfes ist sehr zufriedenstellen.

Grundsätzlich sind drei Modi zu unterscheiden: Automatisch (Online), Automatisch im Wifi und Manuell (Offline).

Die Feinheiten und Notwendigkeit dieser drei Modi beginne ich langsam zu erkennen (halt nur dann hochladen, wenn es nötig und auch technisch möglich ist und dabei Datenvolumen sparen) und hab da auch keine grossen Bedenken.

Alles was dabei hilft, die Anzahl der CS zu minimieren, ist äußerst hilfreich. Und wenn dann mal einer manuell ein Dutzend kleine CS hochlädt, ist das auch nicht so schlimm - das machen unsere Kollegen (und ich)  auch gelegentlich so.

Auf jeden Fall ein Schritt in die richtige Richtung.

Gruss
walter

Offline

#36 2017-04-03 22:15:45

Nop
Moderator
Registered: 2009-01-26
Posts: 2,150

Re: StreetComplete - die nächste suboptimale App

westnordost wrote:

Manueller Modus: Der manuelle Modus ist ein bischen wie man es von einem klassischem Editor kennt. Es wird nichts automatisch hochgeladen und wenn der Benutzer den "Hochladen" Knopf drückt, wird sofort für jeden Aufgabentyp ein Changeset geöffnet, die Änderungen übertragen und der Changeset geschlossen. Das bedeutet, wenn ein Benutzer ständig auf diesen Knopf drückt, dann sind die Changesets eben auch klein.

Die Darstellung ist so nicht richtig. In "jedem anderen Editor" bei OSM wird nur ein CS erzeugt, egal wie oft man auf den Speichern Knopf drückt.

So sollte sich auch Dein manueller Modus verhalten: Keine mehrfachen CS bei mehrfachem Speichern.

bye, Nop


Nothing is too difficult for the man who does not have to do it himself...
Projekte: Reit- und Wanderkarte mit Navigation    Kartengenerator Map Composer

Offline

#37 2017-04-03 22:22:02

westnordost
Member
From: Hamburg
Registered: 2013-07-13
Posts: 84

Re: StreetComplete - die nächste suboptimale App

@Nop: Stimmt, danke für die Korrektur, es ist also nur in der Hinsicht so wie jeder andere Editor, als dass die Changesets direkt hintereinander geöffnet, Änderungen übertragen und direkt geschlossen werden.

So sollte sich auch Dein manueller Modus verhalten: Keine mehrfachen CS bei mehrfachem Speichern.

Also du fändest es sinnvoller, wenn im manuellen Modus die CS nicht geschlossen werden?

Ehrlich gesagt war mir heute dazu noch was eingefallen, ich hatte es aber vergessen. Hier ist ein tolle Idee, ich denke ich werde das so machen, weil 1. weniger Changesets und 2. einheitlicheres Verhalten (und 3. dadurch weniger Code):
Im manuellen Modus gelten die gleichen Regeln wie im automatischen Modus. CS werden nur geschlossen, wenn 10 Minuten seit der letzten Änderung vergangen sind.
Kommt man also von einer Offline-Survey nach Hause, drückt man "Upload" und die CS werden alle schön im bulk übertragen, dann direkt geschlossen weil die letzte Änderung etwas länger her ist.
Ist man auf der Survey, hat nur aus welchen Gründen auch immer den automatischen Modus aus, macht es nichts wenn man ständig auf "Upload" drückt, denn die App merkt dass die letzte Änderung erst vor wenigen Minuten erfolgt ist und hängt die jeweiligen Änderungen an den offenen CS an.
Dann passt es auch besser mit dem Wifi-Modus. (Denn normalerweise wenn man zurück kommt ins Wifi, ist man eben zurück von der Survey und will alles abgeschlossen sehen)
Tadaa, alle sind bedient :-)

Last edited by westnordost (2017-04-03 22:31:55)

Offline

#38 2017-04-04 07:21:57

DD1GJ
Member
Registered: 2009-04-12
Posts: 559

Re: StreetComplete - die nächste suboptimale App

Die OSM-API schließt  ein CS erst nach einer Stunde Inaktivität bzw. bei Dauereditieren nach 24 Stunden. Du kannst also Deine Zeiten noch erheblich ausdehnen und sicherheitshalber die Antwort der API auf eine Fehlermeldung für ein bereits geschlossene CS berücksichtigen.

Normale Straßen für den Autoverkehr sind zu 99% asphaltiert und die Oberfläche wird für das Autorouting  in den Industrienationen nicht benötigt. Gleiches gilt für tracktype=grade1. Effektiver wäre eine nur eine  Erfassung für fehlende Tracktype (grade1-5) bzw. die Oberflächenbeschaffenheit und evtl. Güte bei Wegen für Fußgänger und Radfahrer  (footway, cycleway, foot=*, bicycle=*).

Ergänzend zu den Öffnungszeiten wären die (letzten) Leerungszeiten und Operator/Brand von Briefkästen interessant.

Die Erfassung von Dachform und Anzahl der Stockweke könnte in einen Vorgang zussammengelegt werden.

Bisher ist zwar Löschen/Neuanlegen von Objekten nicht vorgesehen. Dennoch wäre eine Möglichkeit sinnvoll, z.B eine geschlossene Gaststätte auf disused:amenity und old_name umtaggen zu können. Langfristig wäre auch eine Überprüfung von abgebauten Telefonzellen denkbar mittels last_check (oder ähnlich). Wenn die letzte Bestätigung/Edit länger als ein bis zwei Jahre zurückliegt, erscheint das Symbol wieder zur Überprüfung.

Ob eine Trennung der CS nach Edit-Art sinnvoll ist, wird sich noch zeigen. Nach einer Offline-Erfassung sollte bei einer CS-Trennung  vor dem Hochladen vorsortiert werden.

Trotz der "Anlaufschwierigkeiten" sehe ich in der App ein großes Potential für OSM.

Last edited by DD1GJ (2017-04-04 07:28:51)

Offline

#39 2017-04-04 08:14:23

Nakaner
Member
Registered: 2011-09-03
Posts: 1,724
Website

Re: StreetComplete - die nächste suboptimale App

DD1GJ wrote:

Normale Straßen für den Autoverkehr sind zu 99% asphaltiert und die Oberfläche wird für das Autorouting  in den Industrienationen nicht benötigt. Gleiches gilt für tracktype=grade1. Effektiver wäre eine nur eine  Erfassung für fehlende Tracktype (grade1-5) bzw. die Oberflächenbeschaffenheit und evtl. Güte bei Wegen für Fußgänger und Radfahrer  (footway, cycleway, foot=*, bicycle=*).

In Baden-Württemberg mag das vielleicht so sein, aber in Ostdeutschland ist innerorts der Anteil von Straßen mit schrecklichem alten Kopfsteinpflaster deutlich höher und diese Information trotzdem von Relevanz.


Bitte aussagekräftige Threadtitel verwenden und bei Änderungssätzen einen aussagekräftigen Kommentar eingeben.

Offline

#40 2017-04-04 08:35:41

Hakuch
Administrator
Registered: 2014-03-16
Posts: 611

Re: StreetComplete - die nächste suboptimale App

DD1GJ wrote:

Ergänzend zu den Öffnungszeiten wären die (letzten) Leerungszeiten und Operator/Brand von Briefkästen interessant.

solche vorschläge find ich auch gut, aber vielleicht finden sie in einem eigenen Thread oder im github issue mehr beachtung als hier wo der Thread mit der Seuche StreetComplete startet smile

DD1GJ wrote:

Trotz der "Anlaufschwierigkeiten" sehe ich in der App ein großes Potential für OSM.

dito, hat mich sehr gefreut endlich mal eine App mit einem so einfachen Konzept nutzen zu können, soetwas in der Art hatte ich mir eigentlich immer gewünscht. Wenn diese Changeset Problematik erledigt ist und das Ding stabil läuft wird es bestimmt noch einen guten Beitrag zum mappen leisten.

Offline

#41 2017-04-04 09:13:17

PT-53
Member
From: Oberschwaben (BW, DE)
Registered: 2013-09-01
Posts: 489

Re: StreetComplete - die nächste suboptimale App

DD1GJ wrote:

Normale Straßen für den Autoverkehr sind zu 99% asphaltiert und die Oberfläche wird für das Autorouting  in den Industrienationen nicht benötigt. Gleiches gilt für tracktype=grade1. Effektiver wäre eine nur eine  Erfassung für fehlende Tracktype (grade1-5) bzw. die Oberflächenbeschaffenheit und evtl. Güte bei Wegen für Fußgänger und Radfahrer  (footway, cycleway, foot=*, bicycle=*).

Bei unclassified- und service-highways kann es durchaus auch in BW vorkommen, daß diese nicht geteert sind. Hier erfasse ich grundsätzlich surface und - fürs Fahrradrouting - auch smoothness, ebenso bei path ...

Grüße aus Oberschwaben

Offline

#42 2017-04-04 10:23:59

whb
Member
Registered: 2013-01-18
Posts: 212

Re: StreetComplete - die nächste suboptimale App

DD1GJ wrote:

Normale Straßen für den Autoverkehr sind zu 99% asphaltiert und die Oberfläche wird für das Autorouting  in den Industrienationen nicht benötigt. Gleiches gilt für tracktype=grade1.

Sehe ich nicht so.
Gerade in Altstadtbereichen gibt es sehr viele gepflasterte Straßen, auch viele Anwohnerstraßen sind gepflastert.
Autobahnen sind oft betoniert, deshalb gilt dort im Sommer oft Tempo 80, wegen aufplatzendem Beton.
grade1-Feldwege sind oft nicht asphaltiert, sondern betoniert.
unclassified sind gerne auch mal nicht befestigt...

Offline

#43 2017-04-04 10:34:00

Hakuch
Administrator
Registered: 2014-03-16
Posts: 611

Re: StreetComplete - die nächste suboptimale App

(zur info: ich hab jetzt den Titel geändert, aufgrund der vorangegangenen Diskussion und da gezielte provokative Äußerungen hier nicht angebracht sind. Ich hätte mir mehr gewünscht, dass Bekri selbst handelt weil ich ungerne in andere Posts eingreife.)

Offline

#44 2017-04-04 14:17:05

TZorn
Member
From: Leverkusen
Registered: 2015-06-02
Posts: 263

Re: StreetComplete - die nächste suboptimale App

Nop wrote:

Die Darstellung ist so nicht richtig. In "jedem anderen Editor" bei OSM wird nur ein CS erzeugt, egal wie oft man auf den Speichern Knopf drückt.

So sollte sich auch Dein manueller Modus verhalten: Keine mehrfachen CS bei mehrfachem Speichern.

Hmm: Bei JOSM wird standardmäßig (zumindest war es, meine ich, der Standard, als ich JOSM das erte mal eingerichtet habe), pro Upload ein Changeset erstellt und geschlossen. "Speichern" habe ich da noch nie benutzt, ehrlich gesagt. In iD wird auch jedes Mal beim Drücken von "Speichern" ein neues Changeset erzeugt und geschlossen. Habe es gerade noch mal ausprobiert.

Offline

#45 2017-04-04 14:40:42

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 14,013
Website

Re: StreetComplete - die nächste suboptimale App

TZorn wrote:

Hmm: Bei JOSM wird standardmäßig (zumindest war es, meine ich, der Standard, als ich JOSM das erte mal eingerichtet habe), pro Upload ein Changeset erstellt und geschlossen.

Man kann das allerdings in den Upload-Optionen einstellen. Ich hab das Schliessen nach dem Upload z.B. abgestellt und kann somit mehrere Uploads in einen Changegeset packen. Erst wenn ich "Datei/Offene Änderungssätze schliessen" macht, wird mein CS geschlossen.

Das mache ich idR., wenn ich Missing Boundaries verarbeite und jeweils ein Land in einem CS haben will - und wenn ich das mal vergesse, werd ich angesch... https://www.openstreetmap.org/changeset/47365222 wink

Gruss
walter

Last edited by wambacher (2017-04-04 14:40:59)

Offline

#46 2017-04-04 21:07:00

dafoxia
New Member
Registered: 2017-04-04
Posts: 1

Re: StreetComplete - die nächste suboptimale App

OSM kennt keine Transaktionen, sprich wenn die Transaktion abbricht, erfolgt kein Rollback, sondern das, was geschrieben wurde, bleibt persistent und der Rest ist weg. Was geschrieben wurde, kannst du nur umständlich herausfinden. Wenn man dann einfach ein zweites Mal blind hochlädt, erzeugt man Objekte doppelt.

Daran müsste meiner Meinung auch dringend gearbeitet werden. Weiters bestünde auch die Möglichkeit von Seiten der OSM-API ChangeSets von sich aus zu Gruppieren wenn Sie das gleiche Tag und den gleichen Benutzer innerhalb eines Zeitfensters beinhalten.
So würde von vornherein ein unerwünschtes Verhalten dieser Art von einer Applikation verhindert. Des weiteren könnte die API auch berücksichtigen das ChangeSets aufgespalten werden wenn sich die Länge und Breite des Ortes von einer anderen Änderung zu weit entfernt ist. Das würde das Wheelmap-Problem lösen.
Zusammengefasst: Wenn die Probleme von der API erst gar nicht ermöglicht werden, ist das Problem schon Zentral gelöst und muss nicht in jeder Applikation behandelt werden. Es ist deshalb aus technischer Sicht falsch Applikationen auszusperren weil die API von OSM Fehlverhalten zulässt. Es ist vielmehr ein Aufruf die API selbst zu berichtigen.

Offline

#47 2017-04-04 21:38:08

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 7,715

Re: StreetComplete - die nächste suboptimale App

Hakuch wrote:

zur info: ich hab jetzt den Titel geändert

Was ist denn das gefährliche an den vielen CS? Wird die DB zu warm?

Ein sachlicher Titel für mich wäre: "Neue App erstellt pro Änderung ein Changeset" oder so.........


Faktum des Tages: Geld allein macht nicht glücklich, man muss schon Bier dafür kaufen.

Offline

#48 2017-04-04 22:26:42

Hakuch
Administrator
Registered: 2014-03-16
Posts: 611

Re: StreetComplete - die nächste suboptimale App

chris66 wrote:
Hakuch wrote:

zur info: ich hab jetzt den Titel geändert

Was ist denn das gefährliche an den vielen CS? Wird die DB zu warm?

wäre jetzt auch nicht meine persönliche Wortwahl gewesen, aber da es Bekri so wichtig war hab ich noch ein bisschen Brisanz ohne Provokation dringelassen smile

Offline

#49 2017-04-05 03:58:16

BeKri
Member
From: München, Aubing
Registered: 2014-08-14
Posts: 127

Re: StreetComplete - die nächste suboptimale App

Hakuch wrote:
chris66 wrote:
Hakuch wrote:

zur info: ich hab jetzt den Titel geändert

Was ist denn das gefährliche an den vielen CS? Wird die DB zu warm?

wäre jetzt auch nicht meine persönliche Wortwahl gewesen, aber da es Bekri so wichtig war hab ich noch ein bisschen Brisanz ohne Provokation dringelassen smile

Servus Hakuch, Du kleiner Wtzbold,
das Du Deine Möglichkeiten als Admin ausnutzt,
eine Meinung, die Dir nicht pass in Deinem Sinne passend zu machst,
nun gut, Meinungsfreiheit ist halt nicht jedermann Sache.

Wenn Du aber schon die Provokations-Moral-Keule schwingst, dann solltest Du schon fähig sein,
eine angemessenen Titel zu wählen, also mal was RICHTIGES  zu machen.
"gefährlich viele CS" hat mit "ein bischen Brisanz" recht wenig zu tun sondern ist einfach nur lächerlich.

Ich habe mich bei dem neue Titel an die Formulierung von DD1GJ angelehnt,
der die letzten Tage gut damit beschäftigt ist zu Bitten von der Nutzung der App abzusehen.
http://resultmaps.neis-one.org/osm-disc … &commented
(Hat fast was ansteckendes, epidemieartiges ... sad )

Hakuch, Du schreibst das Du "ungerne in andere Posts eingreifst". Ich empfehle Dir dringend das in Zukunft auch zu lassen.
Ich bin fast geneigt Dich zur Abgabe Deiner Adminrechte zu bitten
da ich Dich für zu unreif halte mit dessen Rechten und Möglichkeiten passend umzugehen.

Mit wenig freundlichen Grüßen
derBeKri

Offline

#50 2017-04-05 07:42:21

Chrysopras
Member
From: Germany
Registered: 2015-04-01
Posts: 827

Re: StreetComplete - die nächste suboptimale App

BeKri wrote:

Hakuch, Du schreibst das Du "ungerne in andere Posts eingreifst". Ich empfehle Dir dringend das in Zukunft auch zu lassen.
Ich bin fast geneigt Dich zur Abgabe Deiner Adminrechte zu bitten
da ich Dich für zu unreif halte mit dessen Rechten und Möglichkeiten passend umzugehen.

Ich möchte mich nicht einmischen, aber vielleicht kann ich das gerade als Nur-Mitleser dieses Threads halbwegs unvoreingenommen beurteilen. Gerade beim bloßen Mitlesen sieht man, dass Hakuch den Titel keineswegs „mal eben kurz“ geändert hat, sondern erst nach mehreren Bitten, den Titel zu ändern, und erst, nachdem durch die konstruktiven Antworten des App-Erstellers deutlich geworden war, dass die aufmerksamkeitsheischende Provokation nicht (mehr) nötig ist. Auch dass er den Titel nicht ganz entschärft hat, sondern ein bisschen Schärfe dringelassen hat, zeigt eigentlich deutlich, dass Hakuch sich sehr um Ausgleich bemüht. Kurz, von außen gesehen: Hakuch ist sogar vorbildlich mit seinen Adminrechten umgegangen.

Last edited by Chrysopras (2017-04-05 07:45:05)

Offline

Board footer

Powered by FluxBB