Hi Richard, Let me say up front that I'm more than happy to be "picked on" :) I'm not precious about my ideas, so if they're wrong, please demolish them as fast as possible.
Since writing my original message I did a bit more reading about the source tag, and I guess it's a bit more optional than I'd thought. And, yes, given the B key, maybe I was over-reaching a bit. It my reflect my Wikipedia bias, where source is everything. > Ed's idea of an automatically-set changeset tag is potentially a useful one. > Not to be called "source=", because having a background open doesn't mean > you're actually copying from it (I usually have one open just for context, > but do most of my mapping from GPS traces). Perhaps "background_open=". It > shouldn't be too difficult to populate this with all the backgrounds used in > the changeset. Could I humbly point out that if changesets are going to be given this importance, they're going to need a proper interface: the user will need to be able to manipulate changesets, revisit old ones, and have certainty about what changeset is currently open. The GUI should probably also hint that it's time to close one etc. Personally, I've never paid the slightest attention to them. > One problematic trait of OSM (and I'm certainly not picking on you here > Steve, many many people are a million times more guilty :) ) is people's > belief that everything can be solved through code, and in particular, by > editors insisting on/preventing certain things. I do have a belief that what people do on a computer is shaped to a large extent by the user interface they're working in. GUIs that make the socially correct behaviour easy and the socially less desirable behaviour hard are a good idea. But I agree that the knee-jerk suggestions one often sees (show an alert if x! prevent the user doing y!) fall a long way short of that ideal. I'd also say that good UI design is really, really hard, and that's why most open source projects do it so badly. There just aren't the resources to spend on it. > If only. It's an abdication of the community's responsibility to write some > decent, enticing docs, which it has so far completely failed to do in six I don't think the model of "go rtfm, then come back and drive the gui like a guru" is going to work. But good quality documentation, policy etc that can be embedded directly in context-sensitive help would be great. The recent work on taginfo is a big step in the right direction - having a single knowledge base that flows into design decisions in editors, renderers etc. > years. As we've seen with changeset comments, insisting on them doesn't mean > you always get useful ones. Rather, it means those who'd add them anyway add > them; those who wouldn't write nothing, or "...", or "Fixed Stuff", or "Fuck > you". Of course. The way to get good changeset comments is to make them valuable to the user. > The community needs to help the new mapper understand why, and when, source > tags are important. Forcing newbies to fill in something they don't > understand just doesn't work, sadly. To be clear, I wasn't advocating forcing anything. And I agree with your philosophy. > Something I'm hoping to do in the medium term is give people the ability to > choose from pre-defined tag preset files, just as you can for backgrounds > and for stylesheets. Then if you want an advanced mapper's speedy toolkit > with "source" instantly accessible, you can have it; if you want a million > shades of access tags, you can have it; yet P2 can still provide the new > mapper with a simple, comprehensible default. Is such a level of customisation warranted? These kinds of things seem to very rapidly lead to huge amounts of confusing choice with debatable value. Then you have dozens of unmaintained, broken (because they didn't get updated to the latest format) tag preset files to choose from... (Anyway, that's just a mooted future feature I guess so I'll wait till I see it. :)) Steve _______________________________________________ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
