> Yes, I am aware of these buttons. Do you mean that we do Ctrl+S frequently in order to do partial saves? I feel this might allow for greater chance for conflicts to occur rather than uploading frequently.
and that would be my view as well. I'm not sure I see the advantage of bigger changesets. The same amount of data ends up in the database. Thanks John On 20 January 2018 at 09:36, Gaurav Thapa <[email protected]> wrote: > Yes, I am aware of these buttons. Do you mean that we do Ctrl+S frequently > in order to do partial saves? I feel this might allow for greater chance > for conflicts to occur rather than uploading frequently. > > On Sat, Jan 20, 2018 at 2:59 AM, althio <[email protected]> wrote: > >> Hi Gaurav, >> >> In the row of buttons, the first two are "Open" and "Save": these actions >> are for files locally on your computer. >> Third and fourth buttons are "Download" and "Upload", commonly used to >> interact with OSM servers. >> >> -- althio >> >> On Jan 19, 2018 10:29 AM, "Gaurav Thapa" <[email protected]> wrote: >> > >> > Hi Michael, >> > Could you tell me what buttons are used in JOSM for partial saves? Here >> in Nepal we frequently upload changes as internet is intermittent this >> feature would be greatly beneficial for us all. >> > >> > Regards, >> > Gaurav >> > >> > On Fri, Jan 19, 2018 at 1:13 PM, Michael Collinson <[email protected]> >> wrote: >> >> >> >> Hi Micah, >> >> >> >> I think you came up with a good answer to your conundrum in an earlier >> post in this thread: Don't explain what an optimal changeset IS, explain >> what it is NOT: >> >> >> >> Something like: >> >> >> >> "It helps other contributors understand your edits if you group what >> you are doing in a local area into one changeset. For example, if you are >> creating the outlines of 20 buildings, group them into one changeset. On >> the other hand, if you are adding 3 POIs, (points of interest), that are >> 1000 km apart in different countries, then it is more useful to put them >> into 3 changesets. Of course, if you are creating the outlines of 1,000 >> buildings in your town, you do not have to do them all at once! >> >> >> >> If you worried about losing your data, our data editor software allows >> you to make incremental saves to the OSM server as you go along. iD does >> this automatically. Potlatch and JOSM have buttons that allow you to save >> partial work into a changeset and then keep adding to it until you are >> done." >> >> >> >> [This could probably be improved for readability by non-native English >> speakers. And the editor text should be fact checked, I am a die-hard >> Potlatch user.] >> >> >> >> >> >> Mike >> >> >> >> (first post for a long, long time) >> >> >> >> >> >> On 1/17/18 4:13 PM, Micah Brzozowski wrote: >> >>> >> >>> Certainly I am not intending to change the community and require >> every mapper to comply. If you're an experienced mapper, you're fine. >> >>> >> >>> I mean new users, who are not yet integrated with the community. >> Their work should be checked thoroughly (in Achavi, osmcha...). All novices >> make mistakes, after all. Better to give them good habits. By extension, >> smaller number of changeset will lead to less recycling of same changeset >> comments. >> >>> >> >>> I made this thread because I found it difficult to convey what is >> best practice in short form in changeset comments. >> >>> >> >>> Maybe I should simplify things when explaining to them? No need to >> tell all the conventions, just what is a good start - but hoping it won't >> backfire ;) >> >>> >> >>> 17.01.2018 3:35 PM "Imre Samu" <[email protected]> napisał(a): >> >>>> >> >>>> > one changeset per building, repeated 20 times >> >>>> >> >>>> my typical use case: House numbering on the street: push the >> numbers & forget & go to the next house ( fast feedback loop vs. Delayed >> gratification ) >> >>>> - sometimes the mobil app is crashing, and I don't want to go back >> 100m to re-enter - the last 5-10 numbers >> >>>> >> >>>> >> >>>> > Obviously this makes them PITA to review quickly in Achavi or >> whatever tool you use. >> >>>> >> >>>> imho: it is easier to group the changeset on the reviewer side : by >> user + by hour ( group by user, hour ) than change the community. >> >>>> >> >>>> Imre >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> 2018-01-17 15:13 GMT+01:00 Michał Brzozowski <[email protected]>: >> >>>>> >> >>>>> Certainly not: >> >>>>> - one changeset per building, repeated 20 times >> >>>>> - one changeset for 3 POIs that are 1000 km apart in different >> countries >> >>>>> >> >>>>> These are real world examples. In the latter Achavi can often >> refuse to run. >> >>>>> >> >>>>> That's also why I asked ;-) It's not that easy to formulate the >> answer what is reasonable to include in a changeset. >> >>>>> >> >>>>> Michał >> >>>>> >> >>>>> 17.01.2018 2:54 PM "Tobias Zwick" <[email protected]> napisał(a): >> >>>>>> >> >>>>>> So, what is the optimal changeset size, and why? >> >>>>>> >> >>>>>> Tobias >> >>>>>> >> >>>>>> On 17/01/2018 14:26, Michał Brzozowski wrote: >> >>>>>> > Many new users have a habit of e.g. sending one or few objects >> per >> >>>>>> > changeset, resulting in a dozen or even more changesets per day. >> >>>>>> > Obviously this makes them PITA to review quickly in Achavi or >> whatever >> >>>>>> > tool you use. >> >>>>>> > >> >>>>>> > This habit is probably caused by non-knowledge of how auto-save >> works in >> >>>>>> > iD (which makes the work reasonably secure), as well as just not >> knowing >> >>>>>> > better thus forming their own judgement. >> >>>>>> > >> >>>>>> > How should we teach about optimal changeset size? This is quite >> tricky - >> >>>>>> > how we would define it? >> >>>>>> > >> >>>>>> > Can the iD nudge users towards better practice? (Linking to Good >> >>>>>> > changeset comments wiki page would be useful as well) >> >>>>>> > >> >>>>>> > Michał >> >>>>>> > >> >>>>>> > >> >>>>>> > _______________________________________________ >> >>>>>> > talk mailing list >> >>>>>> > [email protected] >> >>>>>> > https://lists.openstreetmap.org/listinfo/talk >> >>>>>> > >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> talk mailing list >> >>>>>> [email protected] >> >>>>>> https://lists.openstreetmap.org/listinfo/talk >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> talk mailing list >> >>>>> [email protected] >> >>>>> https://lists.openstreetmap.org/listinfo/talk >> >>>>> >> >>>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ talk mailing list >> [email protected] https://lists.openstreetmap.org/listinfo/talk >> >> >> >> >> >> >> >> _______________________________________________ >> >> talk mailing list >> >> [email protected] >> >> https://lists.openstreetmap.org/listinfo/talk >> >> >> > >> > >> > >> > -- >> > Gaurav Thapa >> > Project Manager >> > Secondary Cities Pokhara Project >> > Kathmandu Living Labs >> > >> > _______________________________________________ >> > talk mailing list >> > [email protected] >> > https://lists.openstreetmap.org/listinfo/talk >> > >> > > > > -- > Gaurav Thapa > Project Manager > Secondary Cities Pokhara Project > Kathmandu Living Labs > > _______________________________________________ > talk mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk > >
_______________________________________________ talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk
