Reported as https://github.com/streetcomplete/StreetComplete/issues/6944

Hey Frank!

Seems like StreetComplete made a mistake here for some reason, incorrectly issuing a quest here when both sidewalk=no and sidewalk:both=no were already correctly tagged and doing nothing but removing the valid sidewalk:both=no tag I added. I'll be reporting this as a bug to their GitHub, and I've reverted it in changeset/185968865.

changeset/185968865

BTW, still in the process of getting to formally reviewing and fixing a couple small issues with your recent Givens Lane changesets as part of a basic pass in the area; hope to finish that in the next few days.

(Typo correction--I mean the building=roof could be tagged with layer=1 , not layer=-1)

Hi HingleMcCringle,

Thanks for your contribution--this is definitely a big improvement to the mapping and detailing in for this assisted living complex!

After reviewing the changeset, I've got a few tips and bits of feedback. I've already implemented all of them in changeset/185966133 , plus a handful of other tweaks and enhancements, but I figured I'd share them here for the benefit of your future mapping!

changeset/185966133

Here's the points I have to share:

- The (entire) service way that goes under the covered roof at the entrance was tagged level=-1, which would actually mean it was an underground tunnel. Instead, there are two main methods to actually handle this correctly: the part of the building that is just the roof could be split as a building=roof with layer=-1, and/or the road passing underneath it can be split where it enters and exits the roof area (with the split nodes shared between the road way and the building way) and that portion only of the road tagged covered=yes. I ended up doing a combination of both in my changeset. See building=roof for more details
- The service way around the building is actually not a service=parking_aisle; it's a common mistake but parking aisles are not intended to be used for a way that provides through access like this one, but rather individual aisles in a larger parking lot (see, for example, how the service ways in the Gucci Kroger parking lot north of here are tagged). More details: service=parking_aisle
- There were a fair few extra nodes on that service way and it wasn't quite streight--straight ways should be kept straight, without extra nodes in between, see osm.wiki/Good_practice#Keep_straight_ways_straight
- Likewise, the right parking lot particularly and parts of the left were not quite square, despite being so in real life--you can use the "square" feature in your editor to align the parking lots to right angles, where they are in fact square (or nearly so)
- Also, while not strictly required its a really idea to tag at least parking=* and access=* on amenity=parking ways, as they can represent a bunch of different things (parking lots, parking structures, street parking, underground garages, etc) and consumers need to know who can park there in order to be useful in most cases. See parking=*
- Also not required, but its a good idea to add a specific building=* tag (at least as specific as you reasonably can), to classify what type of building it is. See building=*
- Finally, note the standard formatting for phone=* in the US/NANP is +1-NNN-NNN-NNNN; a bot should come around and fix most cases automatically, but figured I'd mention it as its simpler to get it right from the get go. See phone=*#United_States

Thanks, and happy mapping!

Hi Akshay,

Thanks for your prompt and comprehensive response, and reviewing my changeset.

I realized I actually forgot to mention the one other potential issue I noticed with this changeset, specifically that it removes the start_date=2025 tag from the the existing service way it modified without explanation, despite the fact that it appears based on the road's lack of existence in 2023, being under construction in 2024 and appearance on imagery after that date and before the present that it was presumably opened then. This is also a key signal to other mappers that the roadways are valid, despite not appearing on aerial or street-level imagery, and avoid them removing the roads you added. Do you have information to suggest that this tag was incorrect, or shall I add it back?

> Regarding the missing surface and noexit=yes tags: we usually don't add these tags during editing unless there's an exceptional case.

Yeah, that's in general perfectly fine as you are by no means required to add any specific tag (beyond at least a top-level tag); the reason I raised it here was because it as you mentioned updated existing geometry that at least in part replaced existing service ways rather than creating entirely new service ways where none existed before, thus leading to some loss of detail.

> For nodes 13540242324 and 8427127744, I adjusted the intersection based on the alignment visible in the newer imagery to improve its accuracy and better reflect the access geometry. However, I agree that the shift is subtle and may not have been significant enough.

I want to clarify that I have no particular reason to believe the shift of these two nodes to the south southwest lengthwise along S Main St is not correct, and didn't mean to imply that, sorry. The potential issues here was:

* the ~1 m shift of the sidewalk to the west northwest inward toward South Main, which seems very unlikely and without clear motivation, and is rather most likely due to either imprecise positioning, an accidental drag or an offset issue with the imagery you are using as I've registered the Bing imagery to within ~25 cm or less of the actual position using a large number of GPS traces and observations around the immediate area; and

* The other service way being dragged south along with this one, as given the substantial offset traffic cannot legally cross directly to the other without first making a legal right turn on to South Main Street and then a left turn onto the street. (Arguably, they shouldn't have been connected in the first place, which may have been my mistake).

Thanks!

Gotcha, thanks for updating it further!

BTW, I meant to mention it before, but I noticed you linking Google Maps in the changeset comment--just a reminder that both Google and OSM policy prohibit using Google Maps as a source to contribute to OpenStreetMap, see osm.wiki/Google , and would normally require complete removal of any affected changeset. As the changeset source=* is listed as survey and local knowledge without any mention of Google, I didn't take any action on that but just wanted to make sure you were aware.

Thanks, and happy mapping!

Hi Akshay,

Thank you for updating this area with imagery newer than is available publicly to OSM mappers. However, it did introduce a couple issues:

- You replaced the existing ways with ones that lack the same descriptive tagging as the originals, including surface=* and, where applicable, service=*.
- Additionally you removed and did not replace the noexit=yes tags on the terminating nodes, so it is not entirely clear (especially lacking the imagery you used) if the unconnected service way ends actually terminate or continue/connect to pedestrian infrastructure.
- node/13540242324 , the intersection between the service way and the sidewalk, was shifted 1 m to the WNW of where it appears the sidewalk should be at that location (based on imagery and GPS traces) without clear justification.
- Furthermore, node/8427127744 , the intersection between the two service ways and North Main St, was moved 4 m SSW to match the new position of the service way, dragging the other service way with it despite the fact that they no longer intersect that the same junction.

I fixed all these issues to the extent I am able to without the imagery in changeset/185689414, but I would appreciate your response on each of these areas and your feedback as to whether my changes are correct based on your imagery or further adjustment is needed. Thanks.

changeset/185689414

Hey Jake, thanks! I'd barely touched this area so far, so it really needed the love.

Just FYI, your work here inspired me to follow this up with some small changes in changeset/185685933 , to add a separate sidewalk plus crossings and links along the southern bit of Grissom Lane and updated the road tags accordingly, as well as added sidewalk tags to the the couple remaining streets in the area that didn't yet have them.

changeset/185685933

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

Gotcha. Yeah, at least talking with Frank Peng, the other main active local mapper who's been around a while, he also determines Bing to be aligned closest to ground truth and so we and others align on that at least in terms of overall offset (though once the bulk offset, VBMP can sometimes be more accurate than Bing in areas of sharp elevation change or things like overpasses that Bing can have more issues with).

While GPS tracks don't lend themselves to sub-meter precision on their own, a careful comparison of them with Bing and VBMP at a number of high-traffic locations suggests the former is close to 0 offset to +/- 0.25 m, at least at high zoom (whereas the former is visibly off, over a meter from Bing).

The old Blacksburg GIS layers that were imported back in early 2010 appear to either be aligned with VBMP, or have at least appear to have a common offset with it (due to coordinate transformation or another issue). However, the latest Blacksburg GIS layers I've pulled in from their open data portal, e.g. "Paths to the Future -> Existing", appear to match almost perfectly (to at least <=0.2 m and likely <=0.1 m) with Bing imagery and VBMP offset to Bing imagery, whereas they have the consistent ~1 m offset from VBMP imagery.

So, at least as far as the available evidence I've reviewed (and it seems Frank as well), alignment to Bing is the closest we have to ground truth, at least down to the decimieter precision that's generally useful for OSM.

I'm fairly confident in the offset mentioned above (-0.65; 1.00) to around ~0.2 m in each direction least for central and northern Blacksburg; optimal offset can vary a bit by up to 0.3 m/0.15 m in each respective dimension within the Blacksburg city limits, though still not by nearly as much as VBMP's mean offset from Bing and other sources--e.g. I've found -0.95; 1.15 is a closer match near Hethwood on the western edge of town.

Hope that's helpful!

Hey Jake! Just a tip that I'd been meaning to give you after when you so exquisitely micromapped the newer apartment developments out west on Price's Fork, but didn't get the chance to.

Specifically, especially if you're micromapping features on the scale of meters, it is particularly helpful to offset your imagery before mapping as otherwise everything will be substantially off. It seems you're using VBMP (consistent with your previous mapping) but without an offset; its off by over a meter from Bing which in turn closely matches GPS tracks and is known to be pretty well-registered at least at higher zoom levels (although the orthorectification can be not good as VBMP in areas with significant elevation differences). It also makes it much easier to cross-check between Bing (higher resolution) and VBMP (less tree cover) which I find invaluable when mapping and am constantly doing.

It's really easy to permanently fix this in JOSM as you can just dial in the offset once and it will be saved forever (at least within the same saved session; I haven't created one from scratch since nearly the beginning so can't say for sure about that). The approx offset to use for VBMP around here is -0.65; 0.99 ; it varies slightly in Blacksburg's outskirts but is pretty close, and if needed JOSM lets you save different offsets and switch between them with a click.

In this case, its pretty easy to align your mapping here by just selecting everything you changed and moving it to the correct offset. Unfortunately its far trickier to do for your detailed parking areas in the two western developments as you've also mapped kerbs and footways in detail, which in turn connect to buildings and other (properly-aligned) footways, so I haven't fixed it there (at least not yet) given the huge effort involved (and the misalignment there appears to be greater, by as much as half a parking space). Needless to say, spending a minute dialing the correct offset once can save an enormous amount of time and effort fixing things later or else negating much of the benefit of the also-considerable effort you've put it micromap everything :)

BTW, just for fun, here's a before and after comparison of Blacksburg before I started mapping in May 2024 vs. ~now that I created with Ian's amazing new Before and After web app, where you can also see your mapping of e.g. the various apartment complexes out west on Price's Fork https://beforeafter.mapki.com/jobs/885a7b97-6280-420d-9c87-0a85a87fa7d6 You can actually use it to create timelapses with a bunch of frames as well to see how mapping has progressed over time.

Gotcha, thanks! Yeah, you'd really think we'd have some more progress solving this by now. After discussing it with Minh on Slack I ended up on [this OSM forum thread](https://community.openstreetmap.org/t/secondary-address-unit-designators/136660/) where the discussion on how to handle this has evolved considerably since then, and chimed in there--I encourage you to do so as well given this issue also matters to you!

You've got me very curious--where'd you find addr:unit:label=*? I don't see any documentation of it on the wiki, and the only non-trivial usage appears to be from a few VA/WV county address imports in 2023-2024 (e.g. osm.wiki/Lynchburg_VA_Area_Import ) where Minh suggested it in https://community.openstreetmap.org/t/proposed-import-of-rockbrige-county-va-address-points/102594/45 .

I definitely agree that something should be done about the current situation wrt that which is less than ideal, curious if there's been any followup movement after that. I asked Minh as well if he has any followup thoughts; feel free to join us there https://osmus.slack.com/archives/CA9RX1PPS/p1783363442218879

Thanks!
---

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

Thanks for the revert on this one!

Okay, gotcha!

BTW, you're welcome to join the OSM-US Slack https://openstreetmap.us/get-involved/slack/ we have a NRV channel there (albeit not too active at the moment) in addition to loads of different channels for different topics of interest that you can join, or not! It's also a convenient place to get the handful of local mappers together to discuss and get consensus on community-wide questions/changes, of which a couple have been proposed lately (e.g. directionals in streets/addresses, consistant tagging for VT footways, etc).

Happy mapping!

Thanks! I just finished aligning and tagging Broce and its sidewalks/crossings to the east of this, so this mostly completes the rest of it (modulo a handful of additional tags). Are you planning on working more in the area between UCB and TCR? Was planning to do a comprehensive pass at some point in the near future, but don't want to interfere with your work!
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/184981284

Thanks! Was looking forward to when this would be completed.
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/184820385

Thanks Irina! Sorry if I came across a little overly harsh above, and I appreciate you taking my feedback in stride.

Your opening_hours=* format is _close_ to being valid at this point; the only remaining error here is using a three-letter rather than two-letter weekday abbreviation--weekday abbreviations must always be the two letter form. Not sure about iD, but Osmose https://osmose.openstreetmap.fr/en/map/#item=3250&zoom=17&lat=29.6993958&lon=-95.3995276&issue_uuid=9781a3fb-e31d-9171-0388-678dbdcd8bef&loc=17/29.699396/-95.399528&level=1 , the Opening Hours editor https://openingh.ypid.de/?zoom=18&lat=29.699396&lon=-95.399528&layers=B0T&filter=none&tags=opening_hours and JOSM's validator will all warn you about this and even offer to fix it automatically in most cases (at least for syntax like this that is close to being valid).

Great, thanks! Make sure to disclose and link to the other account in the bio of each, in the interests of transparency and to avoid any chance of it being perceived as sockpuppetry or evasion. No need to replicate all of it, but you can see what I've done for my alt accounts, for example.

Cheers, and happy mapping!

Thanks, I was hoping someone would come along and update this!

Since you confirmed it was still a car wash, I mapped the building_passage way through the building as well as updated the operator=* of the parking area (that had been left as the old name) in changeset/184723074

changeset/184723074
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/184706113

Reverted adding SEO spam POI with blatant advertising and misleading, malformed and nonsensical tags/values--for example, its an AI company inexplicably tagged as a shop=supermarket (which SEO spammers seem to love to do for some reason, presumably SEO-related), in changeset
changeset/184692113

changeset/184692113