Hi. That's curious. The tags have been like this for 4 months, so it's curious that two editors noticed the same thing almost at the same time. I was not able to determine what the intended value was, otherwise I would have made the correction instead of removing the tag. That said, looking into who added the tag and contacting them would indeed have been a more appropriate course of action. Thanks for enacting the fix yourself!

Thanks for the quick response and the detailed explanation! I'm not an expert on lane mapping but your explanation sounds reasonable based on the little that I know. I was just concerned because from the changeset itself it merely looked like the tags were removed indiscriminately. Maybe if next time you could add a bit more detail in the changeset comment it would make it more evident that the changes were intentional and considered :)

Btw, would you prefer to communicate in Portuguese? I don't know French well enough so I defaulted to English, but I've noticed that you edit frequently in Portugal, and in Braga in particular.

Hey Manuel, can you explain why you removed lane-related tags in this edit? For example way 20460864 lost a bunch of tags that described the lane-related information in detail.

I am a bit puzzled by the tag "tree_lined=separate" added to way 714490950 in this edit. Does that mean there are trees around the edge of this area? Or could this mean that the segment of Ching Tak Street (way 86041176) that passes next to this area is what should be considered "tree-lined"? Please clarify :)

Maxheight for way 1204146284 fixed in change set 155870805.

The max height for way 1204146284 is incorrect. It should be 14.58 but was entered as 1.58.

I didn't mean to say that anything that merits UIAA should be considered climbing. I can certainly agree that levels 1 and 2 may not match the definition of climbing, strictly speaking. All I'm saying is that if the tag name is inadequate, we could consider changing it, but having two tags for different values of the same scale doesn't seem like a sustainable system.

I performed this edit because it seemed like, with an order of magnitude of difference in adoption, there was de facto consensus that `climbing:grade:uiaa` is a good enough key name, even if it's not ideal. But I'm definitely open to stand corrected if you disagree with this interpretation of the status quo.

Hi Hungerburg. I'm not sure I get what you're asking me. As far as I understand, the `climbing:grade:uiaa` and `uiaa_scale` keys represent the same information (a UIAA grade as described in https://www.theuiaa.org/grades-standards/rock-climbing/), just with two different names. Are you proposing that we use `uiaa_scale` for grades 1 and 2, and `climbing:grade:uiaa` for the higher grades? I think that may be rather confusing for mappers and map consumers alike.

The `climbing:grade:uiaa` naming is described in detail in the [Climbing#Grading](osm.wiki/Climbing#Grading) wiki page, as well as in [Key:sac_scale#See also](osm.wiki/Key:sac_scale#See_also), follows a consistent nomenclature regarding other difficulty scales mentioned in the [[Climbing]] page, and is used extensively (over 11 thousand uses at the time of writing) all over the world: https://taginfo.openstreetmap.org/keys/climbing%3Agrade%3Auiaa — many of which with values under 3.

In contrast, `uiaa_scale` had an order of magnitude fewer uses, and it was not described in the wiki except in the [highway=scramble proposal](osm.wiki/Proposal:Highway%3Dscramble#Tagging), and with the hard-to-enforce restriction for use in grades 1 and 2 only.

Is your objection only because of the `climbing:` prefix? I'm sympathetic to the desire for clear nomenclature, but then we'd lose consistency with the other hiking/climbing/mountaineering difficulty tags, and I doubt it would make a dent in the sensibleness of OSM keys anyway (I mean, don't we use the `highway` key for all sorts of roads, paths, etc.?)

Hi, Michael! Thanks for the message, but I believe there may have been a misunderstanding, as I didn't touch the maxspeed tags in this edit — I only modified the sidewalk:left and sidewalk:right tags. Feel free to make any corrections you deem necessary.

I appreciate that you did — I had read the discussions before, but didn't have their detailed contents front of mind when I made this edit (I guess I just internalized back then that there was a general consensus to drop "none").

I have now commented in two of the discussions (in GitHub and in the wiki talk page) in the hopes of pushing the needle so that we finally get to a decision :)

Thanks for the comment! I actually had read that section before, and the discussions linked from it, but between the actual contents of the discussions (which seem to have mostly coalesced around agreement for deprecating "none" as long as it's explicitly documented as such), and the fact that the "none" value has been explicitly marked as deprecated in the Values table for almost 3 years now, I kind of missed that the section about the deprecation still uses a more cautious language (which IMHO seems inconsistent with the discussions and the table).

In any case, I am of course open to reverting this change, but I'd rather take the opportunity to help resolve the apparent contradiction — ideally by editing the wiki to reflect the outcome of those decisions and the fact that the value is already marked as deprecated in the table. What do you think?

Olá, ciampi. Podes por favor explicar as alterações que fizeste neste changeset? Não percebi bem qual foi o objetivo. Parece que vários elementos foram apagados e recriados, perdendo-se bastantes tags e relações no processo.

Se precisares, eu e outros da comunidade de editores em Portugal temos todo o gosto em apoiar-te sobre este tipo de alterações. Diz coisas :)

p.s. - ajuda também que uses sumários de edição mais descritivos. Dizer apenas "Alterações em Braga" não explica realmente o que foi mudado e porquê 😅

I suspect the tracing of paths/tracks and waterways in this area is mixed up a bit, probably due to intermittent streams of water that are used as tracks when dry.

Obrigado pela observação! Trata-se de um erro na inserção dos dados devido a um bug no StreetComplete (https://github.com/streetcomplete/StreetComplete/issues/5232). Corrigi agora, no changeset osm.org/changeset/142592971

Fixes note 3429159.

Apologies, I'll be more careful in the future. Given the scale of the changes, I should indeed have announced my intent and obtained community approval for the edit. I am OK with these edits being reverted if they're deemed damaging.

Note: I meant to limit the changes just to continental Europe, as the changeset comment attests, but my overpass clumsiness led me to edit nodes in other places as well.

In any case, this isn't problematic, as I was going to do those edits anyway. I just wanted to separate them by region for more convenient inspection.

Note: I meant to limit the changes just to the nodes in the Philippines, but my overpass clumsiness led me to edit nodes in other counties as well.

In any case, this isn't problematic, as I was going to do those edits anyway. I just wanted to separate them by country for more convenient inspection.

You're right, it is burdensome and unpractical for OSM editors. I am not aware of this being a common practice -- I just happened to need this personally, so I went ahead and "scratched the itch" :) of course, if there's a better way to fill the same need (now or eventually), I'll be happy to apply it.

Hi Josef. The relation is the only way to combine the various disjoint ways and identify the full avenue as a single object corresponding to the real-world location that people can refer to, associate to representations in other datasets (e.g. Wikidata), search for, use in addressing, etc.