Per the request of Citrula on the OSM-US Slack, reverted/repaired mistagging of the entire private road as a barrier=gate instead of setting access=private and adding/tagging the individual gate nodes with such in changeset/181388287

changeset/181388287

Per the request of Citrula on the OSM-US Slack, reverted/repaired mistagging of the entire service road as a barrier=fence just because it is sometimes blocked by one, and instead added the helpful changeset comment here to the parking area to assist future mappers in changeset/181388031

changeset/181388031

Per the request of Citrula on the OSM-US Slack, reverted/repaired mistagging of the entire private road as a barrier=gate instead of setting access=private and instead adding the individual gate node with a note=* set to the helpful changeset comment provided here, in changeset/181387857

changeset/181387857

Per the request of Citrula on the OSM-US Slack, reverted/repaired mistagging of the entire private road as a barrier=gate instead of setting access=private and tagging the individual gate nodes with such in changeset/181387495

changeset/181387495

Per the request of Citrula on the OSM-US Slack, reverted/repaired mistagging of the entire private road as a barrier=gate instead of setting access=private and tagging the individual gate nodes with such in changeset/181387495

changeset/181387495

If this is a service way for private usage as stated, then this should be tagged as such with access=private (and the gate tagged as a node at the appropriate spot if desired), rather than as a ~100 m long barrier=gate (with no explicit access restrictions).

Hey B2B, thanks for the followup (and cool name, BTW)!

As a former Blacksburg resident (VT alumnus) myself for whom my bike was my primary means of transportation around town and campus (I didn't own a car till years later), I appreciate the enthusiasm!

Thanks for the explanation--I was rather perplexed when reading this changeset's comment, as while accidental node drags are not uncommon especially by newer mappers, I didn't see any actual intentional changes in the changeset--the node drag was the only OSM change here.

Based what I'm able to gather from you and other "Bike Streets" mappers with similarly puzzling changeset comments, I'm inferring that the actual intentional changes you are making to establish these routes you're referring to are only being reflected in Bike Streets' own proprietary data via its internal editor, with only certain relevant bits and pieces being applied upstream to the OSM data. Therefore, while the changeset comment makes sense in the context of the change you are making to that proprietary dataset, it reads as rather confusing to other mappers in the context of just the open OSM data actually being contributed back. At least IMO I don't think this overall approach is _inherently_ flawed, but ISTM that _something_ should be done to avoid this confusion and clarify the situation, not 100% sure what yet.

In any case, I went ahead and executed the revert of the node drag in changeset/181347840 changeset/181347840 ; it should presumably leave whatever intentional changes you made in Bike Streets' proprietary data intact. It's all good now as far as this particular case is concerned, but hopefully one of us can follow up with regards to the broader issue to help reduce future mapper confusion in these sorts of situations. Thanks!

Hi Molly, thanks for the fast and considerate response! I'm really sorry if I gave you the impression you did something wrong; to clarify again while the the two access tags you added in your changeset are already de-facto implied by highway=cycleway , there's certainly nothing wrong with adding them explicitly (in fact, I would encourage it!) so not to worry! As such, there's no need to revert your changeset (changes and the changes they introduce cannot under normal circumstances be deleted, but much like with Git they can be reverted, either manually or with semi-automated tools).

The main reason I reached out was because I was a bit confused by your changeset comment, which implied multi-use path was being added to the map when it already existed and was tagged as such, and wanted to help clear up any misunderstanding. Based on your helpful clarification above, Bike Streets should presumably already recognize a highway=cycleway as being accessible to bikes (by definition), and also to pedestrian traffic given `foot=yes` is tagged; if not, seems like a bug that could hopefully be easily fixed.

Furthermore, I don't think you're ultimately responsible for this confusion--it seems there may be something with Bike Streets' custom private deployment of the iD OSM editor, or else something common to your organization, that is causing similar confusion as another Bike Streets mapper submitted a changeset around the same time as you where not only did the changes not match the changeset comment (much more so than you), but in fact the only change was what appeared to be an accidental node drag of an address point which (unlike your changes) appears to be a clear mistake. So no worries, you're good!

Happy to help clarify further or answer any followup questions I can--feel free to reach out further here or via OSM direct message. Cheers!

Hi Molly, and welcome to OpenStreetMap!

I was a bit confused by your changeset comment, so I wanted to reach out to confirm your intent here. It implies a multiuse path was added, but one already existed--the only change made here was adding the access tags bicycle=yes and motor_vehicle=no , which are already implicit for a highway=cycleway in the US, see osm.wiki/OSM_tags_for_routing/Access_restrictions#United_States_of_America . There's nothing _wrong_ with adding them explicitly per say (in fact, I personally generally encourage explicitness over implicitness when practicable), but I just wanted to make sure to touch base, clear up any misunderstandings and ensure we are on the same page here.

Also, just a heads up--as you appear to be part of the [Bike Streets organized editing activity](osm.wiki/Organised_Editing/Activities/Bike_Streets), per the [OSM Organized Editing Policy](https://osmfoundation.org/wiki/Organised_Editing_Guidelines) please make sure you are familiar with the latter, disclose that fact on your user profile and link to the former wiki page, and include a unique hashtag and the same link on your changesets, among other requirements. Your organizer should also make sure you are familiar with local and OSM community consensus, mapping practices and guidelines; I encourage you to reach out to them as well if you aren't sure about anything.

Thanks, and happy mapping!

Hi Between2Burgs, and welcome to OpenStreetMap!

Could you help us understand what you were trying to achieve in this changeset? The changeset comment refers to a bike route and "marking" (not sure how?) alleyways parallel to N Main. However, the only change in this changeset is what appears to be an accidental node drag of the Unit 2 address for 619 Progress St around 25 m to the NW. I'm happy to go ahead and revert that for you, but I wanted to reach out first to see if you could help me understand what you actually intended to do here, so I could help you understand how to achieve it.

Also, just a heads up--as you appear to be part of the [Bike Streets organized editing activity](osm.wiki/Organised_Editing/Activities/Bike_Streets), per the [OSM Organized Editing Policy](https://osmfoundation.org/wiki/Organised_Editing_Guidelines) please make sure you are familiar with the latter, disclose that fact on your user profile and link to the former wiki page, and include a unique hashtag and the same link on your changesets, among other requirements. Your organizer should also make sure you are familiar with local and OSM community consensus, mapping practices and guidelines; I encourage you to reach out to them as well if you aren't sure about anything.

Thanks, and happy mapping!

Yup, that's a good point--I've definitely seen it used much more broadly than intended. I have tentative plans to address it in a landuse=* pass over the area at some point, but if you get to it before then by all means for go it!

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

Ahh, I see. Thanks for checking!

landuse=farmland is specifically for growing food crops as mentioned on that page, while landuse=meadow (mentioned above) would be more appropriate for managed grassland for agricultural use, such as hay ( meadow=agricultural ), livestock ( meadow=pasture ), horses ( meadow=paddock ), etc. It would seem based on your assessment of it being managed, landcover=grass and being used for hay that it should be landuse=meadow meadow=agriculture , rather than landuse=farmland , no?
---

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

Does this niche travel agency really occupy the entirety of this four storey building, such that the entire building is named after it?

NB, way/1493791589 way/1493791589 doesn't seem to fit the definition of landuse=grass landuse=grass , which is intended for (typically smaller) areas of mown, managed grass like a lawn or verge.

The plant cover here looks more or less natural rather than carefully managed, which would be landuse=heath or landuse=grassland , or possibly landuse=meadow if it is used for agriculture, rather than landuse=grass.
---

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

Frank mentioned it, but just to emphasize--in addition to selecting and using the most appropriate imagery source(s) for an area when mapping, it is also critical to use GPS tracks and reference features in multiple imagery layers to set the correct imagery offset, especially with fine-scale mapping and performing alignment of features like this. This is especially true with VBMP as it has a significant (>1 m) and somewhat varying offset over the Blacksburg area (whereas Bing, orthorectified or not, typically hews close to GPS traces for features at ground level). This unfortunately affects many if not most existing features in the Blacksburg area, including mapping performing recent, very detailed micromapping of things like individual parking spots that are most affected by a lack of offset. Spending just one minute to get the offset dialed in before mapping in a new area can save other mappers hours, sometimes days later of fixing the alignment on everything you map.

Hi, in changeset/180388256 changeset/180388256 , I reverted the beach way boundary change for now, as it inexplicably expanded the small, appropriately mapped pebble beach you'd added previously to cover almost the entire water surface of the lower Virginia Tech Duck Pond and some area around it with said beach, while also giving said "beach" the name "Duck pond[sic]" (which is instead a water feature, already mapped in detail). By contrast, from your changeset comment what you apparently intended to do was fix the water area way boundary near the beach to be less inland, which indeed appears quite warranted given current imagery as well as your previous mapping, but which was not in fact done as the Duck Pond natural=water outer way was essentially untouched. Accordingly, I went ahead and made that change for you as you apparently intended in the changeset above, as well as refined the outer way in a few other spots. Let me know if you have any questions or further feedback on this. Thanks!

Hey Frank, just FYI per both the wiki and recent discussions and consensus with the OSM-US Pedestrian Working Group and PWG schema, since you already mapped separate kerb notes (great!) no need to tag kerb=* on the highway=crossing node when the kerbs are already tagged separately, and in fact that is actively discouraged, e.g. per the wiki kerb=*#To_add_information_to_another_map_feature

> If you place separate barrier=kerb nodes, please remove the kerb=* tag from [the crossing] node (otherwise a router might think that there are four kerbs to cross).

Also, just FYI I recommend tagging crossing:signals=* as well (no in these cases), as it is unambiguous and more clear and expressive then relying on the overloaded and somewhat ambiguous crossing=* tag, and it also is the only thing missing for your mapping here to get this area fully up to PWG Silver Tier osm.wiki/Foundation/Local_Chapters/United_States/Pedestrian_Working_Group/Schema

Hi Jon, thanks for requesting a review and leaving a detailed, helpful changeset comment!

it looks like this changeset entirely deleted the driveway and its nodes, instead of splitting the way and tagging it appropriately, as you've properly done in your other changesets. Therefore, I've restored it and tagged it appropriate in changeset/180037317 : changeset/180037317

See the wiki for some more background on why this is avoided on OSM: osm.wiki/Why_we_won%27t_delete_roads_on_private_property

Thanks, and happy mapping!

Maybe should be scrubbed entirely given the stated source of Google Maps, per OSM policy?