Is there any way we could have a filter on the History Changesets page so that it does not display changesets that are labeled as BIG.
Most of the time I am only interested in small changes in my local area and not global changes to the whole world, or large parts of it.
Agreed that this is a problem. The correct solution would require a fair amount of additional processing to generate the change list - a BIG change may have actually affected the area of interest, and the only way to know for sure is an additional query for each changeset. That’s why it hasn’t been done yet.
A simple solution would be to have an option to hide all BIG changes, but people are not comfortable with that because it could hide relevant changes.
As far as I know, Matt Amos has done a fair amount of work on trying to solve this problem in a proper way, i.e use a more sophisticated way of determining which changesets affect a given history bounding box. I don’t know what the status of that is though, but I don’t think it is ready yet. Hopefully eventually it will materialize though. Or parhaps someone else will get to a proper solution before that.
Part of my thinking in adding that “BIG” label in the first place, was to kickstart a discussion on whether BIG changesets should even be allowed. We could set a server-side rule that you’re simply no longer allowed to check in BIG changesets. I tried to set the threshold such that any normal editing activity in a particular area would not count as BIG.
This would push some complexity to the editor software, which would then need to deal with the case where a user edits in far apart places (An easy solution would be simply be to disallow the user doing that until after they’ve uploaded their current changeset. A more tricky solution would involve splitting changes geographically into two changesets)
For bots/import scripts it would be a pita …which is an advantage 
I’m mapping in Thailand. Even the primary highways of Thailand which are in general more than 100 km long are incompletly mapped in OSM. But already tertiary highways are 10 to 100 km long. When I added or enhanced highways or added villages along a highway the changeset was tagged as big. Most of my changesets were tagged as big. What is the criteria? Why is this done? Why should this be forbidden?
Currently the BIG label appears based on a crude calculation of the unprojected area of the changeset bbox. (maxlat - minlat) x (maxlon-minlon). So actually there’s some weirdness such as editing areas will trigger the BIG changeset more easily when working further away from the equator. I deliberately didn’t want to expose the area result itself, since it is a crude (but fast running) calculation, and is only intended to give a rough (is it BIG or not?) idea
After all, the changeset bounding box itself is a crude mechanism. It encompasses all elements touched by the change. In the case of a very long way, if you just move one little node sightly, this might result in a BIG changeset (if using Potlatch) But then for some uses of changesets that may be the most useful way to define the bbox. Certainly a small change to a tag, effects the whole length of a long way. small change… big changeset. Another quirk: A long way running diagonally will yield a much bigger rectangular area than a long way running east-west or north-south.
So yes you’re right. My suggestion would cause problems for working with long ways. We’d need to refine the calculations, or work out another workaround for that. e.g. We could disallow very long ways?!
I’m really just thinking aloud on this one. We’re not about to do it. I should stress that there’s nothing wrong with editing long ways (Keep up the good work!)
I don’t think disallowing large changesets is the right way to go. There may well be reasons for far distributed editing. Lets assume for the moment we agree upon bot usage and think that fixing e.g. spelling mistakes with a bot is a good thing. Then imho those changes should be in a single changeset rather than split across as they logically are one set of changes. Changing a tag on the admin boundary of Russia would be another one. The real problem simply is that a single rectangular bbox for a changeset just isn’t a sensible way of determining what is happening in an area. Tweaking this in small ways like filtering out the big changesets isn’t really solving this issue.
There are better monitoring tools though by now, such as Ito! mapper ( http://www.itoworld.com/static/osmmapper ) or OpenStreetMap Watch list, OWL ( http://matt.dev.openstreetmap.org/owl_viewer/ ), the latter still needing some UI work to make it properly useful. So we should concentrate on these and get more people helping to develop and expand them, than tweak a “broken system”.