Replies: 2 comments
-
If I understand your correctly, you say that creating a changeset for each quest creates more changesets than if changesets were created per object. However, that is just the case, if one answers many different quests for just a few elements. If used for, say, one hour, the number of quests may be smaller than the number of elements that were edited in the process. The number of quests is limited, while elements to edit are practically endless. See #5116 for more information on the upload process. Creating changesets for each quest is also very concise and transparent. It probably also helps with reverting if a quest was misunderstood by a certain user, for instance. When grouping by element (does not scale well, as described above) or by area, many quests could be mixed in one changeset, making it difficult to understand. Apparently, small and readable changesets are preferred over large and obscure ones (see wiki). I don't know how this is viewed by the database people, but I would assume that the infrastructure is designed to handle what is considered to be best practice. |
Beta Was this translation helpful? Give feedback.
-
This is not causing any issues (compare with latest vandalism wave in Russia: several million vandalised and later fixed objects, caused some increased resource consumption for Nominatim servers and tile servers, have not caused issues at database level). And anyway many changesets are not making it worse, it is more about amount of edits anyway. |
Beta Was this translation helpful? Give feedback.
-
The app makes many-many little changes to objects. I.e. every quest makes a separate change. But actually quite often one user makes changes to the same object within a short time period.
Does it bother anyone (besides me?). And do the OSM hosters mind?
Maybe consolidating the changes makes sense?
P.S. SC app doesn't consolidate changes even when the delayed changes set.
Beta Was this translation helpful? Give feedback.
All reactions