[Tagging] Relations (was directions)

Simone Saviolo simone.saviolo at gmail.com
Wed Aug 10 08:49:00 BST 2011


2011/8/10 Serge Wroclawski <emacsen at gmail.com>

> On Tue, Aug 9, 2011 at 7:13 PM, Simone Saviolo <simone.saviolo at gmail.com>
> wrote:
>
> > if we make a system that any newcomer can
> > use completely without even having to dwelve into the details, then we're
> > basically dumbing it down and limiting its potential.
>
> I think we're venturing a bit off topic, but you're keying on to a
> difference in how various people see the project, and while I don't
> want to venture too far into navel gazing, seeing this difference
> really helps underly the differences between how we approach tagging,
> and other aspects of the project.
>
> First, I think it's important to remember that I don't think anyone is
> advocating removing any existing object types or object
> classifications, but rather providing feedback to the tagging process
> about how best to represent something in OSM.
>

To this extent and talking about the specific case, I agree with the author
of the proposal that his solution is "the best available" method to
represent the direction of an object. Others differ, and I accept that.
Others disagree simply because it's not a tag, and I'm not ok with that.


> In other words, no one's talking about taking relations away, but
> putting the breaks on a bit where it comes to making new relation
> types.
>

I agree on this. But, judging from the discussion that ensued, it seems that
no new relation should be used because it's hard to edit, and this seems a
wrong approach to me.


> Now onto your concern about "dumbing down" OSM.
>
> Honestly, I don't like that term, because it implies that simple =
> dumb. That's just not true.
>

I think it is true, in this case. When you make something simpler than it
was, there may be two reasons for that. The first is that the current
approach is overly complicated, and streamlining it would make it smarter,
more stable, less error prone. The second is that you just want to make it
less error prone. While this is a noble intent anyway, you have to make sure
that you're not removing flexibility, otherwise you're making it simpler AND
dumber.

Newcomers have a hard time understanding C++ templates (experts make errors
too, sometimes). Does this mean that they should be removed from the
standard? No, because, as steep their learning curve is, there's a whole lot
of stuff that couldn't be done without templates - or that could be done in
much more complicated ways.

So, what does this mean? That users should be more educated, and while
they're not they should limit themselves to easier things. Of course, the
advanced features would have to be made somehow transparent to them: if I'm
a newbie and am barely able to add a name=* tag, in case I edit an object
that is part of a relation then the editor should allow me to do so with the
minimum possible interference on the relation.

When I first got into Linux, I had to compile a new kernel when I got
> new hardware, and if I changed monitors, I had to edit the X config
> myself by hand. Now I don't do that. I'm not any dumber.
>

This doesn't mean that Linux got simpler. I remember having to measure the
physical size of my Full-HD monitor in order to set the correct physical
resolution into I-can't-remember-which config file. Hopefully, now the
process is *easier* because there are better tools, or because someone wrote
down the physical size of most monitors. This doesn't mean that the process
is *simpler*.

I was glad to see an installer tool with a GUI in Kubuntu: dpkg and its
options, though commonly used, were not simple at all. But the GUI is
probably just offering a visual checkbox and translates that to an option in
the command line for dpkg. This is what should be done with OSM too for
newcomers: better tools.

In his recent talk, Andy Allen presented an excellent case for why we
> need more mappers, and the value of a simple, clean interface for
> mappers:
>
> http://sotm-eu.org/talk?52
>
> When I've taught mappers, I've come to the conclusion that keeping
> things simple is the best way to encourage more mappers to map, and
> more mappers means more accuracy and more detail.
>

I agree to a point. Now of course I'm not going to discuss the policies on
recruitment of new mappers, but I'm not sure that lowering the learning
curve would be all good. Having to learn how to map what you're interested
in may work as a bit of lock-in: it took you one hour to learn about this on
the wiki, and you've been trying and getting feedback on your attempts for
two weeks, now tell me you're going to give up mapping because you're bored
with it! On the other hand, I know people who started mapping by drawing
lines and marking the street names, and left after a week, because they lost
their shallow interest and felt they were ok with the small contribute they
had given. Not that their contribute is to be rejected, but what's the point
in having new mappers who abandon the project in a week?

But it's not just entirely new mappers that we're talking about, but
> experienced mappers too. I clean up mistakes from experienced mappers
> almost as often as new mappers! Tools like Potlatch 2 which provide
> simple interfaces to the data don't "dumb down" the results, they
> actually seem to increase the quality of the data!
>

Ok, but there are use cases where simple things don't suffice. In the case
at hand, for example, using something like direction=forward doesn't work in
all the use cases. And using direction=<angle in degrees> is in no way
simpler (can you figure a newcomer trying to work out the angle? What's the
reference? Should I use degrees, decimal degrees, radians? Should I use
minutes and seconds for the fractional part (the horror)? Should I be
content with something like direction=225 or be more precise and use
direction=221,32? You know what, nevermind, I'll use Streetview instead).


> - Serge


Best regards,

Simone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20110810/a5325291/attachment.html>


More information about the Tagging mailing list