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 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 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!

The source for hazmat classes was https://dot.ca.gov/programs/traffic-operations/legal-truck-access/restrict-list , which is in the public domain as a work of a California state government agency.

…added traffic lights, crosswalks; upgraded tracks to cycleways

Please take the time to learn more about the roads you’re editing before making changes to their classification. Recently you’ve changed several roads in the region to trunk or motorway, both of which have safety implications for routers. If these changes are motivated by wanting the rendered map to look more coherent, please understand that the highway network is often messy and incomplete in reality, so it’s important that our rationale for classifying roads be thoughtful and well-researched. I encourage you to join slack.openstreetmap.us to discuss these topics with the local mapping community in more detail.

Hi, thanks for the attention you paid to this part of the map. changeset/94805058 changes this section of El Camino and The Alameda back to a primary road. I can see how this road might look from the air like a convenient connection between San Tomas and I-880, but I can assure you it’s anything but. A common-sense road classification scheme for the South Bay would classify El Camino and The Alameda the same way as other low-speed, uncontrolled-access roads (such as Stevens Creek and De La Cruz), as opposed to the county expressways (Lawrence, Central, San Tomas), which are high-speed and limited access with occasional grade-separated interchanges.

If you have any questions or concerns, I’d be happy to explain further here, or please feel free to join OSMUS Slack’s #local-ca-sfbay channel, where we can discuss the topic with other local mappers more easily.

Hi, I think you mistakenly assumed that the CVS drugstore had been taken over by the Whole Foods Market, but in fact it was just misplaced. The drugstore and its pharmacy are next door. (This was the time I finally gave in and mapped the pharmacy counter separately because the pharmacy counter and drugstore have different hours.) changeset/94798119 restores the drugstore, and changeset/94798245 moves both CVS POIs to the correct location next door, consistent with the DCGIS address node.

By the way, changeset/94727436 had originally attempted to place the monolith in the valley, but using Esri imagery. The monolith’s shadow is pretty clear in Esri imagery, but that layer is offset from Bing imagery.

Thanks for resolving these notes. By the way, if you haven’t seen it already, the OSIP 6in layer is much crisper and better aligned than NAIP, though it isn’t quite as up to date in Southwest Ohio. Bing is reasonably up-to-date in Greater Cincinnati, but somewhere in between OSIP and NAIP in terms of resolution.