Hi Jon, thanks for clarifying this!

It seems that while it is marked private, the other tagging of the residential street you split it from is mistakenly retained, as it is still tagged as a residential street (`highway=residential`), with a 25 mph speed limit (`maxspeed=25 mph`), a `name` of `Lynn Drive`, and (less critically) the various `bbug:` import tags corresponding to the public street. Like the other instance, as a private driveway it should instead be tagged `highway=service + service=driveway` and those tags removed. Happy to take care of this for you if you like!

Also, I happened to notice an untagged node was created, node/13616074609 , that doesn't appear to modify its parent way way/132781771 . Was this created by accident (can be easy to do sometimes), or was there some intended purpose here? Thanks!
---

Published using OSMCha: https://osmcha.org/changesets/179328589

I did noticed you changed the driveway to a highway=living_street, which is a specific legal designation of type of _public_ residential street marked by specific signs found mostly in Europe where pedestrians and cyclists have a legal right of way over vehicles. By contrast, house driveways are tagged `highway=service + service=driveway`.

Also, it seems this driveway was previously incorrectly named by another mapper as as "Royal Lane", which is in fact the name of the next public residential street to the south, and the house it serves has the address of Farmview Drive, not Royal Lane (unlike the houses on the actual Royal Lane).

Would you like to address these issues yourself, or would you like me take care of it? Thanks!
---

Published using OSMCha: https://osmcha.org/changesets/179328521

Hi Jon, welcome to OpenStreetMap! We're glad to see you join our NRV mapping community. Feel free to join the OSM US Slack https://openstreetmap.us/get-involved/slack/ and other local channels to stay in touch.

Mapping access tags for private and semi-private roads is definitely something that has considerable room for improvement around the area, so thanks!
---

Published using OSMCha: https://osmcha.org/changesets/179328521

As you can clearly see from the existing `contact:phone` tag you modified, your phone number is in an invalid format for OSM. *Especially* as you are paid to map to promote your client's business, it is _imperative_ that you ensure you do not introduce invalid tags or values (especially very basic ones like `phone`) and degrade the quality of the data on the map.

Also, source is Google Maps which is strictly prohibited per OSM policy. Reported to DWG.

Of course, man! SEO spammers are everywhere these days, unfortunately.

Just to note, changesets spanning massive bounding boxes aggregating changes from multiple very geographically separate areas changeset/179007344 are strongly discouraged on OSM, as they make browsing and reviewing them difficult or impossible with common tools, and also interfere with tools' ability to monitor changesets for a given area (e.g. OSMCha didn't show me it despite it making changes in Blacksburg due to the massive bbox). Its best to keep changesets as geographically-focused as practical, at most spanning a single town or small metropolitan area (e.g. your changeset here is about the largest I'd ever do, and only in very special circumstances like this where it is a handful of edits to a single object type unfortunately distributed around a single metropolitan area; normally I'd keep my changesets to a neighborhood or smaller).

In changeset #179040841 changeset/179040841 for all ALPRs in the Blacksburg/Christiansburg area, I've corrected the `wikipedia` links added here to `manufacturer:wikipedia`, as well as fixed other instances of the same (and with `wikidata`), added `operator:wikidata` where possible, moved a few instances of the `power` tag to the correct `electricity`. I've also remove problematic and inappropriate "image" tags that simply linked to the object on Google Maps, which are not in fact an image file and is an impermissible data source, in addition to the various known issues with the `image` tag.

Hi NRV Privacy Advocate,

Thanks for verifying and updating these ALPRs and adding some additional useful tags to them. As a card-carrying EFF and ALCU member, I appreciate the work of those like yourself to document and bring attention to the increasingly invasive and pervasive surveillance measures we are becoming surrounded with, especially in this area of unprecedented weaponization of state resources against those that disagree with its current policies.

I did want to point out one thing with the changes here, namely that the cardinal principle of using the `wikipedia` (and `wikidata`) tag is that it should correspond 1:1 with the _specific_ feature being mapped (i.e. that one _specific_ camera). The wikipedia/wikidata entry for a owner, operator, brand, manufacturer etc. of a feature belongs as a secondary wikipedia/data tag, in this case `manufacturer:wikipedia`, as you can already see done with `manufacturer:wikidata` for these same POIs you edited.

Also, while I've used it a lot in the past, just to note consensus has been recently shifting toward using only `:wikidata` secondary tags (with an approved automated edit removing all `brand:wikipedia` tags in the United States: https://community.openstreetmap.org/t/proposed-bulk-removal-of-brand-wikipedia-tag-from-united-states-pois/107776/ ), since it is essentially redundant with `:wikidata` which links to every Wikipedia article plus much more, and Wikidata IDs are stable while article titles are not.

In part, a followup to changeset #179002817 changeset/179002817 to correct the `wikipedia` links added therein to `manufacturer:wikipedia` (assuming we want to leave them at all and not just rely on the preferred `manufacturer:wikidata`, per US national community consensus.

Also remove problematic and inappropriate "image" tags that simply link to the object on Google Maps, which are not in fact an image file and is an impermissible data source, in addition to the known problems with the `image` tag leading to proposals to add such being rejected: image=*

Sure, see the wiki article osm.wiki/Names . In short, as something spray painted on top of the cave, it is at most a `loc_name`:

> loc_name=* is for the name of a feature as it is known locally, but only where this is deemed to be too much of a slang name or otherwise unofficial-sounding.

However, this would need to be substantiated by further research or at least informally asking various folks that live there to confirm it is actually what locals call it. It could very well be the graffiti of a single vandal that no one has gotten around to changing. Given the location near Provo and the local culture of most of the folks that live there (who would likely consider such a name to be quite blasphemous), I highly doubt they actually call it such.

Therefore, at least for now I would suggest removing the name and adding a Map Note saying what you state above, for other local mappers to follow up on. Thanks!

Is this really the name of the cave? Could you provide a source for this? I'm not seeing one provided in either the changeset tags or comment. Thanks!

And welcome to OpenStreetMap; thanks for your contribution to our community! I'm happy to answer any questions you may have on your mapping journey, and there are a number of other friendly users mapping in the NRV that would be glad to do likewise. Feel free to reach out, and looking forward to your future contributions!

Great, thanks for adding these details and refinements!
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/178644582

Hi user3266,

Thanks for your rapid, thoughtful and comprehensive response! I'm glad to hear it my comments were well-taken, and I apologize if any of it came across as unduly harsh--it certainly didn't rise to the level of "mayhem" that perhaps some of my feedback might have come across as, sorry.

I'm always happy to answer any questions you might have ahead of time; just FYI ultimately with OSM all changes go live in the DB immediately and requesting review only sets a flag that makes it theoretically more likely that folks using various tools will see and review it ex post facto. Since I monitor every changeset within the Blacksburg town limits regardless of that flag (I don't know if I've ever actually seen it used in practice), not selecting that option didn't have any practical negative impact here.

Hey, most if not almost everyone mapping has _some_ sort of personal motivation for doing so, so no need to denigrate yourself here--so long as that doesn't conflict with the data quality of the map as a whole, that's perfectly fine and it does further emphasize the necessity of the holistic change this would be a part of.

Revert looks good! I didn't feel up to using osm-revert until at least many months/hundreds of changesets/tens of thousands of changes, so good on ya.

Just curious, you doing this as part of a company, class or a personal project? I'm a VT alum ('17, BS Meteorology BA Geography/GIS), so always love to see OSM getting used in the Blacksburg community.

Cheers, and looking forward to your future contributions!

Looks good, thanks! For the record I do agree with the change (to add directional) in principle, and am planning to do comprehensively once discussed with the community. Thanks!
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/178686469

Hi user3266,

First off, welcome to OpenStreetMap, and thanks for your contribution to our community! I'm happy to answer any questions you may have on your mapping journey, and there are a number of other friendly users mapping in the NRV that would be glad to do likewise.

Could you help us understand the rationale for your change here? Like every other town-maintained street in Blacksburg, the street signs for Church Street (and addresses along it) have always had directional suffices, at least as far back as when I first arrived in Blacksburg in 2013 (and likely far longer), which has been visible on the signage as long as street-level imagery exists (e.g. Streetside, Mapillary and other sources). Therefore, I'm not really sure what street-sign change you're citing here as far as this is concerned.

The reason the directional suffix isn't currently in any of the Blacksburg street names, nor `addr:street` is for, AFAIK, historical reasons related to the limitations of the data import of Town of Blacksburg GIS data circa 2010 that form the basis for the OSM data in the area. I absolutely agree that we should be adding it, but rather than a piecemeal effort like this for one part of a single relatively-unremarkable street (there are a number of further blocks of Church St to the south that are still missing the directional suffix), this should be done consistently and holistically everywhere it applies (possibly with automated or semi-automated tooling) following a discussion and consensus in the local community as required by OSM principles, to ensure everyone is on the same page. I've been planning to do so for quite some time following the completion of several other ongoing Blacksburg mapping projects, and I'd of course appreciate your contributions to that process.

Also, the change introduces two significant regressions in terms of data quality and correctness per OSM guidelines. First, it changes the name of the street way while not also updating the `addr:street` of the addresses along it, leading to the latter not matching the former creating a serious data inconstancy. Second, one of the core OSM principles when naming things is to always expand abbreviations for clarity, including in directional suffices like this as well as street names. So this should be "Northwest" and "Northeast" rather than "NW" and "NE" (and "Road", not "Rd" in your other changeset #178565996 changeset/178565996 ).

The easiest and most consistent fix I'd recommend is just reverting the change for now, either by manually changing the street name back or using OSM-Revert (which I can do for you, if you'd like). Alternatively, if you really want to make this change now rather than waiting for community discussion and consensus, and then just having it being applied consistently in an automated/semi-automated fashion town-wide, you should be prepared to fix the naming issue, be consistent about renaming the southern parts of Church Street as well, and update all the various addresses that refer to Church Street to reflect the new names (a relatively straightforward task for an experienced mapper using a full-featured editor like JOSM, but likely rather tedious and error prone to do using iD as you are).

Looking forward to hearing from you, and happy to answer any further questions you might have and assist you in remediating this! And again, welcome to OSM!

Thanks!
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/176886412

No worries at all, man! I get all bummed out too when I realize I made a mistake, but I find there's always something new to learn and improve with OSM and it was a learning opportunity for both of us; I didn't realize myself until double-checking the wiki on this changeset that recommended tagging practice had evolved to explicitly condone tagging a node of a highway=* way with road_marking=* without highway=stop in the case of all-way stops.

And I have the utmost respect for you and your mapping skill! FWIW, for the longest time I've found public transport relations the most complex set of concepts, rules and practices to master in OSM (and still wouldn't consider myself nearly having done so yet, having only recently really started to engage with them), whereas you seem to be quite adept at them. So when I finally get around to fixing the various Osmose-detected issues with BT transit's I've indirectly touched (hopefully soon), I'm sure you'll have some helpful feedback in case I miss anything!