Ok. Look. I wrote a long rant about how cycleway=no is a horrible idea and then I deleted it. I have no idea where you map, but here, >90% of roads never even heard about cycleways. For us here, it makes sense to consider cycleway=no to be implicit, as the information that someone surveyed it is not worth the extra tags. Your location might differ, and in that case I envy you. Now, you want to have cycleway=no explicitly tagged. I want to stop the spam of cycleway=no tags. Someone in the Netherlands might want to assume cycleway=both as the default. (The cycleway tag is just an example here.) Could we perhaps agree that we need a way to list assumed and implied values on a smaller than global level? And ideally have a formal way of writing that down? You set cycleway=no as assumed for your region. I set cycleway=no as implied for mine. Our fictional friend from the cyclist's heaven-on-earth sets cycleway=both as assumed or even implied. Changes to this policy will move to local talks. Data consumers will have a list of rules to apply instead of having to guess. Everyone will live happily for ever after. Sounds good?
On 5 January 2018 at 11:04, Fernando Trebien <[email protected]> wrote: > Well, by not adding tags with assumed default values, we simply cannot > distinguish them from the situation where they have not been verified. > > For instance, some mappers don't care about cycleways but still map > streets. How can somebody that cares about cycleways know that they > should verify the presence of cycleways on ways surveyed by others? > Now suppose this mapper then surveys a big area and finds no cycleways > there. How can this person tell others they don't need to repeat the > survey? By adding cycleway=no to all the streets this becomes obvious. > By not adding them, there will be further unnecessary surveys. Mapper > effort that could have been invested in other more valuable activities > is therefore wasted. > > On Fri, Jan 5, 2018 at 2:15 AM, Matej Lieskovský > <[email protected]> wrote: > > 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 <[email protected] > > > > wrote: > >> > >> On Thu, Jan 4, 2018 at 9:57 AM, Matej Lieskovský > >> <[email protected]> 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/ > Access-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 > >> > <[email protected]> > >> > 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" < > [email protected]> > >> >> 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 < > [email protected]> > >> >>> 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 > >> >>>> [email protected] > >> >>>> https://lists.openstreetmap.org/listinfo/tagging > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Dave Swarthout > >> >>> Homer, Alaska > >> >>> Chiang Mai, Thailand > >> >>> Travel Blog at http://dswarthout.blogspot.com > >> >>> > >> >>> _______________________________________________ > >> >>> Tagging mailing list > >> >>> [email protected] > >> >>> https://lists.openstreetmap.org/listinfo/tagging > >> >>> > >> >> > >> >> _______________________________________________ > >> >> Tagging mailing list > >> >> [email protected] > >> >> https://lists.openstreetmap.org/listinfo/tagging > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Tagging mailing list > >> > [email protected] > >> > https://lists.openstreetmap.org/listinfo/tagging > >> > > >> > >> > >> > >> -- > >> Fernando Trebien > >> +55 (51) 9962-5409 > >> > >> "Nullius in verba." > >> > >> _______________________________________________ > >> Tagging mailing list > >> [email protected] > >> https://lists.openstreetmap.org/listinfo/tagging > > > > > > > > _______________________________________________ > > Tagging mailing list > > [email protected] > > https://lists.openstreetmap.org/listinfo/tagging > > > > > > -- > Fernando Trebien > +55 (51) 9962-5409 > > "Nullius in verba." > > _______________________________________________ > Tagging mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
