Furthermore, the added tags were for a completely different business in an entirely different state (as is obvious from the added description), so I reverted them completely in changeset:

changeset/187623602

That would be great!

BTW, this case you fixed was actually more incorrect than most, as in this case the parent entity of the library system was not the town at all, but rather a association of multiple counties (Montgomery and Floyd)--so it wasn't just imprecise but clearly flat-out wrong. Not sure how I let that one slip through!

Thanks for correcting what was originally my mistake here!

Just FYI, I see operator:wikipedia=* I originally added way back when (that still refers to the town as the operator rather than the country library system) wasn't removed or updated here along with operator:wikidata=*, so I removed it for consistency in changeset/187554555

changeset/187554555

> (A lot of Google's information has been added and maintained by volunteers, so I consider it unfair that our own shared information is considered their property)

Ah, well unfortunately that's pretty much how any of the proprietary internet platforms operate by default, and is in the ToS that every Google Maps contributor agrees to when submitting their information/suggestions--it is only natural that they want to exploit and profit off their data and their monopoly position with it as much as they can, to benefit their bottom line.

Why I personally struggle with understanding is why so many people voluntarily work for free mapping for a trillion dollar megacorperation like Google that has complete control of the data they contribute, when OpenStreetMap exists. But unfortunately, that's the world we live in...

Thanks @HaritaDuzenlemeHesabi , really appreciate a local expert chiming in!

As an additional reminder @sudoers , while you of course have personal knowledge of the business, just keep in mind that use of Google Maps as a source for OSM is strictly prohibited by both OSM and Google policies, and may violate local law -- see osm.wiki/Google for more details. Therefore, it cannot be used by other mappers as a source for verifying a bullishness or information about it. Even if that wasn't the case, it still wouldn't be a reliable source of verification in cases of uncertainty like this, as anyone can add their business to it and they have looser standards for inclusion than we have--not to mention they don't always enforce them, e.g. almost every SEO spam POI I clean up from OSM has a pin on Google, even ones that are completely nonsensical (e.g. a "party store" in the middle of a public park).

Happy mapping!

Thanks!

Overall looks pretty good, but a couple issues here (at least with the end state; there appear to have been more changes in further of your changesets:

- The recreation center building is completely missing any building=* tag, probably building=civic . Additionally, it is dual-tagged tagged as a landuse=*, which it itself isn't (leisure=sports_center accurately covers it)
- way/1548675765 and way/1548675764 shouldn't be two separate ways as there is only a painted line between them. As I've reminded you previously, the general rule in OSM is to only map separate ways when there is physical separation (barrier, median, verge, etc) between them. Furthermore, only way/1548675765 is tagged oneway, with way/1548675764 left as the default two-way (which is not correct even absent that rule).
- Around that same location, you've updated the roads but not the crosswalk (way/1170368989), leaving it in the wrong location not near the actual roads.
- Not all of them were directly touched by you, but way/911119293, way/911119292, way/734351162 and way/734351159 are all two-ways (the latter tagged incorrectly as a one-way) that form the perimeter of the lot and/or serve through traffic, not parking aisles.
- way/1548674640 that you tag as just landuse=grass seems to in fact be some kind of specialized recreation area, not just an empty grass patch (in a median, verge, etc.)

Fixed in changeset/187253785

changeset/187253785

Hi Herdy,

Welcome to OpenStreetMap, and thanks for your contribution!

I did notice some issues and improvements to be made here:

- As a dance academy, the main function of this place is _teaching_ dance, not hosting social dances that anyone can attend as a leisure activity (swing dance, salsa, etc). Therefore, it should be tagged amenity=dancing_school , not leisure=dance
- The opening time of 04:30 (4:30 AM) on Friday appears to be a mistake. I'm assuming you probably mean 16:30 (4:30 PM) instead.
- The consensus standard NANP (e.g. US) phone number format is +1-NNN-NNN-NNNN (with +1 NNN-NNN-NNNN and the international standard +1 NNN NNN NNNN being also used). See phone=*#United_States for more info.
- The website=* should be the official URL for this specific feature, so it should point to the homepage for the Blacksburg studio, https://www.thelittleleapers.com/blacksburg
- As stated a number of places on their website as well as elsewhere, they are in Suite 301, so it should be tagged addr:unit=Suite 301
- Not _strictly_ required, but its standard practice throughout Blacksburg (and most of the US) to include at least addr:city=* and addr:state=* (Blacksburg POIs conventionally also include addr:country=*, though that's mostly due to an import and probably not necessary).

I've fixed all this for you in changeset/187193518

changeset/187193518

Thanks, and happy mapping!

Gotcha--I do have a lot of experience detecting and dealing with spam and SEO activity (that's the primary purpose of this particular account of mine, in fact), so it's easier for me to stop such things. Besides cleaning up the existing POIs, I would recommend avoiding adding POI info under your name that Facebook accounts send you without personally verifying it via streel-level imagery, survey or local knowlege (at least in cases where the business may be remote/online, service-call, home-based, etc) where the customer wouldn't typically physically visit the location on the map, which greatly increases the chances of something phishy going on).

Happy mapping!

Thanks!

Hey Frank,

Like your other changeset/185598708, there was already a separately-mapped sidepath for many of these segments. Additionally, for Progress St north of Givens Lane, it was tagged as sidewalk=left (where a sidewalk was already mapped separately), but there was actually an unmapped sidewalk on the right side, so it was actually _that_ side which could have had `sidewalk:right=yes`.

I fixed these as part of a transportation pass over the area as well as mapped seperately all the sidewalks that weren't already mapped, with northern Progress St specifically being fixed in the final changeset of the pass, changeset/187001598

changeset/187001598

Thanks, and happy mapping!

Hey Frank,

There was already a separately-mapped sidepath for most of these segments, so your selection here actually created a second, duplicate sidewalk tagged on the road in addition to the separately mapped path. I fixed these as part of a transportation pass over the area starting in changeset/186742516 , but in the future make sure to check if a mapped way already exists and select the "mapped separately" option for the relevant side(s).

changeset/186742516

Thanks, and happy mapping!

Hey Frank! I'm not sure why SC removed the correct segregated=no here for way/1104325724 way/1104325724 , but I restored it along with adding/standardizing the tagging for the rest of the Shenandoah Bike Trail and connectors in changeset/186685091

changeset/186685091

Thanks! Just to make sure, while the first paragraph was the same on each changeset, I had some different specific comments on each one, so make sure to carefully read all of them just in case you haven't already.

Happy mapping!

Great! And it wasn't actually tagged as anything either (missing a top-level tag osm.wiki/Top-level_tag ) so it needed some cleanup in any case.

There are a couple parking stalls around each one, yeah, but of course a few parking stalls does not a parking_aisle make; the primary or sole purpose of the way must be to access those stalls, whereas it seems to me that the primary purpose of these ways are first and foremost to provide access to the loading bays, with parking access a secondary function (which can mostly also be accessed from the main service way in any case).

Yeah, I normally never remove something mapped, assuming it actually exists. This is arguably a bit of an exceptional case, as only one (half of) one unexceptional, poorly delineated way was mapped out of dozens of identical adjacent ones, which is rather confusing to consumers of the map as they would expect that way to be distinct in some way. I would probably have used the JOSM parallel way tool to quickly add all of them rather than completely removing it, but I am also not sure I'd have personally gone to the effort of manually adding it back if someone else removed it as part of cleanups, unless I was ready to add all of them.

See also: https://community.openstreetmap.org/t/do-you-map-loading-dock-lanes/145691

Udar is definitely correct about the gate and the name=*; it isn't clear the former change is in dispute and for more detail about how to name=* things on OSM, see osm.wiki/Names

As for:

> Also unit numbers were out of place and 47th Street was in the wrong place.

> What for you mean by “ 47th Street was in the wrong place”?

Looking at the changeset deltas, the change @HiddenMapper is referring to is renaming the former NW 47th St way/11143991 to 48th St and the service road here to 47th St way/572728724 . Udar wasn't questioning that change itself, but rather how it was tagged incorrectly in name=*. I am curious, though, what source you've based on that change on.

As for the part of way way/572728726 , recreated by Udar as way/1546659626 between NW 47th St and the warehouse bays, I'm actually at least neutral on the change here, and wouldn't have added it back personally. There are numerous vaguely-defined ways you could in theory potentially draw between the NW 47th St and the warehouse bays, but unless you're going to add all of them (or at least apply some consistent standard as to what to map), like the warehouses to the north just south of 50th St, I wouldn't object to just removing that one single way for now as was done in this changeset, particularly with how the geometry was prior to @HiddenMapper 's change which didn't really make any sense, since it is potentially confusing why that one way is special on the map but not at all on the ground.

Yeah, that's what I figured--it's easy to miss sometimes if its in the changeset source=*, especially on platforms like OSMCha where you need to click-click-click to see that. Thanks!

To make up for my initial misjudgement, I decided to restore it and fixing the various issues for you instead, in changeset:

changeset/186783261