Reverted in osm.org/changeset/141137030

Hi andriu44, looks like the 77A route was mostly deleted in this changeset but has one remaining segment: osm.org/relation/12332618/. Can you clean it up? I would but I'm not sure if the relation can be deleted or if the segment needs to be added to another relation. Thanks.

Alright, seems like you've put plenty of thought into it. I hope some day we'll have a better way of tagging these facilities.

Okay I see the dilemma. I've mapped some hockey arenas before, many of which have multiple rinks and so have a similar issue about names for individual rinks (Rink A, Rink B) vs the arena as a whole. As far as I know there is no good solution yet.

For single non-notable baseball fields with no name I would think it's best to leave the name off entirely, as adding a generic name wouldn't reflect reality and wouldn't help anyone find the field. And for fields notable enough for wikidata pages, noname=yes seems better than adding a generic name. That's just my opinion though, I'm not by any means an expert in this.

Re: duplication
There are now overlapping ways for leisure=sports_centre osm.org/way/36907037 and leisure=pitch osm.org/way/36907037. I think there should only be a pitch. The wiki for sports_centre says it's not meant for single fields.

Also, the feature is now duplicated, and what is the restaurant=no tag for? Were you following some guide for baseball diamond tagging?

This looks like a description, not a name osm.wiki/Names#Names_are_not_for_descriptions
---

Published using OSMCha: https://osmcha.org/changesets/139943005

Okay, please go ahead and make whatever fixes or changes you think are necessary.

Hi webfil,

In this change (and the others like it) I was focused on cleaning up the admin_level=6 (MRC) boundaries. I did fix issues when I saw them on smaller administrative areas but there are >1000 municipalities in Quebec so I didn't check every one. So there are definitely still issues or inconsistencies that should be fixed but it would be a big project.

I remember looking at Cookshire-Eaton specifically because it is part of an urban agglomeration while also being a part of an MRC, both of which are usually tagged admin_level=6. I made sure the city was mapped, but the agglomeration is currently unmapped.

I placed the Cookshire-Eaton node with a goal of having a node and a boundary relation for every administrative area, with matching name, and place tag on the node. There is not any guidance for that on the wiki but I have found that JOSM, osm-carto, and nominatim all seem to prefer it like that. And yes I did choose place=city because of the administrative status, not realizing how it would compare to Sherbrooke. That could be fixed.

I don't think that those two nodes are duplicates, given that the population center called Cookshire and the municipality called Cookshire-Eaton seem to be different concepts. However I would say the Cookshire node could be the admin_centre and Cookshire-Eaton node the label of the Cookshire-Eaton boundary relation. I'm not sure why I didn't do it that way in this changeset.

Okay. I ask because it is usually best not to add temporary information to OpenStreetMap. Let's say it's been under construction for a month, we tag it today, it takes a month for third party routers to update, another month to complete construction, then a month for someone to notice it's still tagged, and one more for routers to update again. After all that, the routers spent more time with inaccurate data than they did accurately rerouting around the closure. So it's best to tag things only if they are permanent or semi-permanent. That's loosely defined somewhere as about six months or more.

I see someone else has added a note on the road segment, visible to other mappers (osm.org/changeset/138375550), and I would say that's sufficient. But if you think the road will be closed for several more months you could tag that way with highway=construction and construction=tertiary and then routers would know not to use it.

Do you know how long the construction will last?

I've reverted this changeset in osm.org/changeset/138644151. By the way it looks like the cycleway on the bridge is already mapped.

Looks like you just deleted the restrictions? Were they perhaps already broken or redundant?

There are lots of broken turn restrictions around so I'm not that concerned about fixing these few, I'm more worried that there's something happening in your editing workflow that will break more in the future. Do you know what caused it? Maybe deleting a node, combining ways, something like that?

Hi elkodr, you seem to have broken some turn restrictions in this change. OSMCha will show them for you: https://osmcha.org/changesets/137932281/

Hi une abeille, welcome to mapping in Montreal. I see you have requested a review for this change.

I believe that when the cycleway is a lane with no physical separation, it should be tagged using cycleway:*=* tags on the main highway way. I haven't done much cycleway tagging myself, so check the wiki and other cycling infrastructure in the area to see how it's done. However, it looks like 16e Avenue already had the cycleway tags so now that infrastructure is double-tagged.

Also, be aware that aerial imagery can be out of date. For example, the cycleways on Christophe-Colomb have been removed and are now being rebuilt since the imagery was taken. I'm not sure about 16e Avenue but there was some construction at Parc Étienne-Desmarteau in the imagery so I assume some things may have changed. It would be appropriate to check the site before mapping it in this case.

Finally, when aligning features to Bing imagery in Montreal, please use an offset of 0.6, -1.54. This can be set in the "Imagery Offset" section of the "Background Settings" panel in the iD editor.

I did review every tag before making changes, and only changed tags that were already in list format. There were a few that had semicolons but were more like sentences or descriptions - these are bad and need to be fixed but I didn't just blindly remove spaces from them.

I believe it falls under the typo correction section of the Automated Edits CoC.

The 1400 changes I made represent 0.3% of cuisines tags with semicolons, and just 0.1% of all cuisine tags. That is, 99.7% of people were already using the space-less separator.

IMO that's rare enough that data consumers shouldn't have to, or are likely to forget to, handle this case. But also 1400 is large enough that it's worth making sure the information for these restaurants can get used.

Hi Ktr101, according to the wiki, abandoned railways with no presence on the ground should not be mapped.

(I also opened a note osm.org/note/3745083)

Apologies for submitting a change with nodes in Alaska and New Zealand. But there are 1400 other nodes in between and on every continent. Even splitting it into chunks it would have covered most of the globe with at least one bounding box anyways.

Hi zigong, I had moved Iconoglace to the correct location about a month ago, but it seems this change moved it back to the exact same coordinates as it had been previously. Please make sure you are mapping on the most recent data available. Thanks!