bridge_ref was far and away the more common tag until this year, well after I uploaded this changeset:

http://taghistory.raifer.tech/#***/bridge:ref/&***/bridge_ref/

The mention of bridge:ref at osm.wiki/Key:bridge#The_building_number is somewhat obscure, so I was unaware that the less common key was the one that was documented.

I changed bridge_ref to bridge:ref in changeset 100879804.

Yeah, it’s an awkward situation to be sure. To complicate matters, at least one of these locations actually closed for good a few months ago, but we hadn’t gotten around to retagging it until now.

Thanks for taking a look. I see your point, but I’m hesitant to tag ghost signs with the name key because a data consumer could look at the combination of that key and addr:housenumber or shop (as in shop=vacant) and make it look too much like a shop by the name Fry’s. If I were to add a name, it would be to the effect of “Former Fry’s”; I’ve done that on occasion to brownfields that are commonly referred to by their former uses.

My understanding is that, due to the pandemic, these store closings are more abrupt than they normally would be. If there were a liquidation sale or service-only period, it might make sense to keep tagging them as shop=electronics but set opening_hours=closed. I may be wrong though.

Thanks for taking care of that, lonvia. Wikidata’s label quality is high in some languages but poor in others. Quite unlike OSM, most of the QA work there happens along linguistic lines rather than by geography. So IP concerns aside, any panlingual introduction of labels from Wikidata can be messy, as we saw here.

If the route number isn’t signposted, you could ignore the route number for the purpose of road classification. It somewhat surprises me that the route number isn’t signposted in this case, because West Virginia tends to signpost every road number all the way down to HARP driveways.

The wiki page doesn’t require every county road to be tertiary; it’s just a rule of thumb. There are exceptions for sure. In my experience, the majority of fractional county roads would reasonably qualify for tertiary since they don’t dead end, but one that does probably should be unclassified or residential.

Thank you for your explanation. I agree that the website:vi tag was unnecessary, so I left that change alone.

Regarding the name, even though there are language-suffixed name tags, the main name tag is still important as an indication of the primary name that a user will encounter in reality regardless of their language preference. For example, a navigation application may display the actual signposted name instead of the localized name, to facilitate wayfinding. Since no approved tag indicates the signposted language, removing one of the names from the name tag does lose information.

This business was only problematic because it has two equally prominent names in a bilingual neighborhood. If you asked me to keep only the more commonly used name or only the more important language, I honestly wouldn’t be able to decide. Fortunately, it’s a relatively rare situation even in this neighborhood. But there are plenty of cases where the English name is only slightly less prominent than the non-English name. I would argue that we shouldn’t bias the name tag towards English just because English is the most widely spoken language in the country.

Anyhow, I don’t mean to give you a hard time about this edit from long ago. I just wanted to make sure you were aware that there are reasons to want name to be set to multiple values.

Hi, please be careful deleting data in areas that you’re unfamiliar with. This office is in a Vietnamese enclave. Its Vietnamese and English names have roughly equal prominence, depending on which sign you look at, and I know first-hand that people use both names interchangeably: https://www.mapillary.com/map/im/alPxd0ld94X9LcNGCSlMVQ Some renderers handle the semicolon-delimited list by replacing the semicolon with a more aesthetically pleasing em dash, so the unsightly rendering in openstreetmap-carto is a rendering limitation, not a data issue.

Thank you for clarifying and for the Achavi link.

Your changes look fine at a glance, except that osm.org/way/852541565 needs to be retagged. It was previously leisure=park, which was not quite correct, but now it’s a bare boundary=protected_area. If you use boundary=protected_area, you also need to set the appropriate protect_class; otherwise, renderers would have no idea how to interpret the area, because boundary=protected_area is used for a wide variety of features.

https://zelonewolf.github.io/openstreetmap-pad-us-inspector/state/West_Virginia.html suggests protect_class=3 based on the PAD-US database. Does that seem reasonable to you?

Appalachia is the name of a region that covers over 200,000 square miles in 13 states. OpenStreetMap automatically calculates the bounding box of your changes, so naming a broad geographic area isn’t very helpful. Please try to provide more descriptive changeset comments that indicate what you’re changing. Thanks!

“there is a real potential for serious public harm by mapping it is a service road”

Tagging it access=no should mitigate the potential harm caused by mapping it as a service road. It will prevent any router from using the road, and every renderer indicates access=no to err on the side of caution.

“It is debatable whether that is a service road or a storage yard.”

Perhaps consider tagging it as a highway=track instead of a highway=service (but still add access=no)? That would make it even clearer that it isn’t meant for normal use.

If nothing else, impiaaa is right that sooner or later someone will come and add it back in using aerial imagery without local context, potentially causing exactly the dangerous situation you’re trying to avoid. Whenever this is a possibility, there should be something there, even if it’s only tagged not:highway=service. (But then you’d be saying it isn’t a service road, and the question becomes whether that’s accurate.)

Sorry for the large changeset – this is the result of following up on systematic but problematic edits by ZenithTheFox, who was quite prolific before being blocked.

Just a heads-up that changeset 96438437 deletes way 766306007. Routers expect turn:lanes tags to extend to the intersection; otherwise, they’ll drop the tags as invalid data. turn:lanes technically represents lane movements; if you’d like to indicate where the lane markings begin and end, there’s a osm.wiki/Key:road_marking key for that.

The Ismaili Cultural Center (node 8258604837) was a tough one to find: they list their address incorrectly in the social distancing protocol submitted to the county and also in some (but not all) of the permit applications to the City of Milpitas.

https://saesdp.sccgov.org/sdpdocs/2901694-SocialDistancingProtocolForm.pdf
http://www.ci.milpitas.ca.gov/_pdfs/building_reports/2018/bld_report_ci0818.pdf#page=10
https://www.mercurynews.com/2017/11/09/milpitas-planners-ok-religious-assembly-in-industrial-zone/

Making matters worse, the sign outside the building has the wrong (or old) address. A longstanding tenant submitted an SDP with the new address.

https://saesdp.sccgov.org/sdpdocs/3196674-SocialDistancingProtocolForm.pdf
https://www.bing.com/maps?osid=16fee0bc-9a05-4cf4-907d-bf55a9bc4ffb&cp=37.422632~-121.893604&lvl=19&dir=343.53674&pi=-6.2944713&style=x&mo=z.2.87&v=2&sV=2&form=S00027

(The SDP database and the Milpitas city permit book are in the public domain under California law.)

This mapper also performed a mass untagging of buildings in changeset 95721077. Quite unusual for a new mapper to be this involved in lifecycle tagging, but I suppose there’s no prohibition against opening secondary accounts, generally speaking.

This changeset was partially reverted in changeset 96054624.

For context, most of these buildings were meticulously hand-drawn 11 years ago in an editor that lacked a right-angles operation despite aerial imagery in which the buildings were barely discernible at zoom level 17. The rest of these buildings were part of an approved import of high-quality county building data.

Your changeset indiscriminately removed the building key from these features, effectively deleting them in the eyes of any data consumer. While the hand-drawn buildings certainly could be refreshed using modern tools and imagery, many of the buildings you singled out were added more carefully than they were taken out.

For example, how did you know way 656340207 needed to be redrawn? It’s obscured by a tree in the leaf-on Maxar and Mapbox layers, but CAGIS digitized it from leaf-off imagery. (It looks fine compared to leaf-off OSIP 6-inch imagery.)

As ivanbranco notes, the building key was replaced with a key that would’ve been unlikely to attract the attention of anyone looking for quality assurance issues to fix. If you want to encourage other mappers to improve OpenStreetMap’s building coverage, there are less disruptive ways to do so than to erase their work.

As far as I can tell, I or my import account were responsible for originally adding all these buildings. If you wanted to get my attention, you would’ve gotten it more promptly by contacting me or commenting on my original changesets than by this mass retagging that I only discovered by accident when looking at the history of a park that happened to be touched by this changeset.

The store posts signs with both spellings (also on their website). I realize it’s unusual; however, mnemonics may or may not be typeable anyways. (It isn’t uncommon for a pnemonic to be too long for a phone number, for instance.)

Hi, thanks for taking the time to add more detail to this parking lot. It appears that you drew each line separating a parking space as a “Parking Aisle”. In fact, a parking aisle is the roadway that you drive on to get to a parking space. If you’d like to map individual parking spaces, there’s a “Parking Space” option for that, but you have to draw an area rather than a line to access that option. I converted these lines to parking spaces in changeset 95074988. Feel free to reach out to me if you have any questions or would like additional help with mapping.

Reverted in changeset 95064080.

I’m pretty sure I was trying to straighten something (using the L key in iD’s Vietnamese localization), but the focus was on that text field by accident. Fixed in changeset 94976651. Thanks for the heads-up!