[Tagging] cycleway:both=no in StreetComplete

Fri Jan 5 12:23:54 UTC 2018

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 <fernando.trebien at gmail.com>
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ý
> <lieskovsky.matej at gmail.com> 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 <fernando.trebien at gmail.com
> >
> > wrote:
> >>
> >> On Thu, Jan 4, 2018 at 9:57 AM, Matej Lieskovský
> >> <lieskovsky.matej at 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/
> 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
> >> > <fernando.trebien at 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" <
> daveswarthout at 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_irc at 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 at 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 at openstreetmap.org
> >> >>> https://lists.openstreetmap.org/listinfo/tagging
> >> >>>
> >> >>
> >> >> _______________________________________________
> >> >> Tagging mailing list
> >> >> Tagging at openstreetmap.org
> >> >> https://lists.openstreetmap.org/listinfo/tagging
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > Tagging mailing list
> >> > Tagging at openstreetmap.org
> >> > https://lists.openstreetmap.org/listinfo/tagging
> >> >
> >>
> >>
> >>
> >> --
> >> Fernando Trebien
> >> +55 (51) 9962-5409
> >>
> >> "Nullius in verba."
> >>
> >> _______________________________________________
> >> Tagging mailing list
> >> Tagging at openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
> >
> >
> >
> > _______________________________________________
> > Tagging mailing list
> > Tagging at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "Nullius in verba."
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180105/f5e64668/attachment-0001.html>