On Fri, Jan 5, 2018 at 10:23 AM, Matej Lieskovský <lieskovsky.ma...@gmail.com> wrote: > 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.
I map in southern Brazil and we have far fewer cycleways than the countries in central Europe. > Now, you want to have cycleway=no explicitly tagged. I want to represent somehow the knowledge about the absence of a cycleway, which is different from not having knowledge about it whatsoever (meaning "we don't know if there is a cycleway"), so that surveying can be properly prioritized. Much of the data in OSM was imported from sources that did not have that data, so we can't know. > I want to stop the spam of cycleway=no tags. Fair enough. But let's first define what is spam and what is useful expression of absence. > Someone in the Netherlands might want to assume > cycleway=both as the default. (The cycleway tag is just an example here.) There are many more residential ways than ways of any other type, and cycleways are not common in residential streets in the Netherlands AFAIK. > 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? Regarding cycleways, all apps that I know of assume cycleway=no when the cycleway tag is absent. cycleway=no, however, means we "know" there is no cycleway, which is different from "assuming" there is none. > Sounds good? Honestly, it depends. I would be quite annoyed if someone wrote a bot and started removing cycleway=no where I've added it so far. I see your point, but I can't agree that cycleway=no is something to be avoided everywhere and in every case. What I suggest is that we define when it is desirable, and then contact the developer of StreetComplete so that the app provides proper instructions to its users. Now, to be honest, it would help a lot if iD considered absent tags to mean different tags and prevented combining them when one has a cycleway and the other has not. Or maybe iD could assume certain default values and allow combining ways with different tags in some situations, so that cycleway=no and no cycleway=* could be combined, but not cycleway=yes and no cycleway=*. > On 5 January 2018 at 11:04, Fernando Trebien <fernando.treb...@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.ma...@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.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/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.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 >> > >> >> >> >> -- >> 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 > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
