Yeah, I use OsmAnd but not for mapping--I mostly stick to SCEE on mobile and do anything more non-trivially complex in JOSM at my workstation.

Awesome, glad its just like old times! I bought probably my favorite lens, "Fitty" my Yashica 50/1.7 PL from there--not as big and flashy as "Pearl", my 70-200/2.8L IS, but it sure produced some lovely shots. Would have mapped it myself, but I wasn't sure it was still there.

I was partway through a comprehensive pass around campus, but got sidetracked doing other parts of Blacksburg instead and ended up finishing most of the town before I finally got back to it very recently and started working through the rest.

Cheers!

Hey Caleb, welcome to OSM!

I'm glad to see John's is still in business--it was one of my favorite spots in town when I was there; I used to hang out there for many hours back when I was at VT (Meteorology BS/Geography BA '17), chatting with John & co and browsing and buying old glass and other gear.

Just FYI, I fixed a few tags (name=*, addr:street=*) and added the remaining address ones in changeset/190430529 .

Happy mapping!

I've strongly suspected as well, but the evidence was just circumstantial enough that I haven't been able to prove a formal DWG case. However, at the very least there is strong evidence they are a sock of the perma-blocked @TheAutoAidEditor given the nearly identical pattern involved (whom I also strongly suspected is an AK sock), but while I compiled substantial evidence the DWG member reviewing it did not consider it compelling enough to act accordingly.

Thanks!

Just FYI, though, I see operator:wikipedia=* wasn't updated to match operator=* and operator:wikidata=*; since there isn't a Wikipedia page specific to VT Libraries, should it just be removed?

> Bring the conversation here, or invite me to the slack.

NB, just a sidenote--the Slack @cubbe8 is presumably referring to is the official OSM-US one, which you can join through https://openstreetmap.us/get-involved/slack/ , and the thread in question is presumably https://osmus.slack.com/archives/CCJ2P6KCH/p1788585496676919

Ended up fixing this in changeset/188553417

changeset/188553417

Cheers!

So actually, it later turned out that I was mistaken here and interpreted the wiki page incorrectly--it actually was intended to imply that all way stops _can_ be mapped on the junction node, not that they _must_ or even _should_ be. Rather, it mentions it adds more detail to map them separately, and that makes them consistent with how other stops are mapped as well as their stop lines.

I went back and fixed the rest of them over the areas I already mapped (essentially all but this one) in changeset/187469597 , and I will be doing a full pass over the UCB area as one of my next priorities after completing the last bits of my current Blacksburg baseline pass (just fixing errors, issues, etc) and finally doing a full pass over the rest of campus. However, feel free to change this earlier, if you like.

changeset/187469597

Sorry about that, and happy mapping!

Hi rittoch, thanks for your contribution. However, there are a few significant issues here:

By de-facto local convention, the directional suffix isn't currently in any of the Blacksburg street name=* s nor addr:street=* (except for Turner St, for historical reasons) although my understanding is that is due to them being derived from the Town of Blacksburg GIS data circa 2010 that forms the basis for the OSM data in the area that didn't consistently include them--not TIGER 2008. I agree it should be added it, but rather than a piecemeal effort like this for one part of a single street, this should be done consistently and holistically everywhere it applies (possibly with a semi-automated process). And this in turn would entail a discussion and consensus in the local community as required by OSM principles, to ensure everyone is on the same page, which I've been planning to propose and execute following the completion of my current error cleanup pass.

Furthermore, this change as implemented introduces a significant regression: it changes the name of the street way while not also updating the `addr:street` of the addresses along it, leading to the latter not matching the former creating a significant data inconsistency and a number of Osmose, OSMI and Nominatum validator errors.

Also, it only adds the SW directional to the portion of Washington St west of Main St, without adding the corresponding SE directional east of it.

For now, the easiest and most consistent fix I'd suggest is just reverting the change for now (which I can do for you, if you'd like). Alternatively, if you really want to make this change now rather than waiting for community discussion/consensus and consistent application Town-wide, you'll need to update all the various addr:street=* s that refer to Washington Street to include the correct directional (a straightforward task using a full-featured editor like JOSM, but rather tedious and error prone to do using iD as you are), and be consistent about renaming the eastern half of Washington St as well.

Looking forward to hearing from you, and happy to answer any further questions you might have and assist you in remediating this!

Thanks, and happy mapping.

BTW, OSM forum discussion thread for this change: https://community.openstreetmap.org/t/lake-ontario-lake-america/146975

Thanks!

It seems the GNIS update was already pushed through per the above; my understanding was that it normally needs to go before the Board of Geographic Names and various procedural steps before it becomes official, but then again the current administration hasn't been one for following established procedure and due process...

In any case, per a [discussion in the OSM-US Slack](https://osmus.slack.com/archives/CCJ2P6KCH/p1787853493613639) and a request from a forum admin, I created a OSM Forum thread for this change: https://community.openstreetmap.org/t/lake-ontario-lake-america/146975

Community discussion thread for this change: https://community.openstreetmap.org/t/lake-ontario-lake-america/146975

I see nobody commented on changeset/188110442 yet to notify them of the revert and the reasons for it as is standard practice (nor was it originally referenced here), so I did so.

changeset/188110442

I also pinged the DWG to give them a heads up about this, as it is likely to be a reoccurring problem.

Although I am seeing https://edits.nationalmap.gov/apps/gaz-domestic/public/gaz-record/970427 updated when I checked again just now? I seemed to remember it took much more time for the Gulf of Mexico and had to go through a whole process first.

As far as I'm aware, the official name hasn't been updated yet in GNIS, the official register of names by the US government and the source of official_name:en-US=* . Therefore, it is premature to change this, which I assume is what @Shrinks99 is referring to. See the Gulf of Mexico discussion where the same standard was applied: https://community.openstreetmap.org/t/gulf-of-america-gulf-of-mexico/124571/5

Thanks for looking into it. Interestingly, way/112628723 (same number as this node) is actually in France, but in a small town near Boulonge-Sur-Mer rather than in Paris as this node's tags would imply (and there is no relation of that number).

way/112628723

SEO spam, advertising and mistagging by commercial mappers is strictly prohibited on OpenStreetMap and is subject to immediate removal and possible further consequences for your account. Please see osm.wiki/About_OpenStreetMap_for_SEO_mappers for more information.

Reverted adding SEO spam taqs with blatant advertising and malformed values in changeset:

changeset/187918303

Of course! And thanks again for your work here!

Sure thing, happy to help out! And thanks again for the update!

Hi, thanks for updating this!

I resolved the note you created for this, note/5468682 , since you added the details here.

Just FYI, the standard phone number format for NANP regions, including the US, is +1-NNN-NNN-NNNN (with +1 NNN-NNN-NNNN and the international +1 NNN NNN NNNN also being sometimes seen), see phone=*#United_States Also, it seems you accidentally used a `_` instead of a `;` between `italian` and `pizza` in cuisine=* I fixed both for you in changeset

changeset/187814874

Thanks, and happy mapping!

I also commented and resolved the note you created for this: note/5468678