https://www.cambridgema.gov/-/media/Files/Traffic/steelplaceresolution.pdf

It has been a while since I've lived in the area and so I can't go look and for all I know the shop might be gone now.

IIRC they sold all kinds of smoking accessories. That's not my cup of tea so I never went in to learn more. Their website shows mostly vapes now so shop=e-cigarette might work, but I think not all "smoke shops" sell e-cigarettes. shop=headshop might not be wrong either, but again, not every "smoke shop" sold cannabis paraphernalia.

shop=tobacco and shop=smartshop are definitely not appropriate. I don't think there are very many of those around.

I started using the shop=smoke_shop tag because that's what they call themselves and none of the other tags are close. It seemed like a reasonable time to use ATYL instead of trying to pretend it's another type of shop. I see it's been used a handful of times since then (13 total, 5 of them from me in this neighborhood).

Hi mleeeee, welcome to the OpenStreetMap community and thanks for mapping this park! I see you requested a review for this change.

These streets appear to be two-way on satellite imagery. Was the traffic pattern recently changed?

Hi Jacob, welcome to the OpenStreetMap community and thanks for mapping bicycle parking in this area! I see you requested a review for this change.

The only issue is that the bicycle parking nodes should be separate and next to the sidewalk way. Also the access=yes tag is not necessary as that is the default.

Also, I noticed you added some parking lanes in other changesets. If you want to map this information, it can be more easily added to the highway object itself using the parking:lane=* tag. A separate way would only be necessary in a parking lot or if there was some physical barrier between the road and the parking.

Let me know if you have any questions about this!

Name had been updated recently but another change was made from Organic Maps which hadn't updated yet and so accidentally reverted the name.

osm.org/note/3953637
osm.org/note/3953638
osm.org/note/3953639

Hi Sam, there is an offset of (0.6, -1.54) for Bing Imagery in Montreal. Please use this offset when aligning features. Thanks!

Deleted in osm.org/changeset/141829292

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?