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

Thanks

Thanks.

Hi PowerMapper,

Thanks for the updates! power=* mapping is one of the areas I don't really touch, so it's helpful to have a dedicated expert take a look!

Just one request--for your future changesets, it would be great if you could add a little more detail/explanation to your changeset comments, about what you changed, how and why. For example, "Upgraded minor line to high-voltage per [SOURCE]" (or specifying a changeset source=*). See osm.wiki/Good_changeset_comments for more info on that.

Thanks, and happy mapping!
---

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

Oh, I thought you were answering the first question (about your use of the normally prohibited Google Maps as a source), since they were presumptive derived from that source and my second question didn't mention anything related to those tags, but rather why it was missing a lifecycle prefix (and implicitly, why it rather had the idiosyncratic and nearly unused opening_hours=24/7%20closed ).

Hi Kaarlim, could you explain what you were trying to do with this changeset?

It looks like you took a road from the US, moved it to Senegal and turned it in to some sort of representation of a administrative boundary (but missing any appropriate tags that would define it as such). Needless to say, this doesn't seem to make any sense to me or the several other mappers who reviewed it, so we were hoping you could let us know what you actually intended here so we could advise you appropriately.

Thanks, and happy mapping.

Okay, so could you please link to where specifically the wiki says that? I.e. your source=* ;)

As mentioned, I was referring to the website=*, not the name, at least per what you stated in the changeset source tag. It should be easy to independently find that URL without (at least directly) relying on Google Maps as a source, which is proprietary and of course prohibited per OSM policy osm.wiki/Google

Sorry, but I'm not following how any of that is supposed to justify using an explicitly prohibited source. By contrast, Google being the _only_ source for the name makes all the risks and problems of copying it from them much more severe, both the legal risks (it becomes a de-facto "Copyright Easter Egg") and offers unclear value as its just whatever Google's AI thinks/assumes it should be; you could make that same judgement yourself (I would) in a blackbox without it.