Oops, sorry about that! Thanks for the catch; I'd checked the wiki and taginfo before as usual but saw very low usage (only a few hundred hits) of the correct tag and none of my many validators flagged the incorrect one, so I didn't realize I'd made a mistake and not entered it correctly the first time, which then propagated to the others.

I've fixed it in changeset 155850997 osm.org/changeset/155850997

Thanks. Would it make sense to fix the bad previous name tag to old_name=Mish Mish rather than removing it entirely? Or is it just _too_ old to be relevant now?
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/155715498

Also left a comment on the original user's changeset, so this is brought to their attention to keep in mind for the future.

FYI, this mistakenly removed node with still-valid details (e.g. addr:*); reverted in changeset https://osmcha.org/changesets/155715403?aoi=15aa7c6a-52b1-4bb0-a810-81319c87415b
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/155604661

Thanks! And also ""Be brave in what you add but careful in what you delete", i.e. not removing valid, in-scope detail from the map when making changes (e.g. addr:* tags here), e.g. osm.wiki/Good_practice#Don't_remove_tags_that_you_don't_understand
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/155715403

For some guidance, in the Blacksburg area I've found the following uses for the available imagery:

- VBMP for primary work (newer, moderate resolution, lower tree blockage, needs alignment)
- Bing for details and alignment (older, very high resolution, higher tree blockage, well-aligned at high zooms)
- NAIP for very recent changes and cross-checking (newest, very low resolution, higher tree blockage, aligned)
- Esri Clarity for an additional cross-reference of older imagery (oldest, moderate to higher resolution, moderate tree blockage, needs alignment)
- Esri World as another datapoint to view change over time (older, low to moderate resolution, higher tree blockage, needs alignment)
- Mapbox for double-checking objects through tree cover and as a last-resort cross-reference datapoint (older, low resolution, lowest tree blockage, needs alignment)

To align VBMP (to Bing, which closely matches GPS traces and is well-aligned at high zooms), I use the following imagery offset: -0.67;0.82

Additionally, I suggest (and implemented) the following changes, mostly similar to the previous: osm.org/changeset/155448900

- These days, the source tag Source should generally be set on your changeset itself rather than specific objects, as it is a property of your specific changeset and not anything inherent to the object itself (for example, someone like myself might later update the object using e.g. aerial imagery, making the source out of date)
- As mentioned elsewhere, US phone numbers should follow the standard "+1 ###-###-####"
- Purely optional, but email, fax and opening hours can also be added per the website info
- Likewise, addr:country can be added to match surrounding addresses

Good job here! Just a few suggestions and tips, with the main one being:

With recently-constructed buildings like these, its a good idea to check all available imagery to see which is the most up-to-date. Esri Clarity (which the imagery tag on your changeset indicates you used) is often some of the oldest (though some of the best quality, depending on region) and just shows a greenfield, as does the somewhat newer Bing. VBMP, while lower resolution, shows the construction site, while NAIP actually shows the building outline.

This allowed me to trace the building, and transfer your tags to it from the node. To help preserve the history, I moved your original node to be the top-left corner of the resulting building.
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/155344954

Looks good! The only changes I might consider are adding a few more (entirely optional) basic details from the linked website (phone number, and ideally fax and opening hours as well), addr:country since other local addresses use it, and tagging the building the POI is in appropriately (building=commercial in this case). I've implemented them in my changeset: osm.org/changeset/155448900

But again, all those are just a bonus on top of what you've already done—what you have is great! The only other possible thing is that if the vet clinic occupies the whole building (which I cannot tell for sure from the available information as I'm not on the ground), its good to add the tags on the building itself rather than a standalone node.
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/155344380

One last tip—OSMCha is a terrific tool for viewing (and reviewing) OSM changesets, as it shows you the actual changes made on the map. You can check out my followup changeset at https://osmcha.org/changesets/155448900 (and feel free to review it, too!)

Also, a few more specific tips on the details, which I've also implemented in my followup:

- Make sure the name of the POI is accurate :) In this case, the name of this POI (per its website that you linked), is Kibbles on Main (plural)
- Since OSM is a global map, phone numbers should always include the country code, i.e. "+1 <number>". Also, the standard format for US numbers is "+1 ###-###-####", i.e. "+1 540-961-5410"
- Less critical, but its a good idea to check nearby POIs to see what other tags are commonly included. For example, `addr:country` is common for Blacksburg POIs and other addresses including those nearby, so nice (though by no means required) to include it here. You could optionally also add, for example, this POI's Facebook page and opening hours (as I have), though I don't always go into that level of detail—you've included the most important bits here already.
- Similarly, by no means necessary, but I like to make sure the building the POI is contained in is at least aligned and has the appropriate building type, e.g. `building=retail` in this case.

Here are some suggestions to level up your OSM-fu further! I've implemented all of these in the followup changeset osm.org/changeset/155448900

- If you've confirmed "on the ground" that this store currently exists at this location, which is the considered the "gold standard" of OSM contributions, make sure to include "Survey" under the Sources field of the changeset (right under the changeset comment in iD), and/or any other sources you've used.
- It can be easy to miss, but its a good idea to check if a POI was previously located nearby and moved to the new location you're mapping. If so, per the OSM "Keep the history" guideline, make sure to move and update the existing node rather than making a new one. There's actually an existing Kibbles POI across the street from this one; a check of the object history strongly indicates it presumably moved to this new location you've mapped. Therefore, I merged your new node with the existing one to keep the history while updating the latter's outdated location and details with your changes.
- Make sure to check for OSM Notes near where you're mapping, and close them if your change will resolve them. In this case, there was a note for both the old and new location of Kibbles mentioning it was here, so you can resolve both since you've added it to the map! Since iD inexplicably doesn't show Notes by default, unlike basically every other editor, make sure to enable them at the start of every mapping session under Map Data > OSM Notes.

Hi Caitlyn, and welcome to OSM! Thanks for your contribution, and for requesting feedback on your changeset. Seeing as your edits are in or near two of the three areas I regularly map, I figured I'd step up and review them!

Just to make sure (since it can be pretty unclear for new users), requesting a review just adds a flag to your changeset asking your fellow mappers to give you feedback on it; otherwise your changeset goes live on the map immediately as normal.

Overall, looks like a great change! You added a POI with an appropriate type, address and some useful contact details. Thanks!
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/155344197

Speaking of which, on a related (heh) note—I see the cycleway along Beamer Way connecting the Huckleberry trail along Southgate with that just north of the airport is part of the Huckleberry Trail route relation, but doesn't have `name=Huckleberry Trail` like the others.

Is that an oversight that should be fixed, or is there a reason for that, do you know? Thanks!

And on that note, I fixed the crossing ways for the cycleway connecting the segment of Huckleberry Trail along Southgate with that just north of the airport to be cycleway rather than footway crossings.

Gotcha, thanks! It seems my initial confusion stemmed from misreading the wiki guidance to say that cycleway crossings should only be used when cycleway crossings have a legal status distinct from _footway crossings_ as opposed to a distinct status from _plain cycleways_, which is why I initially tagged this (and others) as a footway crossing instead of a cycleway crossing (despite the latter seeming more intuitive).

Given both the legal status and also my misread, its clear tagging this as the latter indeed makes more sense, thanks, and I'll keep that in mind for other crossings.

Ah gotcha—that makes more sense; I thought I might be missing some context. I couldn't see just from comparing those two changesets what was being restored relative to mine, except for possibly the relation, so I just assumed it must have been that. Thanks for the explanation and taking care of the fix!

Hey, so since it looks like you have quite a bit of experience mapping cycleways in OSM, I'd really appreciate your insight on the appropriate method of mapping cycleway or dual-use foot/cycleway crossings. Intuitively, tagging as `cycleway=crossing` seemed to make the most sense, as you've reverted to here. However, when I checked the wiki page for this tag, osm.wiki/Tag:cycleway%3Dcrossing , it said:

> This tag is only to be used in countries where cycle crossings have a legal status (for instance having right of way when an ordinary cycleway wouldn’t).

My assumption from the examples presented and my understanding of cycling law in the US (versus Europe) was that this was not the case here, but upon further thought it seems I might have misunderstood and in fact this is appropriate after all, with cyclelists having right of way over cars at this junction without dismounting?

Thanks!
---

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

Hey, thanks—its not entirely clear from the OSMCha UI, but I'm guessing I accidently broke the Huckleberry Trail route relation here in my previous Southgate changeset? I usually try to be careful to not do so and ensure any split/combining of way segments preserve relations, but I guess I must have gotten a bit too complacent here trusting in JOSM to either do the right thing automatically or warn me if the situation was ambiguous, as it usually does.
---

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

Thanks for the fixes! In the original change I was just typing the tags free-text into Rapid's text field, and for whatever reason I didn't catch it in my later pass with the JOSM validator, despite fixing another tag value on the same object.
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/150883788