I like what Dominic is saying quite a bit. The more complicated we make the assignment of values to describe usability or trafficability the more people will simply opt for the lowest common denominator, the easiest choice. I can guarantee that I will not be going out and measuring the frequency and depth of holes in the highways I travel on. Call me lazy if you will but Thailand, where I map, has so many roads that are not yet on OSM in any form that I simply don't have the time for this even if I agree with the idea in principle.
> Based on the agreed practice in Brazil, I would tag this one either as > highway=unclassified or highway=track, depending on how much this is > in use and what it connects (I cannot determine this from pictures > alone) with surface=dirt or surface=ground. One other point I want to make. I read this sentence several times in the above discussion and want to comment on it. Whether a highway is tagged as unclassified has nothing to do with its surface or its usability but depends on whether it has received a certain kind of recognition of importance by the people who administer the roads in your area. Does it have a route number or other designated reference number? If so it is a classified highway and has the further characteristic of tertiary, primary, or what have you. Here in Thailand there are many roads that are paved, smooth, but have no designated route numbers. We tag those roads as unclassified. So let's not confuse the issue of usability with classified or unclassified. From the Wiki Project Thailand: Typically unclassified roads in Thailand are the roads having no designated number and connect villages to major highways. Unclassified is used for minor public roads typically at the lowest level of the interconnecting grid network. Unclassified roads have lower importance in the road network than tertiary roads, and are not residential streets or agricultural tracks. Unclassified roads are considered usable by motor cars. On Sat, Jan 4, 2014 at 7:07 AM, 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 > > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
