If we follow the idea of "mapping what's on the ground", then it seems reasonable to say that none of the tags we have discussed so far represents the ground more objectively than the "surface" tag. All other tags attempt to describe how the ground behaves in different situations (when used for transit by different kinds of vehicles or by people). But since "surface" has more uses than for routing decisions (be them automated or made visually), it would have to be mapped anyway. When I suggested combining tracktype+smoothness+mtb:scale+sac_scale into a single surface classification tag, I didn't mean to discard the surface tag (I've put it in that equivalence table only for comparison).
Since I understand that "tracktype" and "smoothness" are intended for a similar purpose (representation of "trafficability"), I think that smoothness=bad would need to be broken down into 4 new values in order for that tag to gain acceptance with people who advocate for the tracktype tag (see that equivalence table that I tried to compile). These values could then be named: "not_that_bad", "little_bad", "kinda_bad", and "quite_bad". :P For tracktype to be acceptable to those who advocate for the smoothness tag, we need these new values: "grade1b", "grade1c" and "grade2b". Suppose we add these values to both tags. Then, I'd consider almost equivalent in practice. Then, it makes sense to pick only one of them. I'd choose "smoothness" only because it's been designed with more vehicle types and also with bikes and wheelchairs in mind. But I don't like how its values are named and I'd support changing that if that's the way we go. If we can't change its values, then I'd pick tracktype. Either choice (tracktype or smoothness) would completely ignore the needs of pedestrians and cyclists (as my last graph reveals), lumping in the same 2 classes (grade7/grade8 or horrible/very_horrible) ways of various conditions for these users. One can assume that these users would happily continue to use mtb:bike and sac_scale for further "trafficability" refinement. But you see, we'd still have 3 tags to express "trafficability", each becoming more relevant at a different point of the trafficability spectrum. Maybe I'm rushing things and we first need to decide on tracktype vs smoothness and, if we can agree on something, then decide if such chosen tag has any value for the desired rendering decision that started this debate. I believe either of them do, so whatever we choose, it's fine for me, because all I wish right now is to arrive at a well agreed system that allows us to render these "bad" roads using Mapnik's default OSM-Carto style. On Fri, Jan 3, 2014 at 10:07 PM, Dominic Hosler <dominichos...@gmail.com> wrote: > Hi, > I've been observing for a while but I want to chime in on the discussion. > > Let's not forget that mapping for OSM is not about the rendering, it's about > mapping what is actually on the ground. Therefore we are actually discussing > two different but related issues. > > The first is how to appropriately capture the physical state of the road, > perhaps considering different seasons / weather possibilities. The second is > how should we suggest that the default map tiles be rendered to show that > some roads are 'more difficult' to travel using a certain category of > vehicles. > > In my opinion the tagging should not include user specific descriptions like > 'bad' because of the obvious 'bad for what?' questions. I think that the > current 'surface=' tag does a good job at specifying the material from which > the road is made. Personally I think we should leave the surface tag as it > is, and maybe use the values to guess defaults for the condition. I do think > that there should be some other tag to describe the condition. The > suggestion of adding a 'surface:sealed=yes|no' seems to me a good idea, not > that I have much experience of any rough roads. We seem to be requiring a > standardised, not open ended, description of the quality of the road, to > extend the information of it's construction material. > > I think we should combine the surface tag with smoothness, and make it > easier to understand for mappers. It should be well defined in the wiki with > example pictures as to what type of quality (frequency / depth of holes, > cracks or anything) corresponds to what value for smoothness. Personally I > am against combining it all into one tag, because that reduces the detail of > the maps, thus reducing the usefulness for those that render their own maps > for certain niche requirements. A combination of smoothness and surface > would be good. Possibly even including 'surface:stable=yes|no' to declare if > short term conditions (weather / seasons) will affect the surface. These two > or three tags should efficiently describe what is actually on the ground, > then we leave it to the renderer to decide how to display it according to > the users that renderer is targeting. > > My opinion on the rendering is that there are already a number of usage > specific rendering and routing engines. Some render tags specific to > cyclists, some for lorries. I agree that the default map tiles should have a > different rendering for something along the lines of 'normal cars will have > to be careful / struggle on this road'. The exact line drawing of exactly > what would count as that would have to be decided and other use cases who > require a different setting may need to design their own rendering styles. > > Dominic. > > > On 3 January 2014 22:20, Fernando Trebien <fernando.treb...@gmail.com> > wrote: >> >> My bad, I thought "Carto" was the name of the main Mapnik style. So >> I'm referring to openstreetmap-carto. >> >> Well, I was trying to expose my idea that the multiple current >> classifications of "trafficability" may not be necessary at all. >> >> On Fri, Jan 3, 2014 at 6:35 PM, Andy Townsend >> <li...@mail.atownsend.org.uk> wrote: >> > >> > On 03/01/14 19:56, Fernando Trebien wrote: >> >> >> >> Well, when proposing this, I'm trying to avoid these problems: >> >> - the set of paved and the set of unpaved surfaces is not closed, and >> >> so it would require us to continuously update Carto with new surface >> >> types >> > >> > >> > I'm a bit confused by what you mean by "carto" here. The tool itself >> > just >> > converts from a CartoCSS stylesheet (such as you can create/edit >> > relatively >> > easily with TileMill): >> > >> > http://wiki.openstreetmap.org/wiki/CartoCSS >> > >> > The stylesheet used for the OSM standard map is: >> > >> > https://github.com/gravitystorm/openstreetmap-carto >> > >> > and for the HOT map is: >> > >> > https://github.com/hotosm/HDM-CartoCSS >> > >> > So there isn't just one "Carto" rendering. Also, there's not likely >> > ever >> > going to be "an agreement between everyone" about what sort of >> > "suitability >> > for X sort of traffic" is represented on the "standard" map. Personally >> > I'd >> > argue that the whole tracktype / path / footway / bridleway rendering >> > area >> > is "too complicated" now for lay users, rather than "not complicated >> > enough". We've already had help questions on the lines of "what's that >> > brown stain on the map": >> > >> > https://help.openstreetmap.org/questions/13521/icon-explanation >> > >> > So the answer surely has to be different rendered maps for different >> > purposes - someone who's creating an MTB map can render the MTB tags, >> > someone who's mapping an area where "smoothness" is used in a sane >> > manner >> > can map that, etc. If someone wants to come up with a big x-dimensional >> > matrix that combines various tracktype / smoothness / mtb / whatever >> > tags >> > into a numeric value, they can do that too. >> > >> > The good news is that it's actually easier than ever to do that now as >> > osm2pgsql now supports external tag transformations using a lua script: >> > >> > https://help.openstreetmap.org/questions/28465/osm2pqsql-and-lua >> > >> > https://github.com/openstreetmap/osm2pgsql/blob/master/README_lua.md >> > >> > It's so easy that even someone like me (with less design expertise than >> > the >> > average three-year-old with a crayon) can do it to render other values >> > instead of tracktype without changing the openstreetmap-carto stylesheet >> > at >> > all: >> > >> > https://github.com/SomeoneElseOSM/designation-style >> > >> > So if you think an extra tag makes sense ("trafficability" or something >> > else), start using it locally, create a map using it, and ask people >> > what >> > they think. >> > >> > Similarly, if you think that some numerical combination of existing or >> > new >> > tags to create a "new tracktype" would work, create a map using that. >> > >> > Cheers, >> > >> > Andy >> > >> > >> > >> > _______________________________________________ >> > 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 > > > > _______________________________________________ > 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
