2011/8/10 Serge Wroclawski <emac...@gmail.com> > On Tue, Aug 9, 2011 at 7:13 PM, Simone Saviolo <simone.savi...@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
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
