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
