I agree that this deserves a separate topic, but I want to respond to some points you made.
I don't like the highway_defaults idea. Default values should be assumed whenever they are not explicitly given. I don't think that a tag that states "most of those are probably going to be correct" is useful. In general, we don't even have a way of saying "everything is OK here". Feel free to disagree, but I think that the most reasonable path is relying on users reporting discrepancies. I'd simply apply the defaults everywhere and, if someone notices an error, it will get fixed. Tagging "this default is correct" will lead to the same DB bloat as not having defaults. Using the most common value as default has a major problem: the most common values are oneway=yes, tunnel=yes, ford=yes. I think that exceptions to the rule should be tagged, leaving the majority up for defaults. I'm strongly in favour of dealing with the defaults on a local basis - defining defaults for elements in a given administrative area would be a good beginning, but letting us draw the extent of individual defaults would (for example) give us an elegant way of tagging maxspeed=30 zones for free. I think that data consumers would appreciate a system, that would fill in the relevant defaults for them. I'm not entirely sure how to make it, but it sounds doable. Worst case scenario would be a special server providing an "extended" database. As a final remark, I'd consider a two-level system: Assumed values are reasonable defaults, but should be confirmed by an explicit tag when possible. Implied values are those that are almost certainly correct and only exceptions should be tagged. Assumed values are good for the consumers and can be implemented reasonably safely. This will provide an opportunity to test some of the relevant systems. Implied values are what will make the database cleaner, but are more debatable. I think they are going to be OK, provided that we are careful about adding new ones. On 5 January 2018 at 00:09, Fernando Trebien <fernando.treb...@gmail.com> wrote: > On Thu, Jan 4, 2018 at 9:57 AM, Matej Lieskovský > <lieskovsky.ma...@gmail.com> wrote: > > 1) If we try to add every possible tag to every element, the DB will be > > immense and the OWG will try to kill us. Imagine every road having access > > tags. Should roads have tunnel=no? > > I will digress a bit, as I believe this should be a separate topic. > > We could define a tag such as highway_defaults=yes to express that a > certain number of default values have been throughly verified by a > mapper, and assume that any difference from those defaults will be > mapped by adding extra tags. It could also be automatically inserted > by bots once all tags in the default tags set have been added. > > So highway_defaults=yes could include things such as: > - oneway=no for all highway types except motorway and motorway_link, > for which oneway=yes > - cycleway=no (implying cycleway:left=no, cycleway:right=no and > cycleway:both=no) for all highway types > - surface=asphalt (and perhaps lit=yes) for highway=cycleway > - tunnel=no, bridge=no, lit=yes, embankment=no, cutting=no, ford=no, > ice_road=no for all highway types > > And much more. In fact, the most common value (as reported by TagInfo > or as implied by experience) for every tag could be the default value > (subject to periodic review). A few ideas that come to my mind > immediately: > - access=* as defined in the Default table here: > https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Acc > ess-Restrictions#Default > - shoulder=no, parking:lane:both=parallel, sidewalk=both, > tactile_paving=no, wheelchair=yes for local public urban highway types > (residential, living street) > - surface=asphalt, smoothness=excellent for non-local highway types > (unclassified, tertiary, secondary, primary, trunk, motorway) > - shoulder=yes, sidewalk=no for motorway and motorway_link and perhaps > trunk and trunk_link > - service=driveway for highway=service > - tracktype=grade3 for highway=track > - wall=no for buildings and landuse > - material=wood for power towers and power poles > - frequency=50 for power lines > > We would also have to contact the developers of several important apps > to request support for such a tag. In the case of cycleways, that > would be Thunderforest / OpenCycleMap. For the other tags, ITO World > comes to my mind. And of course, StreetComplete too. And iD still > needs to warn the user about absent tags when combining ways. And we > have to update the wiki article of several tags to list their default > values. That's a ton of work, but if database efficiency and mapper > effort is a concern, maybe it's worth doing. (I honestly think it is, > but it requires more discussion and a proposal for voting.) > > And also something similar could be done for other modes of > transportation, such as railway=* and waterway=*. > > > 2) Data consumers will sometimes still need to guess the value, which > means > > a default still needs to be known. > > They already do, and especially those providing global services are > doing so incorrectly as none that I know of support definitions that > vary between countries, such as the differences in access=* defaults. > But I think global defaults would already mitigate a great part of the > problem. > > > On 4 January 2018 at 02:22, Fernando Trebien <fernando.treb...@gmail.com > > > > wrote: > >> > >> Tag absence has never been defined clearly in OSM. Some think of it as > >> meaning "the tag has the default value," others think "the value of the > tag > >> is still unknown," which seems to be the most common understanding > (that's > >> why noname=* exists). > >> > >> I always add tags in their default value to express that the value is > >> known and has been surveyed, cycleways included. (though in the case of > >> cycleways I usually only add them around existing cycleways to avoid > >> confusion and to prevent mappers - especially those using iD - from > >> combining sequential ways without getting a warning) > >> > >> Em 25 de dez de 2017 23:34, "Dave Swarthout" <daveswarth...@gmail.com> > >> escreveu: > >>> > >>> This sounds similar to those that suggested adding oneway=no to all > >>> streets that are not explicitly tagged as oneway=yes. All roads without > >>> cycleways could conceivably be tagged this way. > >>> Unless there is some cause for such a tag, for example, noting that a > >>> cycleway once existed here but is no longer present, this tag is > totally > >>> unnecessary and adds needless data to OSM. > >>> > >>> On Tue, Dec 26, 2017 at 6:50 AM, marc marc <marc_marc_...@hotmail.com> > >>> wrote: > >>>> > >>>> Hello, > >>>> > >>>> Le 26. 12. 17 à 00:22, Dave F a écrit : > >>>> > >>>> > There's been quite a few recent additions of 'cycleway:both=no' > being > >>>> > added by users of StreetComplete. > >>>> > > >>>> > http://www.openstreetmap.org/way/8609990 > >>>> > > >>>> > There's no mention of this tag on the wiki & to me appears a bit > >>>> > ambiguous. Most (all?) are the sole cycle tag on the entity. Both=no > >>>> > suggests that a cycleway could exist in one direction. > >>>> > >>>> I agree that cycleway:both=no is not a good tag. > >>>> cycleway=no is better. > >>>> > >>>> > What is the reason the developers aren't using the established > tagging > >>>> > scheme: > >>>> > https://wiki.openstreetmap.org/wiki/Key:cycleway > >>>> > >>>> ask the dev :) > >>>> > >>>> > Note under 'cycleway=no' as a tag of "dubious usefulness". > >>>> > >>>> I could help to see what road have been surveyed and somebody see that > >>>> this road doesn't have a cycleway. Put in urban area, it's a (minor) > >>>> added value. Without a cycleway tag, the cycleway is unknown. > >>>> > >>>> > This email has been checked for viruses by Avast antivirus software. > >>>> > >>>> it's also a dubious usefulness :) > >>>> > >>>> Regards, > >>>> Marc > >>>> _______________________________________________ > >>>> 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 > >>> > >> > >> _______________________________________________ > >> 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 > > "Nullius in verba." > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
