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!

No, you’re fine, I just figured you might find it more convenient to work with 6-inch imagery than the blurrier global layers when realigning things. However, I forgot that OGRIP blocks overseas connections for some reason. Sorry for the confusion.

Hi, thanks for your attention to this area. Please use a high-resolution imagery layer when realigning roads and other features. Most parts of Ohio have OSIP (Ohio Statewide Imagery Program) imagery that’s both high-resolution and well-aligned, albeit sometimes a little older than the global layers.

Hi, can you elaborate on the reason that this changeset deleted the boundary of the San Manuel Reservation? This changeset also removed part of the San Bernardino city limits. Did you intend for your road edits to have this effect?

It wasn’t a particularly serious endeavor. The locations of the highway=traffic_signals nodes didn’t quite describe the complex layout of this bridge and intersection, so I had a bit of fun micromapping it all. As far as I can tell, the more practical aspects of this bridge are already in good shape for rendering and routing (as best as can be done for a SPUI).

Not quite. highway=traffic_signals is for the point along a roadway that is controlled by traffic signals, whereas I was attempting to also mark the location of the physical signals. I avoided highway=traffic_signals for this purpose because of the likelihood that it would generate validator errors and surprise data consumers.

This usage is quite experimental and has not yet been documented, but I may propose it in the future if no one else comes up with an alternative.

A lot of the discussions so far have focused on edge cases, hence the hedging and weasel words. You aren’t alone in favoring DOT functional classification as a factor in OSM highway classification because they seem more cut and dry. I’d be interested in hearing everyone’s thoughts about how the Caltrans FC criteria would best translate to OSM tags, so we can identify any shortcomings in that approach and find ways to keep the weasel words to a minimum. Just… not here in this tiny sidebar please. :-)

To participate in the talk-us mailing list, go to https://lists.openstreetmap.org/listinfo/talk-us/ and enter your e-mail address and a password. You’ll be able to post to the list and reply to others’ messages using whatever software or service you normally use for e-mail. However, you won’t be able to easily respond to existing messages from before you joined the list, so make sure to join before someone starts the thread about the California classification proposal.

A local community of one does not own any part of the map; that’s not how OpenStreetMap works. You may also recall that I’ve previously defended your right to make edits in another part of the country that one local mapper disagreed with, in a changeset discussion that got heated very quickly. Decisions about how to map should be based on the merits, not the identity of the mapper. A local mapper can inform the discussion with much-needed local knowledge, but that’s different than being a final authority.