Reverted in changeset 121741937.

Hi, this sledding hill is 20 meters tall over the average ground elevation. By changing height=* to ele=*, this changeset implies that Chill Hill is only 20 meters above sea level, which would make it a pit more than 250 meters deep. You may want to review other peaks that you retagged in case they were similarly legitimate heights rather than elevations.

This changeset did the same thing to the route relation for California State Route 1, which ended up getting deleted as a tagging error in changeset 98079414. Changeset 121350189 restored the relation and 121351794 reverted it to being a road route again.

This relation were somehow broken in changeset 93689318, but the correct fix would’ve been to revert that changeset rather than delete the relations, which represented California State Route 1. The relation has been restored in changeset 121350189 and was unrepurposed in changeset 121351794.

I reverted this change in changeset 121029361 because I saw the one-way restriction with my very eyes and mapped it the same day. It’s very recent, but you can read about it at https://bit.ly/quiet-zone-project

government=legislative is apparently for the main legislative meeting hall. (Don’t ask me how the State Capitol counts as a single office.)

https://taginfo.openstreetmap.org/tags/government=legislator was used three times until today, based on the discussion at https://osmus.slack.com/archives/C2VJAJCS0/p1608585986190800 osm.wiki/Talk:Tag:government%3Dlegislative#Legislative_offices I was going through retagging all the occurrences of office=political_party that weren’t party headquarters or field offices.

There’s an ongoing discussion about whether to use office=politician for any kind of office run by a politician, whether a campaign office or a constituent service office. https://lists.openstreetmap.org/pipermail/tagging/2022-May/thread.html#64575 I’m leaning towards retagging these offices as office=constituent_service for additional clarity, but in the meantime I moved them away from office=political_party, which is more incorrect.

Based on https://council.nyc.gov/district-30/ , I think node 9344579187 might’ve moved to a different neighborhood just after you mapped it. I’ve tagged it office=vacant for now, but perhaps you could double-check the new location?

Hi, I retagged node 6778205752 as office=political_campaign to distinguish the campaign headquarters from a party field office. Since Bhalla ran unopposed in 2021, do you know if the campaign headquarters is still open?

Hi Mingwei, thanks for taking an interest in these bridges. I don’t quite agree with moving these names to official_name, since they are posted on the bridge, often visibly, if not in a manner that’s particularly usable at freeway speeds. I see you’re on OSMUS Slack, so I started a discussion on the topic in #local-california. I hope we can come to an agreement on the best way to tag these bridges.

Thanks for updating the airport concessions! By the way, it probably would’ve been a good idea to keep the closed POIs around but with just the address (stall number). For example, node 4853689423 could’ve kept its addr:unit tag, which presumably won’t change even if something has replaced that bakery.

See discussion at https://github.com/ZeLonewolf/openstreetmap-americana/issues/289

I also had to fix a lot of other orphaned nodes where you had clearly wanted to add a node somewhere along a way, but the .osc file omitted the way.

Specifically, ways 1046405516 and 1046405515 were missing from the .osc file. Way 1033401133 was also missing, so the nodes you added to the south of the railroad crossing would’ve gotten orphaned.

It looks like iD uploaded this empty changeset as you were experiencing something similar to https://github.com/openstreetmap/iD/issues/7199 .

I took the .osc file you recovered from iD and reuploaded it as changeset 119098882 using JOSM. Please review my changes. The .osc file appeared to be partial or corrupted; I had to fill in some ways that were missing. Maybe it was just that you had to recover the data from a POST request body in your browser’s network inspector instead of the usual osmChange download link.

I’m also unsure if I resolved the conflict in relation 1476971 correctly.

Sorry for the big bbox; didn’t realize these two changesets were so far apart.

Reverted in changeset 118794072.

In the absence of an approved relation type representing a street, it’s pretty common to tag individual roadways with identical QIDs in wikidata, name:etymology:wikidata, etc., just as with names. Maybe it isn’t ideal for some purposes, but the onus would be on someone who likes a particular relation type to use it in their own mapping and perhaps push it through the proposal process.

Hi, thanks for noting the change in access for this road. Is the road still closed? For future reference, the proper way to close off a road is to set “access” to “no”. Don’t change the road to a fence, as this changeset did. Thanks for your attention.

This change optimizes for routers at the expense of other kinds of data consumers. Changeset 118310149 introduces name:left/right and restores name but keeps name:forward/backward for routers.

Ah, sorry about that. I’ve been going through GNIS records and missed that this one had been moved. Tagging it with `disused:amenity=place_of_worship` or `old_name` would keep someone from making a similar mistake in the future based on these records.

I attempted to fix the mistake in changeset 118255772. I also retagged the parish hall so it isn’t a church. Please take a look and let me know if I can help with anything else. Thanks!