<div dir="ltr">I agree that this deserves a separate topic, but I want to respond to some points you made.<div><br></div><div>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.<br><div class="gmail_extra"><br></div><div class="gmail_extra">Using the most common value as default has a major problem:</div><div class="gmail_extra">the most common values are <span class="" id=":2fl.1" tabindex="-1" style="">oneway</span>=yes, tunnel=yes, ford=yes.</div><div class="gmail_extra">I think that exceptions to the rule should be tagged, leaving the majority up for defaults.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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 <span class="" id=":2fl.2" tabindex="-1" style="">maxspeed</span>=30 zones for free.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">As a final remark, I'd consider a two-level system:</div><div class="gmail_extra">Assumed values are reasonable defaults, but should be confirmed by an explicit tag when possible.</div><div class="gmail_extra">Implied values are those that are almost certainly correct and only exceptions should be tagged.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On 5 January 2018 at 00:09, Fernando <span class="" id=":2fl.3" tabindex="-1" style="">Trebien</span> <span dir="ltr"><<a href="mailto:fernando.trebien@gmail.com" target="_blank"><span class="" id=":2fl.4" tabindex="-1" style="">fernando</span>.<span class="" id=":2fl.5" tabindex="-1" style="">trebien</span>@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, Jan 4, 2018 at 9:57 AM, Matej Lieskovský<br>
<<a href="mailto:lieskovsky.matej@gmail.com" target="_blank">lieskovsky.matej@gmail.com</a>> wrote:<br>
> 1) If we try to add every possible tag to every element, the DB will be<br>
> immense and the OWG will try to kill us. Imagine every road having access<br>
> tags. Should roads have tunnel=no?<br>
<br>
</span>I will digress a bit, as I believe this should be a separate topic.<br>
<br>
We could define a tag such as highway_defaults=yes to express that a<br>
certain number of default values have been throughly verified by a<br>
mapper, and assume that any difference from those defaults will be<br>
mapped by adding extra tags. It could also be automatically inserted<br>
by bots once all tags in the default tags set have been added.<br>
<br>
So highway_defaults=yes could include things such as:<br>
- oneway=no for all highway types except motorway and motorway_link,<br>
for which oneway=yes<br>
- cycleway=no (implying cycleway:left=no, cycleway:right=no and<br>
cycleway:both=no) for all highway types<br>
- surface=asphalt (and perhaps lit=yes) for highway=cycleway<br>
- tunnel=no, bridge=no, lit=yes, embankment=no, cutting=no, ford=no,<br>
ice_road=no for all highway types<br>
<br>
And much more. In fact, the most common value (as reported by TagInfo<br>
or as implied by experience) for every tag could be the default value<br>
(subject to periodic review). A few ideas that come to my mind<br>
immediately:<br>
- access=* as defined in the Default table here:<br>
<a href="https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Default" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org<wbr>/wiki/OSM_tags_for_routing/Acc<wbr>ess-Restrictions#Default</a><br>
- shoulder=no, parking:lane:both=parallel, sidewalk=both,<br>
tactile_paving=no, wheelchair=yes for local public urban highway types<br>
(residential, living street)<br>
- surface=asphalt, smoothness=excellent for non-local highway types<br>
(unclassified, tertiary, secondary, primary, trunk, motorway)<br>
- shoulder=yes, sidewalk=no for motorway and motorway_link and perhaps<br>
trunk and trunk_link<br>
- service=driveway for highway=service<br>
- tracktype=grade3 for highway=track<br>
- wall=no for buildings and landuse<br>
- material=wood for power towers and power poles<br>
- frequency=50 for power lines<br>
<br>
We would also have to contact the developers of several important apps<br>
to request support for such a tag. In the case of cycleways, that<br>
would be Thunderforest / OpenCycleMap. For the other tags, ITO World<br>
comes to my mind. And of course, StreetComplete too. And iD still<br>
needs to warn the user about absent tags when combining ways. And we<br>
have to update the wiki article of several tags to list their default<br>
values. That's a ton of work, but if database efficiency and mapper<br>
effort is a concern, maybe it's worth doing. (I honestly think it is,<br>
but it requires more discussion and a proposal for voting.)<br>
<br>
And also something similar could be done for other modes of<br>
transportation, such as railway=* and waterway=*.<br>
<span><br>
> 2) Data consumers will sometimes still need to guess the value, which means<br>
> a default still needs to be known.<br>
<br>
</span>They already do, and especially those providing global services are<br>
doing so incorrectly as none that I know of support definitions that<br>
vary between countries, such as the differences in access=* defaults.<br>
But I think global defaults would already mitigate a great part of the<br>
<div><div class="m_-7276141651803988588h5">problem.<br>
<br>
> On 4 January 2018 at 02:22, Fernando Trebien <<a href="mailto:fernando.trebien@gmail.com" target="_blank">fernando.trebien@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Tag absence has never been defined clearly in OSM. Some think of it as<br>
>> meaning "the tag has the default value," others think "the value of the tag<br>
>> is still unknown," which seems to be the most common understanding (that's<br>
>> why noname=* exists).<br>
>><br>
>> I always add tags in their default value to express that the value is<br>
>> known and has been surveyed, cycleways included. (though in the case of<br>
>> cycleways I usually only add them around existing cycleways to avoid<br>
>> confusion and to prevent mappers - especially those using iD - from<br>
>> combining sequential ways without getting a warning)<br>
>><br>
>> Em 25 de dez de 2017 23:34, "Dave Swarthout" <<a href="mailto:daveswarthout@gmail.com" target="_blank">daveswarthout@gmail.com</a>><br>
>> escreveu:<br>
>>><br>
>>> This sounds similar to those that suggested adding oneway=no to all<br>
>>> streets that are not explicitly tagged as oneway=yes. All roads without<br>
>>> cycleways could conceivably be tagged this way.<br>
>>> Unless there is some cause for such a tag, for example, noting that a<br>
>>> cycleway once existed here but is no longer present, this tag is totally<br>
>>> unnecessary and adds needless data to OSM.<br>
>>><br>
>>> On Tue, Dec 26, 2017 at 6:50 AM, marc marc <<a href="mailto:marc_marc_irc@hotmail.com" target="_blank">marc_marc_irc@hotmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Hello,<br>
>>>><br>
>>>> Le 26. 12. 17 à 00:22, Dave F a écrit :<br>
>>>><br>
>>>> > There's been quite a few recent additions of 'cycleway:both=no' being<br>
>>>> > added by users of StreetComplete.<br>
>>>> ><br>
>>>> > <a href="http://www.openstreetmap.org/way/8609990" rel="noreferrer" target="_blank">http://www.openstreetmap.org/w<wbr>ay/8609990</a><br>
>>>> ><br>
>>>> > There's no mention of this tag on the wiki & to me appears a bit<br>
>>>> > ambiguous. Most (all?) are the sole cycle tag on the entity. Both=no<br>
>>>> > suggests that a cycleway could exist in one direction.<br>
>>>><br>
>>>> I agree that cycleway:both=no is not a good tag.<br>
>>>> cycleway=no is better.<br>
>>>><br>
>>>> > What is the reason the developers aren't using the established tagging<br>
>>>> > scheme:<br>
>>>> > <a href="https://wiki.openstreetmap.org/wiki/Key:cycleway" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org<wbr>/wiki/Key:cycleway</a><br>
>>>><br>
>>>> ask the dev :)<br>
>>>><br>
>>>> > Note under 'cycleway=no' as a tag of "dubious usefulness".<br>
>>>><br>
>>>> I could help to see what road have been surveyed and somebody see that<br>
>>>> this road doesn't have a cycleway. Put in urban area, it's a (minor)<br>
>>>> added value. Without a cycleway tag, the cycleway is unknown.<br>
>>>><br>
>>>> > This email has been checked for viruses by Avast antivirus software.<br>
>>>><br>
>>>> it's also a dubious usefulness :)<br>
>>>><br>
>>>> Regards,<br>
>>>> Marc<br>
>>>> ______________________________<wbr>_________________<br>
>>>> Tagging mailing list<br>
>>>> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
>>>> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/tagging</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Dave Swarthout<br>
>>> Homer, Alaska<br>
>>> Chiang Mai, Thailand<br>
>>> Travel Blog at <a href="http://dswarthout.blogspot.com" rel="noreferrer" target="_blank">http://dswarthout.blogspot.com</a><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> Tagging mailing list<br>
>>> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
>>> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/tagging</a><br>
>>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Tagging mailing list<br>
>> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
>> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/tagging</a><br>
>><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Tagging mailing list<br>
> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/tagging</a><br>
><br>
<br>
<br>
<br>
--<br>
</div></div>Fernando Trebien<br>
<a href="tel:%2B55%20%2851%29%209962-5409" value="+555199625409" target="_blank">+55 (51) 9962-5409</a><br>
<br>
"Nullius in verba."<br>
<div class="m_-7276141651803988588HOEnZb"><div class="m_-7276141651803988588h5"><br>
______________________________<wbr>_________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/tagging</a><br>
</div></div></blockquote></div><br></div></div></div>