[OSM-talk] How to teach novices about optimal changeset size?

Sat Jan 20 15:06:26 UTC 2018

> 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 <gthapa.work at gmail.com> 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 <althio.forum at gmail.com> 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" <gthapa.work at gmail.com> 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 <mike at ayeltd.biz>
>> 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" <pella.samu at gmail.com> 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 <www.haxor at gmail.com>:
>> >>>>>
>> >>>>> 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" <osm at westnordost.de> 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
>> >>>>>> > talk at openstreetmap.org
>> >>>>>> > https://lists.openstreetmap.org/listinfo/talk
>> >>>>>> >
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> talk mailing list
>> >>>>>> talk at openstreetmap.org
>> >>>>>> https://lists.openstreetmap.org/listinfo/talk
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> talk mailing list
>> >>>>> talk at openstreetmap.org
>> >>>>> https://lists.openstreetmap.org/listinfo/talk
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________ talk mailing list
>> talk at openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> talk mailing list
>> >> talk at openstreetmap.org
>> >> https://lists.openstreetmap.org/listinfo/talk
>> >>
>> >
>> >
>> >
>> > --
>> > Gaurav Thapa
>> > Project Manager
>> > Secondary Cities Pokhara Project
>> > Kathmandu Living Labs
>> >
>> > _______________________________________________
>> > talk mailing list
>> > talk at openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk
>> >
>>
>
>
>
> --
> Gaurav Thapa
> Project Manager
> Secondary Cities Pokhara Project
> Kathmandu Living Labs
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20180120/a8cde9fd/attachment-0001.html>