OpenStreetMap logo OpenStreetMap

Changeset When Comment
137932281 about 2 years ago

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

137899297 about 2 years ago

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.

137465295 about 2 years ago

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.

137463548 about 2 years ago

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

137465295 about 2 years ago

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.

134541215 about 2 years ago

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)

137465295 about 2 years ago

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.

136713826 about 2 years ago

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!

137061020 about 2 years ago

osm.org/note/3652104
osm.org/note/3425483
osm.org/note/3580622
osm.org/note/3580624

136709119 about 2 years ago

Okay! I didn't think it could have been from a survey because of the huge area covered. So I had thought maybe it was random items traced from aerial imagery but you obviously could not have seen a bench that way. And I had also thought it might have been an import because so many of the items were about railways.

If you had a three week long railway themed trip that explains everything! Hope it was a good trip. You visited a few places I know well :)

136709119 about 2 years ago

Hi IIVQ. This change and osm.org/changeset/136694495 are very odd. Most of your changes are in Europe but then you made two changesets of 300 random objects across several states and provinces in the US and Canada. Most seem to be tiny geometry updates but some of them look problematic, like
osm.org/way/1177288580 or osm.org/node/10937226756

What is going on with this change and did you import any data?

136188068 about 2 years ago

Most were about 10m off and in different directions from each other. So likely not just an offset error. I am using the (0.60;-1.54) offset for Bing in Montreal.

133997906 over 2 years ago

I was unable to determine what the correct boundary should be here. It would likely take some pretty deep research, or may not be knowable at all.

Is it worth guessing in order to silence the errors?

123440051 over 2 years ago

Hi bhietsch, same question about the segment in Granby, VT.
osm.org/way/1077477141
osm.org/way/1077477036
osm.org/way/1077477156

133800884 over 2 years ago

J'ai pas changé le nom d'aucun autre MRC.

Je voudrais discuter avec la communauté sur community.openstreetmap.org mais il y a pas de catégorie.

133341895 over 2 years ago

You've added the name "D'Auria Street" to a segment of the East River as part of this change. Is that a mistake?

133800884 over 2 years ago

osm.org/changeset/134187294

133800884 over 2 years ago

Désolé. Je suivais les noms écrit sur le site web de MAMH, comme ça: https://www.mamh.gouv.qc.ca/repertoire-des-municipalites/fiche/mrc/140/

Je vais remplacer les noms de tous les comtés qui partagent un nom avec une ville.

132233390 over 2 years ago

A little more information: Usage was about 2/3 cookies, 1/3 cookie before my cleanup, which is why I had picked cookies originally. But after more thought, cookie is the better value because it matches other singular values. Also, it looks like "cookie" was used more for places that serve specifically cookies and "cookies" was used a lot in long lists where mappers added everything on the menu.

131618695 over 2 years ago

For almost all of these choices between spellings I changed them to the most common spelling at the time. For example:
salvadorian(16), salvadorean(14), Salvadoran(10) -> salvadoran(69)
taco(152) -> tacos(972)
hot_pot(198) -> hotpot(687)
sandwiches(566) -> sandwich(60440)

For something like pupusa, where there were a lot of different spellings (pupusa, pupusas, pupuseria, etc), but none had more than a handful of uses I moved them all to the singular term.

On Korean barbecue: The korean_bbq tag only had 11 uses, not enough to be supported by any consumer, and it has an abbreviation which we would like to avoid in tag values. Changing these to korean;barbecue allows the data to be used by consumers since both values are common. And, unlike Mongolian barbecue, the cuisine both is Korean and is barbecue. I suspect there are hundreds of Korean barbecue restaurants currently tagged as "korean", "korean;barbecue", or just "barbecue". In order for a korean_barbecue tag to be useful someone would have to go through and tag them. Leaving 11 restaurants as "korean_bbq" wouldn't have made that easier.

(Also I fixed that mistake you found, thanks for pointing it out.)