"Does it look bad" can have many different answers for the same way, depending on whether you're on a bike, a car or on foot, right? How is "horrible" different from "bad" and in which situations? Honestly, there's no way you can tell everyone that they can skip the documentation and hope the result will be a map with reliable information - not to mention the number of people disagreeing on whether a particular way is just "bad" or "very horrible".
If you want a full justification of why a particular way was classified as it is, then I think you need a reasonably full description of a surface that would be useful for various kinds of routing. Considering what we've debated so far and also the characteristics that are used in many road quality assessment systems out there, this would involve collecting at least the following information, each on its own tag: - average frequency of bumps - average depth of bumps - average frequency of cracks - average width of cracks - soil grain size - soil humidity - soil compaction With that one can figure out reasonably well if a way is suitable for a wheelchair, a bike (various kinds), an elder, a passenger car, a sports vehicle, a truck, and and emergency vehicle. (And that's for basic coverage.) You don't even need to know if the surface is "concrete" or "paving_stones" or "metal". If we're not going that far, then it's inevitable to adopt certain classification systems that are somewhat arbitrary. That's what we have right now: tracktype for vehicles, smoothness for "various transport modes", mtb:scale and sac_scale for certain sports. The point I tried to make is that they could be unified with little loss of information, and from this unification we could establish a criteria to decide whether the way is remarkably "bad" and render it differently. On Fri, Jan 3, 2014 at 7:17 PM, Gerald Weber <gwebe...@gmail.com> wrote: > >> >> I don't think that unifying them all into a single tag is a bad idea. >> It would be easier while editing the map (only 1 choice to make, >> instead of 5), easier to describe to users (instead of 5 different >> tags), to consume in applications (such as the renderer, but also in >> routers), and it would also use less database space. It's a big >> culture change, but it simplifies a lot of things. Moreover, we could >> leave some space between the classes that we establish now so that >> new, intermediary classes can be added in the future (if tracktype had >> done that, maybe I'd be advocating for it right now). > > > I am sorry Fernando, but is is a bad idea. > > What I suspect will happen is that you will find yourself with highways > mapped just like this: > > highway=primary > tracktype=grade3 > > and now what? Why grade3? Why not grade2 or grade4? Is it paved? Is is not? > perhaps the mapper was lazy and just put in the first number that came to > his mind? > > The other problem I see with this is that you are asking people to do the > work the renderer is supposed to do. The renderer (be it an Android app, or > a website) needs to combine the various descriptions and come up with a > grade which may change depending on the vehicle or on weather conditions. > That is why I think your table is the sort of thing a renderer should use. > > I think this is moving into the wrong direction. We need the opposite, we > need for people to be descriptive. Is the highway paved with asphalt? > surface=asphalt. Does it look bad? smoothness=bad and so on. > > If we disagree on what surface=compacted truly means, then add a more > descriptive tag to it. A grading system cannot replace this. > > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Fernando Trebien +55 (51) 9962-5409 "The speed of computer chips doubles every 18 months." (Moore's law) "The speed of software halves every 18 months." (Gates' law) _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
